UDP behind NAT


There are challenges when communicating through NAT.
1. client is behind NAT. It doesn’t know it’s own public IP, which is needed by, e.g. RTSP
The public IP can be learned from STUN server.
2. server is behind NAT. No private-to-public port map in NAT initially.
server talks to STUN to establish the map, and STUN tells client server’s public IP-port.
With STUN, for both restricted and unrestricted NAT, two hosts can talk to each other directly.
TCP is not discussed here, which is more complicated.

A few words on NAT type:
Cone: one private IP-port maps to one public IP-port, when talking to multiple destinations
Symmetric: one private IP-port maps to different public IP-port pairs for different destinations

Advertisements

ICE STUN and TURN


Assuming host A B both behind NAT on the internet.
STUN: Session Traversal Utilities for NAT
A B talk to STUN server to know each other’s external IP and port state for hole punching.
The goal is to let A B directly talk to each other on UCP and sometimes TCP, if NAT is not symmetric.
This public IP is also needed in RTSP SDP when RTP over UDP.
STUN server itself communicates over UDP by default.
TURN: Traversal Using Relays around NAT
A first asks TURN server a permission, and then A sends all data to TURN, which is relayed to B.
Used for some NAT TCP, when hole punching doesn’t work.
ICE: Interactive Connectivity Establishment
Just a combination of STUN and TURN, and automatically switches between the two.