[asterisk-bugs] [Asterisk 0014815]: DTMF Appears to be broken from certain sources on asterisk 1.4.24 - double digit.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14815 
====================================================================== 
Reported By:                geoff2010
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14815
Category:                   Core/RTP
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     new
Target Version:             1.4.25
Asterisk Version:           1.4.24 
Regression:                 Yes 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-04-02 15:38 CDT
Last Modified:              2009-04-28 16:54 CDT
====================================================================== 
Summary:                    DTMF Appears to be broken from certain sources on
asterisk 1.4.24 - double digit.
Description: 
I am having some trouble with 1.4.24.  This appears to be a regression
since 1.4.21.1 as I have just recently upgraded and started to experience
the problem.

When calling my asterisk box from a cell phone the system detects double
DTMF digits.  When calling from a landline or pure SIP device DTMF
detection works fine.  I have determined that the cell phone is sending the
RTP DTMF payload about 2x more than the other devices, but as far as I can
tell it should still be considered a single digit as per the RFC.

Attached are two TXT files of pcap exports which show the dump for a
working DTMF interaction, and one for a failure situation.

Please let me know if I can provide any further information.

Thanks,
Geoff
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0014460 Asterisk plays a continuous tone foreve...
====================================================================== 

---------------------------------------------------------------------- 
 (0103898) dimas (reporter) - 2009-04-28 16:54
 http://bugs.digium.com/view.php?id=14815#c103898 
---------------------------------------------------------------------- 
No I do not have a solution. First of all because as I said I'm not RTP
guru - I did not even know that "The RTP stream is totally within spec
though, because voice timestamps need to continue to increment even thought
the ts for the RFC2833 packet needs to remain static" :)

I someone make me fix it quickly, I would probably use following
approach:
1. rename dtmfcount to dtmfstartts (timestamp)
2. change "rtp->dtmfcount = dtmftimeout;" in process_rfc2833 to
"rtp->dtmfcount = timestamp"
3. fixed 

        if (rtp->dtmfcount) {
                rtp->dtmfcount -= (timestamp - rtp->lastrxts);

                if (rtp->dtmfcount < 0) {
                        rtp->dtmfcount = 0;
                }

code to be something like

  if (rtp->dtmfstartts && dtmfstartts + dtmftimeout < timestamp) {

4. And searched for all occurenses of dtmfcount and patched the code
appropriately.

However this is just a theory.... 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-28 16:54 dimas          Note Added: 0103898                          
======================================================================