I have an issue which does not appear often , but that is still recurring on my trunk.
So I have a trunk on which Asterisk is installed. Everything works properly except sometimes when someone makes a call on my trunk and hang up (whatever the length of the communication) , Asterisk does not detects that the user in fact hung up and the call continue (phantom call) up to 14400 seconds (trunk limit) and then call is cut.
The trunk provider informs me this issue should come from my IPBX which doesn’t send the BYE.
Is this problem that you guys are aware of ? Have you any idea about the problem’s cause ?
Any help will be generously rewarded with a big thank you !
If the other party hangs up the call then your trunk provider should send BYE to your PBX and not the other way.
If it is you releasing the call then you should collect a SIP trace and see if re-transmission is happening on BYE.
I have a return from my provider. He tells me that my PABX isn’t well configurated for all call terminations … Do you have an idea on what parameter I have to add / delete / modify to handle this ?
What is needed to determine what is going on is the console output of a call that experiences the problem with “sip set debug on” done so we can see the SIP signaling. There’s nothing to control the behavior because that’s what should happen, so something else is going on or something else is misconfigured.
Well, in asterisk logs, when I search for a call with this problem, there is nothing between the supposed time of hang up and the end of the call after 14400 seconds …
You should ask them what they are seeing wrong in your configuration. Once you know that, you can update your configuration.
Further, unless you provide SIP trace for such calls it’s impossible for someone here to help you on this.
Problem is that I’ve looked in my asterisk log files and there is nothing between the supposed end of the call and the moment where my trunk close the channel (at 14400 seconds), not a warning, nothing …
Here is an exemple of a phantom call this morning. Call passed at 09:32, finished at 09:33 but chanel stayed open until 13:32. In my logs I got this when chanel were closed :
So everything seems to work as if the call did last for 14400 seconds except it didn’t, and between the real en of the call and the chanel closing, there is nothing in the logs that relates to this call …
Something funny happened with this thread. A section of log showing a normal remotely initiated hangup, appeared, then went away, but I’m unable to get the unread status on the thread go away.
However, that log section was not useful as what is needed is log showing the event that you believe should have caused Asterisk to hangup, together with Asterisk’s response to that event.
The previous message is temporarily hidden for moderation … it’ll be posted again soon. And as I say in that hidden message, there is nothing in the log before, no action initiated to close the chanel (the chanel is closed because it reaches the trunk max time, 14400 seconds) …
Asterisk can only initiate an action if some incoming event causes it to do so. Without evidence of such an incoming event, Asterisk appears to be behaving correctly.
Hangup on polarity switch is useful if the first to hangup call is on a DAHDI analogue line from a PSTN exchange and that exchange supports that method of signalling disconnect supervision. No battery is rather more common.
Enough information to understand how you are connected to both called and calling parties and how hangups are supposed to propagate through your system. You seem to be connected to one by SIP, and the question you just asked seems to suggest another one is connected over an analogue line.
Details of the supplier and product for the non-SIP connection (example supplier: British Telecom. example product: standard domestic analogue line). Ideally some technical details (in my case System Y exchange) as they can affect the choice of signalling options.
The section of the dialplan that should be handling the hangup.
Note that, in general, PABXes will not provide disconnect supervision over analogue lines, so in that case, there may be no solution.
Also, note that, if you are using something like FreePBX, we are not experts on FreePBX dialplans. However, it is probably reasonable to assume that their dialplans simply forward hangups from one party to the other.
(Generally, you seem to have been assuming that everyone knows exactly how your system is constructed. Asterisk is a tool kit and you can make many different systems using it.)
Here is my configuration :
Asterisk 13.3.2 installed on an OVH dedicated server running CentOS release 6.6
Calls are made on the SIP trunk from mobile or non-mobile line from french operators.
Section of the dialplan which handle the hangup is : exten => h,1,agi(script.php,${call_id},${CDR(duration)},${CDR(billsec)})
I doubt my problem could come from my dialplan since some most calls works fine.
Please expand on the following. I still can’t work out your configuration. Preferably provide any of sip.conf, pjsip.conf, chan_dahdi.conf that are used in your system (and any other similar file that is used).
Calls are made on the SIP trunk from mobile or non-mobile line from french operators.
Please provide the part of the AGI script that makes the call.
Please clarify whether it is the caller or the called whose hangup is being ignored.
You talked about hangup on polarity, which can only appear in chan_dahdi.conf, but you have not provided that file (and from your subsequent answers, it is non sequitur).
The AGI script should exit and hangup. If it doesn’t the call will only hang up when the caller hangs up. If you don’t understand why the script is not terminating, you need to provide us with at least the main loop logic from the script.
Even if it does, it can take up to three minutes for the network to release the call if party A doesn’t.
I’m surprised that your callers don’t give up more quickly.
If the caller really is hanging up, then your ITSP is at fault if it does not immediately send BYE on the leg that is incoming to you.
I’m assuming these are real incoming calls and not calls from call files or originates. Your BYE transcript is too obfuscated to work out whether the Call ID comes from Asterisk or xxx.
