Summary:	ASTERISK-11903: Reception of RFC2833 (DTMF) when dtmfmode=info stops RTP transmission
Reporter:	boatright (boatright)	Labels:
Date Opened:	2008-04-23 14:18:10	Date Closed:	2011-06-07 14:08:28
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) dtmf_a_bug_1.txt
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.
Comments:	By: boatright (boatright) 2008-04-23 14:24:37 If you look at the dtmf_a_bug_1.txt file, search for "DTMF A" to find the point before which RTP traffic is going back and forth just fine and after which RTP traffice arrives from the VOIP provider but is not transmitted by Asterisk. Again, I am trying to get the packet dumps in the format requested by the bug posting guidelines, but I need to wait for the next complaint before that data will be available. By: boatright (boatright) 2008-04-23 15:34:28 Someone with the same VOIP provider and same problem described here replied privately to me that rfc2833compensate=yes   solves this problem. Given that, I am not sure this issue should be considered a bug.  I'm going to try this configuration option and see if that solves the problem for me (which means that I won't be posting any Asterisk packet dumps if the problem is solved). I'll post another update with my results when enough time has lapsed to be confident in them. By: boatright (boatright) 2008-05-07 09:13:47 An update after several weeks of using rfc2833compensate=yes: That sip.conf option seems to have resolved the bad behavior I found.  This bug report can be closed without any further action as far as I am concerned. By: Joshua C. Colp (jcolp) 2008-05-07 09:16:31 Closed per reporter.