[asterisk-users] DTMF issue with 1.8.6.0 and SIP Trunks [WORKING]

JR Richardson jmr.richardson at gmail.com
Thu Nov 10 11:07:20 CST 2011


> I recently turned up some 1.8.6.0 call servers in productions, SIP trunks in
> routing calls to upstream carrier via SIP trunks out.  I spent a lot of time
> in the lab testing 1.8 which included heavily testing DTMF with no issues
> that came up.  It all just seemed to work fine.  But then again you can’t
> reproduce every real work scenario in the lab.
>
>
>
> I’m using rfc2833 inbound and outbound for the new 1.8 call servers.  Here
> is a quick diagram of what is working and what is not:
>
>
>
> Not working:
>
> Customer IP PBX><sip trunk rfc2833><ast 1.4 rfc2833><sip trunk><call server
> ast 1.8 rfc2833><sip trunk><upstream carrier
>
>
>
> Customer PRI><cisco PRI gateway><sip trunk rfc2833><ast 1.4 rfc2833><sip
> trunk>< call server ast 1.8 rfc2833><sip trunk><upstream carrier
>
>
>
> I can see DTMF RTP events pass through call server to carrier but no
> response, nothing, nada, zip.
>
>
>
> Working:
>
> Customer SIP Phone><sip rfc2833><ast 1.4 rfc2833><sip trunk>< call server
> ast 1.8 rfc2833><sip trunk><upstream carrier
>
>
>
> Customer SIP Phone><sip rfc2833><ast 1.4 rfc2833><sip trunk>< call server
> ast 1.2 rfc2833><sip trunk><upstream carrier
>
>
>
> Customer IP PBX><sip trunk rfc2833><ast 1.4 rfc2833><sip trunk>< call server
> ast 1.2 rfc2833><sip trunk><upstream carrier
>
>
>
> Customer PRI><cisco PRI gateway><sip trunk rfc2833><ast 1.4 rfc2833>< call
> server sip trunk><ast 1.2><sip trunk><upstream carrier
>
>
>
> I can see DTMF RTP events pass through to carrier, RTP stream looks the same
> as the 1.8 server with reliable responses.
>
>
>
> On both the 1.4 and 1.8 ast servers, these sip.conf parameters are active on
> peer and global settings:
>
> relaxdtmf=yes
>
> rfc2833compensate=yes
>
> dtmfmode=rfc2833
>
>
>
> Now it quickly appears like a problem between the customer PBX and Customer
> PRI with the SIP trunks to the ast 1.4 servers but it all worked fine before
> with the 1.2 call servers.  After the upgrade of the call servers to 1.8
> DTMF is not recognized by the carrier on calls from the customer IP PBX or
> PRI but is fine with the SIP phones directly registered to the ast 1.4
> servers.
>
>
>
> I found the bug issues with the SRCC change/update issues with DTMF events.
> It looks like 1.8.6.0 implemented the ‘update’ and as I read it, should have
> fixed the issue with the changing SRCC effecting DTMF.  But this may not be
> the case.
>
>
>
> Specifically, how would I debug RTP/DTMF on the new ast 1.8 server and see
> if the SRCC is changing between my scenarios described above.  Am I on the
> right track or is there something else I should be looking at?
>
I added [96] in */main/rtp.c of the ast 1.4 servers then recompiled.
        [96] = {0, AST_RTP_DTMF},
        [97] = {1, AST_FORMAT_ILBC},
        [99] = {1, AST_FORMAT_H264},
        [101] = {0, AST_RTP_DTMF},
This seemed to allow flow through of the DTMF up to the new 1.8 call
servers and on to the carrier.  I don't know why this seemed to fix
the issue, I'm not 100% convinced it really did.  I reverted the
change and could not reproduce the issue, so I also suspect the
upstream carrier started working or may have changed something
coincidentaly.

Thanks.

JR
-- 
JR Richardson
Engineering for the Masses



More information about the asterisk-users mailing list