[asterisk-dev] Reception of RFC2833 (DTMF) when dtmfmode=info

[Bryan Boatright]

This might be a bug report, but I'd like your feedback before I claim that.
:-)

 

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 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 was at first skeptical of the report until someone came running to me with
a cordless phone (zap channel bridged to the VOIP provider in question) and,
sure enough, there was a continuous DTMF tone evident.

 

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. 

 

But the reason for the email is to question why Asterisk behaves so badly in
this scenario rather than simply ignoring the RFC2833 packets.  I am using
version 1.4.19.  Does this sound like a bug (i.e., reception of RFC2833
frames when non-codec capability is 0 causes Asterisk to stop transmitting
RTP frames)?  I can provide the packet dump if a bug report seems warranted.

 

Thanks for your feedback.

 

Bryan

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080423/bb849553/attachment-0001.htm