[asterisk-dev] rana-dtmf-rtp-duration - adventures in DTMF/RTP

Olle E. Johansson oej at edvina.net
Fri Aug 19 04:08:51 CDT 2011


Just to update you on my work with DTMF:

This all started when we noticed that the duration of DTMF on the incoming stream compared with what we sent was radically different. DTMF in RTP consist of a start packet, updates (continuation) and an end packet. The end packet contains the final duration.

While working on this, I noticed DTMF delays in the feature code, something that I tried to solve and Terry added a silence generator to and committed, so that's no longer the case. If Asterisk listens to DTMF and the tone is not a feature code, we're no longer waiting for the END packet to start sending out.

For longer tones, we receive DTMF on one RTP channel and send AST_CONTROL messages to the outbound channel, where we play them according to the RTP packet stream there. The updates where previously silently ignored, which caused issues. I have added an AST_CONTROL message with duration updates, so that we can play out properly as we receive incoming RTP packets.

That fixed a lot of issues. We still run into issues, partly due to feature code and partly because of the RTP stack architecture, where the outbound playout is often delayed compared with the inbound DTMF. Yesterday I discovered that people may come up with the idea to start sending a new DTMF tone on the incoming stream, while we're still playing the outbound DTMF. This causes a lot of interesting issues, the result being that we jump to the new one in the middle of the old one without sending any END messages.

For those cases, I will have to create a DTMF queue in the outbound channel, consisting of the END frames with a duration so I can start the playout immediately after the previous tone.

Hopefully the end result of this work will be:

 - more correct duration going through the Asterisk PBX bridge on rtp2rtp calls
 - no dropped DTMF tones when they are played quickly

The branch I'm working on is currently for 1.6.0, which is what's used in production at the customer site. It will be upgraded to 1.8 and trunk versions as soon as we have tested.

Any feedback is of course, as always, welcome.

Regards,
/Olle





More information about the asterisk-dev mailing list