[asterisk-users] Integrate a CPE with Asterisk in MGCP

[Steve Totaro]

I am still waiting on chan_megaco....

I think the only way these channel drivers are going to move is with a bit
of financing.

I am willing to chip in.

Thanks,
Steve Totaro

On Mon, Dec 21, 2009 at 9:18 AM, Adrien Lemoine <alemoine at legos.fr> wrote:

> 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
>
>
> _______________________________________________
> -- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20091221/6f7f258f/attachment.htm