[asterisk-dev] [Code Review] Fix various issues that can cause out of order DTMF processing

[Russell Bryant]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/85/
-----------------------------------------------------------

Review request for Asterisk Developers and Joshua Colp.


Summary
-------

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.


This addresses bug 12658.
    http://bugs.digium.com/view.php?id=12658


Diffs
-----

  /branches/1.4/include/asterisk/channel.h 163079 
  /branches/1.4/main/autoservice.c 163079 
  /branches/1.4/main/channel.c 163079 

Diff: http://reviewboard.digium.com/r/85/diff


Testing
-------

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.


Thanks,

Russell