[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 Apr 23 14:59:44 CDT 2008
The following issue has been ASSIGNED.
======================================================================
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: assigned
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:
======================================================================
Date Submitted: 04-23-2008 14:18 CDT
Last Modified: 04-23-2008 14:59 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.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
04-23-08 14:59 file Status new => assigned
04-23-08 14:59 file Assigned To => file
======================================================================
More information about the asterisk-bugs
mailing list