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

[Matt Jordan]

> On Sept. 20, 2012, 8:25 a.m., Joshua Colp wrote:
> > Silly endpoints...
> > 
> > Before checking this in get it tested by the reporter I'd say.

He confirmed it fixed his endpoint's behavior.


- Matt


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


On Sept. 19, 2012, 4:52 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2124/
> -----------------------------------------------------------
> 
> (Updated Sept. 19, 2012, 4:52 p.m.)
> 
> 
> 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/20120920/157e46ee/attachment-0001.htm>