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-0600 | Date Closed: | 2011-03-16 12:29:24 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | 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 |