A SIP Application Layer Gateway (SIP ALG) is a feature in many firewalls and routers that reads Session Initiation Protocol (SIP) call signaling as it passes through and rewrites the IP addresses and ports written inside it. The goal is to help VoIP calls work through network address translation (NAT). In practice its behavior varies widely by firewall and router, and many voice providers recommend turning it off, because a SIP ALG that rewrites messages the provider already handles is a common cause of one-way audio, dropped calls and phones that won’t stay registered.
At a glance
- SIP ALG is a firewall or router feature, not a separate device or service.
- It inspects SIP messages and rewrites embedded addresses and ports so they match the translated public address.
- Implementations differ by vendor and firmware; some help, and many interfere with hosted phone services.
- Many hosted phone and SIP trunk providers recommend disabling it and handle NAT traversal on their side instead.
- It is often enabled by default, so it is worth checking whenever a firewall or router is replaced.
What problem it solves
NAT lets many devices on a private network share a public IP address. It rewrites the address in each packet’s header, which works for most traffic. SIP is different: phones write their own IP address and the port they want to receive audio on inside the signaling messages themselves. Behind NAT, that embedded address is a private one the outside world can’t reach. The provider sends audio to an address that doesn’t work, and the result is one-way audio or silent calls.
SIP ALG was created to fix this at the network edge. The firewall looks inside SIP messages, swaps the private addresses for the public ones, and opens the matching ports for the audio stream, so a phone that knows nothing about NAT can still place calls.
The catch is that most modern hosted phone systems and SIP trunk services already solve NAT another way: the phones send keep-alive traffic, and the provider’s servers or session border controllers learn the real public address from the packets they receive. When the firewall also rewrites the messages, the two methods can conflict. Some ALGs rewrite fields they shouldn’t, mishandle encrypted or non-standard ports, or close audio ports too early, and the buyer sees intermittent problems that are hard to trace.
How it works
Inspection. The firewall watches traffic on the ports SIP commonly uses (often 5060 for unencrypted SIP) and parses the messages that set up, change and end calls.
Rewriting. In each message it replaces private addresses and ports in the headers and in the session description that tells the other side where to send audio. It may also change contact and via headers used for registration and replies.
Pinholes for media. Because it now knows which ports the call’s audio will use, the firewall opens temporary openings for that media and closes them when the call ends.
Where it breaks. Problems usually come from mismatches: the ALG rewrites something the provider expected unchanged, it doesn’t understand a newer or vendor-specific message format, it can’t read encrypted SIP (so it does nothing, or interferes with the connection), or its timers close ports or translations while the call is still up. Results include one-way audio, calls that drop after a fixed time, transfers that fail, and phones that unregister.
Most hosted voice providers publish firewall guidance for common makes and models, usually covering the SIP ALG setting, the ports and address ranges to allow, and NAT timeout values.
When it matters for buyers
- When moving to hosted voice or SIP trunks. Check the SIP ALG setting at every site as part of the rollout, before users report problems.
- When replacing a firewall or router. A new device or ISP-supplied gateway may enable SIP ALG by default, and calls that worked last week stop working.
- When troubleshooting intermittent call problems. One-way audio, dropped calls and registration failures are classic symptoms worth ruling out early.
- When choosing who owns the edge. If an MSP manages your firewalls and a separate provider runs your phones, agree who sets and documents the voice-related firewall settings.
- When deciding whether you need an SBC. For larger or more complex voice deployments, a session border controller is often the more controlled way to handle NAT and security for SIP.
Our SIP trunking overview covers how providers connect business phone systems to the public phone network.
Questions to ask vendors
- Do you recommend SIP ALG on or off for our firewall make and model, and do you publish configuration guides?
- How does your service handle NAT traversal, and does it rely on keep-alives, an SBC or something else?
- Do you support encrypted SIP and media, and how does that interact with our firewall’s SIP inspection?
- Which ports and IP ranges must we allow, and what NAT or UDP timeout values do you recommend?
- If calls fail after a firewall change, who troubleshoots: you, our MSP or the firewall vendor?
- Does the ISP-supplied router at any of our sites have a SIP ALG we can’t disable, and can it be put in bridge mode?
How it differs from a session border controller (SBC)
Both deal with SIP at a network boundary, but they are built for different jobs. A SIP ALG is a feature inside a general-purpose firewall or router that rewrites SIP messages so calls can pass through NAT, with little else in the way of voice controls. A session border controller is a dedicated voice element, a device, virtual appliance or cloud service, that terminates SIP on each side, manages the media, normalizes differences between voice systems, enforces call policies and helps protect against voice-specific abuse such as toll fraud. Providers that use SBCs on their side often recommend disabling SIP ALG on the customer’s firewall so the SBC sees the traffic unchanged.