JR Richardson
2011-Nov-10 17:07 UTC
[asterisk-users] DTMF issue with 1.8.6.0 and SIP Trunks [WORKING]
> 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