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-0600Date Closed:2011-06-07 14:01:00
Versions:Frequency of
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).


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.


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:


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 was released back in November.

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!