Fundamentals
NAT Traversal: Why NAT Breaks VoIP (and How It's Fixed)
NAT — network address translation — is the technology that lets a whole office share one public IP address, and it is the single largest source of VoIP faults on earth. The reason is architectural: SIP and its SDP bodies carry IP addresses inside the messages ('send my voice to 192.168.1.50, port 12000'), and a basic NAT device rewrites packet headers, not message contents. The signaling reaches the server; the instructions inside it point at an address that doesn't exist on the public internet.
Every NAT-traversal technique is a different way of repairing that mismatch. Understanding which one your system uses explains its failure modes — and its fixes.
The mismatch, concretely
A phone at 192.168.1.50 registers and invites. Its packets leave through the NAT as 203.0.113.5 (the office's public address) — the headers are fine. But the Contact header and SDP inside still say 192.168.1.50. A naive server stores that Contact and sends inbound calls to a private address in someone else's network; the callee's phone never rings (or rings but the media goes nowhere — one-way/no audio). A second failure rides along: NAT mappings are temporary. An idle UDP mapping may live 30–120 seconds, so a phone registered an hour ago may be unreachable until its next refresh punches the hole open again.
| Technique | How it repairs the mismatch | Where it lives |
|---|---|---|
| SBC / provider media anchoring ('symmetric RTP') | The border element rewrites SDP to its own address and relays/latches media to the address packets actually arrive from | Carrier/hosted edge — why hosted VoIP 'just works' through NAT |
| STUN | The phone learns its public mapping from a STUN server and advertises that in SDP | Endpoints; works for many NAT types, fails on symmetric NAT |
| TURN / ICE | If direct paths fail, media relays through a TURN server chosen by ICE negotiation | WebRTC-style stacks; some modern endpoints |
| Keepalives & short registration expiry | Frequent small packets keep the NAT mapping warm so inbound signaling/media find the hole open | Phones and PBXs (CRLF ping, OPTIONS, re-REGISTER) |
| SIP ALG (the anti-fix) | The router tries to rewrite the message contents itself | Routers/firewalls — see the next guide for why it so often makes things worse |
Why hosted VoIP usually survives NAT and DIY struggles
Hosted providers assume every customer is behind NAT and engineer for it: their SBCs anchor media, latch onto actual packet sources, and their phones ship with NAT-friendly defaults. The failures appear at the seams — a customer firewall doing something exotic (symmetric NAT with port randomization that breaks latching assumptions, double NAT, an ALG 'helping'), or an on-premise PBX where the administrator must consciously configure the external address, RTP ranges and keepalives. If you run your own PBX behind NAT, three settings decide your fate: the system's declared external IP/hostname (written into SDP), the fixed RTP port range (opened on the firewall), and registration/keepalive timers shorter than your NAT's memory.
Diagnose a suspected NAT fault
- Capture at the WAN edge during a failing call: read the SDP c=/m= lines. A private address (10/172.16/192.168) in SDP crossing the public internet is the smoking gun.
- Check for double NAT: if the router's WAN address is itself private, there are two translators (ISP gateway + your router). Bridge the ISP gateway or expect traversal quirks.
- Compare behavior by call direction and by idle time: faults that appear after quiet periods indict mapping expiry; faults on every call indict SDP addressing.
- Apply the fix at the right layer: provider-side anchoring/latching confirmed with the carrier, or your PBX's external-address + RTP-range settings, or phone STUN/NAT options for direct registrations.
- Disable SIP ALG anywhere on the path before judging the remaining behavior — it rewrites the same fields your fixes are trying to set (next guide).
- Verify with calls in both directions after an idle gap longer than the old failure interval.
Frequently asked questions
- Does IPv6 eliminate NAT problems?
- Largely, in principle: globally routable addresses remove the translation mismatch. In practice, mixed IPv4/IPv6 paths introduce their own interworking faults, and most business VoIP still lives on IPv4 — NAT literacy remains a working skill.
- Why do internal calls work perfectly while external calls fail?
- Internal calls never cross the NAT — addresses inside are real and routable. That split is the cleanest NAT signature there is, and it exonerates the phones themselves.
- What is 'symmetric NAT' and why does STUN fail there?
- A symmetric NAT assigns a different external port for each destination, so the mapping STUN discovers (talking to the STUN server) is not the mapping the provider sees — the advertised address is wrong for the actual peer. Relay-based fixes (SBC anchoring, TURN) are the answer because they don't depend on the prediction.