[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 15:06 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0103891) dimas (reporter) - 2009-04-28 15:06
 http://bugs.digium.com/view.php?id=14815#c103891 
---------------------------------------------------------------------- 
I do not really know ins and outs of RTP but from your debug output it
seems that your peer sends voice (0) in parallel with DTMF (101) in two
"streams" and that timestamms of these streams are not in sync. In fact
voice timestamp is increasing while DTMF "stream" timestamp is constant
(equals to the timestamp of first DTMF packet).

Got  RTP packet from    209.244.16.207:60296 (type 101, seq 012982, ts
1043001391, len 000004)
Got  RTP RFC2833 from   209.244.16.207:60296 (type 101, seq 012982, ts
1043001391, len 000004, mark 0, event 00000008, end 0, duration 02825)
Got  RTP packet from    209.244.16.207:60296 (type 00, seq 012983, ts
1043004111, len 000160)
Got  RTP packet from    209.244.16.207:60296 (type 101, seq 012984, ts
1043001391, len 000004)
Got  RTP RFC2833 from   209.244.16.207:60296 (type 101, seq 012984, ts
1043001391, len 000004, mark 0, event 00000008, end 0, duration 02978)
Got  RTP packet from    209.244.16.207:60296 (type 00, seq 012985, ts
1043004271, len 000160)

I believe that because of this the code at the line 1294 of main/rtp.c
("if (rtp->dtmfcount) {") forces end of digit.

I'm curious what kind of equipment produces such a RTP...
Anyway, it is the fix for 14460 which caused this behavior. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-28 15:06 dimas          Note Added: 0103891                          
======================================================================