What Is SIP ALG and Why You Should Disable It

You set up a new VoIP phone, it registers fine, and the first test call connects. Then the audio is one-way, or the call drops at exactly thirty seconds, or the phone shows “No Service” an hour later for no reason anyone can find. You check the SIP provider, the credentials, the codecs, the firewall rules, and everything looks correct. The fault is almost never in any of those places. It is a single setting on the router in front of the phone, enabled by default, called SIP ALG.

SIP ALG (Application Layer Gateway) is a feature built into most consumer and small-business routers that inspects SIP traffic as it passes through and rewrites parts of it. The intention is to help VoIP work across Network Address Translation. In practice it is the most common cause of unexplained VoIP faults on business networks, and the standard recommendation across the industry is to turn it off. In the sections below, we’ll walk through what SIP ALG is trying to do, why it corrupts SIP instead of helping, how to recognize and confirm the symptoms, how to disable it on common routers, and what handles the underlying problem correctly once it is gone.

What SIP ALG Actually Does

To understand why SIP ALG causes problems, start with the problem it was built to solve. SIP carries IP addresses and ports inside the message body, not only in the packet headers, which follows from how the SIP standard (RFC 3261) and the SDP payload describe a session. A phone on a private network (for example 192.168.1.50) writes that private address into its SIP signaling and into the SDP that describes where it wants to receive audio. When the router performs NAT and sends the packet out to the public internet, it rewrites the IP header so the source looks like the router’s public address. The private address buried inside the SIP message is left untouched, because ordinary NAT only edits packet headers, not payloads.

The result is a SIP message that tells the far side to send signaling and audio to 192.168.1.50, an address that means nothing on the public internet. Replies and audio go nowhere. SIP ALG was created to patch this gap. It reads inside the SIP message as it passes through the router, finds the private addresses in the headers and the SDP, and rewrites them to the router’s public address so the far side has somewhere reachable to reply to. On paper it is a reasonable idea, and it is why router vendors ship it enabled by default: it lets a single VoIP phone behind a basic router work without any extra configuration.

The trouble is that doing this correctly requires fully and consistently parsing SIP, a protocol with many message types, optional headers, line folding, compact header forms, and vendor variations. Consumer router firmware does a fast, shallow version of that parsing, and that is where it falls apart.

Why SIP ALG Breaks SIP

SIP ALG fails not because rewriting addresses is the wrong idea, but because the implementations do it incompletely and inconsistently. A few distinct failure modes show up again and again.

Incomplete and Inconsistent Address Rewrites

An ALG that rewrites the address in one header but misses it in another leaves the SIP dialog describing two different return paths. The Via header might be corrected while the Contact header is not, or the signaling address is fixed while the SDP media address is missed. The two sides of the call then disagree about where packets should go, and the symptoms depend on which header was mangled.

Mangled SDP and One-Way or No Audio

The SDP carries the address and port where each side expects to receive RTP audio. When an ALG rewrites the SDP address incorrectly, or rewrites the signaling but not the SDP, the call connects and the phones ring, but the audio has nowhere valid to go. This produces the classic one-way audio fault, where one party can hear and the other cannot, or calls that connect with complete silence. The same family of symptoms is covered from the operator side in the VoIP troubleshooting guide.

Broken Registration and Contact Rewriting

When a phone registers, the Contact header tells the provider where to send incoming calls. An ALG that rewrites the Contact address inconsistently, or that loses track of the registration when it rewrites the expiry handling, causes registrations to fail or to lapse silently. The phone shows “No Service,” inbound calls never ring because the provider is sending them to an address that no longer works, and registrations recover and break on a cycle that looks random from the outside.

Calls That Drop After About Thirty Seconds

A call that sets up cleanly and then drops at a consistent interval, often around thirty seconds, is a signature of mangled in-dialog signaling. The session refresh or the acknowledgment that should keep the call alive is sent to an address the ALG rewrote incorrectly, so it never arrives and one side tears the call down.

Encrypted SIP Makes It Pointless and Harmful

When SIP signaling is protected with TLS, the router cannot read the message body at all, so the ALG has nothing to inspect or rewrite. At best it provides no useful signaling assistance; at worst it interferes with NAT handling or session state in ways that disrupt the call. Any deployment using TLS and SRTP, which includes Microsoft Teams Direct Routing and most modern carrier interconnects, gains nothing from SIP ALG and only inherits its side effects.

