STUN

STUN stands for Session Traversal Utilities for NAT.

It is a lightweight client-server protocol that lets any device behind a NAT router discover its public-facing IP address and port. The protocol is defined in IETF RFC 5389. By design, STUN carries no media and maintains no session state - it simply answers one question: "what does my connection look like from the outside internet?"

In WebRTC, STUN is one of two NAT traversal mechanisms (the other is TURN). Both are coordinated by ICE, which manages the full connectivity establishment process.

What is a STUN Server?

A STUN server runs on the public internet and replies to incoming requests from devices behind NAT. The response includes the public IP address and port that the request arrived from. The WebRTC client uses that information to tell its peers where they might be able to reach it.

In most deployments, STUN servers are not installed as separate entities - they run as part of a TURN server. Configuring a TURN/UDP server implicitly also provides STUN, so there is no need to list a separate STUN entry in the iceServers configuration of a peer connection.

While there are free public servers that can be used (such as the one Google operates), it is not advisable to use them in commercial services as a primary NAT traversal mechanism.

Using a STUN Server

A WebRTC client has to know its public IP address to improve connection success rates. For that purpose, WebRTC sends a request to a STUN server during ICE candidate gathering. The server replies with the public IP and port the request came from. The client then includes this server-reflexive candidate in its ICE candidate list and shares it with the remote peer.

It might not always work. With some network architectures and symmetric NAT configurations, the public IP address discovered via STUN will not be reachable from outside. This is why STUN is used together with TURN and ICE - TURN provides a relay fallback when direct paths fail.

Free and Public STUN Servers

There are various free STUN servers available, and STUN's stateless design makes them cheap to operate.

Using free public servers is not advisable for commercial services:

• These free STUN servers might not be available tomorrow - there is no SLA and no support
• You will usually also need TURN servers, which are not free. TURN servers also handle STUN, so deploying or paying for TURN already covers your STUN requirements
• Using too many STUN and TURN servers in the iceServers list is counterproductive - it increases ICE gathering time and can cause delays in connectivity rather than improving connection success

Best Practices

• If you are using a free or public server (like the famous stun.l.google.com:19302), expect it to go down from time to time or even disappear at some point - you have no control over it and no SLA
• STUN is usually deployed with TURN servers. Focus on a TURN server solution and STUN "will follow"
• Configuring TURN/UDP implicitly also implements the STUN protocol. If you use a TURN/UDP server, you can skip explicitly listing a separate STUN server in the iceServers configuration

See also the episode of "WebRTC Codelab" on setting up STUN in a WebRTC app:

Additional Reading

• We TURNed to see a STUNning view of the ICE
• Do you still need TURN if your media server has a public IP address?
• WebRTC ports: Understanding IP addresses and port ranges in WebRTC