We’ve recently installed a new phone system based on Asterisk and FreePBX (PBX in a Flash distro.) Just about everything is working as expected except direct dialing from our IVR. I’ve been getting reports that people call in and dial an extension but get a different extension. At first I thought the callers were just dialing the wrong extension or fat-fingering it, but I’m getting more and more reports of it. I haven’t been able to duplicate it myself.
We have about 80 extensions (mostly Aastra 57i)
We have 2 PRIs from the local telco going into a digium TE220B
Here’s a snippet from the logs:
[Mar 9 11:10:25] VERBOSE[20796] logger.c: – <Zap/2-1> Playing ‘custom/mainmenu’ (language ‘en’)
[Mar 9 11:10:32] VERBOSE[20796] logger.c: == CDR updated on Zap/2-1
[Mar 9 11:10:32] VERBOSE[20796] logger.c: – Executing [111@ivr-2:1] ExecIf (“Zap/2-1”, “0|dbDel|”) in new stack
[Mar 9 11:10:32] VERBOSE[20796] logger.c: – Executing [111@ivr-2:2] Set(“Zap/2-1”, “__NODEST=”) in new stack
[Mar 9 11:10:32] VERBOSE[20796] logger.c: – Executing [111@ivr-2:3] Goto(“Zap/2-1”, “from-did-direct|111|1”) in new stack
[Mar 9 11:10:32] VERBOSE[20796] logger.c: – Goto (from-did-direct,111,1)
The system thinks the caller dialed 111, but the caller claims to have dialed 109. This caller called at least 4 times, supposedly dialing 109 each time, and always ended up at 111.
So far, only 2 users have reported getting calls for the wrong people. They’re at extensions 111 and 142 and have each gotten 6-10 misdirected calls in the past week (since we put this into production.) They’ve each received calls destined for a variety of other extensions with no discernable pattern. I’ve had no reports of this happening with DIDs, only when dialing extensions from the IVR. I’ve checked VmX Locator and FollowMe settings to make sure my users didn’t misconfigure something, but those are fine.
I’m having the same problem as jrevans. People are dialing in to an IVR then while it is playing a message they attempt to dial through to an extension and they get extension 111. What’s so special about this extension?
Try putting relaxdtmf=yes in the zapata.conf file and see if that helps. There is also a known issue in SIP that causes machine gun DTMF on Asterisk 1.4.21.2 and earlier.
first make sure you have appropriate logging on. In your logger.conf file, an entry that looks something like:
full => notice,warning,error,debug,verbose,dtmf
would be good, the important thing being the dtmf if it is not there. That should allow you to see the dtmf digits as they are pressed in the log file to see what is actually pressed.
If you find they are hitting the digits correctly, check what version of Asterisk you are running. There is an issue in 1.4.24 which effects the Background() command. Although the bug is not known to create an issue for the dialplan that is in the ivr code, it’s not out of the question. You can role back to 1.4.22 which did not have the issue.
I forgot to add, my system uses 7 pots lines in running through 2 zaptel 4 port boards, 7 FXO ports and 1 FXS port. The inbound DTMF is from the PSTN and not the gateway provider.
Robert, I have several machines running that version of Asterisk. It is the last version that supports Zaptel. If relaxdtmf=yes did not resolve it, try reducing or increasing the rxgain setting in zapata.conf. It may be that the PBX simply can’t hear the tones or that they are too loud and distorting.
It is my understanding that the rxgain is adjusted in decibels, so a little goes a long way. If it is currently set at 0.0, I would try -1.0 and see if that helps. I suspect that the tones are too loud and distorting which is why you are seeing repeating digits.
I am having a similar problem - Asterisk collects incorrect DTMF digits for callers in IVR.
I want to add relaxdtmf=yes, however my system does not have zapata.conf. We are running Asterisk 1.4.24, FreePBX version 2.5.2.3. In this version zapata has been replaced with dahdi. Which config file should I update with relaxdtmf=yes ?