[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:                     closed
Asterisk Version:           SVN 
JIRA:                       SWP-2728 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-08-03 12:28 CDT
Last Modified:              2011-03-16 12:29 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...
related to          0017404 [patch] [regression] audio delay when b...
====================================================================== 

---------------------------------------------------------------------- 
 (0132959) svnbot (reporter) - 2011-03-16 12:29
 https://issues.asterisk.org/view.php?id=15642#c132959 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 310941

_U  trunk/
U   trunk/main/features.c

------------------------------------------------------------------------
r310941 | twilson | 2011-03-16 12:29:17 -0500 (Wed, 16 Mar 2011) | 50
lines

Merged revisions 310902 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43
lines
  
  Merged revisions 310889 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36
lines
    
    Merged revisions 310888 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) |
29 lines
      
      Don't delay DTMF in core bridge while listening for DTMF features
      
      This patch is mostly the work of Olle Johansson. I did some cleanup
and
      added the silence generating code if transmit_silence is set.
      
      When a channel listens for DTMF in the core bridge, the outbound
DTMF is not
      sent until we have received DTMF_END. For a long DTMF, this is a
disaster. We
      send 4 seconds of DTMF to Asterisk, which sends no audio for those 4
seconds.
      Some products see this delay and the time skew on RTP packets that
results and
      start ignoring the audio that is sent afterward.
      
      With this change, the DTMF_BEGIN frame is inspected and checked. If
it matches
      a feature code, we wait for DTMF_END and activate the feature as
before. If
      transmit_silence=yes in asterisk.conf, silence is sent if we
paritally match a
      multi-digit feature. If it doesn't match a feature, the frame is
forwarded
      along with the DTMF_END without delay. By doing it this way, DTMF is
not delayed.
      
      (closes issue https://issues.asterisk.org/view.php?id=15642)
      Reported by: jasonshugart
      Patches: 
            issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson
(license 396)
      Tested by: globalnetinc, jde
      
      (closes issue https://issues.asterisk.org/view.php?id=16625)
      Reported by: sharvanek
      
      Review: https://reviewboard.asterisk.org/r/1092/
      Review: https://reviewboard.asterisk.org/r/1125/
    ........
  ................
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=310941 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-03-16 12:29 svnbot         Checkin                                      
2011-03-16 12:29 svnbot         Note Added: 0132959                          
======================================================================