NAT lets a home or office network of dozens of devices reach the internet behind a single public IPv4. The router rewrites the source IP and port of outbound packets to its own public address and remembers the mapping in a table; inbound replies are rewritten back. For HTTP and other client-initiated protocols NAT is invisible — the connection always starts from inside, so the mapping always exists when the reply arrives.
For peer-to-peer streaming NAT is the central problem. WebRTC and other UDP-based protocols want two endpoints to talk directly, but neither side can initiate a connection to the other because both are behind NAT. STUN discovers each endpoint's public address by asking a third-party server. ICE coordinates the two sides to swap candidates and try direct connections. TURN provides a fallback relay when direct connection fails — typically 10–20 % of WebRTC sessions in production. RFC 8445 (July 2018) standardised this dance as ICE.
NAT comes in several flavours: full cone (most permissive), restricted cone, port-restricted cone, and symmetric (most restrictive). Symmetric NAT — common on corporate networks and 4G/5G carrier networks — assigns a different external port for each destination, defeating STUN-only hole punching and forcing TURN. Operations teams designing WebRTC services must budget TURN bandwidth for the percentage of sessions that fail to peer directly.
