If you are troubleshooting VoIP problems and you have not checked whether SIP ALG is enabled on your router, check now. It is the single most common router-level cause of VoIP failures, and it is enabled by default on a surprising number of routers.
SIP ALG is a feature that is supposed to help VoIP work through NAT. In practice, it causes one-way audio, registration failures, dropped calls, and a catalog of intermittent issues that are maddening to diagnose because they look like they should be impossible.
What SIP ALG does
To understand why SIP ALG exists, you need to understand the problem it tries to solve.
SIP messages contain IP addresses and port numbers in their headers and bodies. The Contact header includes the phone's IP address. The Via header includes the phone's IP address. The SDP body includes the IP address and port where the phone expects to receive audio. These addresses are embedded in the text of the SIP message itself.
When a phone sits behind a NAT router, its local IP address (something like 192.168.1.50) is not reachable from the internet. The router translates the source IP of outgoing packets to its public IP address. This works fine for the IP packet header — NAT rewrites it automatically. But the SIP message body still contains the phone's private IP address because NAT operates at the network layer and does not normally look inside application-layer payloads.
The result is that the remote SIP server receives a message where the IP packet came from the router's public IP, but the SIP headers and SDP body say the phone is at 192.168.1.50. The server tries to send audio to 192.168.1.50, which is not routable on the internet. One-way audio — you can hear the other person, but they cannot hear you.
SIP ALG attempts to fix this by inspecting SIP messages as they pass through the router, finding the embedded private IP addresses, and rewriting them to the router's public IP address. In theory, this means the remote server receives consistent addressing information and can route audio correctly.
In theory.
Why it goes wrong
The concept is sound. The implementations are not. SIP ALG has been poorly implemented across decades of router firmware from dozens of manufacturers, and the result is a feature that creates problems far more often than it solves them.
It rewrites things it should not
SIP ALG implementations vary in what they rewrite and how. Some rewrite only the Contact and Via headers. Some also rewrite the SDP body. Some rewrite the From and To headers. Some rewrite addresses inside the SIP message that are not IP addresses at all. Some rewrite the message even when the addresses are already correct (because the phone is using STUN or an outbound proxy to handle NAT).
When SIP ALG rewrites a field that the phone or server does not expect to be rewritten, the result is a message that does not match what the sender intended. SIP authentication is particularly vulnerable because authentication digests are computed over specific header values. If the ALG rewrites a header after the phone computed the digest, the authentication fails. The server sees a valid-looking REGISTER or INVITE with an authentication response that does not match, and rejects it.
It corrupts the Content-Length
SIP messages contain a Content-Length header that specifies the size of the SDP body in bytes. When SIP ALG rewrites IP addresses in the SDP body, the body's byte length changes (a private address like 192.168.1.50 is a different length than a public address like 203.0.113.25). Well-implemented ALGs update the Content-Length to match. Poorly implemented ones do not.
A mismatched Content-Length causes the receiving SIP parser to either truncate the SDP (reading too few bytes) or read past the end of the SDP into the next message (reading too many bytes). Both result in malformed messages that cause call setup failures, codec negotiation errors, or outright crashes in some SIP stacks.
It mangles encrypted SIP
SIP over TLS (SIPS) encrypts the SIP signaling. The router cannot read encrypted messages, so it cannot rewrite the addresses inside them. Some SIP ALG implementations attempt to rewrite TLS-encrypted traffic anyway, corrupting the encrypted payload. Others silently drop TLS SIP traffic because they cannot inspect it.
It interferes with NAT keepalives
Modern VoIP phones send periodic keepalive packets to maintain their NAT binding — the mapping between the phone's private address:port and the router's public address:port. These keepalives ensure that return traffic (like inbound calls) can reach the phone through NAT.
SIP ALG can interfere with this process by creating its own NAT mappings for SIP traffic that conflict with the phone's keepalive-maintained mappings. The result is that the phone thinks its NAT binding is at one address:port, the remote server thinks it is at another, and inbound calls fail. Phones stop ringing for calls that were routed correctly by the server but could not reach the phone through the confused NAT state.
It creates asymmetric behavior
Because SIP ALG only operates on the router where it is enabled, its effects are asymmetric. Outbound calls may work fine (the ALG rewrites the outbound SIP message, the remote server gets corrected addressing) while inbound calls fail (the ALG does not correctly handle the inbound INVITE, or its NAT mappings do not match what the server expects). Or calls work in one direction but produce one-way audio because the SDP was rewritten correctly for one media direction but not the other.
This asymmetry makes troubleshooting confusing. The VoIP system appears to work partially, with failures that are directional, intermittent, or depend on which party initiates the call. These are classic SIP ALG symptoms.
The symptoms
If SIP ALG is causing problems, you will typically see one or more of these:
One-way audio. You can hear the other party but they cannot hear you, or vice versa. The SDP was rewritten incorrectly, causing audio to be sent to the wrong address. This is the most common SIP ALG symptom.
Registration failures. Phones cannot register or lose registration frequently. The ALG is corrupting the REGISTER message, causing authentication failure or misdirecting the server's response.
Calls dropping after 30 seconds. The call connects but drops after a consistent short interval. The ALG created a NAT mapping for the SIP signaling but not for the RTP media. The router's connection tracking times out the RTP flow because it does not recognize it as part of the same session.
Inability to receive inbound calls. Outbound calls work fine. Inbound calls do not ring, ring the wrong extension, or fail with SIP errors. The ALG's NAT mapping for inbound traffic is incorrect.
Intermittent failures. Calls sometimes work and sometimes do not, with no apparent pattern. The ALG's behavior depends on the specific content of each SIP message, the timing of NAT binding refreshes, and possibly the phase of the moon. Inconsistency is the hallmark of a buggy ALG.
How to check and disable it
Consumer and small-business routers
Netgear. Look under Advanced → WAN Setup → "Disable SIP ALG" or under Advanced → Setup → WAN Setup. Netgear labels it differently across models.
Linksys. Some models have SIP ALG under Security → Firewall or Administration → Management. Some models have no option to disable it and require firmware that does not include it.
TP-Link. Check Advanced → NAT Forwarding → ALG. SIP ALG is typically a checkbox.
ASUS. Look under WAN → NAT Passthrough → SIP Passthrough. Set to "Disable."
ISP-provided routers/modems. Many ISP-provided devices have SIP ALG enabled with no option to disable it. If your ISP router does not expose SIP ALG settings, put it in bridge mode and use your own router where you can control the settings.
Enterprise firewalls
SonicWall. Under VoIP → Settings, disable "Enable Consistent NAT" and "Enable SIP Transformations."
Fortinet/FortiGate. SIP ALG is part of the application-level gateway under the SIP session helper or SIP ALG profile. It can be disabled per policy or globally.
pfSense/OPNsense. Under System → Advanced → Firewall & NAT, uncheck "Disable Firewall Scrub" and under Firewall → NAT, check for SIP proxy or siproxd packages that may be installed.
Ubiquiti. EdgeRouter and UniFi Security Gateway have SIP ALG modules that can be disabled via CLI: set system conntrack modules sip disable.
After disabling SIP ALG, reboot the router and restart your phones. Existing NAT bindings created by the ALG need to be cleared.
What to use instead
Modern VoIP handles NAT traversal without SIP ALG using several mechanisms:
STUN (Session Traversal Utilities for NAT). The phone queries a STUN server to discover its public IP address and the NAT mapping for its SIP and RTP ports. It then includes the correct public address in its SIP messages. No router intervention needed.
Outbound proxy. The phone sends all SIP traffic through the provider's outbound proxy, which handles NAT traversal on the server side. The phone's private address in the SIP message is expected and handled by the proxy.
Symmetric RTP. The phone sends RTP from the same port it expects to receive RTP on, and the remote end sends RTP back to whatever address:port the packets came from rather than what the SDP says. This works through NAT without any ALG because the return path follows the NAT mapping created by the outbound packets.
SIP keepalives. The phone sends periodic OPTIONS or empty SIP packets to maintain the NAT binding. As long as the binding stays active, inbound traffic reaches the phone.
These mechanisms are standard in every modern VoIP phone, softphone, and PBX. They were designed specifically because SIP ALG proved unreliable. When you disable SIP ALG, you are not removing a necessary feature — you are removing an obstacle that prevents these proper NAT traversal mechanisms from working correctly.
The VoIP industry's collective advice is consistent and nearly unanimous: turn SIP ALG off. If you are experiencing any of the symptoms described in this post, disable it and test. Running a VoIP quality test before and after disabling SIP ALG gives you objective data on whether it was affecting your calls, and a PCAP analyzer can reveal exactly how the ALG was rewriting your SIP messages. If the problems resolve, leave it off. If they do not, you have at least eliminated one variable and can move on to other potential causes.
Frequently Asked Questions
What is SIP ALG and why does my router have it?+
SIP ALG (Application Layer Gateway) is a feature built into many routers that inspects and rewrites SIP messages as they cross NAT. It exists because SIP embeds IP addresses in its message body, and those addresses break when NAT changes the source IP. The idea is that the ALG fixes the addresses automatically. In practice, SIP ALG implementations are frequently buggy and cause more problems than they solve.
How do I know if SIP ALG is causing my VoIP problems?+
The signature symptoms are one-way audio, registration failures, calls dropping after 30 seconds, inability to receive inbound calls, and intermittent failures that defy other explanation. If disabling SIP ALG resolves the issue, you have your answer. See our SIP ALG router guide for disable instructions on every major brand. SIP ALG is enabled by default on many consumer and small-business routers.
Is it always safe to turn off SIP ALG?+
In the vast majority of cases, yes. Modern VoIP phones and PBX systems handle NAT traversal using mechanisms like STUN, outbound proxies, and NAT keepalives that work correctly without SIP ALG. Disabling SIP ALG is the first recommendation from most VoIP providers' support teams. The rare cases where SIP ALG is needed typically involve legacy equipment that cannot handle NAT on its own.
Will disabling SIP ALG affect non-VoIP traffic?+
No. SIP ALG only inspects and modifies SIP traffic. Disabling it has no effect on web browsing, email, file transfers, or any other type of network traffic. It simply tells the router to stop rewriting SIP packets and let them pass through NAT like any other UDP or TCP traffic.
Share
Want to know when we publish new articles? Sign up for updates