SIP ALG is a feature in many routers and firewalls that inspects SIP messages as they pass through and rewrites the IP addresses and ports inside them. It exists to help SIP calls cross NAT. In practice it is one of the most common causes of one-way audio, calls that drop after roughly 30 seconds, and phone systems that register successfully but cannot receive inbound calls. The IETF recommends that ALGs of this kind be turned off by default, and most SIP providers and PBX vendors say the same.
The full name is Application Layer Gateway, written as Application Level Gateway in the RFCs. When people say “SIP ALG” they almost always mean the SIP-specific ALG built into a consumer or small-business router, often enabled out of the box with no obvious way to see that it is running.
Quick facts
| What it is | A SIP-aware inspection and rewriting function inside a NAT device or firewall |
| What it modifies | SIP headers (Via, Contact, Record-Route) and the SDP body (connection address, media ports) |
| Why it exists | SIP carries IP addresses in the message payload, which plain NAT does not translate |
| Standards position | RFC 4787 (BCP 127) REQ-10 states that NAT ALGs for UDP-based protocols SHOULD be turned off |
| Typical symptoms | One-way or no audio, call drops near 32 seconds, inbound calls failing after registration, malformed SIP |
| Works with encrypted SIP | No. TLS-protected signalling cannot be inspected or rewritten |
| Better alternatives | rport and symmetric response, symmetric RTP, SIP Outbound keepalives, correct endpoint NAT settings, an SBC |
The problem SIP ALG was built to solve
SIP has an unusual property compared with most protocols that cross NAT: it carries IP addresses and ports inside the message body, not just in the IP header.
A normal NAT device translates the source address and port in the IP and UDP headers. It does not look inside the payload. So when a phone system on 192.168.1.20 sends an INVITE, the SIP message still contains that private address in its Contact header, and the SDP body still advertises 192.168.1.20 as the address where audio should be sent. The far end reads the SDP, dutifully sends RTP to a private address it cannot reach, and the call has no audio even though signalling worked perfectly.
RFC 6314 documents this problem set in detail. Signalling responses do not reuse the NAT mapping created by the request, inbound requests are filtered because no long-lived path exists, and media is advertised on addresses that are unreachable from outside.
Router vendors responded by making the NAT SIP-aware. If the device can parse SIP, it can rewrite the private addresses inside the message to the public address it is using, and open matching pinholes for the media. That is SIP ALG. The idea is reasonable. The execution is where it falls apart.
What a SIP ALG actually rewrites
A SIP ALG typically modifies some combination of the following:
- The Via header, so responses come back to the public address
- The Contact header, so in-dialog requests reach the endpoint
- The Record-Route header in some implementations
- The connection address (
c=) in the SDP body - The media port (
m=) in the SDP body - The Content-Length header, which must be recalculated after any body change
Each of those rewrites has to be consistent with the actual NAT mapping the device created, consistent with what the endpoint expects, and maintained for the whole life of the dialog. Many implementations get one or more of these wrong. A very common pattern is that the ALG rewrites the SDP connection address to the public IP but assumes the media port is preserved through the NAT, when in fact no mapping exists on that port. Signalling completes, the call is answered, and the return media has nowhere to go.
The five failure modes you will actually see
SIP ALG rarely announces itself. It shows up as a symptom that looks like something else. These are the patterns worth recognising.
One-way audio or no audio at all. The most frequent one. Signalling succeeded, so the call rings and connects, but the SDP now points at an address or port where media cannot be delivered. If audio flows in one direction only, one side’s SDP survived the journey intact and the other side’s did not.
Calls drop at roughly 32 seconds. This is a signalling failure with a precise fingerprint. Under RFC 3261, the default T1 timer is 500 milliseconds, and Timer H, the wait time for ACK receipt, is 64 times T1. That is 32 seconds. If the ALG mangles the Contact or Record-Route headers so that the ACK cannot be routed back to the answering party, the server retransmits its 200 OK until Timer H expires and then tears the call down. A call that consistently dies between 30 and 35 seconds after answer is almost always a missing ACK, and a rewriting middlebox is a prime suspect.
Registration succeeds but inbound calls never arrive. The REGISTER goes out and gets a 200 OK, so the PBX reports itself as registered. But if the Contact address stored at the registrar does not match the actual path back through the NAT, inbound INVITEs go to an address that is not reachable. Outbound calls work. Inbound calls silently fail.
Registration flaps. NAT mappings expire. RFC 4787 requires that a UDP mapping must not expire in less than two minutes and recommends a default of five minutes or more, but real devices vary widely, and an ALG that shortens or resets mappings on its own schedule produces registrations that come and go.
Malformed or truncated SIP. If the ALG rewrites the SDP body but does not correctly recalculate Content-Length, or if it cannot parse a header extension it was never designed for, the message that reaches the provider is invalid. This tends to surface as unexplained 4xx responses. Our SIP response codes reference covers what each code means, but the important point here is that a code returned to a mangled message describes the damaged message, not the original one.
Why SIP ALG cannot be made reliable
This is not a matter of buggy firmware that a vendor might one day fix. The design has three structural problems.
It has to keep up with a protocol that keeps moving. SIP is extended constantly. An ALG shipped in router firmware in 2019 has a fixed idea of what SIP looks like. Headers and body types it does not recognise get passed through unmodified, mangled, or rejected.
It cannot see encrypted signalling. RFC 6314 states this plainly in its problem statement: ALGs have limitations and, in practice, an adverse impact on SIP, including requiring media and signalling to traverse the same device and not working with encrypted signalling or payload. If you run SIP over TLS, the ALG has nothing to read. It either passes the traffic through untouched, which is fine, or it interferes at the transport level, which is not.
It fights the endpoint. Modern SIP stacks already solve NAT traversal properly. When both the endpoint and the router try to fix the same problem independently, they produce conflicting rewrites.
The IETF position is explicit. RFC 4787, published as BCP 127, states in REQ-10 that to eliminate interference with NAT traversal mechanisms and allow integrity protection of UDP communications, NAT ALGs for UDP-based protocols should be turned off, and recommends in REQ-10a that where a NAT does include ALGs, administrators should be able to enable or disable each one separately.
How to confirm SIP ALG is the cause
Symptoms alone are not proof. One-way audio has several possible causes, and blaming the router without evidence wastes time. Take a capture and compare the two ends before you touch a single router setting.
Two practical notes on running this. First, capture at the endpoint itself, not on a mirror port outside the router, or you will see the already-rewritten version on both sides. Second, if you cannot arrange a provider-side capture, comparing what your PBX believes it sent against what it received back in the response headers will often be enough to spot the rewrite.
Turning SIP ALG off
The setting is named inconsistently across vendors. Look for SIP ALG, SIP Transformations, SIP Helper, VoIP passthrough, Application Layer Gateway, or an entry under a general ALG or protocol inspection menu. On some enterprise firewalls it lives inside a default inspection policy rather than as a visible checkbox, and on a few consumer devices it cannot be disabled at all through the interface.
After disabling it, reboot the device or at minimum clear existing sessions. An ALG that has already built state for an active registration will often keep applying it until that state is flushed, which leads people to conclude that disabling it did not help.
If the setting genuinely cannot be turned off, the workable options are to place the SIP endpoint in a network segment that does not pass through that device, to use TLS signalling so there is nothing for the ALG to parse, or to replace the device.
What to use instead
Disabling SIP ALG does not solve NAT. It removes an unreliable solution, so the reliable ones have to be in place. RFC 6314 sets out the accepted approach, and the work happens at the endpoint and at the session border, not in the middle of the path.
On the signalling side. Symmetric response, defined in RFC 3581, adds the rport parameter to the Via header so that responses return to the port the request actually came from rather than the port the client is listening on. SIP Outbound, defined in RFC 5626, binds registrations to a specific flow and provides a keepalive mechanism that holds NAT mappings open, which is the correct fix for registrations that flap.
On the media side. Symmetric RTP, defined in RFC 4961, means an endpoint sends and receives media on the same address and port, which lets the far end simply reply to wherever the audio arrived from. STUN, TURN and ICE cover the harder cases where that is not sufficient.
In endpoint configuration. Most PBX platforms expose these directly. The Asterisk documentation for configuring res_pjsip through NAT covers the transport options local_net, external_media_address and external_signaling_address, which tell Asterisk which addresses to advertise externally, alongside endpoint options including rtp_symmetric, force_rport and rewrite_contact. Setting these correctly does properly, once, at the endpoint what the ALG was attempting to do badly on every packet.
At the network edge. A session border controller performs the same class of function as an ALG but with full protocol awareness, media anchoring and maintained state. The difference is that an SBC is a purpose-built SIP element that is configured and updated for the job, whereas an ALG is a background feature in a general-purpose router.
SIP ALG compared with the things it is confused with
| What it is | Where it sits | Sees encrypted SIP | Recommended default | |
|---|---|---|---|---|
| SIP ALG | NAT feature that parses and rewrites SIP in transit | Inside a router or firewall | No | Off |
| SIP-aware firewall | Filtering policy that recognises SIP traffic without necessarily rewriting it | Network edge | Only at transport level | Filtering yes, rewriting no |
| Session border controller | Dedicated SIP element handling signalling, media, security and interworking | Access or interconnect edge | Yes, it terminates the session | On, where required |
| SIP proxy | Routing element that forwards SIP requests without terminating media | Service provider or enterprise core | Yes, it is a SIP endpoint | On, by design |
Common mistakes
Disabling SIP ALG and stopping there. If the endpoint has no NAT configuration of its own, removing the ALG can make things worse before it makes them better. Configure the endpoint first, then disable the ALG.
Assuming there is only one ALG in the path. Home working, branch offices and layered networks often mean two or three NAT devices between the phone system and the provider. Any one of them may be inspecting.
Blaming the provider for a 4xx response. If the SIP that reached the provider was already mangled, the response describes the damaged message. Compare captures before escalating.
Confusing SIP ALG with codec problems. Both produce audio complaints. An ALG problem gives you complete silence in one or both directions. Codec and network problems give you audio that is present but degraded, which is a different investigation covered in latency, jitter and packet loss and voice codecs.
Treating a 32-second drop as a network timeout. It is a SIP transaction timer expiring because an ACK never arrived. That is a signalling path problem, not bandwidth.
Where didlogic fits
didlogic operates the voice infrastructure layer: the SIP trunks and DID numbers that connect a phone system, contact centre or platform to the public phone network. The customer edge, including the router or firewall that may be running an ALG, sits on the customer side of that boundary, which is why ALG problems are diagnosed with captures taken at both ends rather than from one side alone.
Two things on the didlogic side are relevant to this topic. Trunks support both registration-based and IP-based authentication, and IP authentication removes the registration refresh cycle that ALG-induced NAT timeouts tend to disrupt. didlogic also supports TLS for signalling and SRTP for media across inbound DIDs and outbound trunks, described on the encrypted calls page. Encrypted signalling is useful here for a structural reason as well as a security one: an ALG cannot rewrite what it cannot read. Interconnection details, including transport and authentication options, are documented in the interconnection guide.
Frequently asked questions
Should I disable SIP ALG?
In almost all cases, yes. RFC 4787, published as BCP 127, recommends that NAT ALGs for UDP-based protocols be turned off. Configure NAT handling on the endpoint or at an SBC instead.
Will disabling SIP ALG break a working setup?
It can, if the endpoint was relying on the ALG to rewrite its private addresses. Set the endpoint’s external address and symmetric RTP options first, then disable the ALG and retest.
Does SIP ALG affect SIP over TLS?
It cannot inspect or rewrite it, because the signalling is encrypted. This is why moving to TLS often makes an ALG problem disappear, and why the TLS retest is a useful diagnostic step.
Why do my calls drop after about 30 seconds?
That is the signature of a missing ACK. Under RFC 3261, Timer H, the wait time for ACK receipt, is 64 times the T1 timer, which with the default T1 of 500 milliseconds is 32 seconds. Something rewrote the routing headers so the ACK could not get back.
Is SIP ALG the same as a session border controller?
No. Both mediate SIP at a network boundary, but an SBC is a dedicated, configured and maintained SIP element that terminates the session, while an ALG is an inline inspection feature in a general-purpose router with a fixed idea of what SIP looks like.
How do I know whether SIP ALG is enabled on my router?
Check the firewall or NAT settings for SIP ALG, SIP Transformations, SIP Helper, VoIP passthrough, or a protocol inspection list. If nothing appears in the interface, run the capture comparison described above, since some devices apply inspection without exposing a setting.
Continue learning
- What is SIP? explains why signalling and media travel separately, which is the reason ALG failures look the way they do
- What is SIP trunking? covers what a trunk carries and how authentication works
- SIP response codes explained is the reference for interpreting the codes you see during troubleshooting
- Latency, jitter and packet loss covers audio that is present but degraded, which is a separate class of problem
- Voice codecs explained covers what is negotiated in the SDP that an ALG rewrites
