SIP ALG: why to turn it off

Turn it off. SIP ALG is a router feature that rewrites the addresses inside your call-setup messages, and most implementations rewrite some of them and miss others, which leaves the message describing two different networks at once. The result is phones that register and then stop, and calls with audio in only one direction.

That is the conclusion first, because it is almost always the right one. The rest of this is why, which matters when somebody tells you to leave it on. The protocol the feature is meddling with, and the product sold on top of it, are covered in what SIP trunking is. It is one of the recurring subjects in SIP and networks.

Your phone sits on a private address. The internet does not know that address exists. Your router translates between the two, and for ordinary traffic that is invisible: a web request goes out, the reply comes back to the router, and the router remembers which machine inside asked.

Call setup breaks that pattern in one specific way. The messages carry addresses inside them, as content, not just in the packet headers. A phone announces, in the body of the message, "send my audio to 192.168.1.50, port 16400". Translate the headers and leave the body alone, and the far end has been handed an address it cannot reach.

So somebody had the idea of teaching the router to read the message and fix the addresses inside it. That is an Application Layer Gateway, and applying one to SIP is a SIP ALG.

It is a reasonable idea. It is also the idea the people who wrote the standards asked applications not to rely on. RFC 3235, the guidance on designing applications that work through address translation, is blunt about it: making a protocol work this way "presupposes every NAT device can be updated in a timely fashion to support a new protocol. Since this is unlikely, application writers are urged to avoid placing addressing information in payloads all together." It also notes that an ALG may be "difficult or easy to construct, though in some cases it may not be possible at all."

Every router in the world running a SIP ALG is a small piece of evidence for that warning.

Not that the router rewrites the message. That it rewrites part of it.

A call setup carries addresses in several places, and they have to agree. The Via header says where to send replies. The Contact header says where to send later requests in this conversation. Inside the message body, a c= line names the host that should receive the audio and an m= line names the port. And a Content-Length header states how many bytes that body is.

Rewriting a private address to a public one makes the body a different length. A device that changes the body and leaves the declared length alone has produced a message that contradicts itself, and what happens next depends entirely on how strictly the far end reads it.

Grandstream's own documentation for its gateway products describes the mechanism plainly: a SIP ALG exists to "modify the IP addresses and ports in the SIP messages, to account for the fact that many SIP deployments use Network Address Translation", and to "create a pinhole to allow RTP traffic to flow dynamically". It also notes where the trouble concentrates: in most cases "the issue is with the Media Session", when the values inside the body are not adjusted correctly. You can read the whole note in the GWN Application Layer Gateway guide.

The header and body field names above are the real ones, from RFC 3261 and RFC 4566. What no specification says is which of them a given router will touch, which is why the same setting produces a different symptom on every make, model and firmware version.

You do not need a packet capture to suspect an ALG. Three patterns are characteristic.

A phone that registers and then goes quiet. Registration succeeds. Outbound calls work all day. Inbound calls stop arriving after a while, then start again on their own. The Contact address the provider was given no longer routes back to the phone, and the next registration temporarily repairs it. Registrations default to an hour under RFC 3261, which is roughly the period people describe.

Audio in one direction only. The call connects, both ends show connected, and one side hears nothing. The signalling got through and the audio did not, because the addresses describing where to send it were rewritten inconsistently. Network settings that break VoIP audio covers the whole family of causes; the ALG is the one you can eliminate in thirty seconds.

Calls that drop at a consistent time. Thirty seconds, or some other number that is the same every time, is a message the far end sent and your phone never received, or a reply your phone sent that never got back.

None of these prove it is the ALG. All of them are worth spending one setting change to rule out. What none of them are is a capacity problem: if the phones sound thin or choppy rather than silent, that is a different investigation, and how much bandwidth does VoIP need is where it starts.

Router interfaces differ too much for a menu path to be worth printing, and a path copied from the wrong firmware version wastes more time than it saves. What is stable is the class of setting and the words used for it.

Look for any of these labels:

Two things worth knowing before you start clicking. On some firmware the setting is a per-protocol list, and SIP is one row among FTP, TFTP and others, so a page-level search for the word "SIP" finds nothing. And on a small number of consumer routers, the option is not exposed in the interface at all, in which case the choices are to ask your internet provider to turn it off on their side, to put their box in bridge mode behind your own router, or to move your phones onto an encrypted transport, which the ALG cannot read and therefore leaves alone.

Change one thing, reboot the phones so they re-register cleanly, and test both directions of audio on an inbound call and an outbound one. Changing three settings at once and then testing tells you nothing about which one mattered.

The reason turning it off is safe is that the problem it addresses was solved properly, in the endpoints and the provider's equipment, by people who could see the whole message rather than a slice of it passing through.

A phone that keeps its registration alive with small periodic messages holds the router's mapping open without anybody rewriting anything. A provider that sends audio back to wherever your audio came from, rather than to the address written in the message, does not care what your private address says. Both mechanisms work with an unmodified message and stop working when a middlebox edits one.

Which is the real argument. An ALG is not adding a capability. It is intercepting a problem that both ends had already agreed how to handle, and handling it worse.

1. Turn it off. Then reboot the phones, and test an inbound call, an outbound call, and a transfer.
2. If the symptom persists, you have removed a variable, not wasted an afternoon. Work down the rest of the list: mapping timeouts, two routers in series, and the direction the audio is missing in.
3. If your router will not let you, that is a fact about the router worth knowing before you buy phones. It is also worth raising with whoever supplied it.

If you have run out of things to try, tell us what the phones are doing and what changes when you make a call. The direction the audio is missing in, and whether the problem survives a reboot, narrow it down faster than any list can.