Summary: | ASTERISK-13564: Asterisk plays a continuous tone forever if it never receives a 2833 end packet | ||
Reporter: | Mike Oliveras (moliveras) | Labels: | |
Date Opened: | 2009-02-11 14:46:56.000-0600 | Date Closed: | 2009-05-13 08:42:31 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Core/RTP |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) dtmf_logging.txt ( 1) endless-digit-svnBranch1.4-r178508.pcap.gz ( 2) issue_14460_debug.diff.txt ( 3) rfc2833-noEnd.pcap.gz ( 4) talkoff.pcap ( 5) uac_talkoff.xml | |
Description: | I am running asterisk 1.4.21.1, but have also reproduced this issue with 1.6.1-rc1. Asterisk is bridging a call between two endpoints, both using rfc2833 for digit detection. SBC (192.168.196.40) --> asterisk (192.168.196.33) --> IP Phone (192.168.196.181). Asterisk receives a single rfc2833 digit with a duration of 320 (no end packet) from 196.40. Asterisk then sends a continuous stream of 2833 events towards the other end with increasing duration, causing a continuous tone to be played. Asterisk also stops sending rtp towards 196.181 while sending the 2833 events. I believe that this is not compliant with rfc2833. Would it be better if the 2833 packets were simply forwarded on if bridging between two peers that both do 2833? At least the tone should not last forever, and should not block rtp. This 2833 packet originated from an Adtran TA904 gateway that falsely detected a digit when none was pressed (talk off). I will attach a packet capture after submitting this ticket. ****** ADDITIONAL INFORMATION ****** As mentioned, I am running 1.4.21.1 but saw the same behavior in 1.6.1-rc1 | ||
Comments: | By: Joshua C. Colp (jcolp) 2009-02-11 14:50:27.000-0600 If the two channels can indeed bridge they will do as you say. Sometimes though the core has to intercept and generate the DTMF instead. Even if it did bridge though I'm sure some devices would just generate continually generate DTMF like we do. The remote side really should send us an end. By: Mike Oliveras (moliveras) 2009-02-11 14:58:46.000-0600 Yes it should, however bugs can occur and packets can be lost. If the end packet is simply lost, we would not want to play a tone forever, causing the end users to have to drop the call. The rfc (pg 7) states in fact that it should not. From RFC2833 Alternatively, the receiver can start a tone and play it until it receives a packet with the "E" bit set, the next tone, distinguished by a different timestamp value or a given time period elapses. This is more robust against packet loss, but may extend the tone if all retransmissions of the last packet in an event are lost. Limiting the time period of extending the tone is necessary to avoid that a tone "gets stuck". Regardless of the algorithm used, the tone SHOULD NOT be extended by more than three packet interarrival times. A slight extension of tone durations and shortening of pauses is generally harmless. By: Russell Bryant (russell) 2009-02-11 18:03:27.000-0600 I have a patch written for this. It is currently in the following branch, but I'll probably merge it into the 1.4 branch tomorrow morning: http://svn.digium.com/svn/asterisk/team/russell/issue_14460 By: Digium Subversion (svnbot) 2009-02-12 10:51:14.000-0600 Repository: asterisk Revision: 175124 U branches/1.4/main/rtp.c ------------------------------------------------------------------------ r175124 | russell | 2009-02-12 10:51:13 -0600 (Thu, 12 Feb 2009) | 27 lines Don't send DTMF for infinite time if we do not receive an END event. I thought that this was going to end up being a pretty gnarly fix, but it turns out that there was actually already a configuration option in rtp.conf, dtmftimeout, that was intended to handle this situation. However, in between Asterisk 1.2 and Asterisk 1.4, the code that processed the option got lost. So, this commit brings it back to life. The default timeout is 3 seconds. However, it is worth noting that having this be configurable at all is not really the recommended behavior in RFC 2833. From Section 3.5 of RFC 2833: Limiting the time period of extending the tone is necessary to avoid that a tone "gets stuck". Regardless of the algorithm used, the tone SHOULD NOT be extended by more than three packet interarrival times. A slight extension of tone durations and shortening of pauses is generally harmless. Three seconds will pretty much _always_ be far more than three packet interarrival times. However, that behavior is not required, so I'm going to leave it with our legacy behavior for now. Code from svn/asterisk/team/russell/issue_14460 (closes issue ASTERISK-13564) Reported by: moliveras ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=175124 By: Digium Subversion (svnbot) 2009-02-12 10:57:26.000-0600 Repository: asterisk Revision: 175125 _U trunk/ U trunk/main/rtp.c ------------------------------------------------------------------------ r175125 | russell | 2009-02-12 10:57:26 -0600 (Thu, 12 Feb 2009) | 35 lines Merged revisions 175124 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r175124 | russell | 2009-02-12 10:51:13 -0600 (Thu, 12 Feb 2009) | 27 lines Don't send DTMF for infinite time if we do not receive an END event. I thought that this was going to end up being a pretty gnarly fix, but it turns out that there was actually already a configuration option in rtp.conf, dtmftimeout, that was intended to handle this situation. However, in between Asterisk 1.2 and Asterisk 1.4, the code that processed the option got lost. So, this commit brings it back to life. The default timeout is 3 seconds. However, it is worth noting that having this be configurable at all is not really the recommended behavior in RFC 2833. From Section 3.5 of RFC 2833: Limiting the time period of extending the tone is necessary to avoid that a tone "gets stuck". Regardless of the algorithm used, the tone SHOULD NOT be extended by more than three packet interarrival times. A slight extension of tone durations and shortening of pauses is generally harmless. Three seconds will pretty much _always_ be far more than three packet interarrival times. However, that behavior is not required, so I'm going to leave it with our legacy behavior for now. Code from svn/asterisk/team/russell/issue_14460 (closes issue ASTERISK-13564) Reported by: moliveras ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=175125 By: Digium Subversion (svnbot) 2009-02-12 11:03:22.000-0600 Repository: asterisk Revision: 175126 _U branches/1.6.0/ U branches/1.6.0/main/rtp.c ------------------------------------------------------------------------ r175126 | russell | 2009-02-12 11:03:21 -0600 (Thu, 12 Feb 2009) | 43 lines Merged revisions 175125 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r175125 | russell | 2009-02-12 10:57:25 -0600 (Thu, 12 Feb 2009) | 35 lines Merged revisions 175124 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r175124 | russell | 2009-02-12 10:51:13 -0600 (Thu, 12 Feb 2009) | 27 lines Don't send DTMF for infinite time if we do not receive an END event. I thought that this was going to end up being a pretty gnarly fix, but it turns out that there was actually already a configuration option in rtp.conf, dtmftimeout, that was intended to handle this situation. However, in between Asterisk 1.2 and Asterisk 1.4, the code that processed the option got lost. So, this commit brings it back to life. The default timeout is 3 seconds. However, it is worth noting that having this be configurable at all is not really the recommended behavior in RFC 2833. From Section 3.5 of RFC 2833: Limiting the time period of extending the tone is necessary to avoid that a tone "gets stuck". Regardless of the algorithm used, the tone SHOULD NOT be extended by more than three packet interarrival times. A slight extension of tone durations and shortening of pauses is generally harmless. Three seconds will pretty much _always_ be far more than three packet interarrival times. However, that behavior is not required, so I'm going to leave it with our legacy behavior for now. Code from svn/asterisk/team/russell/issue_14460 (closes issue ASTERISK-13564) Reported by: moliveras ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=175126 By: Digium Subversion (svnbot) 2009-02-12 11:08:26.000-0600 Repository: asterisk Revision: 175129 _U branches/1.6.1/ U branches/1.6.1/main/rtp.c ------------------------------------------------------------------------ r175129 | russell | 2009-02-12 11:08:25 -0600 (Thu, 12 Feb 2009) | 43 lines Merged revisions 175125 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r175125 | russell | 2009-02-12 10:57:25 -0600 (Thu, 12 Feb 2009) | 35 lines Merged revisions 175124 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r175124 | russell | 2009-02-12 10:51:13 -0600 (Thu, 12 Feb 2009) | 27 lines Don't send DTMF for infinite time if we do not receive an END event. I thought that this was going to end up being a pretty gnarly fix, but it turns out that there was actually already a configuration option in rtp.conf, dtmftimeout, that was intended to handle this situation. However, in between Asterisk 1.2 and Asterisk 1.4, the code that processed the option got lost. So, this commit brings it back to life. The default timeout is 3 seconds. However, it is worth noting that having this be configurable at all is not really the recommended behavior in RFC 2833. From Section 3.5 of RFC 2833: Limiting the time period of extending the tone is necessary to avoid that a tone "gets stuck". Regardless of the algorithm used, the tone SHOULD NOT be extended by more than three packet interarrival times. A slight extension of tone durations and shortening of pauses is generally harmless. Three seconds will pretty much _always_ be far more than three packet interarrival times. However, that behavior is not required, so I'm going to leave it with our legacy behavior for now. Code from svn/asterisk/team/russell/issue_14460 (closes issue ASTERISK-13564) Reported by: moliveras ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=175129 By: Mike Oliveras (moliveras) 2009-02-13 09:39:12.000-0600 I checked out the 1.4 branch yesterday to test against and I am still seeing the same behavior. Is it possible that what I checked out does not contain the fix? Does the reporter generally get a chance to test the fix before it is closed ? [root@mikeo_asterisk1 ~]# asterisk -r Asterisk SVN-branch-1.4-r175311M, Copyright (C) 1999 - 2008 Digium, Inc. and oth ers. Created by Mark Spencer <markster@digium.com> Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for detail s. This is free software, with components licensed under the GNU General Public License version 2 and other licenses; you are welcome to redistribute it under certain conditions. Type 'core show license' for details. ========================================================================= Connected to Asterisk SVN-branch-1.4-r175311M currently running on mikeo_asteris k1 (pid = 11491) Verbosity is at least 10 mikeo_asterisk1*CLI> show version Asterisk SVN-branch-1.4-r175311M built by root @ mikeo_asterisk1.wiline.com on a i686 running Linux on 2009-02-12 23:32:44 UTC mikeo_asterisk1*CLI> exit [root@mikeo_asterisk1 ~]# cat /etc/asterisk/rtp.conf ; ; RTP Configuration ; [general] ; ; RTP start and RTP end configure start and end addresses ; ; Defaults are rtpstart=5000 and rtpend=31000 ; rtpstart=10000 rtpend=19000 ; ; Whether to enable or disable UDP checksums on RTP traffic ; ;rtpchecksums=no ; ; The amount of time a DTMF digit with no 'end' marker should be ; allowed to continue (in 'samples', 1/8000 of a second) ; dtmftimeout=3000 ; rtcpinterval = 5000 ; Milliseconds between rtcp reports ;(min 500, max 60000, default 5000) [root@mikeo_asterisk1 ~]# By: Russell Bryant (russell) 2009-02-18 11:50:59.000-0600 Thanks for the feedback! I went ahead and closed it because I was pretty confident that it would fix the issue. Let me look a bit closer and see if I can figure out why it may not be working. By: Russell Bryant (russell) 2009-02-23 17:04:58.000-0600 Alright, I'm about to commit another patch which should fix this. However, if you still have problems, please reopen. Thanks! By: Digium Subversion (svnbot) 2009-02-23 17:09:03.000-0600 Repository: asterisk Revision: 178141 U branches/1.4/main/rtp.c ------------------------------------------------------------------------ r178141 | russell | 2009-02-23 17:09:02 -0600 (Mon, 23 Feb 2009) | 14 lines Fix infinite DTMF when a BEGIN is received without an END. This commit is related to rev 175124 of 1.4 where a previous attempt was made to fix this problem. The problem with the previous patch was that the inserted code needed to go _before_ setting the lastrxts to the current timestamp. Because those were the same, the dtmfcount variable was never decremented, and so the END was never sent. In passing, I removed the dtmfsamples variable which was completed unused. I also removed a redundant setting of the lastrxts variable. (closes issue ASTERISK-13564) Reported by: moliveras ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=178141 By: Digium Subversion (svnbot) 2009-02-23 17:11:38.000-0600 Repository: asterisk Revision: 178142 _U trunk/ U trunk/main/rtp.c ------------------------------------------------------------------------ r178142 | russell | 2009-02-23 17:11:38 -0600 (Mon, 23 Feb 2009) | 22 lines Merged revisions 178141 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r178141 | russell | 2009-02-23 17:09:01 -0600 (Mon, 23 Feb 2009) | 14 lines Fix infinite DTMF when a BEGIN is received without an END. This commit is related to rev 175124 of 1.4 where a previous attempt was made to fix this problem. The problem with the previous patch was that the inserted code needed to go _before_ setting the lastrxts to the current timestamp. Because those were the same, the dtmfcount variable was never decremented, and so the END was never sent. In passing, I removed the dtmfsamples variable which was completed unused. I also removed a redundant setting of the lastrxts variable. (closes issue ASTERISK-13564) Reported by: moliveras ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=178142 By: Digium Subversion (svnbot) 2009-02-23 17:17:32.000-0600 Repository: asterisk Revision: 178145 _U branches/1.6.0/ U branches/1.6.0/main/rtp.c ------------------------------------------------------------------------ r178145 | russell | 2009-02-23 17:17:32 -0600 (Mon, 23 Feb 2009) | 30 lines Merged revisions 178142 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r178142 | russell | 2009-02-23 17:11:37 -0600 (Mon, 23 Feb 2009) | 22 lines Merged revisions 178141 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r178141 | russell | 2009-02-23 17:09:01 -0600 (Mon, 23 Feb 2009) | 14 lines Fix infinite DTMF when a BEGIN is received without an END. This commit is related to rev 175124 of 1.4 where a previous attempt was made to fix this problem. The problem with the previous patch was that the inserted code needed to go _before_ setting the lastrxts to the current timestamp. Because those were the same, the dtmfcount variable was never decremented, and so the END was never sent. In passing, I removed the dtmfsamples variable which was completed unused. I also removed a redundant setting of the lastrxts variable. (closes issue ASTERISK-13564) Reported by: moliveras ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=178145 By: Digium Subversion (svnbot) 2009-02-23 17:23:07.000-0600 Repository: asterisk Revision: 178172 _U branches/1.6.1/ U branches/1.6.1/main/rtp.c ------------------------------------------------------------------------ r178172 | russell | 2009-02-23 17:23:07 -0600 (Mon, 23 Feb 2009) | 30 lines Merged revisions 178142 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r178142 | russell | 2009-02-23 17:11:37 -0600 (Mon, 23 Feb 2009) | 22 lines Merged revisions 178141 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r178141 | russell | 2009-02-23 17:09:01 -0600 (Mon, 23 Feb 2009) | 14 lines Fix infinite DTMF when a BEGIN is received without an END. This commit is related to rev 175124 of 1.4 where a previous attempt was made to fix this problem. The problem with the previous patch was that the inserted code needed to go _before_ setting the lastrxts to the current timestamp. Because those were the same, the dtmfcount variable was never decremented, and so the END was never sent. In passing, I removed the dtmfsamples variable which was completed unused. I also removed a redundant setting of the lastrxts variable. (closes issue ASTERISK-13564) Reported by: moliveras ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=178172 By: Mike Oliveras (moliveras) 2009-02-24 11:20:28.000-0600 russel, I checked out the 1.4 branch and I continue to see the same behavior. Were you able to test the fix? I can reproduce the problem easily be using sipp to play back the audio and 2833 packet form the failed call. I would be happy to test any possible fixes before the ticket is closed. This is the version I am using. Regards, Mike Oliveras mikeo_asterisk1*CLI> core show version Asterisk SVN-branch-1.4-r178266 built by root @ mikeo_asterisk1.wiline.com on a i686 running Linux on 2009-02-24 17:12:07 UTC By: Russell Bryant (russell) 2009-02-24 14:14:59.000-0600 No, I was not able to test this. That has proven to not work very well for me in this case. :-) Thanks again for the feedback. I'll keep poking at it ... By: Digium Subversion (svnbot) 2009-02-24 14:36:34.000-0600 Repository: asterisk Revision: 178373 U branches/1.4/main/rtp.c ------------------------------------------------------------------------ r178373 | russell | 2009-02-24 14:36:33 -0600 (Tue, 24 Feb 2009) | 6 lines Only set dtmfcount on BEGIN, and ensure it gets reset to 0 properly. (issue ASTERISK-13564) Reported by: moliveras Tested by: russell ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=178373 By: Digium Subversion (svnbot) 2009-02-24 14:39:58.000-0600 Repository: asterisk Revision: 178374 _U trunk/ U trunk/main/rtp.c ------------------------------------------------------------------------ r178374 | russell | 2009-02-24 14:39:58 -0600 (Tue, 24 Feb 2009) | 14 lines Merged revisions 178373 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r178373 | russell | 2009-02-24 14:36:19 -0600 (Tue, 24 Feb 2009) | 6 lines Only set dtmfcount on BEGIN, and ensure it gets reset to 0 properly. (issue ASTERISK-13564) Reported by: moliveras Tested by: russell ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=178374 By: Digium Subversion (svnbot) 2009-02-24 14:43:17.000-0600 Repository: asterisk Revision: 178378 _U branches/1.6.0/ U branches/1.6.0/main/rtp.c ------------------------------------------------------------------------ r178378 | russell | 2009-02-24 14:43:17 -0600 (Tue, 24 Feb 2009) | 22 lines Merged revisions 178374 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r178374 | russell | 2009-02-24 14:39:57 -0600 (Tue, 24 Feb 2009) | 14 lines Merged revisions 178373 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r178373 | russell | 2009-02-24 14:36:19 -0600 (Tue, 24 Feb 2009) | 6 lines Only set dtmfcount on BEGIN, and ensure it gets reset to 0 properly. (issue ASTERISK-13564) Reported by: moliveras Tested by: russell ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=178378 By: Digium Subversion (svnbot) 2009-02-24 14:44:35.000-0600 Repository: asterisk Revision: 178379 _U branches/1.6.1/ U branches/1.6.1/Makefile U branches/1.6.1/main/rtp.c ------------------------------------------------------------------------ r178379 | russell | 2009-02-24 14:44:35 -0600 (Tue, 24 Feb 2009) | 22 lines Merged revisions 178374 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r178374 | russell | 2009-02-24 14:39:57 -0600 (Tue, 24 Feb 2009) | 14 lines Merged revisions 178373 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r178373 | russell | 2009-02-24 14:36:19 -0600 (Tue, 24 Feb 2009) | 6 lines Only set dtmfcount on BEGIN, and ensure it gets reset to 0 properly. (issue ASTERISK-13564) Reported by: moliveras Tested by: russell ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=178379 By: Russell Bryant (russell) 2009-02-24 14:46:13.000-0600 I was able to reproduce a problem that I introduced with this code and have committed a patch that resolves it. Can you please test again after that change? If you still have a problem, could you provide an updated packet trace? By: Mike Oliveras (moliveras) 2009-02-24 14:51:22.000-0600 I can test it russel. I just tested your latest patch and it did not seem to be working. Maybe that is expected based on your last note? I will test out your latest fix when it has been checked in and will let you know. If it fails I will also attach an updated trace. Thanks for continuing to look into this. By: Mike Oliveras (moliveras) 2009-02-25 09:27:18.000-0600 I just reproduced the problem using the 1.4 branch, SVN r178508. mikeo_asterisk1*CLI> core show version Asterisk SVN-branch-1.4-r178508 built by root @ mikeo_asterisk1.wiline.com on a i686 running Linux on 2009-02-25 15:17:41 UTC I will attach a packet capture. By: Russell Bryant (russell) 2009-02-26 13:50:19.000-0600 I just did a test using rev 178838 and the DTMF timeout code worked as expected for me. Can you apply this debug patch for your test and let me know what NOTICE log messages you get when you reproduce the problem? By: Mike Oliveras (moliveras) 2009-02-27 08:42:57.000-0600 Russel, I tried your patch with the logging and according to the debug output it looks like it worked, however the DTMF end is NOT actually sent. I am reproducing this issue by playing a pcap file to a sip phone using sipp. sipp -sf uac_talkoff.xml -s <phone number> 192.168.196.40 -m 1 I will attach the logging as well as the files that I am using for sipp. Thanks, Mike Oliveras By: Mike Oliveras (moliveras) 2009-03-21 16:08:32 Is any additional info needed from me, or is it just turning out to be a difficult fix? By: Russell Bryant (russell) 2009-03-23 08:13:51 I appreciate the information you have provided so far. There is nothing more that I need at this time. I just have not had the chance to get back to this. By: Keith Baker (krbaker) 2009-04-23 10:26:26 Hi, I'm also experiencing this issue. I stumbled upon it due to what looks like another (fixed) bug. I have a provider that only sends one end of event packet. On Asterisk 1.4.17 (ubunutu package 1:1.4.17~dfsg-2ubuntu1) it seems asterisk never ends an event with just one end packet - three works just fine. Webex plays a short 1 9 DTMF sequence when you join a conference. This meant that every time one of our users joined a webex conference they would get a never ending DTMF tone. The need for multiple end packets looks fixed on trunk (r189082) so that solves most of this problem. Packet loss is the issue then. No real new additions though. Keith By: Mike Oliveras (moliveras) 2009-05-12 08:41:57 This issue has been resolved with the fix referenced in ticket 14815, so this ticket can be closed. By: Digium Subversion (svnbot) 2009-05-13 08:38:13 Repository: asterisk Revision: 194208 U branches/1.4/main/rtp.c ------------------------------------------------------------------------ r194208 | file | 2009-05-13 08:38:08 -0500 (Wed, 13 May 2009) | 11 lines Fix RFC2833 issues with DTMF getting duplicated and with duration wrapping over. (closes issue ASTERISK-13887) Reported by: geoff2010 Patches: v1-14815.patch uploaded by dimas (license 88) Tested by: geoff2010, file, dimas, ZX81, moliveras (closes issue ASTERISK-13564) Reported by: moliveras Tested by: moliveras ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=194208 By: Digium Subversion (svnbot) 2009-05-13 08:39:18 Repository: asterisk Revision: 194209 _U trunk/ U trunk/res/res_rtp_asterisk.c ------------------------------------------------------------------------ r194209 | file | 2009-05-13 08:39:15 -0500 (Wed, 13 May 2009) | 18 lines Merged revisions 194208 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r194208 | file | 2009-05-13 10:38:01 -0300 (Wed, 13 May 2009) | 11 lines Fix RFC2833 issues with DTMF getting duplicated and with duration wrapping over. (closes issue ASTERISK-13887) Reported by: geoff2010 Patches: v1-14815.patch uploaded by dimas (license 88) Tested by: geoff2010, file, dimas, ZX81, moliveras (closes issue ASTERISK-13564) Reported by: moliveras Tested by: moliveras ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=194209 By: Digium Subversion (svnbot) 2009-05-13 08:40:26 Repository: asterisk Revision: 194211 _U branches/1.6.0/ U branches/1.6.0/main/rtp.c ------------------------------------------------------------------------ r194211 | file | 2009-05-13 08:40:24 -0500 (Wed, 13 May 2009) | 25 lines Merged revisions 194209 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r194209 | file | 2009-05-13 10:39:10 -0300 (Wed, 13 May 2009) | 18 lines Merged revisions 194208 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r194208 | file | 2009-05-13 10:38:01 -0300 (Wed, 13 May 2009) | 11 lines Fix RFC2833 issues with DTMF getting duplicated and with duration wrapping over. (closes issue ASTERISK-13887) Reported by: geoff2010 Patches: v1-14815.patch uploaded by dimas (license 88) Tested by: geoff2010, file, dimas, ZX81, moliveras (closes issue ASTERISK-13564) Reported by: moliveras Tested by: moliveras ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=194211 By: Digium Subversion (svnbot) 2009-05-13 08:41:36 Repository: asterisk Revision: 194212 _U branches/1.6.1/ U branches/1.6.1/main/rtp.c ------------------------------------------------------------------------ r194212 | file | 2009-05-13 08:41:34 -0500 (Wed, 13 May 2009) | 25 lines Merged revisions 194209 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r194209 | file | 2009-05-13 10:39:10 -0300 (Wed, 13 May 2009) | 18 lines Merged revisions 194208 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r194208 | file | 2009-05-13 10:38:01 -0300 (Wed, 13 May 2009) | 11 lines Fix RFC2833 issues with DTMF getting duplicated and with duration wrapping over. (closes issue ASTERISK-13887) Reported by: geoff2010 Patches: v1-14815.patch uploaded by dimas (license 88) Tested by: geoff2010, file, dimas, ZX81, moliveras (closes issue ASTERISK-13564) Reported by: moliveras Tested by: moliveras ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=194212 By: Digium Subversion (svnbot) 2009-05-13 08:42:30 Repository: asterisk Revision: 194213 _U branches/1.6.2/ U branches/1.6.2/main/rtp.c ------------------------------------------------------------------------ r194213 | file | 2009-05-13 08:42:27 -0500 (Wed, 13 May 2009) | 25 lines Merged revisions 194209 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r194209 | file | 2009-05-13 10:39:10 -0300 (Wed, 13 May 2009) | 18 lines Merged revisions 194208 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r194208 | file | 2009-05-13 10:38:01 -0300 (Wed, 13 May 2009) | 11 lines Fix RFC2833 issues with DTMF getting duplicated and with duration wrapping over. (closes issue ASTERISK-13887) Reported by: geoff2010 Patches: v1-14815.patch uploaded by dimas (license 88) Tested by: geoff2010, file, dimas, ZX81, moliveras (closes issue ASTERISK-13564) Reported by: moliveras Tested by: moliveras ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=194213 |