[asterisk-bugs] [Asterisk 0016625]: RFC2833 DTMF is not passed correctly when going SIP->IAX2->SIP

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16625 
====================================================================== 
Reported By:                sharvanek
Assigned To:                twilson
====================================================================== 
Project:                    Asterisk
Issue ID:                   16625
Category:                   Channels/chan_iax2
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.28 
JIRA:                       SWP-3151 
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:             2010-01-17 12:02 CST
Last Modified:              2011-03-16 12:20 CDT
====================================================================== 
Summary:                    RFC2833 DTMF is not passed correctly when going
SIP->IAX2->SIP
Description: 
We were the victims of the Sonus bug, we've patched appropriately however
we're still having an interesting issue.

SIP->Asterisk->SIP->Sonus works fine now for DTMF via RFC2833 using the
attached patch.

However if you toss IAX2 in the middle (even with both asterisk boxes
patched) DTMF is unreliable, (jitterbuffer is off).

SIP Phone->Asterisk->IAX2->Asterisk->SIP->Sonus

Attached are packet captures from the last asterisk box in the path to
Sonus for both SIP (working) and IAX2 (not working).

If we substitute the IAX2 trunk for SIP (still using the two asterisk
boxes) DTMF works flawlessly, something is getting lost when going over
IAX2 and we'd like to figure out what that is and get it corrected.

Thanks

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
duplicate of        0015642 [patch] Fix for Sonus DTMF issues
====================================================================== 

---------------------------------------------------------------------- 
 (0132958) svnbot (reporter) - 2011-03-16 12:20
 https://issues.asterisk.org/view.php?id=16625#c132958 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 310902

_U  branches/1.8/
U   branches/1.8/main/features.c

------------------------------------------------------------------------
r310902 | twilson | 2011-03-16 12:19:58 -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=310902 

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