<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="City"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:Arial;}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:#606420;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:Arial;
color:windowtext;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink="#606420">
<div class=Section1>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'>This
might be a bug report, but I’d like your feedback before I claim that.
</span></font><font face=Wingdings><span style='font-family:Wingdings'>J</span></font><o:p></o:p></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'>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.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'>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).<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'>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.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'>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.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'>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. <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'>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.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'>Thanks
for your feedback.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal><st1:place w:st="on"><st1:City w:st="on"><font size=2
face=Arial><span style='font-size:10.0pt'>Bryan</span></font></st1:City></st1:place><o:p></o:p></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt'><o:p> </o:p></span></font></p>
</div>
</body>
</html>