[Home]

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-0600Date Closed:2009-05-13 08:42:31
Priority:MinorRegression?No
Status:Closed/CompleteComponents: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