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

Asterisk Bug Tracker noreply at bugs.digium.com
Wed Mar 16 12:03:35 CDT 2011


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:03 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
====================================================================== 

---------------------------------------------------------------------- 
 (0132956) svnbot (reporter) - 2011-03-16 12:03
 https://issues.asterisk.org/view.php?id=16625#c132956 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 310889

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

------------------------------------------------------------------------
r310889 | twilson | 2011-03-16 12:03:29 -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=310889 

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




More information about the asterisk-bugs mailing list