Hi all,
I know that this is a know issue but I still can’t find a solution to this behavior.
We use asterisk 1.2.7.1, compiled from source. We need this versions because we use also asterisk agents. The scenario is an asterisk server, with two net nterfaces: one on the local net and one on Internet, with a public IP and protected with iptables. The server is a Debian Sarge 3.1 with kernel 2.6.18-4-686, directly from debian resources. We have a couple of VoIP providers like Eutelia and Voip4biz registered through the public net interface and few IP Phones Snom 300 and Snom 320 connected on the local net side of the server.
The problem is that randomly, one of the member of a call hear a beep followed by a second of silence.
We looked around the Forums and the net and seems it’s asterisk that is recognizing voices as DTMF, by mistake. So, what we did is:
tried the relaxdtmf=yes in sip.conf but seems that in asterisk 1.2 does not have meaning yet.
tried the different values of dtmfmode=[info|rfc2833|inband]. The result is that all the methods works as expected but the random Beep appear anyway.
tried to rebuild asterisk after modify the dsp.c file, like described here astrecipes.net/index.php?n=248 The random Beep appear anyway.
So, my question are:
is there a way to stop asterisk from listen for the DTMF tones during a call?
Does anyone has any other suggestion?
Thanks in advance.
Ex. sip.conf
[general]
general=true
number=00
port=5060 ; UDP Port to bind to (SIP standard port is 5060)
bindaddr=0.0.0.0 ; IP address to bind to (0.0.0.0 binds to all)
srvlookup=no ; Enable DNS SRV lookups on outbound calls
nat=yes
externip=XXXXXX
localnet=YYYYYYYY/255.255.255.0
language=it
disallow=all ; Disallow all codecs
allow=alaw ; Allow codecs in order of preference
allow=ulaw ; Allow codecs in order of preference
allow=gsm
register => XXXXXX:YYYYY@voip.eutelia.it/XXXXXXX
Thanks, I already checked this thread. We don’t have Munin or webmin on the server. We don’t have also a Xserver on it, only a Debian Sarge+Apache+postgres+PHP.
I can say that We are using the module ztdummy to have a clock source, even if no zaptel devices are actually installed on the server.
We are now trying a configuration with a sip.conf with the dtmfmode=rfc2833 and asterisk rebuild with the dsp.c file modified to lower the DTMF sensibility.
Do you have any experience on it?
Thanks.
Really there isn’t a way to stop asterisk 1.2.X from listen for the DTMF tones during a call?
Seems that our last configuration limited the beeps problem but it’s not completely solved yet. We put the parameter dtmfmode=rfc2833 on the sip.conf (general section and peer section, even if should be the default).
We also modified the asterisk source file dsp.c in the following way:
First I’d like to point out, that I have little experience with Asterisk. I have installed and tested it several times in the past, but have never deployed it in a production environment. I have a decent amount of experience installing proprietary VoIP capable PBXs, as I do it for a living. That said, I have experienced this before and might be able to at least explain it…
Unexpected DTMF tones during a call are known as Talk-Off. I’ve seen it happen with voicemail systems, IVR systems, and various VoIP equipment…sometimes even a cell phone. The above mentioned equipment is always monitoring the audio for DTMF…since it almost always needs to react to such input. For example, if you’re calling your bank to check your balance, their IVR system must be able to recognize DTMF digits in order to get you in the right direction, authentication, etc. Because so many phone conversations have varying degrees of quality, this equipment must have an understanding of perfect DTMF generation…as well as have a certain range of tolerable distortion of the tones. In another example, VoIP equipment often listens in-band (same audio path as your voice) for DTMF so it can recreate the tone on the trunk interface…really just to ensure a nice clean DTMF tone. This is especially nice when voice compression is used, and compressed DTMF would be far too distorted for far-end equipment to recognize. Same thing often happens with cell phone calls. You may think your dialpad on the cell phone is generating the DTMF tones, but in reality, it’s the carrier’s switching equipment receiving a command out-of-band from the phone and recreating it on the back end.
Now that we have that out of the way…
Sometimes during a VoIP call, human voice may sound very close to a DTMF tone. It’s most common when women are using the phone, and men’s voices are often too deep in pitch to experience Talk-Off. The voice encoding/decoding equipment or codec software will ‘hear’ something it thinks is a touchtone, and spontaneously recreate that tone in a nice, clean and clear fashion.
Nowadays, proprietary software and equipment handling VoIP traffic typically doesn’t have this issue…at least the equipment I work on. It used to be an issue, but seems to have been remedied by advancing technology. I would not be surprised if Asterisk either already has, or will make improvments to reduce the likelyhood of Talk-Off.
Hope this at least helps you understand what’s going on.
Hello, I am sure I don’t have to tell you how annoying this is. I have rebuilt my asterisk box in an attempt to fix this. The only config files I kept were my extensions.conf, sip.conf, unistim.conf and the $#@%ing problem has followed me.
So, my question is, I notice you stopped posing about this, it is my hope that you have managed to resolve the issue. If you could please share your solution if you have one. If not, thanks anyhow.
Only the inband option would make Asterisk vulnerable to detecting DTMF. Detection with the other two options suggests a problem with the sending phone. (Actually, I’m not sure that the dtmfmode setting is communicated to the phone. You may have to set up the phone properly.)
If you don’t want to detect DTMF, but are operating in a pure SIP environment, you can arrange for Asterisk (at least Asterisk 1.4, which is the earliest supported version) to re-invite the connection, so that Asterisk never sees the DTMF. However, this will not prevent the source phone from detecting DTMF and signalling it to the other phone. Re-inviting may be compromised by your NATting arrangements.
Even if there is a problem in Asterisk, it will not get fixed in version 1.2, as that is “end of life”.
I’ve managed to limit the problem but it’s not yet solved for me. I did the following steps:
rebuild asterisk with the modified dsp.c (as explained before)
configured “dtmfomde=info” on all the Sip Gateways and Voip appliance, inside my sip.conf file.
Changed from DTMF=RFC2833 to DTMF=info on all the SIP registered appliance, Voip Phone and all.
Those steps managed to limit the problem but still sometime a “beep” is heard during conversations, followed by a second of silence.
NOTE: i can’t configure the dtmfmode on the external and sip registered Voip Providers because dtmf driven IVR will not work anymore.
Sure we are planning to go with asterisk 1.4 in a pair of month. Hope that it will limit even more this problem.
I have two Asterisk installs, one is 1.2 and the other is 1.4.22.1. Both boxes exhibit the problem described in this thread. Also, once in a while, a call will randomly attempt to transfer. I’m not sure if it happens when the box thinks it hears a ‘#’ but I suspect so. Don’t be surprised if moving to 1.4 does not cure the problem. As someone else pointed out, it may be an ATA or something other than Asterisk that’s at fault. I will continue to investigate and post anything I find.
I’m having right now the same problem you had so long ago. It’s not really a DTMF tone but kind of a beep followed by a couple of seconds of silence. Only us can hear it, not the people we are talking with. We tried everything but the problem still persists. Could you finally solve this issue? What was the problem?