I know there are lots of post RE DTMF problems with asterisk, but I am struggling finding solutions.
I am using the latest stable version of Asterisk and only using ZAP channels (no SIP, IAX etc.) to collect some data via DTMF, then pass this information to a 3rd party telephony system, again via DTMF.
Caller --> Asterisk --> 3rd party system
Tests using SIP for the outgoing branch of the call this works perfectly, but using the PRIs via the fonebridge DTMFs are not detected by the remote system.
Incoming DTMFs are detected by Asterisk fine, but as soon as the calls are dialed outbound the DTMFs are not detected. To my ear they sound distorted and corrupt.
Does anyone have any experience with this? I have tried the usual RELAXDTMF etc.
… I have managed to get the DTMF to work by adjusting the txgain to -7.5.
However, if I set any value to rxgain or txgain in the zapata.conf file then voice is heavily distorted. So the dtmf works now, but normal audio doesn’t.
If a call is coming in on ZAP and routed back out on ZAP, will these gains be applied twice?
It’s okay, no need for you all to reply at once I have managed to resolve this issue!
For anyone who may stumble across this post with the same problem I had to modify the app_dial.c source file to call ast_channel_option to reduce the gain before the sending of DTMF and again to return it to normal.
Feel free to PM / e-mail me if you want the source code.
Simon.
I just noticed we’re having this same problem. I know, 4 years later, but the symptoms described are identical.
Outgoing DTMF works for me about 10% of the time, because it’s all garbled and the equipment on the other end doesn’t “hear” enough of a clean tone. I know this because I’ve called into my answering machine at home (dialing from the Asterisk system at work) and left a message with garbled DTMF tones when I was trying to enter my remote access code.
Not sure if the solution mentioned is the right way to fix it, so… any other suggestions? Maybe DTMF should always be transmitted at some reduced volume level?
Also, is app_dial.c the only place where DTMF tones are generated? What about when DTMF is received from a bridged SIP call to be loaded onto the Zap channel?
DTMF will only work if you either use G.711 codecs, or you use something like RFC 2833 mode. The former are the only common codecs that accurately transmit arbitrary sounds. Many other codecs are only suitable for human speech. The latter decode the DTMF whilst it is still on a good codec and transmit a representation of the digits, rather than the tones, internally.
Mobile phones use the latter type of approach, over the air, and the tones that the caller hears are sent to the earpiece but not over the air.
Garbled suggests to me that you are trying to push tones, in-band, through unsuitable codecs. RFC 2833 and similar fail on Asterisk in terms of tone durations or missing tones, not through what I would call garbling.
Also, please note that Zaptel is obsolete, and I believe no longer supported. It has been replaced by Dahdi, which is partly a rebranding for trademark reasons, but also has significant improvements.
PRIs have no option but ulaw, as far as I know. The DTMF on our SIP phones works perfectly. It’s only outgoing over the PRI that we have problems. My theory is that the DTMF tones are generated at too high an amplitude, and they are being clipped at some point when being loaded on to the PRI. That’s why reducing the gain worked for tbwsimon. I don’t want to reduce our gains, because people already tell us we’re quiet on the line. So I’m wondering if there’s a better way to reduce the DTMF amplitude globally, or if tbwsimon’s patch on app_dial.c is the only way. There isn’t some global setting for DTMF volume is there?
I’ll try to take some time soon and poke around the code myself… if I find anything concrete, I’ll remember to share it.
If you are pure PRI, externally source DTMF will be treated the same as speech.
Internally generated DTMF is injected at the channel boundary in response and internal control message. There are applications that can send DTMF.
A PRI system shouldn’t clip unless someone is playing tricks with gain, as it should normally give a perfect digital copy of the G.711 data.