VoIP NAT Traversal Guide

1. Why NAT breaks VoIP

Network Address Translation (NAT) is designed for TCP/HTTP traffic where the server responds to the client that initiated the connection. VoIP is different — both sides send and receive audio, and the remote endpoint needs to know your real reachable address.

The problem: when a SIP endpoint behind NAT sends an INVITE, it advertises its private RFC 1918 IP address (192.168.x.x, 10.x.x.x) in two places:

• Contact header: sip:1001@192.168.1.100:5060 — tells the remote where to send SIP responses
• SDP c= line: c=IN IP4 192.168.1.100 — tells the remote where to send RTP audio

The remote endpoint receives these private IPs and tries to send traffic to them — but private IPs are not routable over the internet. The result: one-way audio (remote can hear you but you cannot hear them), or no audio at all.

2. STUN — discovering your public IP

STUN (Session Traversal Utilities for NAT, RFC 5389) is a protocol that lets a device behind NAT discover its public IP and port by asking a STUN server on the internet.

How STUN works

1. Your phone sends a STUN Binding Request to the STUN server (e.g., stun.l.google.com:19302)
2. The STUN server sees the public IP and port your NAT assigned
3. The STUN server returns these in a Binding Response
4. Your phone uses the public IP/port in its SDP and Contact headers instead of the private IP

When STUN works: Full cone NAT, restricted cone NAT — most home and small office routers.

When STUN fails: Symmetric NAT — used by many corporate firewalls and carrier-grade NAT. With symmetric NAT, the public port assigned for a STUN query is different from the port assigned for RTP, so the STUN-discovered address does not work for media.

3. TURN — when STUN is not enough

TURN (Traversal Using Relays around NAT, RFC 5766) solves symmetric NAT by relaying all media through a server on the public internet. Instead of trying to punch through NAT, all RTP flows through the TURN server which both endpoints can reach.

TURN is more reliable than STUN — it works with all NAT types. The tradeoff is latency (media takes an extra hop) and cost (bandwidth through the relay server).

4. ICE — the complete NAT traversal solution

ICE (Interactive Connectivity Establishment, RFC 8445) combines STUN and TURN into a systematic process that finds the best possible path between two endpoints. ICE is mandatory in WebRTC and used by modern SIP deployments.

ICE candidate types

ICE gathers all candidate types, exchanges them with the remote endpoint via the SDP, then performs connectivity checks (STUN binding requests) to find which pairs actually work. It selects the best working pair for media.

5. SBC — enterprise NAT traversal

A Session Border Controller (SBC) is the production-grade solution for VoIP NAT traversal at scale. The SBC sits at the network boundary and:

• Rewrites SDP c= lines with its own public IP
• Rewrites Contact and Via headers with its public address
• Anchors media — both RTP streams go through the SBC, eliminating NAT issues
• Handles registration from endpoints behind NAT by maintaining binding state
• Works with all NAT types including symmetric NAT

SBCs are used by carriers, enterprises, and any deployment with multiple remote endpoints or trunks. They eliminate NAT issues entirely at the cost of always relaying media (similar to TURN but at the SIP layer).

6. Configuring NAT traversal in PBX platforms

Asterisk PJSIP

FreeSWITCH

Kamailio with RTPEngine

Frequently asked questions

Why does VoIP not work behind NAT?

VoIP breaks behind NAT because SIP endpoints advertise their private RFC 1918 IP addresses in the SDP c= line and Contact header. Remote endpoints cannot route traffic to private IPs over the internet, causing one-way audio or no audio. The fix requires NAT traversal: STUN to discover the public IP, TURN to relay media, ICE to negotiate the best path, or an SBC to anchor media at the network boundary.

What is the difference between STUN and TURN for VoIP?

STUN discovers your public IP and port by querying a server. It works with simple NAT types but fails with symmetric NAT used by many corporate firewalls. TURN relays all media through a server on the public internet, working with all NAT types including symmetric NAT. ICE uses both: it tries STUN first and falls back to TURN relay if direct connectivity fails.

How do I fix one-way audio in VoIP?

One-way audio is almost always a NAT issue. The remote endpoint is sending RTP to a private IP. Fix by configuring your PBX with its public IP: in Asterisk PJSIP set external_media_address and external_signaling_address in the transport. In FreeSWITCH set ext-rtp-ip and ext-sip-ip. For enterprise deployments, deploy an SBC to anchor media at the network boundary. Also disable SIP ALG on all routers.