What is NAT?

Definition and origin

NAT stands for Network Address Translation. The idea was born in the 1990s, when it became clear that IPv4 addresses were running out. Instead of giving a public address to every computer, you give one address to each network, and the router "mediates" between the devices inside and the outside world.

What began as a temporary solution became the most common thing in networks: almost every home and every office in the world today works behind NAT. Every private address in the office (phone, computer, printer) goes out with the public address of the router.

The simple picture: a receptionist at the entrance to an office building. All letters go out with the building's address. When a reply comes back, the receptionist checks her log for who sent the original letter, and passes it on to them. If the log isn't accurate, the reply reaches the wrong desk, or doesn't arrive at all.

How it works, step by step

1. The phone in the office, at address 192.168.1.21, sends a packet to the cloud PBX server. The packet says: from 192.168.1.21, port 5060.
2. The router replaces the sender's address with the office's public address, and sometimes the port number too, for example with 40211.
3. It records in the translation table: "Whatever comes back to port 40211 belongs to 192.168.1.21, port 5060."
4. The server answers to the public address, port 40211.
5. The router finds the row in the table, restores the original address, and passes the packet to the phone.

The rows in the table aren't kept forever. If there's no traffic for a while (usually tens of seconds to a few minutes, depending on the router), the row is deleted. This is a small detail that explains many telephony problems, as we'll see below.

And the most important detail: the router opens a row in the table only when something from the inside goes out. A packet that arrives from outside with no matching row is dropped. This is also a natural protection: no one outside can contact a computer in the office directly, unless the computer contacted them first.

Types of NAT

• NAT with ports (PAT, also called NAPT or Overload): the type found in almost every router. Many devices share one public address, and the router tells them apart by port numbers.
• Static NAT and port forwarding: a manual setting that tells the router: "Everything that arrives from outside at a certain port, pass to a certain device inside." It's used for servers and cameras.
• Double NAT: two routers in a chain, each one translating. It happens often when the office router is connected behind the internet provider's router.
• CGNAT (provider-level NAT): some providers do the translation themselves, so even your router's "public" address is actually private at the provider. In that case you can't get direct access from outside, and you can't reliably lock systems to your address.

Why NAT complicates phone calls

Browsing the internet is simple for NAT: the computer asks, the server answers, and that's it. A VoIP call is more complex, because it has two separate channels: the signaling channel (SIP), where the phone asks to place a call, rings, and announces a hang-up, and the voice channel (RTP), where the voice packets themselves pass, on other ports.

The problem is that inside the SIP message the phone writes, "Send the voice to address 192.168.1.21, such and such port." This is a private address, which means nothing to a server in the cloud. If the server tries to send there, the voice gets lost. Good telephony servers know how to ignore the written address and answer to the address the packet actually came from, but even that works only if the router behaves predictably.

The well-known problems that result:

• One-way audio — you hear the other side, but they can't hear you, or the other way around.
• Call drops after about half a minute — the signaling channel did not complete the call's "handshake," so the server concludes the call was not received and hangs up.
• Incoming calls don't ring — the phone is registered, but its row in the translation table was deleted due to inactivity, and the server can't reach it. Outgoing works, incoming doesn't.
• A phone that flips between "registered" and "not registered" — usually a sign of a router that clears the table too quickly, or of two routers doing translation.

SIP ALG — the "helper" that gets in the way

Many home and business routers have a setting called SIP ALG (Application Layer Gateway). The idea is a good one: the router "reads" the SIP messages and replaces the private addresses in them with the public address, to avoid the problem we described.

In practice, it often does this only partly or incorrectly, especially when the PBX server already handles NAT on its own — and then two fixes collide. The result: exactly the problems it was meant to prevent. So in most cases, one of the first steps in troubleshooting audio problems on a cloud PBX is to turn off SIP ALG on the router.

The setting goes by different names at different manufacturers: SIP ALG, SIP Helper, SIP Passthrough, SIP Fixup. On some internet provider routers it is hidden, and only the provider can turn it off.

What to check when there is a problem

1. SIP ALG — is it off?
2. Router chain — is there a provider router with another router behind it? If so, it is better to switch one of them to bridge mode, so there is only one translation.
3. Connection hold time — does the router delete UDP rows too quickly? The setting we recommend is a hold time (UDP timeout) of 180 seconds. When it can't be changed, the workaround is to have the phone send "I'm still here" messages (keep-alive) more frequently.
4. Firewall — is it blocking the voice port range? See Firewall and ports.
5. Unnecessary port forwarding — usually there is no need to open ports from the outside to the phones on a cloud PBX. Opening the telephony port to the whole world invites break-in attempts and toll fraud.

Tip: if the problem shows up on only one extension, it is probably in the device's settings or its cable. If it shows up across the whole office, it is almost always the router.

Diagnosis table: what you hear, what causes it, what to do

In the previous chapters we described the faults. Here they are organized by what the user actually experiences, because each symptom points to a different link in the chain:

The last two rows show the most powerful diagnostic tool: comparison. The same phone working on a different network proves that the device and the PBX are fine, and narrows the search to a single router.

A real-world example: an accounting firm that replaced its router

An accounting firm in Bnei Brak, ten workstations, ran for a year with no problems. One Tuesday an internet provider technician replaced the router with a new model. On Wednesday morning the complaints began: "Customers say they called and nobody answered." In the PBX call log, the calls appeared as calls that reached the extensions and went unanswered. In the control panel, all the extensions were registered. The phones looked fine.

What happened: the new router deleted UDP translation rows after 30 seconds without traffic, while the phones sent an "I'm here" message only once a minute. Between the two messages there was a half-minute window in which the PBX could not reach the phone. A call that came in during that window rang on the server, not on the phone. Outgoing calls always worked, because they open a new row on their own.

The fix, in two steps: turning off SIP ALG on the new router (it was on by default), and setting the phones to send a keep-alive every 20 seconds — less than the router's deletion time. The better fix would have been to set a hold time of 180 seconds on the router, as we recommend, but on this model the setting was not accessible.

The twofold lesson: every router replacement in an office with phone service requires a test incoming call after a minute or two of silence, not only an outgoing call. And second, the call log in the control panel is a witness: it shows that the call got as far as the extension and stopped there, which points straight at the office network.

NAT outside the office: home workers, mobiles and branches

Everything said about the office router is true for any other place an extension connects from. An employee running a softphone from home goes through her home router — with its own SIP ALG, its own deletion times, and sometimes a provider router in front of it. When she complains about one-way audio, the thing to check is the router at her home, not the office.

On a cellular network the situation is different: there is almost always carrier-grade NAT (CGNAT), and nothing in it can be changed. Even so, mobile apps work well in most cases, because they open the connection from the inside and keep it alive on their own. A SIM extension bypasses the whole issue: it doesn't go over the internet at all, but over the regular phone network, so NAT doesn't touch it.

And for branches: every branch with its own router is a separate NAT. On a cloud PBX this is actually convenient — each branch registers on its own, and there is no need for a direct connection between branches to pass a call between them. The call goes through the cloud, not through the routers.

What to tell a technician or provider

When someone else manages the router, the following sentences explain exactly what is needed, without arguments:

• "We have IP phones working with a cloud PBX. Please turn off SIP ALG."
• "If there is a provider router with our router behind it — switch the provider's to bridge mode."
• "Don't open ports from the outside to the phones. They connect outward on their own."
• "Set the UDP connection hold time (UDP timeout) to 180 seconds."
• "When done — an incoming test call, after two minutes of silence."

The first sentence is worth saving. It solves more audio problems than the rest of the list combined.