Configuring and debugging DTMF (RFC 2833)
Media in SIP and H.323 is transferred over RTP. It's a protocol that is quite asymmetric with respect to the sender’s and receiver’s responsibilities. Everything that sender does is splits the audio stream into packets, puts a header on top and sends them in a timely manner. Receiver has to deal with the fact that packets may not arrive in timely manner, may arrive in wrong order or may not arrive at all.
DTMF tones, when transferred over RTP, will have the same issues. Different vendors try to overcome these issues by reading and implementing DTMF tone processors differently.
How Cisco sends DTMF tones...
Upon DTMF detection, Cisco GW starts sending tone updates immediately. It sends the initial packet 3 times, the initial tone duration is set to 0. Then it keeps sending updates every 50 ms until the end of the tone. Once the end of the tone is detected, Cisco GW sends the final packet 3 times with the correct “final” duration.
How Intel PIMG sends DTMF tones...
PIMG sends initial packet once but it starts the duration count from the next update. It sends updates every 20 ms, and the initial duration is set to 20. The next update will have duration 40 (even though the real duration at that time is somewhere between 20 and 40 ms). Once the tone is ended, the PIMG gateway sends 3 final packets with the "final" tone duration that is less (or equal) the duration that was reported in the previous update. (Very tricky: if you want to interop, you'll have to expect tone updates with greater sequence numbers but smaller duration).
I wonder, is it actually possible to implement this more different and still stay within the spec compliance...?
How to configure...
In the VoIP dial-peers set:
dtmf-relay rtp-nte
This will use payload type 101 for the DTMF tones. If you want to redefine it, use “rtp payload-type” command in the dial-peer that requires this change.
There is a doc on the Cisco web site that covers these commands in details: “Dual Tone Multifrequency Relay for SIP calls Using Named Telephone Events” (https://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087edb.html#58571)
I remember an issue when we were advertizing PT 96 in the outboung calls and Cisco GW was ignoring it and sending 200 OK with no support for DTMF. When turned on the "deb voip ivr all" and "deb voip ccapi inout", one of these debug outputs had messages about some application being bound to the payload type 96, and due to the conflict, it dropped the DTMF support for that call. Well, not arguing about validity of this (96..127 is the dynamic range after all), just redefine the map of these tones on the gateway, or use 101.
How to debug...
When DTMF tones seemed to be lost (completely not received) by one or another side, it’s very (very!) unlikely that the packet loss is the reason for this. Start from looking at the media negotiation. All or some messages of the call setup (Invite/Trying/Ringing/Ok/Ack) will have SDP block that should have something similar to this:
m=audio 46090 RTP/AVP 0 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
SDP doesn’t really “negotiate” media parameters, but if you see INVITE that has “a= ” with telephone-event, and 200 OK doesn’t have it, you’re likely to end up with the session that won’t use RFC 2833 for DTMF tones.
Does it mean that the DTMF tones are not transferred? It depends. In case with Cisco GWs, they will not extract DTMF tones from the audio, so the tones will come as a wave form. On the other end, if it’s a pure IP endpoint, it likely won’t have tone waveform generator, and the tones won’t be sent at all.
If you want to see whether Cisco GW sends and receives tones (including all tome updates) use “deb voip rtp”. Here is an example of debug output:
Nov 10 07:49:29.061: <<<Rcv> Pt:101 Evt:5 Pkt:0D 00 00
Nov 10 07:49:29.061: <<<Rcv> Pt:101 Evt:5 Pkt:0D 00 00
Nov 10 07:49:29.065: <<<Rcv> Pt:101 Evt:5 Pkt:0D 00 00
Nov 10 07:49:29.113: <<<Rcv> Pt:101 Evt:5 Pkt:0D 01 90
Nov 10 07:49:29.165: <<<Rcv> Pt:101 Evt:5 Pkt:0D 03 20
Nov 10 07:49:29.173: <<<Rcv> Pt:101 Evt:5 Pkt:8D 03 88
Nov 10 07:49:29.181: <<<Rcv> Pt:101 Evt:5 Pkt:8D 03 88
Nov 10 07:49:29.185: <<<Rcv> Pt:101 Evt:5 Pkt:8D 03 88
How to read it: The “5” key was pressed for 113 ms (0x388 / 8). The first three packets are the tone start (3 times resend). The last three packets have the “End” bit on (Pkt:8D...) and they were also three times resent. The timestamp on each line of the logs help to see how the tone updates were sent.