[asterisk-bugs] [Asterisk 0014460]: Asterisk plays a continuous tone forever if it never receives a 2833 end packet

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14460 
====================================================================== 
Reported By:                moliveras
Assigned To:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   14460
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.21.1 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-02-11 14:46 CST
Last Modified:              2009-02-23 17:23 CST
====================================================================== 
Summary:                    Asterisk plays a continuous tone forever if it never
receives a 2833 end packet
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.

====================================================================== 

---------------------------------------------------------------------- 
 (0100594) svnbot (reporter) - 2009-02-23 17:23
 http://bugs.digium.com/view.php?id=14460#c100594 
---------------------------------------------------------------------- 
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 http://bugs.digium.com/view.php?id=14460)
Reported by: moliveras

........

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=178172 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-23 17:23 svnbot         Checkin                                      
2009-02-23 17:23 svnbot         Note Added: 0100594                          
======================================================================