Inbound Calls Connect But Drop After Six Seconds
Scope
This article explains why inbound calls to your FreePBX (Asterisk) or VX system may be dropping after six seconds.
Any information provided here regarding "Asterisk" or "FreePBX" servers refers only to Telos-commissioned FreePBX (Asterisk) servers used with Telos Alliance telephony products. While these are third-party servers and software, we are able to provide limited pointers and advice (like this article) under normal support.
Scenario
Outbound calls can be placed, connect, and stay connected.
Inbound calls connect, bidirectional audio is heard for a short time (usually 6-7 seconds), and then the call is dropped.
Background
SIP signaling is used to set up calls in both VX and Asterisk. These SIP signaling packets are sent between the two or more devices involved in the call. The packets contain information about the incoming call as well as information about the device accepting the call. This signaling is based on SIP standards developed by IETF and accepted worldwide.
If this signaling is not present or is malformed, call setup will not occur properly. SIP signaling is usually UDP, so a method for message acknowledgment is built into SIP signaling standards.
A normal call flow looks like this:
Note the ACK (acknowledge) message from the provider SIP signaling target to the user agent. This message indicates to the user agent that the provider received the 200 OK, which is the last step in establishing a call.
Some firewalls, particularly those employing application level (Layer 7) filtering, can interpret this ACK message as a threat, instead of a normal SIP message, and thus will drop it.
This is what the call flow looks like when the ACK message is dropped by a firewall:
You can see that the user agent sends the 200 OK message to the provider, but then the user agent does not receive an ACK reply from the provider.
In an effort to make sure the 200 OK actually gets received by the provider, the user agent then retransmits the 200 OK several times over a period of about 6 seconds.
At this point, the user agent still has not received an ACK from the provider, so it assumes the provider never actually set up the call. The user agent then gives up, terminates the call, and sends a BYE to the provider.
This behavior results in the call briefly establishing but then dropping after some short period of time because the user agent thinks that the provider never received the 200 OK messages.
In the example directly above, the provider was actually sending the ACK message, but the firewall protecting the user agent dropped the ACK messages.
Resolution
If the firewall is dropping (blocking) ACK or other messages from the SIP provider, there is nothing any user agent, including VX or Asterisk, can do to overcome this. The only solution is to correct the firewall behavior so it does not drop these critical messages.
Application-level or Layer 7 firewall behavior is often complex and difficult to troubleshoot. If possible, it is simpler to disable any application-level filtering that may be applied between the VX/Asterisk server and the SIP service provider, including SIP Application Layer Gateway (ALG) and other proprietary "SIP helpers." As the ports and IP addresses used for SIP signaling by SIP providers is almost always very well defined and limited in scope, it is typically very low risk to rely solely on Layer 3 firewall activity to protect the user agent. Most customers use only Layer 3 firewalls to protect the VX or Asterisk server.
We have also found that application-level filtering can often still be turned on, or the firewall can still not be configured to pass SIP traffic properly, even when the firewall administrator insists it is indeed configured properly. In this case, a packet capture taken on the untrusted side of the firewall can be compared to a packet capture taken simultaneously on the trusted side of the firewall to unequivocally determine if any SIP signaling or media packets are being dropped or altered.
While this can usually be resolved by customer firewall and network administrators, the Telos Alliance Support Team can assist in guiding this troubleshooting as it relates to your VX or Asterisk system, but cannot directly configure your firewall. We offer this consulting service via various paid TelosCare Service Level Agreement options, or a la carte via our Dedicated Remote and Onsite Support service. Please use the Contact Us link above for more information on these options.
Let us know how we can help
If you have further questions on this topic or have ideas about how we can improve this document, please contact us.
