[asterisk-bugs] [Asterisk 0015642]: [patch] Fix for Sonus DTMF issues

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15642 
====================================================================== 
Reported By:                jasonshugart
Assigned To:                twilson
====================================================================== 
Project:                    Asterisk
Issue ID:                   15642
Category:                   Core/RTP
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     ready for testing
Target Version:             1.6.1.19
Asterisk Version:           SVN 
JIRA:                       SWP-406 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-08-03 12:28 CDT
Last Modified:              2010-03-25 00:08 CDT
====================================================================== 
Summary:                    [patch] Fix for Sonus DTMF issues
Description: 
In some cases when Asterisk sends DTMF to Sonus platforms as RFC2833, Sonus
will not recognize the DTMF.  Several articles have identified the problem
as being the gap in the audio prior to the DTMF packets being sent.  This
patch sends a single G.711 ulaw packet prior to the rfc2833 packets.  In
our testing across with two carriers (Level3 and 360 Networks) this patch
fixed our DTMF issues.  The rtp.c file seems very similar for the 1.4
branch, so minor changes could also be applied there.  I added an option to
the rtp.conf file to enable this fix, called rtpfixdtmf.  Attached are both
the rtp.c fix, and the rtp.conf change.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0016625 RFC2833 DTMF is not passed correctly wh...
====================================================================== 

---------------------------------------------------------------------- 
 (0119862) Jamuel (reporter) - 2010-03-25 00:08
 https://issues.asterisk.org/view.php?id=15642#c119862 
---------------------------------------------------------------------- 
Terry:

I tried patching against a clean 1.6.1.18 and got the following error
(after adding your addition to struct sip_pvt:

patching file channels/chan_sip.c
Hunk https://issues.asterisk.org/view.php?id=1 FAILED at 1064.
Hunk https://issues.asterisk.org/view.php?id=2 succeeded at 5965 (offset 1934
lines).
Hunk https://issues.asterisk.org/view.php?id=3 succeeded at 4060 (offset 1
line).
1 out of 3 hunks FAILED -- saving rejects to file channels/chan_sip.c.rej
patching file main/rtp.c
Hunk https://issues.asterisk.org/view.php?id=1 succeeded at 3579 (offset 872
lines).

Index: channels/chan_sip.c
===================================================================
--- channels/chan_sip.c (revision 248348)
+++ channels/chan_sip.c (working copy)
@@ -1064,6 +1064,7 @@
         * The large-scale changes would be a good idea for implementing
during an SDP rewrite.
         */
        struct offered_media offered_media[3];
+       struct ast_silence_generator *gen;
 } *iflist = NULL;


chan_sip.c in 1.6.1.18 already looks like this starting at line 1402:
         * The large-scale changes would be a good idea for implementing
during an SDP rewrite.
         */
        struct offered_media offered_media[4];
        struct ast_silence_generator *gen;
};

Safe to assume I'm good to go by ignoring that failed hunk?

chan_sip.c and rtp.c both compile cleanly.

Please advise. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-03-25 00:08 Jamuel         Note Added: 0119862                          
======================================================================