Telecoms glossary • N
NAT (Network Address Translation)
The router function that lets a whole office share one public address. It is also the reason a call connects perfectly and carries sound in only one direction.
What is NAT?in VoIP and business telephony
1. NAT is the router function that rewrites the addresses on packets so every device on a private network can share one public IP address. Your phone sends from an internal address such as 192.168.1.40, the router swaps in the public address your ISP issued, and it reverses the swap on the traffic coming back.
2. Almost every business router runs the port-translating variant, NAPT, which is how one public address serves fifty devices. That translation is also why returning audio has nowhere to go unless the router still remembers which internal device opened the conversation.
How NAT works, and where the audio falls out
There are not enough public IPv4 addresses for every device, so RFC 1918 set aside three private ranges that anyone may use internally: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Those addresses are not routable on the internet, so something has to translate them at the boundary. That something is your router.
RFC 3022 describes two forms. Basic NAT swaps one private address for one public address. NAPT, the form your router almost certainly runs, swaps both the address and the port number, which is what lets many devices share a single public address. The router keeps a table of which internal address and port each translated conversation belongs to, and uses it to send return traffic to the right device.
That table is the whole story for voice. SIP signalling is a request and response exchange, so the mapping created by the outbound request is still there when the reply arrives. RTP audio is different: it is a continuous one-way stream in each direction, negotiated on ports chosen during the call. If the router has no entry for the inbound stream, it discards it. The call rings, connects and stays up, and one party hears silence.
Why NAT produces one-way audio
This is why one-way audio is diagnostically useful rather than mysterious. It tells you that signalling worked and media did not, which narrows the fault to the boundary of your own network almost every time.
The four NAT faults, and what each one sounds like
- Audio in one direction only
- The signature fault. Signalling completed, the return media stream has no mapping. Distinguish it from packet loss, which breaks audio in both directions, and from latency, which makes both parties talk over each other.
- Calls dropping at roughly thirty seconds
- Usually SIP ALG rewriting message bodies badly enough that a mid-call message never gets a valid response, so one side times the session out. It is consistent rather than random, which is what tells you it is configuration and not a line fault.
- Phones registering, then going offline
- The NAT mapping expires between registration refreshes. RFC 4787 requires that a UDP mapping must not expire in under two minutes and recommends five or more, but plenty of consumer routers do less. Shorten the registration interval on the phone, or enable the platform’s keep-alive, so the mapping is refreshed before it lapses.
- Inbound calls never arrive
- Outbound works, inbound goes nowhere. The provider is sending an invitation to a mapping that has already closed. Same cause, same fix, different symptom depending on whether the phone happens to have refreshed recently.
Fixing it, in order
-
Turn SIP ALG off
SIP ALG is a router feature that inspects SIP messages and rewrites the addresses inside them, on the assumption it knows better than the endpoints. It usually does not. 3CX’s own firewall guidance is to use a device without SIP ALG or one where it can be disabled. Look for it under names like SIP Helper, SIP Transformations or VoIP Passthrough. This one change resolves the majority of cases.
-
Let the provider’s STUN and TURN do the work
STUN, defined in RFC 8489, lets an endpoint discover the public address and port the NAT gave it, so it can advertise something reachable. Where that is not enough, TURN, defined in RFC 8656, relays the media through a server instead. Both are the provider’s job to run. Ask whether they do rather than assuming, because the answer determines whether remote staff work anywhere or only in the office.
-
Check whether you are behind carrier-grade NAT
If the WAN address on your router starts with 100.64, you have no public address at all. RFC 6598 reserved 100.64.0.0/10 for carrier-grade NAT, and it is common on mobile and some wireless connections. Port forwarding is impossible in that state, so either ask the ISP for a public address or rely entirely on the provider’s media relay.
-
Consider SIP over TLS
Signalling encrypted with TLS on port 5061 cannot be read, and therefore cannot be mangled, by a SIP ALG that someone re-enables during a firmware update. It is a durable fix rather than a setting that survives only until the next router reboot.
-
Forward ports only as a last resort
Static forwarding of the SIP and RTP ranges to a specific device works, but it is brittle, it has to be redone whenever internal addressing changes, and it exposes those ports. Prefer it to nothing; prefer everything above it first.
Telling NAT from everything else
Audio one way, or phones that register and then vanish, is NAT or the firewall. Choppy audio in both directions is packet loss. A delay that has both parties interrupting each other is latency. Two minutes spent establishing which of the three you have will save an hour of being asked to reboot the router.
Two questions for the provider, before you sign anything. Do they operate STUN and TURN, or a session border controller, so that a handset behind an unhelpful router still works? And do they publish the SIP and RTP port ranges their platform uses, so that your router can be configured properly rather than guessed at? A provider that answers both without hesitating has solved this problem for other customers already.
About this entry
Definitions are written for South African business buyers and checked against primary sources – provider documentation, standards bodies and ICASA – not vendor marketing. Reviews are independent and sponsors are always disclosed. Read our editorial policy and scoring methodology.
Spotted something out of date, or think we have this wrong? Tell the editors and we will re-check it.