Review Board 1.7.16

While handling RFC 2833 DTMF, accommodate endpoints that increment the RTP timestamp in End of Event re-transmits

Review Request #2124 - Created Sept. 19, 2012 and submitted

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

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.
Ran it through the Test Suite's RFC 2833 DTMF tests.  Passed.

Basic mashing of DTMF keys locally.
Ship it!
Posted (Sept. 20, 2012, 3:25 a.m.)
Silly endpoints...

Before checking this in get it tested by the reporter I'd say.
  1. He confirmed it fixed his endpoint's behavior.
  2. Exxxxxxxxcellent.
Ship it!
Posted (Sept. 20, 2012, 8:10 a.m.)
 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