What Is SIP ALG and Why You Should Disable It

SIP ALG (Session Initiation Protocol Application Layer Gateway) is a router function that inspects SIP packets crossing NAT and rewrites the private IP addresses and ports inside them, so the far end has a reachable reply address. It was designed to help old VoIP equipment work behind NAT — but modern SIP endpoints and trunk providers already solve NAT themselves, so the ALG’s rewrites fight fixes that were already applied. The result is one-way audio, calls that drop at the 32-second mark, and registrations that flap. On a business SIP trunk, SIP ALG should be off.

Every serious trunk provider publishes a “disable SIP ALG” page for a reason: a consumer router rewriting SIP headers mid-path is the single most common cause of the symptom set above. This post explains what the ALG actually does to your packets, how to recognize its fingerprints, and where the off switch lives on the routers business buyers actually run. If you are setting up a trunk from scratch, do this alongside our SIP trunk configuration guide — it is a five-minute check that prevents hours of debugging.

How SIP ALG rewrites your calls — and why that backfires

SIP has a design quirk that NAT hates: it writes network addresses inside the message body, not just on the packet envelope. A SIP INVITE carries the phone’s IP address and ports in its Via and Contact headers, and the SDP payload names the IP and port where the phone wants to receive audio (the c= connection line and the m= media port). When that phone sits behind NAT, those are private addresses — 192.168.x.x — that mean nothing to the far end.

A SIP ALG sits on the router and “fixes” this: it inspects SIP packets on their way out, rewrites the private addresses in the headers and SDP to the router’s public address, and tries to open the matching pinholes for return traffic. On paper, reasonable. In practice, two things sink it:

Modern SIP already solved NAT. Today’s phones, PBXs, and hosted platforms handle NAT traversal themselves — registration keep-alives, short registration expiries, symmetric response routing, STUN/ICE, and provider-side handling on the trunk end. Providers route replies to the source IP and port they actually received packets from, regardless of what the headers claim. An ALG rewriting headers on top of that mangles values the endpoint or provider already fixed, and the two mechanisms fight each other.

Implementations vary wildly, and most are bad. SIP ALG is not one standard behavior — every router vendor writes its own, and many corrupt media negotiation or call setup outright: rewriting the SDP but pointing media at the wrong address, failing to open the RTP pinhole, or mangling a header mid-dialog so a critical message never arrives.

There is also a hard ceiling: an ALG cannot inspect TLS-encrypted SIP at all. If you run SIP over TLS, the ALG can do nothing useful — and some implementations still interfere with the encrypted packets anyway.

The failure signatures: one-way audio, 32-second drops, registration flaps

SIP ALG damage clusters into three recognizable patterns, each with a specific mechanism behind it.

One-way audio. The call connects, one side hears nothing — usually on external calls only, while internal LAN calls are fine. The ALG rewrote the SDP media address or port but pointed the audio at the wrong place, or never opened the matching RTP pinhole for the return stream. Signaling worked, so the call “connects”; the media path is broken in one direction.

Calls drop at around 30 seconds. The classic ALG signature: calls connect with two-way audio, then die at a consistent point — often exactly the 32-second mark. The mechanism: after the far end answers, your side must send an ACK to confirm the call. ALG or NAT mangling prevents that ACK from arriving, the far side treats the call as unconfirmed, and SIP’s retransmission timer gives up and tears it down. A stopwatch is genuinely useful evidence here — if the drops are consistent at ~30 seconds, suspect the ALG before anything else.

Registration flaps. Phones register successfully, then show unreachable or offline within minutes; inbound calls go straight to voicemail while outbound still works. The ALG interferes with keep-alives or fails to refresh the NAT binding, so the registration path dies even though the phone believes it is registered. Missed or phantom inbound-call behavior usually traces back to these dead registrations: the provider cannot reach a phone that thinks it is fine.

How to check for SIP ALG without a detector tool

There is no reliable universal ALG detector — the practical test is a symptom checklist plus, if you want proof, a packet capture.

Run the checklist first. Each item maps to a mechanism above:

• One-way or missing audio on external calls only, while internal LAN calls work.
• Calls that connect and then drop at a consistent ~30 seconds.
• Registrations that flap — registered, then unreachable within minutes; inbound dead while outbound works.
• Problems that appear or disappear when you swap routers, or when a phone works fine off-site (on a hotspot, for instance) but fails on the office network.
• Symptoms that started right after a router firmware update — updates can re-enable an ALG or change its behavior.

Two or more of these pointing the same direction is enough to act on.

For hard proof on unencrypted SIP, capture the traffic (Wireshark or your router’s capture tool, filter on UDP port 5060) and compare what the phone sent on the LAN side against what left on the WAN side. If the Via or Contact headers or the SDP c= line and media port differ between the two legs, something mid-path is rewriting your SIP — that is the ALG at work. The classic fingerprint: a Contact header showing your public IP when the phone put its private IP there and has no STUN configured. On TLS-encrypted SIP you cannot read the headers in a capture, so you are back to symptoms and toggling.

The cheapest practical test is also the fix: disable the ALG using the vendor steps below, reboot the router and the phones so NAT bindings and registrations rebuild cleanly, then retest the exact scenario that was failing. That toggle-and-retest is the test.

