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

Wed Mar 16 12:29:24 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:29 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
====================================================================== 

---------------------------------------------------------------------- 
 (0132960) svnbot (reporter) - 2011-03-16 12:29
 https://issues.asterisk.org/view.php?id=16625#c132960 
---------------------------------------------------------------------- 
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: 0132960                          
======================================================================