Frequently Asked Question

This problem can arise for a few reasons, the drop happens though because the provider sees this as an incomplete or invalid SIP session setup, or dropped call, consequently providers terminate the call as they think its invalid.

 One reason for this is Firewall rules blocking SIP. Usually with todays hardware and softphones, you don't need to forward anything, it sets it up itself, but some older hardware may need manual port forwarding in some rare cases. So check your firewall on your PC too,

If your device gives a NAT option, make sure it's enabled.

Check your routers settings for SIP ALG, usually, and this might sound contradictory, you actually   want this OFF. If it's on, it can work against you, mostly affecting inbound calls, so always disable SIP ALG.

If you are passing a specific CID number, it might be confusing the provider who expects the one assigned to you, their security policies to stop those pesky number spoofers might also kick in, when this happens they see your call as invalid and terminate it.

Another problem can arise if there are multiple simultaneous VoIP calls behind NAT and you all use different SIP servers, NAT can get easily confused in such cases and STUN has been used to resolve this, it's always been tricky one.

The loss of detected audio/RTP stream, the system thinks the circuits gone dead so terminates it, it can also happen from the other parties device as well if their silence detection setting is too strict. This cause is pretty rare though.

If you experience this on FreePBX, your best to run wireshark on a session, to see if you are losing an ACK somewhere, you can do this from your desktop, assuming someIP is the one with the problem, using something like (replace LESSTHAN with a less than symbol - this KB keeps wiping it out if I use it directly :)

wireshark -k -i LESSTHAN(ssh root@sipserver tcpdump host someIP -U -w - )