[Home]

Summary:ASTERISK-15449: RFC2833 DTMF is not passed correctly when going SIP->IAX2->SIP
Reporter:S Harvanek (sharvanek)Labels:
Date Opened:2010-01-17 12:02:25.000-0600Date Closed:2011-03-16 12:29:24
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_iax2
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dumpiax.cap
( 1) dumpsip.cap
( 2) login_rtp.cap
( 3) rtp.c.diff.fix.1.4
( 4) rtp.conf.sample.diff.fix
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


****** STEPS TO REPRODUCE ******

Connect to Sonus Switch via SIP, use applied patch with both SIP and IAX2, it works with SIP it fails if IAX2 is anywhere in the middle.
Comments:By: snuffy (snuffy) 2010-01-17 22:08:49.000-0600

sharvanek: You need to sign a license for code patches.
The license form link can be found along the top with 'view issues' etc.

By: S Harvanek (sharvanek) 2010-01-17 22:14:45.000-0600

Even if the patch is from a previous bug? (just using it as an example in this case).

-SH

By: snuffy (snuffy) 2010-01-18 00:13:21.000-0600

If the patch was from a previous case then you could ask us to link them.
I assume the other case that has this code attached is marked as code etc?

By: S Harvanek (sharvanek) 2010-01-18 00:29:55.000-0600

Hrm, can't find a copy of it, it was passed to me by another of our engineers and I thought he had said it was already doc'd somewhere, guess I heard wrong.

License signed. :)

thanks

By: snuffy (snuffy) 2010-01-18 00:45:17.000-0600

License should clear in a day or so, quite a few people will be interested in this.

By: S Harvanek (sharvanek) 2010-01-18 00:47:24.000-0600

Roger that, yea this 100% fixes the DTMF issue with Sonus switches (Level3, GBLX etc.).

We're just trying to figure out why if IAX2 gets in the middle it breaks, I suspect something is missing in my patch that IAX2 doesn't like in the RTP stream (odd) or something else needs to be patched as well.

I look forward to seeing what we can figure out. :)

-SH

By: S Harvanek (sharvanek) 2010-01-26 16:17:09.000-0600

From Dash:

"ake a look at the attached RTP capture.  At packet 82 (1.616 seconds into the stream) is the last audio RTP packet before the DTMF.  The next audio RTP packet is at packet 95 (1.837 seconds into the stream).  The total time difference there is about 220 ms.  However, the RTP timestamps have increased by 3360 (13120 to 16480) which would represent about 420 ms.  I think this may be some part of the problem.  Please take a look at your RTP stream when doing the Packet2Packet bridging.  I would guess it does not have this problem.  We will keep working on a way to make the DTMF recognizable to Sonus, but you should have Digium look at this.  I would guess the RTP timestamp is being increased too much during DTMF transmission.
"

By: Digium Subversion (svnbot) 2011-03-16 11:58:52

Repository: asterisk
Revision: 310888

U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r310888 | twilson | 2011-03-16 11:58:43 -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 ASTERISK-14589)
Reported by: jasonshugart
Patches:
     issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde

(closes issue ASTERISK-15449)
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=310888

By: Digium Subversion (svnbot) 2011-03-16 12:03:34

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 ASTERISK-14589)
 Reported by: jasonshugart
 Patches:
       issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
 Tested by: globalnetinc, jde
 
 (closes issue ASTERISK-15449)
 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

By: Digium Subversion (svnbot) 2011-03-16 12:20:06

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 ASTERISK-14589)
   Reported by: jasonshugart
   Patches:
         issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
   Tested by: globalnetinc, jde
   
   (closes issue ASTERISK-15449)
   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

By: Digium Subversion (svnbot) 2011-03-16 12:29:23

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 ASTERISK-14589)
     Reported by: jasonshugart
     Patches:
           issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
     Tested by: globalnetinc, jde
     
     (closes issue ASTERISK-15449)
     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