I am facing a serious problem at an FreePBX installation. First of all, let me describe the topology: I have installed an OpenVox card with 4 FXO ports which are connected to the relative FXS ports on a modem/router given by a local provider. Tjhe problem is that when someone calls and redirected to an internal extension after hearing the IVR (or use the direct dialin) and hangs up before the callee answers the phone keep ringing for about 30-45 seconds (the amount of time that is configured in the general PBX settings). In fact even though it has been dropped for quite some time I watched through Asterisk that it is even unreasonably driven to the voicemail of the internal number that had been called.
I tried the busydetect and busycount but nothing changed. More importantly, I have noticed that the problem occurs only when the call is directed to an internal number after the IVR. When I change the inbound route and the call goes directly to any internal number without the intervention of the IVR then the problem does not incur. Based on this I am drawn to the conclusion that there is obviously something wrong with FreePBX and not the provider.
In addition to the above, another deduction from the tests I made is that if the caller drops the call while the IVR message is in progress then the call (and the dahdi channel) is hanged up with a short perfectly expected delay. So the problem appears only when the call is transferred from the IVR to an internal number. Can anyone help me?
Asterisk is obviously having trouble detecting when an incoming call has been disconnected.
First, note that when your inbound route points directly to an extension, Asterisk does not answer the PSTN line until the callee picks up. So, in that case, Asterisk is merely detecting that the line is no longer ringing. It doesn’t have to detect a disconnect, because the incoming call was never connected in the first place.
Next, IMO jfinstrom is being a little strong about no CPC disconnect is probably the providers fault. Many ATAs built into modems simply lack firmware to signal CPC. If his suggested test shows you aren’t receiving CPC, temporarily connect a line-powered corded phone to one FXS port on the modem. Call it from your mobile. After answering the corded phone and an audio path is established, press and hold a number button. Then, hang up the mobile and note whether there is an interruption in the tone heard in the corded phone’s earpiece. If so, then try to configure the OpenVox to detect what you observed. If not, ask the provider whether they can enable CPC. If not, can they deliver the lines by SIP (or other IP means) instead? That would also improve quality by eliminating both a gratuitous conversion to analog and back to digital, and an unnecessary electrical echo path.
If you can’t make CPC work, your other tests suggest that outbound audio played to the caller is interfering with detection of the incoming disconnect tone. Does the caller currently hear music after selecting an extension from the IVR? If so, try temporarily replacing the music file with one containing silence. If this allows disconnect to be properly detected, we can work on echo, adjusting disconnect tone parameters, adjusting levels, etc.
@stewart1 the equipment is provided by his carrier. This makes it their fault weather a setting or lackluster firmware. Most carrier equipment will have a setting they can flip on. This is not likely something within his direct control .
Most FXS devices at a user level assume there is a human who knows to hangup so by default they have the functionality off.
I finally manage to speak with an engineer of my service provider. He told me that the problem is that freepbx does not recognize the busytone sent by the modem/router. For this reason, he configured the FXS ports to temporalily power off the port so the Elastix understand it and hook on. I made some tests and it seems to work fine. Thank you all for your help.
You can set busydetect which will do that but that is not the correct way to do supervision if you have a choice.
Depending on the provider getting reorder can take up to a minute or more so every channel gets tied up for N seconds after hangup. Busydetect is a last resort not a first option.