Summary:	ASTERISK-15256: Asterisk detects DTMF inband even when dtmfmode=rfc2833
Reporter:	Benny Amorsen (amorsen)	Labels:
Date Opened:	2009-12-02 06:28:18.000-0600	Date Closed:	2011-06-07 14:01:00
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/CodecHandling
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When Asterisk has a peer with dtmfmode=rfc2833, it should not react to inband DTMF. Unfortunately, it does. The problem happens when using the Dial option t to allow the callee (B) to transfer the call. When that is done, Asterisk starts interpreting DTMF in order to detect the transfer button presses. At the same time, Asterisk strangely turns into an inband-to-rfc2833 gateway, even though both caller (A) and callee (B) are speaking rfc2833. When the CALLER (A) noises resembling DTMF, those get translated to rfc2833 DTMF, which can be quite annoying especially when the noises weren't DTMF in the first place. I have a tcpdump showing no rfc2833 frames coming from the caller but rfc2833 being sent to the callee (B). Asterisk 1.6.0.18. Reproduce by setting up two SIP phones with dtmfmode=rfc2833, call from one to the other and make sure that Dial has options tT. Then play DTMF-like noises through one of them. Dump packets going to the other phone and notice how no rfc2833-frames are sent from the phone to Asterisk, but rfc2833-frames are sent to the other phone. ****** ADDITIONAL INFORMATION ****** There are two extra bugs here for good measure: Asterisk shouldn't try to handle DTMF coming from the caller (A) when dial option t is set, that should only happen with dial option T. Only DTMF coming from the callee (B) should be interpreted. Asterisks inband DTMF handling should not mistake noise (especially not voice) for DTMF.
Comments:	By: Elazar Broad (ebroad) 2009-12-02 09:54:27.000-0600 What is 'dtmf' set to? By: Benny Amorsen (amorsen) 2009-12-02 14:40:39.000-0600 How do I tell? All I know is this: sip show peer lpbx01 [..]  DTMFmode     : rfc2833 [..] By: Elazar Broad (ebroad) 2009-12-02 16:31:16.000-0600 In your sip.conf under general or under the peer definition, is dtmf set to auto or rfc2833? By: Benny Amorsen (amorsen) 2009-12-03 02:07:04.000-0600 dtmfmode is set to rfc2833 in the [general] section, but isn't set in the peer definition. By: Elazar Broad (ebroad) 2009-12-03 10:09:06.000-0600 Try setting: dtmf=rfc2833 under the general section... By: Benny Amorsen (amorsen) 2009-12-03 12:05:15.000-0600 There is no such thing as a "dtmf" setting, at least according to both the example sip.conf file and voip-info.org. By: Elazar Broad (ebroad) 2009-12-03 12:23:15.000-0600 I stand corrected, not sure where I saw that. Do you have relaxdtmf set? By: Benny Amorsen (amorsen) 2009-12-03 12:32:11.000-0600 Crap, relaxdtmf is set to yes. Turning it off now. By: Benny Amorsen (amorsen) 2010-01-06 04:57:17.000-0600 With relaxdtmf=no the problem is gone as far as Asterisk is concerned. Sorry for the inconvenience. We still have the problem, but that is because one of our providers mistakenly generates DTMF. It took a long time to prove that the tones came from our provider unfortunately. This bug can be closed unless someone feels that Asterisk shouldn't try to turn inband DTMF into RFC2833 DTMF when relaxdtmf=yes. I don't really care much either way; relaxdtmf=no does not cause me any trouble. By: Elazar Broad (ebroad) 2010-01-06 16:49:43.000-0600 Do you have faxdetect=yes in your sip.conf? By: Benny Amorsen (amorsen) 2010-01-06 17:29:24.000-0600 grep -i 'fax.*=' /etc/asterisk/sip.conf comes up empty. It does on the sample configuration file too, so there doesn't By: Benny Amorsen (amorsen) 2010-01-06 17:30:22.000-0600 (Sorry about the previous note) grep -i 'fax.*=' /etc/asterisk/sip.conf comes up empty. It does on the sample configuration file too, which is a bit odd. Perhaps it was added after 1.6.0.x? asterisk -rx 'sip show settings'|fgrep -i fax comes up empty as well. By: Elazar Broad (ebroad) 2010-01-07 10:26:52.000-0600 Interesting, that patch was committed over a year ago, and I believe 1.6.0.18 was released back in November. https://reviewboard.asterisk.org/r/69/ and the commit: http://lists.digium.com/pipermail/asterisk-commits/2008-December/028393.html By: Leif Madsen (lmadsen) 2010-03-23 09:47:05 Looks like there is no change required on this issue. If I am mistaken then please reopen the issue. Thanks!