[asterisk-dev] [Code Review] While handling RFC 2833 DTMF, accommodate endpoints that increment the RTP timestamp in End of Event re-transmits

[Matt Jordan]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2124/
-----------------------------------------------------------

Review request for Asterisk Developers.


Summary
-------

See the long e-mail chain on the -users list for a description of the problem:

http://lists.digium.com/pipermail/asterisk-users/2012-September/274646.html

While endpoints should not be changing the source timestamp between DTMF event packets, the fact is there exists - somewhere - some endpoint that does.  If there's one, there's probably more, and I don't like breaking compatability with such devices in release branches.

To get around this, we absorb timestamps within the expected re-transmit period.  Note that this period would only affect End of Event packets, so it shouldn't prevent the detection of new DTMF digits that happen to arrive right on top of each other.


This addresses bug ASTERISK-20424.
    https://issues.asterisk.org/jira/browse/ASTERISK-20424


Diffs
-----

  /branches/1.8/res/res_rtp_asterisk.c 373060 

Diff: https://reviewboard.asterisk.org/r/2124/diff


Testing
-------

Ran it through the Test Suite's RFC 2833 DTMF tests.  Passed.

Basic mashing of DTMF keys locally.


Thanks,

Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120919/69d3417b/attachment.htm>