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.

Many SIP trunk providers tell customers to switch SIP ALG off as an early troubleshooting step, because a router rewriting SIP headers mid-path is a common cause of exactly that symptom set. 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. Many 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 many are poor. 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. A stopwatch is genuinely useful evidence here — if the drops are consistent at ~30 seconds, suspect the ALG before anything else.

The mechanism: when a call is answered, the answering side sends a 200 OK and the calling side must confirm it with an ACK. If ALG or NAT mangling misroutes either message — a rewritten Contact header is a typical cause — the ACK never arrives. The answering side keeps retransmitting its 200 OK for 64 × T1 (32 seconds with the default 500 ms timer), and then RFC 3261 says it should end the call with a BYE.

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 four platforms common on small-business networks, with the exact steps below it:

The exact steps, with the vendor’s own documentation linked or cited where it publishes one:

• Netgear. Browse to routerlogin.net (or the router’s LAN IP), log in, and open ADVANCED → Setup → WAN Setup. Check Disable SIP ALG and click Apply. Netgear’s knowledge base article confirms the ALG is on by default. Mind the inverted label: checked means off.
• UniFi. In the UniFi Network application, select the gateway under UniFi Devices, open its settings, find Firewall Connection Tracking, and switch SIP off; older builds kept it under Settings → Routing → NAT. On a legacy USG or EdgeRouter, the CLI equivalent is set system conntrack modules sip disable in configure mode. On a controller-managed USG it must also go in config.gateway.json, or the next provision reverts it.
• FortiGate. Fortinet’s SIP ALG and session helper guide (FortiGate 7.6.6 Administration Guide, docs.fortinet.com) says all SIP traffic goes through the proxy-based SIP ALG by default. To take both mechanisms out of the path: find the helper named sip (protocol 17, port 5060) with show system session-helper and delete it under config system session-helper; set default-voip-alg-mode kernel-helper-based under config system settings; and disable SIP in, or remove, any VoIP profile on the policy. Then clear existing SIP sessions (diagnose sys session filter dport 5060, then diagnose sys session clear), which drops calls in progress, so the change applies to every call.
• pfSense. There is nothing to disable. Where rewritten RTP source ports cause one-way audio, Netgate’s VoIP phone NAT recipe uses manual outbound NAT with Static Port on the phones’ UDP traffic, usually leaving UDP 5060 out. If phones randomly drop registration, change the Firewall Optimization Options setting (System > Advanced > Firewall & NAT) to Conservative; a 20–30 second keep-alive on the phones is often the better fix.

Two of those rows are easy to get wrong. pfSense has no SIP ALG at all — on the Netgate forum, a Netgate developer names the optional siproxd package as the closest thing and says you almost never want it. 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 some recent UniFi Network releases ship with the SIP connection-tracking helper already off, so on a newer UniFi gateway the job may be to confirm the state rather than hunt for a hidden on switch. The default has changed between versions, so check yours.

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 draws its line by where the PBX sits: its knowledge base says to turn SIP transformations on for a hosted PBX or proxy out on the internet serving phones inside the firewall, and off when the PBX and its phones all sit behind the firewall. If a hosted-PBX provider gives different instructions for its own platform, follow the provider.

FortiGate is the other deliberate case — Fortinet runs SIP through a full proxy-based ALG by default, and its own guide notes that you may need to disable the ALG and the session helper when your SIP provider advises it. 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 can 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, disable it.

Why do my calls drop after exactly 32 seconds?

That is the classic SIP ALG signature. After a call is answered, the calling side must send an ACK to confirm it. When ALG or NAT mangling stops the ACK from arriving, the answering side keeps retransmitting its answer for 64 × T1 — 32 seconds with default SIP timers — and then ends the call with a BYE. 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.