Calls hangup after exactly 32 seconds


I am having some issues with a FreePBX system dropping calls consistently at 32 seconds. I’m running FreePBX with Asterisk 16.11.1.

I’ve seen a lot of other posts with similar issues as mine and it usually comes out to be a NAT issue, but I can’t figure out where my issue is. I am forwarding UDP port 5060 (pjsip not chan_sip) and RTP ports 10000-20000 to the internal IP of the PBX and have firewall rules block it if the IP address isn’t coming from the Twilio IPs I am using for my trunk. If i go to asterisk SIP settings and detect network settings it fills in the external IP with the correct IP. I have all of my internal networks added under asterisk SIP Settings as well. Here are logs for a call that dropped:

Hang-up cause 16, which is a normal hang-up. You are correct in assuming it is likely an network issue. You could do a wireshark and turn on SIP Debug from the Asterisk CLI to collect additional detail.

Unlikely, but you can try going to Settings > Asterisk SIP Settings > Under Nat Settings click on “Detect Network Settings”, Apply and try again.

Not sure if you have already read here, but maybe some clues.

I hope you are allowing RTP ports 10000-20000 for all IP addresses and not limiting it to the Twilio IPs. You may allow UDP Port 5060 only for Twilio however allow RTP from anywhere.

At the Asterisk command prompt, type
pjsip set logger on
make a new failing call and paste a new log (which will now include a SIP trace).

UDP 5060 is only allowed in from the Twilio IPs. I originally had UDP 10000-20000 only forwarding to the PBX but just set it to allow all RTP traffic anywhere on the network. No security issues in doing this? No effect on fixing my issue however.

Which logging mode should I be using? Debug or Verbose or another? I have a lot of endpoints so the log is filling up very quick (hundreds of lines) with logs we probably don’t need.

Some more information WAN connection is with Google Fiber and I’m using a Sophos firewall with SIP ALG disabled, UDP timeout has been set to 180 as well.

Devices on the network masquerade to a WAN alias IP that is a different IP address than the one Google communicates with the firewall on. Would that be an issue? I tried setting the PBX to masquerade to the same WAN IP that Google uses but that didn’t seem to do anything either.

Just the SIP trace is all we need. At the Asterisk command prompt, type
pjsip set logger on
call in from your mobile, paste the Asterisk log (or the console output).

We need to see starting from the INVITE sent by Twilio through the 200 OK sent by Asterisk and the subsequent ACK (if present). If there is a lot of noise in between from endpoints registering, etc., that’s easy to ignore and not an issue.

Here is a pastebin with the log:

Editing to add a wireshark capture from the Endpoint, as well as from the Twilio Trunk end.


Twilio Trunk:

I can see that the endpoint receives an ACK from the PBX but I don’t see one through the trunk anywhere.

Outbound calls work 100% fine by the way, no dropping whatsoever.

Line 20026:
Contact: <sip:>
is incorrect. is the default external IP address in the FreePBX Distro (it belongs to Sangoma).

In Asterisk SIP Settings, set External Address to (I’m guessing that’s correct based on where Twilio sent the call), Submit, Apply Config, then you must restart (not just reload) Asterisk. Test. If you still have trouble, please post a new paste.

Ahah. Restarted Asterisk and everything is working fine now. I’ve just been reloading this entire time. Uptime was 13 weeks so it likely didn’t pull any of the NAT settings correctly when I set them up initially not too long ago.

Thanks so much for your help!

1 Like

It looks strange, device receive an invite it process and afterward request a registration to FreePBX.

Is device registered? or it loose registration when receive calls?

That’s probably the reason call are released with “exited non-zero on “ “HANGUP CAUSE: 16”

As it seems FreePBX is on another network, have verified, routing, latency etc.?

Bit late but Ive found the causes are usually one of these

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.