[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