STUN is the lookup service WebRTC uses to find out how the wider internet sees a client. The client sends a small UDP packet to a STUN server (Google's stun.l.google.com:19302 is a public default), and the server replies with the IP and port it saw the request arrive from. That tells the client what its NAT translated the source to, and the client advertises that address to its peer as an ICE candidate.
STUN does not pass any media — it only does the address discovery. It is cheap, stateless and runs on UDP/3478 or UDP/5349 for STUN over TLS. Any WebRTC application needs at least one STUN server reachable from both peers, and the standard practice is to configure two or three in iceServers. Public STUN servers (Google, Cloudflare, Twilio) are free to use and handle billions of requests per day.
STUN works for cone-style NATs but fails against symmetric NATs, where the NAT assigns a different external port for every destination. In that case the public IP STUN reports is only valid for the STUN server itself; sending packets to a peer from the same socket produces a different mapping. This is when TURN takes over — a media relay that both peers can reach with conventional client-initiated connections.
The book · Volume 2 of 7
Video Streaming: A Complete Guide to Video Delivery: From Network Protocols and Transport to Ingest, HLS, and MPEG-DASH
STUN tells a client its public address through NAT, and it is the first step that decides whether a WebRTC call connects directly or needs a relay. This volume covers STUN in detail, with NAT types and traversal, UDP behaviour on real networks and the transport choices that follow when direct paths fail. Written by Nikolay Sapunov, CEO at Fora Soft.
WebRTC calls taking long to connect or falling back to relay too often?
We will review your STUN and ICE setup and return a connection plan with server placement and the expected share of direct versus relayed calls. 250+ video products shipped since 2005.
