Direct dialing not so direct

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 [[email protected]:1] ExecIf (“Zap/2-1”, “0|dbDel|”) in new stack
[Mar 9 11:10:32] VERBOSE[20796] logger.c: – Executing [[email protected]:2] Set(“Zap/2-1”, “__NODEST=”) in new stack
[Mar 9 11:10:32] VERBOSE[20796] logger.c: – Executing [[email protected]: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.

Any ideas on what I should try next?

Thanks,
James

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?

Any help on this would be appreciated.

Thanks,
Robert

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.

As you see, I’m grabbing at straws here. Thanks for the response. I will be testing momentarily.

And how do I roll back to a previous version of Asterisk. I know researching that would not kill me, however we are just this side of panic mode.

Thanks,
Robert

I eventually found relaxdtmf=yes and added it to zapata.conf a few days after my original post. I haven’t had any complaints about this issue since.

OK, the logging is showing the wrong DTMF is getting to the dialplan. I enter 107 and the log shows 110 was entered.

Now where do we go? Is this where we back out of this version of asterisk?
Asterisk 1.4.21.2
Zaptel 1.4.12.1

Thanks,
Robert

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.

Thanks for your help,
Robert

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.

After a complete reload from the latest 1.4 pbxinaflash, I am still having the same problem. Any ideas?

Robert

I added relaxdtmf = yes to /etc/asterisk/chan_dahdi.conf. It fixed the problem

This is a very old version of Asterisk. Lot’s of DTMF fixes have been integrated since it’s release.

I would strongly advise running 1.4.36

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 ?