Review Board 1.7.16

Fix various issues that can cause out of order DTMF processing

Review Request #85 - Created Dec. 11, 2008 and submitted

Russell Bryant
The reporter of 12658 pointed out a few problems with DTMF processing logic.  There were various cases where processing order of received DTMF could be incorrect.

1) Change autoservice to put digits on the head of the channel's frame readq instead of the tail.  If there were frames on the readq that autoservice had not yet read, the previous code would have resulted in out of order processing.  This required a new API call to queue a frame to the head of the queue instead of the tail.

2) Change up the processing of DTMF in ast_read().  Some of the problems were the result of having two sources of pending DTMF frames.  There was the dtmfq and the more generic readq.  Both were used for pending DTMF in various scenarios.  Simplifying things to only use the frame readq avoids some of the problems.

3) Fix a bug where a DTMF END frame could get passed through when it shouldn't have.  If code set END_DTMF_ONLY in the middle of digit emulation, digits would get processed out of order.

1) It compiles!

2) I made a SIP call using RFC2833 for DTMF and verified that passing through DTMF BEGIN/END frames still worked.

3) I made a SIP call using RFC2833 for DTMF, and enabled rfc2833compensation=yes in sip.conf, and verified that DTMF emulation still worked.

Review request changed
Updated (Dec. 11, 2008, 5:46 a.m.)
Updated diff to include rev 163161 from my branch.  Commit message:

The code that determines whether it is an acceptable time to pull DTMF out of the
channel readq did not account for a case when DTMF must be deferred.  We enforce
a minimum amount of time between digits, so check for that, too. 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