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 184.108.40.206, 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 220.127.116.11).
I’ll have a look at the bugfixes/release notes for 10.6 to see if there were any relevant patches for 1.8.