Since cutting over to a PRI last week, we’re having an intermittent issue with the IVR. It seems like the first digit entered isn’t registering.
In this install all the extensions are in the form 20x. There is “Press 0 for Operator” option in the IVR as well as the option to call the extensions by entering them.
On the affected calls, the caller pressed the extension, say 207, but is routed to the 0 option.
I tried changing the 0 option to 8. When I did this the affected calls looped in the IVR greeting, as the setting for invalid entry is to return to the IVR.
Not all calls do this. At this very moment the only repeatable source is the Comcast PRI tech support phone system. They can make the problem happen every time, but it’s not an issue calling in from another office or from a cell phone at this time (it was earlier).
All patched up to the current distro release.
This wasn’t a problem until last week when we did a backup/restore of the VM to dedicated hardware and switched from SIP trunks to the PRI.
PRI card is Digium. I had them review it earlier and they couldn’t find an issue.
What type of card are you using. Also I see this alot with comcast PRI as they are not true PRI but VOIP to a gateway that converts it to PRI and in that conversion it gets lost. Never been able to resolve it for a customer.
Well if you had a Sangoma Card you could actually record the audio before it enters DAHDI and then listen to the DTMF coming in with a decoder. Not sure how you would do that without a sangoma card as I am not aware of a way in dahdi to get the audio before it hits asterisk.
I guess that’s a lesson for next time, though I will say that Digium has been, by FAR, the most helpful with the problem. They’ve gone out of their way to assist in pretty much any way I’ve asked.
I did speak with Comcast again this AM. After telling me last week that there was nothing they could do, today the engineer was aware of and changed a DTMF relay setting on their Adtran to 250ms.
Ironically, last week the only source from which we could consistently reproduce the problem was the phone system that the Comcast engineer was using and since the change they made today we’ve had no further occurrences, even from Comcast’s phone system.
I’m seeing things like this pretty consistently:
DTMF end ‘1’ detected to have actual duration 70 on the wire, emulation will be triggered on SIP/202-0000000e
[2012-09-10 10:53:16] DTMF[27339]: channel.c:4067 __ast_read: DTMF end ‘1’ has duration 70 but want minimum 80, emulating on SIP/202-0000000e
It is totally possible to monitor and record, either in or out or blended audio streams with dahdi before it gets to asterisk. both before and after the echo canceller kicks in.
Ref:
man dahdi_monitor
toneduration=100
is a safe addition to the configs for generation, For detection you are dependent on the whims of the sender. 80 milliseconds is generally accepted as the standard but some vendors use less.
Hmm . . . So the sangoma driver records it before it gets to the Sangoma driver? That’s damn clever!! The pre echo canceller records are of course exactly the same as the wanpipe recordings if you don’t use wan"pipe" before dahdi, as it says it is raw.
Also, to my knowledge, dahdi is a channel driver and knows absolutely nothing about asterisk so anything that is part of dahdi is definitely pre asterisk inbound and post asterisk outbound.