Dont know when this started to happen in V2.5 or V2.4 - but about a month ago - I added new (4 Digit) extensions such as 2126, 2128, etc. It so happens we also have a (3-Digit) extension such as 212
In the IVR if someone dials 2126, the system immediately transfers the caller to extension 212, and ignores the last and 4th digit.
I had to temporarily delete extension 212 for now to make it work preperly
Is there a solution for this behavior ?
If a caller dials a 4-digit extension - the system should wait for the caller to finish dialing before it transfers a call, the way it is working now - it immediately detects a valid extension (such as the first 3 digits) and it immediately transfers the caller to the 3-digit extension.
I’m not sure it is a bug. I believe it’s an intentional design function. The way I look at it, the person calling into the ivr is not initiated into how the system operates. They don’t have the “SEND” or “DIAL” button on their phones to signify the end of dialing…Neither would you want them to wait the 4 seconds or so it takes for dialing to time out and proceed. It’s pretty easy to address these two issues when you install a phone within your organization. It’s near impossible to make a caller from outside understand the constraints of the Asterisk system. I think the designers Asterisk took a good course when they made it so that the first extension match from an ivr immediately completes the call.
In some ways, you may have made a tactical error. For the sake of consistancy, I wouldn’t design a phone system with a mix of various extension lengths, beyond that I certainly wouldn’t have a 212 extension and 212n extensions. You’re asking for trouble and confusion.
I’m not trying to be insulting, but only offering a word of advice.
Also - how about when a caller is greeted with the IVR Greeting, Digits accepted during the greeting are ignored, until after the greeting is finished, and as a result - the system transfers incomplete and/or missing digits when the transfer initiates.
Just tried that on mine. I can overdial at any time during the greeting. There’s a setting in the IVR settings something like allow extension dialing or something like that. Sorry I can’t look at my system from where I am this morning… Maybe that setting has something to do with your problem. I’m at a remote site installing a microwave link for data, but hope to have this wrapped up in a couple of hours, so when I get back to the office I’ll look and see the exact setting. Don’t know whether or not that setting will help, but it’s worth a try.
Not accepting dtmf tones until the end of the greeting/announcement is a classic mis-match of DTMF settinge between the remote end and the local end. Check with your provider of your trunk and make sure that it is set to match what they are providing to you.
Who is the Remote End - the Phone Provider ?
Who is the Local End - the PBX Software ?
What do I tell the Phone Provider to check ?
The minute I tell the Phone Provider this issue -
they will blame it on the Software and the PBX System,
and they will claim that it does not have anything to do with their service
The fact that it works only after the IVR Announcement and not during,
(Which are both controlled by the Software) tells me that
it has something to do with the Software setup.
If it is the DTMF Signal coming from the Phone Provider -
then what settings should it be set at ?
How do you setup the DTMF Signal ?
How would I check the DTMF Signal in the PBX software ?
the allow extension dialing is for exactly what it means. You can allow or NOT allow direct dialing of defined extensions. It is there for those that build IVR’s that they want people to use them and NOT be able to dial Bill directly for example.
local end is your server.
Remote end is your provider.
If you call and ask what is the DTMF signaling you are using for my connection and they start by blaming the software you have a BAD provider and should get another one. They should understand they need to provide this information so that you can match it on your side otherwise it will not work as expected.
DTMF signaling (See http://en.wikipedia.org/wiki/Dtmf) can do inband and out of band signaling and what you need to know is how they are sending it to you so that you can tell the server how to expect it and watch for it.
It’s like I say I’m sending you something be ready for it. You ready? Or would you like to know how it’s going to arrive at your door? It could be electronic, Physical, via snail mail, Fed-x, DHL, Military air drop, Tractor Trailer, etc… You get the idea.
You’ve told us noting about your provider and the trunk you have butt I’m guessing it’s sip as that is where 90% of these complaints come from.
Yes it happens to be a software setting for your carriers trunk but it has nothing to do directly with the IVR, you’ll find the same issue in vociemail, etc. It has to do with how you tell asterisk to go about looking for and listening to those signals. When audio is being played unless you tell the server it also has to listen on the inband audio channel it will NOT as it knows there is noise there. When nothing is playing it will listen and some part of the system might hear a signal and process it into a tone that can be used.
The only difference between a T1 and PRI is a PRI uses one of the data channels for signaling, control, DID info. So when you get a PRI you have (size of T1 -1) in B channels (the channels that take the calls) and One D channel. If it was a full T1/PRI that would give your 23 channels and 1 D channel. with a T1 you gave up the D channel for a B channel and receiving that signaling in the channel itself.
Call XO and ask as I do not have service from them to know what DTMF signaling format they are providing you. It could be inband, outofband, rfc2833, auto, etc. I can only guess sitting here while you could have answered this question days ago with a 5 minute phone call to support. Support at XO does know how to make things work with Asterisk based on several other posts I’ve seen…