I’ve experienced a DTMF issue with asterisk 1.6, 1.8, but not on 10.6.
I couldn’t find anything exactly relevant when googling, so at least this post should help others confirm their issue.
When a SIP trunk’s dtmfmode is set to inband (some old systems still expect DTMF tones) and an RFC2833 RTP DTMF event with a different SSRC than the SSRC of the previous RTP audio is received, Asterisk (confirmed with 1.6.2.18, 1.8.11 and 1.8.13) stops forwarding the subsequent RTP audio to the other endpoint (the phone).
When tried with a media server that keeps the DTMF RTP SSRC equal to the audio, the subsequent RTP audio is forwarded without any problems.
A workaround would of course be to make the phones do inband + RFC2833 and keep the SIP trunk in auto/rfc2833, but I’m using Cisco 89xx’s, for which I have found no way to make them do this. Anyway, Asterisk shouldn’t choke on this to begin with.
I would love to know if I’m grossly overlooking something here, or if someone has come across anything relevant before (considering this has at least been present since 1.6.2.18).
I’ll have a look at the bugfixes/release notes for 10.6 to see if there were any relevant patches for 1.8.
Asterisk doesn’t pass SSRC through (except when native bridging). I wonder if what you are really seeing is the result of a discontinuity in the timestamps.
You’re right, Asterisk doesn’t pass SSRC through, do you mean that for this reason you wouldn’t expect Asterisk to choke on a changing dtmf SSRC under these circumstances?
You’re right about the timestamps too, hadn’t checked that yet. The timestamp jumps from 1073295336 to 160, from the last audio to the first dtmf RTP packet. Testing with the other (working) media server just shows an incremental increase of the timestamp over the audio-dtmf-audio sequence of packets.
BTW, I made a mistake stating 10.6 doesn’t have this issue! I had an error in the trunk config so it wasn’t actually in dtmfmode inband. After correcting that, I was able to reproduce it here too!
Actually it now turns out that my original issue, the lack of DTMF tone recognition on Asterisk 1.6 in RFC2833 on certain destinations has vanished with the upgrade to 1.8. No need to run in dtmfmode inband anymore, so the issue is no longer relevant (to me).
I did a quick search on issues.asterisk.org but failed to locate that issue, I wanted to check if there was a need for a trace since the SIP trunk part might not be easily reproduced.