[svn-commits] oej: branch oej/rana-dtmf-rtp-duration-1.6.0 r332445 - /team/oej/rana-dtmf-rt...

[SVN commits to the Digium repositories]

Author: oej
Date: Thu Aug 18 09:36:12 2011
New Revision: 332445

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=332445
Log:
Updating problem scenario with a new thing that hit me in the back with a Danish dagger.

Modified:
    team/oej/rana-dtmf-rtp-duration-1.6.0/README.rana-dtmf-rtp-duration

Modified: team/oej/rana-dtmf-rtp-duration-1.6.0/README.rana-dtmf-rtp-duration
URL: http://svnview.digium.com/svn/asterisk/team/oej/rana-dtmf-rtp-duration-1.6.0/README.rana-dtmf-rtp-duration?view=diff&rev=332445&r1=332444&r2=332445
==============================================================================
--- team/oej/rana-dtmf-rtp-duration-1.6.0/README.rana-dtmf-rtp-duration (original)
+++ team/oej/rana-dtmf-rtp-duration-1.6.0/README.rana-dtmf-rtp-duration Thu Aug 18 09:36:12 2011
@@ -5,9 +5,16 @@
 This branch is trying to focus on DTMF in the RTP channel. Asterisk 1.4 and later
 doesn't send the proper DTMF duration on the outbound call leg. If we receive
 a DTMF with a duration of 480 samples, we might end up sending 1440 samples out.
+
 Another issue is the delayed transmission when using the core bridge with features
 enabled. If you send a three second DTMF inbound, the outbound begins after the inbound
 ends, so you get a six second interruption to the call.
+
+A third issue is that if we get a new DTMF while we're still transmitting the old,
+we immediately jump to the new one without finishing the old DTMF tone. 
+
+Fixes
+=====
 
 In order to handle this a lot of bugs was fixed. We also added a new control
 frame to update the outbound channel with the latest duration from the inbound,