Оффлайн
- Регистрация
- 9 Май 2015
- Сообщения
- 1,480
- Баллы
- 155
If you have ever tried setting up VoIP calls over the internet, you have probably run into the NAT wall.
Packets go out and somehow don’t come back. SIP signaling breaks, RTP streams vanish, and you’re left staring at dead air.
This article explores NAT traversal in SIP and RTP: why NAT complicates things, what types of NAT exist, and how tools like STUN, TURN, and ICE help us get calls working.
Quick Primer: What is NAT?NAT (Network Address Translation) allows multiple devices on a private network to share a single public IP.
Problem? SIP and RTP are peer-to-peer by design, and they often embed private IPs inside signaling (SIP/SDP).
The outside world can’t route to 192.168.x.x.
Types of NATDifferent NAT behaviors affect how easily SIP/RTP can traverse:
| Type of NAT | Behavior |
|---|---|
| Full Cone NAT | Any external host can send to mapped port |
| Restricted Cone NAT | Only hosts previously contacted can reply |
| Port Restricted Cone | Same as above but also checks source port |
| Symmetric NAT | New mapping for each destination |
Symmetric NAT is the hardest for VoIP — it breaks simple hole punching.
Navigating SIP Through NATSIP headers often carry contact addresses that may be private (e.g., Contact: sip:alice@192.168.1.10).
If the proxy or callee tries to respond there —
call fails.Key SIP Helpers:
- rport (RFC 3581): Client adds rport to Via → Server responds back to the source port, not the private IP in the header. Example:
Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK123;rport
- Contact rewriting (NAT-aware SBCs): SIP servers (B2BUA/SBC) may rewrite Contact headers to reflect the public IP/port.
Navigating RTP Through NATRTP streams face the same NAT issues:
- SDP offers may contain private IP addresses (e.g., c=IN IP4 192.168.1.10).
- Even if SIP signaling connects, media won’t flow.
ICE (Interactive Connectivity Establishment) gathers multiple candidates (possible addresses) and tries them in priority order.
Types of candidates:
- Host candidates → Direct local IPs
- Server reflexive → From STUN server (public-facing IP/port)
- Relay candidates → Allocated via TURN server (media relay)
STUN: Simple Traversal of UDPSTUN lets a client discover its public IP/port as seen by a server.
It works well with cone NATs.
Example: SDP with STUN candidates
a=candidate:1 1 UDP 2130706431 192.168.1.10 54400 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.45 60000 typ srflx raddr 192.168.1.10 rport 54400
- Candidate 1: Local private address (host)
- Candidate 2: Public IP/port discovered via STUN (server reflexive)
Instead of sending all candidates upfront, clients can send them as they’re found. Speeds up call setup.
TURN: Traversal Using RelaysWhen NAT is symmetric or firewalls block UDP, STUN fails.
That’s where TURN steps in — media is relayed through a public TURN server.
- Higher latency and resource cost.
- Guaranteed connectivity fallback.
STUN Binding in RTP SetupWhen RTP starts, peers send STUN Binding Requests over the selected candidate pair.
This validates the path and confirms bidirectional connectivity.
Caller (UA A) Callee (UA B)
- Send STUN Binding ------------> Respond Binding OK
<---------------:- STUN Binding - Respond Binding OK
Once validated, RTP media flows over that same path.
Example: SIP INVITE with ICE CandidatesHere’s what a NAT-traversed SIP INVITE might look like when a UA (behind NAT) sends an offer using ICE with STUN:
Breaking it Down
SIP Headers
- Via + rport: Ensures responses come back through the NAT’s mapped port.
- Contact: Rewritten (or discovered via STUN/SBC) to include the public IP:port.
- Call-ID, From tag, To tag: Tie requests and responses into the same dialog.
SDP Offer
- m=audio 54400 RTP/AVP 0 96: Proposes an RTP stream at port 54400 with codecs G.711 (0) and Opus (96).
- a=ice-ufrag + a=ice-pwd: ICE credentials used to authenticate connectivity checks.
- a=candidate:1 typ host: Local private address (192.168.1.10:54400).
- a=candidate:2 typ srflx: Public server-reflexive candidate discovered via STUN (203.0.113.45:60000).
- a=end-of-candidates: Marks candidate gathering complete.
How This Works
- Alice sends the INVITE with both private and public candidates.
- Bob replies with his own candidates in the 200 OK SDP.
- Both sides perform STUN Binding requests across candidates.
- The best working path (host → srflx → relay) is selected.
- RTP flows over the chosen pair.
In practice:- If Alice and Bob are both behind cone NAT, the server-reflexive (STUN) candidate usually works.
- If either side is behind symmetric NAT, ICE will fall back to TURN relay.
- This all happens automatically once ICE/STUN/TURN are implemented by the SIP stack or media engine.
Wrap Up- SIP needs help (rport, Contact rewriting, SBCs) to work behind NAT.
- RTP needs ICE → STUN for discovery, TURN for relaying.
- STUN binding checks ensure the media path is alive.
- Symmetric NAT remains the final boss, and TURN is the safety net.
Follow for the next level.