Our ISP's gateway has SIP ALG we can't disable.

Bridge mode is the standard escape: put the ISP gateway into bridge/pass-through and let your own router own NAT and policy. If bridging is impossible, ask the ISP to disable it (many can, remotely) — and note double NAT as the accompanying risk while both devices route.

Everything worked with ALG on for years. Why now?

Because something coordinated changed: the provider upgraded SBC behavior, your PBX started declaring its own external address, or the router firmware changed the ALG. Two editors tolerate each other until one edits differently.

Is SIP ALG a security feature?

No — it is a NAT workaround, and a buggy one can reduce security by mangling messages unpredictably. SIP security comes from TLS, strong credentials, ACLs and SBC policy, none of which require ALG.

Fundamentals

SIP ALG Explained: Helpful Idea, Harmful Default

By the VoIP Cost Guide Editorial Team | Last updated: October 2026

SIP ALG — Application Layer Gateway — is a feature inside routers and firewalls that inspects SIP messages and rewrites them to 'help' VoIP cross NAT: swapping private addresses for public ones in Contact headers and SDP, opening media pinholes, adjusting timers. On paper it solves the exact problem described in our NAT guide. In practice, each vendor implemented it privately, many implementations are buggy or outdated, and the rewriting collides with the fixing that modern providers and SBCs already do at their edge. Two fixers editing the same message produce garbage.

That is why 'disable SIP ALG' is the most repeated sentence in VoIP support — and why this guide exists to explain when it is right, which is most of the time, and how to recognize ALG damage when you see it.

The damage patterns

Registration flapping: the ALG rewrites the Contact or expires bindings on its own schedule; phones register, vanish and return in a sawtooth pattern.
One-way or no audio: SDP media addresses rewritten inconsistently (IP fixed, port not; or the c= line edited but the m= port left private-mapped), sending RTP into voids.
Calls failing after a router firmware update: the ALG was silently enabled or its behavior changed in the update — a classic 'nothing changed' change.
Transfer and hold anomalies: mid-dialog messages (re-INVITEs, REFERs) rewritten differently from the original dialog setup, breaking exactly the calls that were fine until someone pressed hold.
Timer corruption: Session-Expires and registration expiry values edited by an ALG that thinks it knows better, feeding the timed-drop fault family.

When ALG is (theoretically) useful — and the modern default

ALG had a legitimate era: a lone on-premise PBX behind a dumb NAT, with a carrier that did no edge fixing, sometimes worked only because a good ALG rewrote its messages. That combination is now rare. Hosted platforms anchor media and rewrite at their SBCs; modern PBXs declare their external address themselves; endpoints support STUN/ICE. In all of those designs the ALG is a second, uncoordinated editor. The professional default in 2026: SIP ALG off on every router/firewall in the voice path, unless a specific documented design requires a specific vendor's implementation — and if you inherit a network where disabling ALG 'breaks' things, that dependency itself is the finding to record and eventually engineer away.

Test for ALG damage in one change

Find the setting: in the router/firewall admin it hides under SIP ALG, SIP Helper, SIP Transformations, or VoIP ALG — sometimes per-WAN or per-policy rather than globally.
Change one thing: disable it, then reboot the phones (to force clean registrations) and re-run the failing scenario — registration stability, an inbound call, an outbound call, a hold-and-resume, a transfer.
If evidence is needed first (an inherited network, a skeptical stakeholder), capture the same SIP message on both sides of the router and diff the headers/SDP: lines that change in transit are the ALG's fingerprints.
If a fault persists after ALG is off, you have made progress anyway: the remaining fault now has exactly one editor (your provider/PBX design) and the NAT guide's fixes apply cleanly.
Document the setting in the network run-book with a warning: future firewall replacements re-enable it by default — this fault loves to resurrect at hardware refresh time.

Frequently asked questions

Our ISP's gateway has SIP ALG we can't disable.: Bridge mode is the standard escape: put the ISP gateway into bridge/pass-through and let your own router own NAT and policy. If bridging is impossible, ask the ISP to disable it (many can, remotely) — and note double NAT as the accompanying risk while both devices route.
Everything worked with ALG on for years. Why now?: Because something coordinated changed: the provider upgraded SBC behavior, your PBX started declaring its own external address, or the router firmware changed the ALG. Two editors tolerate each other until one edits differently.
Is SIP ALG a security feature?: No — it is a NAT workaround, and a buggy one can reduce security by mangling messages unpredictably. SIP security comes from TLS, strong credentials, ACLs and SBC policy, none of which require ALG.

Sources and further reading

Related guides

Disclaimer: This guide is educational information based on published VoIP standards and professional practice, not engineering advice for your specific system. VoIP pricing, taxes and fees change and vary by provider and location — verify current figures with providers before purchasing. If your phone system supports emergency calling, work with your provider or a qualified VoIP engineer for changes that affect E911.