As more businesses transition to cloud-based tools during the global shift to remote work, it’s become all the more important for these tools to provide the same reliability and effectiveness as their more traditional counterparts.
Enter SIP trunking. A SIP trunk enables you to extend voice over IP (VoIP) telephony beyond your organization’s firewall and to the PSTN using an internet connection rather than a traditional phone line. Not only do you have the benefit of less physical components as part of your system, but this simpler configuration is also easier and less expensive to design, operate, maintain and upgrade.
While SIP offers notable benefits, there are common firewall issues that could arise and impact communication experiences if not properly addressed. Below are a few best practices to avoid these issues and see smooth sailing for your SIP trunking.
Check Your Firewall. If you’re looking to improve the quality of your voice calls, it may be because of your firewall. A firewall is a necessary network security tool, but issues can arise that prevent high-quality SIP trunking. The right antidote to poor call quality can allow you to maintain the security offered by your firewall but will also include a solution setup that helps calls get through. Further, some of the specific technologies that are intended to support your setup may be hindering it. (Continue reading to see what we mean.)
The Challenges of NATing. In most cases, the endpoints in your network connect to the internet through a central router. Your ISP has assigned an IP address to your router that allows each endpoint to communicate with the internet. The router also assigns a specific internal address to each device so it can send incoming information to the right place. This method is known as Network Address Translation (NAT). NAT is an effective solution for one-way communications that we rely on daily (e.g. internet searches or email delivery). However, for real-time two-way connections like SIP trunking to take place successfully, NAT can cause more harm than good.
As discussed, SIP trunking makes it possible for two parties to communicate by providing the parameters for the connection, such as the IP address where call audio should be sent. This arrangement normally works well, except when the called party receives the internal IP address of the caller’s endpoint. This is because an internal, private IP address is not routable on the public Internet. At this point, the communication may be sent back because it doesn’t have the direction for a destination. This can cause a common but frustrating scenario of the person your calling being able to hear you while you aren’t able to hear them.
Further Challenges with SIP ALG. SIP Application-level gateway (ALG) is enabled by default on many routers. This functionality is intended to alter SIP packets by using the connection information and swapping the private address for your public address. When the other end sends communications back to the public address, your router is able to send the communication along to the private address in a process called “packet mangling.”
While it sounds like an effective way to bridge communication gaps, SIP ALG isn’t a perfect solution. The primary issue is the poor implementation at the SIP protocol level of most commercially available routers. When you consider how it is executed, SIP ALG is mainly a helpful solution for outgoing calls and can’t be as helpful with incoming calls. The reason for this is that when endpoints register with the SIP proxy, the proxy needs to deploy “keep-alives” to maintain the connection. And the keep-alives are only sent if the endpoint is NATed. SIP ALG then modifies the request so that the NATing goes undetected by the proxy, and the registration is lost.
SIP ALG also has the unfortunate habit of breaking SIP signals. The SIP ALG in many commercial routers modifies SIP headers the wrong way. When the private IP address that’s assigned to the endpoint is subbed in with the public IP, the router will maintain a record of which private IP and port the reply should be directed to.
In many cases, the implementations won’t be able to create or maintain this record for the two streams of communication that are necessary to support a SIP call or continue the signaling, resulting in issues such as dropped calls or one-way audio. In other instances, an ALG might right the wrong ports into signaling so that the return communications end up in the incorrect place.
Troubleshooting Options. When a SIP ALG is working as expected, it does not seem to cause any issues. When customers experience dropped calls and/or one-way audio, it seems that more often than not, SIP ALG is the reason why. Below are two solutions we recommend that have been known to frequently resolve the issues.
- Deactivate SIP ALG. When users disable SIP ALG, the challenges with calls seem to disappear. While different routers will have their own settings configurations, users should log in to the router configuration interface and disable SIP ALG. More than likely, there will be a toggle to switch off. If you need more in-depth guidance, VoIP-Info put together a comprehensive list of routers to guide you through the steps to disable SIP ALG.
- Bypass SIP ALG. If you haven’t been able to deactivate your SIP ALG, you can try bypassing it instead. Some ALGs only look for SIP signaling on the default port, 5060. At Flowroute, customers can use 5160 as an alternate port, which can help you bypass a broken SIP ALG.
It may be surprising to learn the root of your call quality issues rest in your firewall, but by following the troubleshooting steps outlined above, you can perfect your troubleshooting efforts and keep your firewall and call quality alive.
If you are experiencing other issues with SIP setup or troubleshooting, please consider reaching out to Flowroute’s support team.
