Review Board 1.7.16

DTMF emulation bad calculation that hurts RTP

Review Request #3546 - Created May 16, 2014 and updated

Olle E Johansson
This code in channel.c is wrong. It first checks if we have a length. If not, we set it to a measured time, which is fine.

If we have a length and it's under the minimum DTMF duration, we set it again to the measured time. In an RTP session, the duration can be under minimum, but has no relationship to the measured time between DTMF start and end. We should keep the given RTP DTMF time and use that for emulation. I have had DTMF that was extended by up to 60 ms because of this code and that really, really broke communication for these alarm panels that send many short DTMF tones.

I suggest that this fix goes into 1.8 and later revisions.
Hours and hours of reading DTMF logs. Countless cups of tea. A gazillion milliseconds wasted. All tested in 1.8.
Description From Last Updated Status
This comment should be deleted as it will no longer do this with the patch. rmudgett May 16, 2014, 9:54 p.m. Open
Review request changed
Updated (May 16, 2014, 8:56 a.m.)
Added issue #
Ship it!
Posted (May 16, 2014, 5:33 p.m.)


  1. Thank you. Found even more issues so I need to come back on this.
    Easiest patch was to avoid DTMF emulation fully by checking min duration in res_asterisk_rtp before you send it up to the core. Now, if other channels send small DTMF tones we still need to fix emulation.
    The problem is that we calculate the difference between the current length and the min duration, then use the difference as the end duration. This is very confusing.
Posted (May 16, 2014, 9:54 p.m.)


/trunk/main/channel.c (Diff revision 1)
This comment should be deleted as it will no longer do this with the patch. runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to