[asterisk-dev] [Code Review] Keep RTP DTMF short and sweet

[Olle E Johansson]

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

(Updated 2011-02-01 07:40:12.458669)


Review request for Asterisk Developers.


Changes
-------

Added comment that further testing invalidates this patch. Actually, it makes Asterisk behave much better, but still not right. 


Summary (updated)
-------

Asterisk by default adds 740 "timestamp units" to every outbound DTMF in the RTP subsystem. For longer DTMF key presses, it doesn't matter much, but for very short ones, it adds a LOT of extra noise in the call. Unfortunately, we had a lot of very short DTMF and got complains.

- 2*160 units in the retransmits of DTMF begin packets. They all should have the same duration
- 160 units in an extra DTMF continue packet that doesn't match any incoming packet
- 160 units by bad calculation in the DTMF end packet

This code fixes all of these issues and make sure that outbound DTMF has the same duration as inbound DTMF on the RTP channel. I am not proud over the code that stops the extra DTMF continue though. Will try to come up with something more cool. This works though. Feedback and ideas are more than welcome.

Further testing shows that while this patch fixes SNOM-2-SNOM calls, it doesn't work with a carrier gateway we're using that spaces packets in 40 units at start, then 400 units... This makes Asterisk's assumption of 160 units (20 ms) not valid.

Go back to the bug report for further discussion in this matter.


This addresses bug 18723.
    https://issues.asterisk.org/view.php?id=18723


Diffs
-----

  /branches/1.4/main/rtp.c 304949 

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


Testing (updated)
-------

Tested beeping with Asterisk 1.6.0 between two SNOM phones many many times. Will continue testing on production servers.

A


Thanks,

Olle E

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