[asterisk-bugs] [Asterisk 0012506]: Reception of RFC2833 (DTMF) when dtmfmode=info stops RTP transmission

noreply at bugs.digium.com noreply at bugs.digium.com
Wed May 7 09:16:42 CDT 2008


The following issue has been RESOLVED. 
====================================================================== 
http://bugs.digium.com/view.php?id=12506 
====================================================================== 
Reported By:                boatright
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   12506
Category:                   Channels/chan_sip/General
Reproducibility:            random
Severity:                   minor
Priority:                   normal
Status:                     resolved
Asterisk Version:           1.4.19 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 suspended
Fixed in Version:           
====================================================================== 
Date Submitted:             04-23-2008 14:18 CDT
Last Modified:              05-07-2008 09:16 CDT
====================================================================== 
Summary:                    Reception of RFC2833 (DTMF) when dtmfmode=info stops
RTP transmission
Description: 
A VOIP provider that I have been using for a long time without problems
requires the use of “dtmfmode=info” in sip.conf and this has worked as
expected.

A day or so ago users whose calls were routed via that provider started
reporting that some calls were being disconnected at random intervals with
a continuous DTMF tone being played to users on my end (the remote end
hears silence and then normal line clearing).

I started capturing all packets on the external interface and caught the
next occurrence of the problem.  What I see is that the provider sends an
RFC2833 sequence for DTMF digit ‘A’ (3 “on” packets followed by 3
“off” packets).  Immediately upon receiving the first “on” frame
Asterisk stops transmitting to the VOIP provider and Asterisk plays what I
assume to be DTMF “A” on the Zap channel for around 30 seconds or so
before the call is cleared.  RTP packets continue to come in from the VOIP
provider, but Asterisk never resumes transmission of RTP traffic.  The call
is eventually cleared by the VOIP provider.

This seems like a “bug” on the side of my provider for sending RFC2833
packets when requiring dtmfmode=info.  It also seems suspicious that the
DTMF “A” was sent at all since there is probably no way that the remote
party could generate that event from a standard telephone. 

I believe Asterisk should be more robust in this scenario and not
effectively drop the call.

The packet capture that I have is from Ethereal (in text format,
attached).  I know that is not ideal and I will work to get the debug
information from Asterisk as requested in the bug posting guidelines.  
====================================================================== 

---------------------------------------------------------------------- 
 file - 05-07-08 09:16  
---------------------------------------------------------------------- 
Closed per reporter. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-07-08 09:16  file           Status                   assigned => resolved
05-07-08 09:16  file           Resolution               open => suspended   
05-07-08 09:16  file           Note Added: 0086533                          
======================================================================




More information about the asterisk-bugs mailing list