Symptoms That Point to SIP ALG

SIP ALG rarely announces itself. It presents as a collection of intermittent, hard-to-reproduce faults that survive every change you make to the phone, the provider, and the credentials. The following symptoms, especially in combination, point strongly at an ALG sitting in the path:

• One-way audio where one party can hear the other but not the reverse, or calls that connect to silence.
• Calls dropping at a consistent interval, frequently around thirty seconds, after a clean setup.
• Registration failures where phones show “No Service” or cycle between registered and offline with no pattern.
• Inbound calls not ringing while outbound calls work, because the provider cannot reach the address the ALG advertised.
• Broken call transfer, hold, or DTMF, where mid-call signaling that changes the session is the part being corrupted.
• Faults that move with the router, where the same phones and provider work fine on a different network.

How to Confirm SIP ALG Is the Culprit

Because the symptoms overlap with ordinary NAT and firewall faults, it is worth confirming SIP ALG specifically rather than disabling settings at random. The reliable method is to compare the SIP messages on each side of the router. Capture the SIP traffic as the phone sends it on the private side, then capture the same messages as they leave the router on the public side, and compare the Contact, Via, and SDP addresses.

If the addresses inside the message have been changed between the two captures, and changed in a way that is inconsistent or points at an unreachable address, an ALG is rewriting the traffic. A clean NAT device leaves the SIP payload alone and only rewrites packet headers. Reading these captures is a skill in itself, and the same technique localizes most signaling faults, not just ALG behavior. For the operator-side toolkit covering call trace and packet capture, the VoIP troubleshooting guide walks through the diagnostic process.

How to Disable SIP ALG

SIP ALG hides under different names on different equipment, which is part of why it is so often missed. Depending on the vendor it appears as SIP ALG, SIP Transformations, SIP Helper, SIP Inspection, VoIP passthrough, or an SIP entry in a NAT or application-layer settings page. On Linux-based gateways it is the nf_conntrack_sip connection-tracking helper. The table below covers where to find it on common platforms.

After disabling SIP ALG, reboot the router if the change does not take effect immediately, re-register the phones, and place test calls in both directions to confirm two-way audio and that the call holds past the interval where it used to drop. If symptoms persist, the cause is a separate NAT or firewall issue rather than the ALG.

When Disabling SIP ALG Is Not Enough

Turning off SIP ALG removes the thing corrupting your signaling, but it does not make the original NAT problem disappear. The private addresses inside SIP messages still need to be reconciled with the public addresses the far side actually sees. For a single phone behind a basic router, the phone’s own NAT keep-alive and the provider’s far-end NAT detection usually close that gap once the ALG is out of the way. At the scale of a carrier, an MSP, or any provider terminating SIP trunks from many networks it does not control, the NAT problem has to be solved deliberately at the network edge rather than left to a router’s best guess.

This is the role a Session Border Controller (SBC) plays. An SBC sits at the border between networks and handles signaling and media on each side as a designed function. Because it operates as a back-to-back user agent, it terminates the inbound signaling dialog and originates a new one toward the far side, so it controls every address in every header on both legs deterministically instead of editing a packet in transit. It performs far-end NAT detection on the addresses traffic is genuinely arriving from, anchors the media so audio flows to its own reachable public address, and applies SIP header manipulation as configured rules rather than a fixed guess. That is the difference between a router ALG and an SBC: the same category of work, done as deliberate signaling control instead of an opaque rewrite. For how this fits the broader picture of why a firewall ALG is not a substitute for an SBC, see the deeper comparison in the guide to SBC security.

Frequently Asked Questions

Conclusion

SIP ALG is a well-intentioned feature that tries to solve a real problem, that SIP carries private addresses NAT does not rewrite, and solves it badly by editing live signaling based on a shallow parse of the protocol. The result is one-way audio, calls that drop on a timer, registrations that lapse, and inbound calls that never ring, all of which survive every other troubleshooting step you take. On almost every business network the right move is to find the setting, under whatever name the vendor gave it, and turn it off.

Disabling it removes the corruption but leaves the NAT problem underneath. For a single phone the network usually copes; at provider scale the work belongs at a Session Border Controller that handles NAT traversal, media, and SIP addressing as deliberate, configured functions rather than a transparent guess. Knowing the difference is what turns an afternoon of chasing a ghost into a five-minute fix.