Where to disable SIP ALG on your router

The setting lives somewhere different on every vendor’s gear — and on some platforms the situation is more interesting than a checkbox. Here is the quick map for the four platforms we see most on business networks, each with a full walkthrough:

Platform	Where the setting lives	The short version
Netgear	ADVANCED → Setup → WAN Setup	Check the “Disable SIP ALG” box (yes, you check it) — on by default on most models. Netgear disable steps
UniFi (UDM/UCG/USG)	Gateway settings → Firewall Connection Tracking → SIP toggle	Recent releases ship with it off by default — verify rather than assume; legacy USG needs the CLI. UniFi disable steps
FortiGate	CLI: session helper + default-voip-alg-mode	Two separate mechanisms to switch off, and changes only affect new sessions. FortiGate disable steps
pfSense	Nowhere — pfSense has no SIP ALG	The real fixes are Static Port outbound NAT and conservative UDP timeouts. pfSense VoIP NAT guide

Two of those rows are worth underlining because most write-ups get them wrong. pfSense has no SIP ALG at all — if a pfSense site shows ALG-like symptoms, the culprits are source-port rewriting in outbound NAT or short UDP state timeouts, not a hidden ALG. And recent UniFi Network releases ship with the SIP conntrack module already disabled, so on newer UniFi gateways the job is to confirm the state, not to hunt for a hidden on switch.

Whatever the platform: after changing the setting, reboot the phones (or restart their registrations) so everything re-registers through the corrected path.

When SIP ALG is not your problem

Disabling the ALG fixes a specific class of failure — signaling and media that were rewritten. It does not fix everything, and blaming it for everything wastes time.

Choppy, robotic, or degraded audio in both directions is a path-quality problem — packet loss, jitter, or congestion — not an ALG problem. The ALG breaks calls structurally (no audio one way, drops at a fixed time); it does not make audio gradually worse. Work that class of issue with our packet loss troubleshooting guide instead.

Failures that persist off-network are not your router. If the same phone fails on a hotspot or at another site, look at the device configuration or the trunk itself.

And occasionally, an ALG is doing a legitimate job. The honest edge case: a true legacy endpoint behind NAT that does nothing for itself — no STUN or ICE, no keep-alives, a PBX that writes private IPs into its Contact and SDP and cannot be configured otherwise. SonicWall’s own guidance draws the line the same way: enable SIP transformations when the PBX lives outside the firewall and the endpoints cannot handle NAT; disable it when the PBX is behind the firewall. FortiGate is the other deliberate case — Fortinet ships a full proxy-based SIP ALG on by default and treats disabling it as a troubleshooting step. But if your equipment was made in the last decade and your trunk provider handles NAT on their end, the ALG is solving a problem you do not have — and its rewrites corrupt the SIP your provider’s infrastructure expects to receive unmodified.

Frequently asked questions

What does SIP ALG stand for?

SIP ALG stands for Session Initiation Protocol Application Layer Gateway. It is a router or firewall function that inspects SIP traffic crossing NAT and rewrites the private IP addresses and ports found in SIP headers and the SDP body to the router’s public address. It ships enabled by default on many consumer and small-business routers.

Should SIP ALG be on or off?

Off, in almost every business VoIP deployment. Modern phones, PBXs, and trunk providers handle NAT traversal themselves, so the ALG’s rewrites conflict with fixes already applied — causing one-way audio, dropped calls, and registration failures. The narrow exception is a legacy endpoint that does nothing for NAT itself, with the PBX outside the firewall. If your provider tells you to disable it — and nearly all do — disable it.

Why do my calls drop after exactly 32 seconds?

That is the classic SIP ALG signature. After a call is answered, your side must deliver an ACK to confirm it. When ALG or NAT mangling prevents the ACK from arriving, the far side waits on SIP’s retransmission timer — roughly 32 seconds — then tears the call down as unconfirmed. Consistent drops at about the 30-second mark point strongly at the ALG; disable it, reboot the router and phones, and retest.

How do I know if my router has SIP ALG enabled?

Check the router admin interface for a SIP ALG, SIP transformations, or SIP passthrough setting — the location varies by vendor, and pfSense famously has no ALG at all. For proof, capture unencrypted SIP on UDP port 5060 and compare the LAN and WAN legs: if the Via or Contact headers or SDP addresses differ, something is rewriting your SIP. Otherwise, the practical test is toggling the setting off, rebooting router and phones, and retesting the failing scenario.

Does SIP ALG affect encrypted SIP (TLS)?

An ALG cannot inspect TLS-encrypted SIP — the headers it would rewrite are unreadable, so it can do nothing useful. Some implementations still interfere with the encrypted packets anyway, which makes the ALG useless at best and harmful at worst on TLS trunks. Either way, the recommendation stands: turn it off.

---

Everything above assumes one thing about your carrier: that its SIP trunking is built for endpoints sending clean, unmodified SIP — no middlebox rewrites required. SIPNEX, an FCC-licensed carrier, builds exactly that. If your calls are dropping at 32 seconds or your audio only flows one way, run the checklist above, then talk to our engineers about a trunk that behaves predictably, or start with the full SIP trunk configuration guide.