I’m running a fairly recent install, with FreePBX 2.3.1.3 on CentOS 5.x. I’m a bit new to FreePBX but I’ve got things mostly working properly. My one major problem right now is that it’s impossible for a caller to direct dial an extension in this system. As you can well imagine, this is causing problems.
My configuration is such that when a call is answered it goes through some announcements and time condition checks, then if we’re open (according to a time condition) dumps the call in a queue. If we’re not open, it plays back a final goodbye and hangs up. I am not using an IVR. Our old, home-brew, asterisk install (which was done by someone else) had no problems doing this.
I already tried using an IVR as a “work around” but it was unreliable at best. Sometimes it would transfer, other times it would just hang up.
What do I need to do to allow direct dialing either during announcements or while in queue?
IVR is the way to go. Ensure you have your xtn’s on a different range to your options, in other words if you have extensions in the range of 100 to 199, then dont have an option 1 in the IVR.
It will work if you do, but it’s best not to. Also, it works for everyone else so it should work for you.
Build the IVR with the announcement you need, enable direct access to the xtn’s and debug from there - it should work fine.
Finally, what trunks are you using? it may be a DTMF detection problem.
It’s pretty simple: I don’t want an IVR. Even if that was a solution, it wouldn’t address not being able to dial an extension from within the queue. I’m sorry but answering a question with “Don’t use feature X, use feature Y” is like saying “Don’t put the top up to drive your convertible in the rain, buy a new car.”
I had a previously existing asterisk system which did these things with no problem, but it was a config-file only maintained system, and the maintainer left. I don’t have time to figure out all the complexities of configuring by file, so I’ve installed this system. So - don’t tell me “asterisk can’t do that” either.
As for additional details:
Incoming routes: defaults ANY DID goes to my announcement chain which ends up in the queue
Trunks: one PRI and several FXO channels. both can have incoming calls.
Call Path: Announcements -> Time Conditions -> Queue
Outside of business hours, the time conditions route to another announcement that says “We’re closed”, which should also allow for dialing an extension. i.e. “I’m sorry, we’re closed right now. If you know your parties extension please dial it now.” then wait a few seconds and hang up. It does all of that except allow you to dial an extension.
I doubt that the problem is DTMF detection because when I dial “7777” from a SIP extension (which has no problems dialing any other digits, voice mail, outbound calls) the symptoms are identical. Additionally, the same behavior is observed calling “7777” from an FXS extension, as well as dialing in from the PSTN on both the PRI and the FXO channels. In short, I find it extremely unlikely that the issue is with DTMF detection; though I am by NO means an expert and could be wrong.
Actually IVRs are made to work with Queues in the Break Out Menu option of the Queue. As long as the caller knows what button to push (# is the default key used to get to the dial-by-name directory from the IVR) then at any time while in the queue he can dial # or the extension if you allow it. IVR would work the same after hours; according to your time condition it will play your announcements and then put them in the after hours IVR which would tell them your statement “I’m sorry, we’re closed right now. If you know your parties extension please dial it now.” You are asking for menu driven dialing and that is what an IVR is used for; Queues, Ring Groups, Announcements, and Time Conditions don’t have an option where callers can dial. I put your scenario into my test server and it worked. Again if you are having a problem with IVRs not transferring then you need to trouble shoot the IVRs.
your initial post was short on details. No description of what modules you are using, how you have things configured, etc. What you said was “it’s impossible for a caller to direct dial an extension” We are telling you yes it is possible use IVR, You never said you had a customized system that you were trying to duplicate, etc.
You are compairing a highly customized dialplan against a software bundle that is designed to address the needs of the masses in the shortest possible way. Yes * can do it if you can write the code. Can FreePBX do it without using any of the predetermined modules (like IVR) and no custom coding possibly and possibly not.
To try and answer you directly, probably not, but there are ways to make it work if you work with the system. Either way you are goingto need to learn how it was designed to work (that being FreePBX or your old system). In * there is more then one way to play audio. One way is in background (background command) so that while the audio is playing you can program it so that the caller can interact with the system as seen in the IVR, the other way is using the playback command and then while the audio is playing the caller can’t interact with it.
99.5% of us are just other users who are here trying to help but when they details are missing the best we can do is try and provide a answer we think is right until we get better information.
Apparently the only way to do this is to use an IVR, as you have all indicated, so I’ve set up my system to work with an IVR. Though having an IVR with only one option is a bit annoying, as it interrupts smooth call flow and requires interaction from the caller.
In the case of having no other activities other than waiting in queue to talk to someone, why would anyone want to have an IVR in which their caller must press a button and no other options are presented. It’s an annoying interruption to the call flow.
It makes much more sense to me, to simply have an option to allow dialing of extensions when waiting in a queue, rather than having to kludge around it with an IVR.
Though while typing this, I did have an idea:
Get rid of the one option in the IVR, reduce the timeout value, and set the timeout destination as my queue; or have the initial call path dump to the queue anyways, with the breakout IVR simply available while within the queue.
Looks like there’s a bit more flexibility to the IVR options than I originally thought…