What Is SIP ALG and Should You Disable It?

SIP ALG stands for SIP Application Layer Gateway. It is a function built into many routers that watches for SIP traffic, opens the packets and rewrites the private IP addresses inside them to the router's public address. The intention is good: SIP embeds addresses in its messages, and NAT does not translate message contents. The execution is usually poor, and the advice from most PBX vendors and VoIP providers is the same: turn it off. Modern phones and servers handle NAT themselves, and an ALG that rewrites the same fields a second time produces errors that are hard to diagnose.

Quick checklist

1. Symptoms: registration drops after a few minutes, one-way audio, incoming calls that go to voicemail without ringing, calls that end after about 30 seconds.
2. Test from another network, for example mobile data. If the problem vanishes, the router is a suspect.
3. Log in to the router and find the SIP ALG, SIP passthrough or SIP helper setting under firewall, NAT or advanced settings. Turn it off.
4. Restart the router and re-register the phone.
5. If you cannot change the router, switch the softphone to TLS so the ALG cannot read the packets.

What does a SIP ALG actually rewrite?

A SIP request from a phone behind NAT contains its private address in three places: the Via header, the Contact header and the SDP body that describes where audio should be sent. How NAT Affects SIP and RTP explains why those are there. The ALG intercepts the packet as it leaves the network, replaces each private address with the router's public one and, for the SDP, opens a port mapping for the RTP stream so return audio can get in. On the way back it reverses the change so the phone sees responses addressed to itself.

On paper this is exactly what the phone needs. In practice several things go wrong.

Why does it break SIP?

It conflicts with the phone's own NAT handling

Nearly every modern softphone includes rport (RFC 3581) and can use STUN (RFC 5389) to learn its public address. A phone that already wrote its public address into the SDP does not need the ALG, but the ALG may rewrite it anyway, sometimes to the wrong value, or may change the port without changing the phone's actual listening port. The server now has an address that neither matches the phone's private address nor the mapping the router really created.

It conflicts with the server's NAT handling

PBXs such as Asterisk use symmetric RTP: they send audio back to the address the phone's RTP actually came from, ignoring the SDP. When the ALG has also opened a mapping on a different port, the two mechanisms fight and audio goes nowhere.

It rewrites inconsistently

ALG implementations often miss fields. They may rewrite the Via but not the Contact, or the c= line in SDP but not the m= line. They may fail on packets larger than one fragment, which happens with INVITEs that list many codecs or ICE candidates. They may not understand SIP over TCP at all. Each gap produces a message that is half private and half public.

It breaks authentication

Some ALGs alter the request URI or headers that take part in the digest authentication hash. The server computes a different hash from the phone and answers 401 or 403, even though the password is correct.

It drops mappings early

Even when the rewriting is correct, the ALG may close the RTP mapping on its own schedule, typically when it believes the call ended. If it misreads a re-INVITE or a hold as the end of the call, audio stops mid-call.

What are the symptoms?

The signature of a SIP ALG problem is inconsistency. The same phone and account work perfectly on another network. Common patterns:

• Registration succeeds, then the phone stops receiving calls after a few minutes while still showing registered.
• One-way audio, sometimes alternating direction between calls.
• Calls drop at a fixed interval, often around 30 seconds, when the server's re-INVITE or ACK does not arrive.
• Incoming calls reach the server but the phone never rings.
• Problems appeared the day a new router was installed.

How do I disable it?

Router interfaces differ, but the setting lives in roughly the same place everywhere. Log in to the router's admin page, then look under one of Firewall, NAT, Advanced, Security or Application settings for an entry named SIP ALG, SIP passthrough, SIP helper or SIP transformations. Set it to disabled or off, save, and restart the router. Some ISP-supplied routers hide the option or do not offer it; in that case ask the ISP, or put your own router behind theirs in bridge mode.

Three notes:

1. "SIP passthrough" is confusing. On some routers enabling passthrough means enabling the ALG; on others it means letting SIP pass untouched. If the behaviour is unclear, test both states.
2. The change takes effect for new registrations. Unregister and register again, or restart the phone.
3. On a managed business firewall the same feature may be called a SIP inspection policy. Ask the firewall administrator to disable inspection for your SIP ports.

How does TLS avoid the problem entirely?

A SIP ALG can only rewrite what it can read. With TLS transport, the SIP messages are encrypted between the phone and the server. The router sees an ordinary TLS connection on port 5061 and has nothing to inspect. The phone must then handle NAT itself, through rport, STUN and ICE, and the server must support symmetric RTP, but these mechanisms work reliably once the ALG is out of the way. Using a non-standard SIP port has a similar effect on ALGs that only watch port 5060, though a port change alone does not add any security.

The audio stream is not affected by TLS unless SRTP is also enabled; the ALG does not inspect RTP, so this does not matter for ALG purposes. TLS and SRTP explains what each one protects.

Should you ever leave it on?

Only when you have a very old phone with no NAT handling of its own and a server with no symmetric RTP, and you have confirmed by testing that the ALG helps. That combination is rare today. In every other case the ALG duplicates work that the endpoints do better, and disabling it removes a variable from every future troubleshooting session.

Next steps

After disabling the ALG, retest registration and a two-way call. If audio is still one way, continue with How to Fix One-Way Audio in VoIP Calls. To stop the router seeing your SIP traffic at all, set the softphone's Transport to TLS as described in SIP over UDP, TCP and TLS; in SIPdia this needs a server certificate from a public certificate authority, according to the app's documentation.