Hey there,
here I am, back again with dropped calls…
Since the last time (which turned out to an issue with the appliance itself), I’ve bought a new server for FreePBX and made a completly fresh install, configuring everything from the ground up so there are no “leftover” testing/troubleshooting configurations from the last time.
I’m now using Stun and, since my registration is outbound, am no longer forwarding any ports to my PBX.
It has never been as stable as it is right now and I’m extremly happy with the result.
However, today I got the notice from a colleague that he had three calls drop - two standard calls and one conference.
All three were Inbound, from the same caller. My colleague described it like this:
During the first call, he couldn’t hear anything for about 1 minute, then he hung up.
The second call dropped mid sentence. The third one was a conference, where alledgidly he couldn’t hear anything for 10 seconds, then he hung up aswell.
I wouldn’t give too much for his sense of time, but this is how he described it to me.
Since it’s definetly impacting our work, I’d just ask you to maybe take a look at the logs (provided here) and tell me if you can find anything that could be the reason for this behaviour.
I’ve read them over and over and couldn’t find anything indicating an issue.
I certainly don’t want to rule out the possibility of the callee being the source of the drops, however I still want and have to investigate if the problem could be on our side.
There is nothing in the call logs inditing anything other than a normal channel clearing. Generally you will want your RTP port range forwarded, see the test in this post: SIP Port Forwarding
Thank you very much for your fast response! I’m impressed
I’ll forward the RTP-Portrange (10k-20k) and will report back if that solves the issue or not.
Assuming it doesn’t - is there anything else I should look out for (Firewall, Sip config) or is it unlikely to be an issue on my side?
Edit: I’ve just been informed, there were two external members in said Conference (I’ve cut out the first one joining from the log). So it’s no longer a possibility of an issue with the callee’s phone system. There has to be something wrong with my setup or something else in between.
I would be surprised if it fixes, but I am surprised almost daily by what I don’t know. You are going to have to look at the signalling. It looks like extension 203 dropped the call first in all 3 cases. Do a search for ‘left’, it’s not proof, but a good indicator.
But even if the extension 203 should’ve dropped the calls (looks like it did in the logs), why did both other members get dropped out of the conference? This doesn’t add up. In the two calls, yes, would certainly make sense. But not in a conference server, configured to stay up no matter what.
Okay, I found out something very interesting.
I’m currently concentrating on the conference and dove a bit deeper into the logs, finding entries after 13:18:33. I’ve added them to the logfile, starting at 13:18:37.
What’s interesting:
All conference members (my colleague and both external members) reported to have been dropped out at exactly 13:18:33. However, according to the log, the first member left at 13:34:39 and the second at 13:44:03. So there’s a difference of almost half an hour between the call actually dropping and the server noticing it, which I have absolutley no explanation for whatsoever. Any ideas regarding that?
That’d very much explain the silence at least. My colleague was still in the conference and since the PBX thought there were members still present, it didn’t play any MoH. So internally everything seems to be fine, just the external connections are unreliable.
I remember having an issue at the beginning where a a call wouldn’t hang up after the external callee hung up. That was only affecting external calls, no internal calls. This hasn’t happened again since then, but it do leads me to believe that something in regards to signalling or NAT is not going right.
Just wanted to finish this off with the solution: Forwarding the RTP-Portrange solved all problems that were still in existence. It works flawlessly now. Thanks to both of you for your help!
