I recently turned up some 188.8.131.52 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:
Customer IP PBX>
ast 1.8 rfc2833>
trunk>< call server ast 1.8 rfc2833>
response, nothing, nada, zip.
Customer SIP Phone>< call server
ast 1.8 rfc2833>< call server
ast 1.2 rfc2833>< call server
ast 1.2 rfc2833>< call
server sip trunk>
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:
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
I found the bug issues with the SRCC change/update issues with DTMF events.
It looks like 184.108.40.206 implemented the ‘update’ and as I read it, should have
fixed the issue with the changing SRCC effecting DTMF. But this may not be
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?