Adrien Lemoine
2009-Dec-17 17:47 UTC
[asterisk-users] Integrate a CPE with Asterisk in MGCP
Hello all, I'm looking for some help to try to understand why my CPE doesn't work good with Asterisk in MGCP. Here is what I want to do : - Register a TECOM AH4021 on Asterisk in MGCP with the following profile in mgcp.Conf : [general] port = 2727 bindaddr = 10.95.20.1 disallow=all allow=g729 allow=alaw 020202020202] context=mgcp host=dynamic canreinvite=no dtmfmode=rfc2833 nat=yes threewaycalling=yes transfer=yes ; transfer requires threewaycalling=yes. Use FLASH to transfer callwaiting=yes ; this might be a cause of trouble for ip10s cancallforward=yes line=aaln/1 - Place outgoing calls through a SIP PROXY : OK, but the call goes down after some seconds : -- Executing Answer("MGCP/aaln/1 at 020202020202-1", "") in new stack -- MGCP mgcp_answer(MGCP/aaln/1 at 020202020202-1) on aaln/1 at 020202020202-1 -- Executing Dial("MGCP/aaln/1 at 020202020202-1", "SIP/mgcp-out/0xxxxxxxx") in new stack -- Called mgcp-out/0xxxxxxxxxx Dec 17 18:34:47 NOTICE[17889]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist -- SIP/mgcp-out-09d998c0 is making progress passing it to MGCP/aaln/1 at 020202020202-1 Dec 17 18:34:48 WARNING[17932]: chan_mgcp.c:1375 mgcp_indicate: Don't know how to indicate condition 14 -- SIP/mgcp-out-09d998c0 answered MGCP/aaln/1 at 020202020202-1 -- Attempting native bridge of MGCP/aaln/1 at 020202020202-1 and SIP/mgcp-out-09d998c0 -- Resetting interface aaln/1 at 020202020202 == Spawn extension (mgcp, 0141909872, 2) exited non-zero on 'MGCP/aaln/1 at 020202020202-1' -- MGCP handle_request(aaln/1 at 020202020202-1) ast_channel already destroyed, resending DLCX. -- MGCP handle_request(aaln/1 at 020202020202) set vmwi(-) - Receive incoming calls through SIP PROXY : OK too, but as with the outgoing calls, the interface seems to self restart : -- Executing Dial("SIP/XXXSIPCALLID", "MGCP/aaln/1 at 020202020202") in new stack -- MGCP mgcp_request(aaln/1 at 020202020202) -- MGCP cw: -1, dnd: 0, so: 0, sno: 0 -- MGCP mgcp_new(MGCP/aaln/1 at 020202020202-1) created in state: Down -- Called aaln/1 at 020202020202 -- MGCP/aaln/1 at 020202020202-1 is ringing -- MGCP/aaln/1 at 020202020202-1 answered SIP/XXXSIPCALLID -- Attempting native bridge of SIP/XXXSIPCALLID and MGCP/aaln/1 at 020202020202-1 Dec 17 18:38:33 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Dec 17 18:38:34 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Dec 17 18:38:35 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Dec 17 18:38:36 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Dec 17 18:38:38 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Dec 17 18:38:41 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Dec 17 18:38:44 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Dec 17 18:38:47 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist -- Resetting interface aaln/1 at 020202020202 == Spawn extension (frommgcp, 0973009997, 1) exited non-zero on 'SIP/87.237.184.116-087f4fb0' -- MGCP handle_request(aaln/1 at 020202020202-1) ast_channel already destroyed, resending DLCX. -- MGCP handle_request(aaln/1 at 020202020202) set vmwi(-) I don't succeed in using g729 for incoming calls whereas its works with outgoing calls. So the incoming calls negociate in ulaw only and the callee side doesn't ear the caller.... I review my ip routes, it's okay because I see the RTP in both way by running ethereal. I don't see what is the problem. So ideally, Asterisk will be able to drive the codec negociation for incoming calls, but I don't know how that is possible. Asterisk 1.2.35 runs under Redhat Enterprise 4 To conclude, I don't understand the following logs : chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Thanks for your attention. -- Adrien
Adrien Lemoine
2009-Dec-21 14:18 UTC
[asterisk-users] Integrate a CPE with Asterisk in MGCP
Hello, Nobody has any feedback on the MGCP? And especially on the symptoms described in my previous emai ? Thanks. Regards, Adrien -----Message d'origine----- De?: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] De la part de Adrien Lemoine Envoy??: jeudi 17 d?cembre 2009 18:48 ??: asterisk-users at lists.digium.com Objet?: [asterisk-users] Integrate a CPE with Asterisk in MGCP Hello all, I'm looking for some help to try to understand why my CPE doesn't work good with Asterisk in MGCP. Here is what I want to do : - Register a TECOM AH4021 on Asterisk in MGCP with the following profile in mgcp.Conf : [general] port = 2727 bindaddr = 10.95.20.1 disallow=all allow=g729 allow=alaw 020202020202] context=mgcp host=dynamic canreinvite=no dtmfmode=rfc2833 nat=yes threewaycalling=yes transfer=yes ; transfer requires threewaycalling=yes. Use FLASH to transfer callwaiting=yes ; this might be a cause of trouble for ip10s cancallforward=yes line=aaln/1 - Place outgoing calls through a SIP PROXY : OK, but the call goes down after some seconds : -- Executing Answer("MGCP/aaln/1 at 020202020202-1", "") in new stack -- MGCP mgcp_answer(MGCP/aaln/1 at 020202020202-1) on aaln/1 at 020202020202-1 -- Executing Dial("MGCP/aaln/1 at 020202020202-1", "SIP/mgcp-out/0xxxxxxxx") in new stack -- Called mgcp-out/0xxxxxxxxxx Dec 17 18:34:47 NOTICE[17889]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist -- SIP/mgcp-out-09d998c0 is making progress passing it to MGCP/aaln/1 at 020202020202-1 Dec 17 18:34:48 WARNING[17932]: chan_mgcp.c:1375 mgcp_indicate: Don't know how to indicate condition 14 -- SIP/mgcp-out-09d998c0 answered MGCP/aaln/1 at 020202020202-1 -- Attempting native bridge of MGCP/aaln/1 at 020202020202-1 and SIP/mgcp-out-09d998c0 -- Resetting interface aaln/1 at 020202020202 == Spawn extension (mgcp, 0141909872, 2) exited non-zero on 'MGCP/aaln/1 at 020202020202-1' -- MGCP handle_request(aaln/1 at 020202020202-1) ast_channel already destroyed, resending DLCX. -- MGCP handle_request(aaln/1 at 020202020202) set vmwi(-) - Receive incoming calls through SIP PROXY : OK too, but as with the outgoing calls, the interface seems to self restart : -- Executing Dial("SIP/XXXSIPCALLID", "MGCP/aaln/1 at 020202020202") in new stack -- MGCP mgcp_request(aaln/1 at 020202020202) -- MGCP cw: -1, dnd: 0, so: 0, sno: 0 -- MGCP mgcp_new(MGCP/aaln/1 at 020202020202-1) created in state: Down -- Called aaln/1 at 020202020202 -- MGCP/aaln/1 at 020202020202-1 is ringing -- MGCP/aaln/1 at 020202020202-1 answered SIP/XXXSIPCALLID -- Attempting native bridge of SIP/XXXSIPCALLID and MGCP/aaln/1 at 020202020202-1 Dec 17 18:38:33 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Dec 17 18:38:34 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Dec 17 18:38:35 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Dec 17 18:38:36 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Dec 17 18:38:38 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Dec 17 18:38:41 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Dec 17 18:38:44 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Dec 17 18:38:47 NOTICE[17957]: chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist -- Resetting interface aaln/1 at 020202020202 == Spawn extension (frommgcp, 0973009997, 1) exited non-zero on 'SIP/87.237.184.116-087f4fb0' -- MGCP handle_request(aaln/1 at 020202020202-1) ast_channel already destroyed, resending DLCX. -- MGCP handle_request(aaln/1 at 020202020202) set vmwi(-) I don't succeed in using g729 for incoming calls whereas its works with outgoing calls. So the incoming calls negociate in ulaw only and the callee side doesn't ear the caller.... I review my ip routes, it's okay because I see the RTP in both way by running ethereal. I don't see what is the problem. So ideally, Asterisk will be able to drive the codec negociation for incoming calls, but I don't know how that is possible. Asterisk 1.2.35 runs under Redhat Enterprise 4 To conclude, I don't understand the following logs : chan_mgcp.c:1656 find_subchannel_and_lock: Gateway '020202020202' (and thus its endpoint 'virtual/nat-timeout') does not exist Thanks for your attention. -- Adrien _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Nenad Kljajic
2010-Mar-23 10:23 UTC
[asterisk-users] Integrate a CPE with Asterisk in MGCP
>[020202020202]>context=mgcp >host=dynamic >canreinvite=no >dtmfmode=rfc2833 >nat=yes >threewaycalling=yes >transfer=yes ; transfer requires threewaycalling=yes. Use FLASH to >transfer >callwaiting=yes ; this might be a cause of trouble for ip10s >cancallforward=yes >line=aaln/1 Order of variables is important. Try this configuration: [020202020202] nat=yes canreinvite=no context=mgcp callerid=020202020202 host=dynamic canreinvite=no dtmfmode=rfc2833 threewaycalling=yes transfer=yes; transfer requires threewaycalling=yes. Use FLASH to transfer callwaiting=yes ; this might be a cause of trouble for ip10s cancallforward=yes ;wcardep = * ; This option is required by some devices line=> aaln/1 line=> virtual/nat-timeout -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100323/4d404c4f/attachment.htm