Summary:ASTERISK-14213: Inband DTMF Double digits being sent.
Reporter:Ken Leland (kenlee)Labels:
Date Opened:2009-11-13 12:04:29.000-0600Date Closed:2010-04-27 12:46:15
Versions:Frequency of
Description:When dtmfmode is set to inband for SIP, and a zap channel is bridged with the SIP channel, and the user on the zap channel side presses a digit, you can hear the DTMF digit twice in the audio stream. This happens while Asterisk is parsing the DTMF. For a fraction of a second, while the end user generated DTMF is being detected, the DTMF is passed inband. Once the DTMF is detected Asterisk silences it and regenerates it. Sensitive machines like auto attendants pick up both the brief end user generated tone as well as the full length asterisk generated tone and ultimately perceive each digit twice.


This was reported in 2007 for asterisk 1.2 but was closed as "won't fix."  You can hear the brief initial unwanted digit with your ears every time.  However it seems the length of that digit determines whether sensitive equipment picks it up as a digit or not.  We measured the effect of this bug with a Metro-Tel Corp Digit Grabber, Model TPM32.  We were able to detect 5 out 100 double digits very reliably.

Really what we want in our application is for asterisk *not to detect, silence, and regenerate dtmf.*  We especially don't want it because it is not reliable, but also because we do not need asterisk to do anything with the dtmf and only want to pass it through like the rest of the audio.  This site describes a hack to acheive this:


Though I'm sure an option to disable DTMF detection, silence and regeneration would be preferred by the community.  What about an option: dmtf_dection=off, which causes dtmf detection to be disabled on bridged channels, where both channels have dtmf set to inband?  

I can work on this if it sounds like a good direction to you guys?
Comments:By: Ken Leland (kenlee) 2009-11-13 12:11:05.000-0600

This is the same bug as described here:

By: Ken Leland (kenlee) 2009-11-13 16:22:41.000-0600

I suspect this bug is categorized wrong:/ I'm not sure where it should have gone.

By: Ken Leland (kenlee) 2009-11-14 15:41:02.000-0600

I tested this with the latest asterisk16 packages from the packages.asterisk.org repository and was still able to reproduce the double digits.

Here is the installation i just tested where the double digits were still exhibited:

I will retest the trunk, perhaps there was an error in that test and it should be disregarded.  I have deleted that post (0113819) from this ticket for now until i retest and confirm.

By: Ken Leland (kenlee) 2009-11-16 08:21:51.000-0600

ARGG, my test in post 0113835 was flawed and needs to be disregarded.

By: Ken Leland (kenlee) 2009-11-16 08:26:16.000-0600

I restested the trunk (230247) and was able to pass the digits straight through.  I debugged the channel in the console and confirmed that the digits were being detected, yet asterisk was not silencing and regenerating them.  I will investigate the difference between my asterisk16 package installation from post 0113829 and my installation from the trunk to see if it is a code difference or a config difference.

By: Ken Leland (kenlee) 2009-11-16 08:45:23.000-0600

I tested trunk (230247) and asterisk16- with the same configs.

asterisk16- - got double digits
trunk (230247) - audio passed straight through

By: Ken Leland (kenlee) 2009-11-16 09:30:58.000-0600

I confirmed this is working in the latest version (227757) of the branch.

By: Leif Madsen (lmadsen) 2009-11-16 10:23:50.000-0600

Are you saying this issue can be closed as working in

By: Ken Leland (kenlee) 2009-11-16 10:31:57.000-0600

yes, that is correct.

By: Leif Madsen (lmadsen) 2009-11-16 10:54:57.000-0600

Thanks for the follow up!