videocalling
Back to Glossary

STUN (Session Traversal Utilities for NAT)

Protocol

Protocol helping devices discover their public IP address

What is STUN?

STUN (Session Traversal Utilities for NAT) is a network protocol that helps devices behind NAT routers discover their public IP address and determine whether they can establish direct peer-to-peer connections. Think of STUN as a mirror on the internet—your device asks the STUN server "what's my public IP?", and the server replies with what it sees.

STUN doesn't relay media or data. It's simply a discovery service that enables WebRTC clients to learn their network configuration. Once a device knows its public IP and port, it can share this information with peers to attempt direct connections.

Standardized in RFC 5389 (with extensions in RFC 7635), STUN is a foundational component of WebRTC's ICE framework, enabling most browser-to-browser video calls to connect directly without expensive relay servers.

The NAT Problem STUN Solves

To understand STUN, you must first understand the problem:

Your home router uses NAT (Network Address Translation) to share one public IP address among multiple devices. Your laptop gets a private IP like 192.168.1.100, which only works on your local network. When you access the internet, the router translates your private IP to its public IP and tracks which internal device each connection belongs to.

This creates a problem for peer-to-peer connections: You can't tell someone else to connect to 192.168.1.100 because that address is private and unreachable from the internet. You need to know your router's public IP and which port the router assigned for your connection.

STUN provides this information.

How STUN Works: Step by Step

1. Client Sends STUN Request

When initiating a WebRTC connection, your browser sends a STUN binding request to a public STUN server (like stun.l.google.com:19302). This request travels through your router, which applies NAT by replacing your private IP/port with the router's public IP and a port it assigns.

2. STUN Server Observes and Responds

The STUN server receives the request and notes the source IP address and port—this is your router's public IP and the NAT-translated port. The server sends this information back to you in a binding response.

3. Client Learns Public Address

Your browser receives the response and now knows: "From the internet's perspective, I'm reachable at 203.0.113.45:54321". This becomes a "server reflexive candidate" in ICE terminology.

4. Candidates Exchanged and Connection Attempted

Both peers perform STUN queries, learn their public addresses, exchange this information via signaling, and attempt to connect directly using these public IPs. If both routers allow the connection (which happens 75-85% of the time), the peers establish a direct WebRTC connection without any relay.

When STUN Works

STUN succeeds in establishing direct connections when NAT routers use "cone NAT" or similar permissive mapping:

  • Full cone NAT: Router maps one internal IP:port to one external IP:port. Anyone can connect to the external address. STUN works perfectly
  • Restricted cone NAT: Router only accepts incoming packets from addresses the internal device has contacted. STUN works after peers exchange addresses
  • Port-restricted cone NAT: Like restricted cone, but also checks source port. STUN still works with proper negotiation

These scenarios cover most consumer routers and mobile networks, which is why STUN enables the majority of WebRTC connections.

When STUN Fails

Symmetric NAT

STUN's nemesis. Symmetric NAT creates different port mappings for each destination. When you query the STUN server, the router assigns port 54321. But when you try connecting to a peer, the router assigns a completely different port 54322. The public address STUN discovered is useless because it doesn't work for peer connections.

Symmetric NAT is common in corporate networks and some carrier-grade NAT (CGNAT) deployments. When both peers are behind symmetric NAT, STUN cannot help—TURN relay is required.

Restrictive Firewalls

Some firewalls block all incoming UDP traffic, even if the internal device initiated the connection. STUN can still discover the public IP, but the connection will fail because the firewall drops incoming packets.

Double NAT

When you're behind multiple layers of NAT (e.g., router behind ISP's NAT), STUN only reveals the outermost public IP. This may still work, but adds complexity and reduces success rates.

STUN Server Infrastructure

STUN servers are lightweight and cheap to operate because they don't relay media—they just answer simple queries. This is why free public STUN servers exist:

  • stun.l.google.com:19302 (Google's public STUN server)
  • stun1.l.google.com:19302 through stun4.l.google.com:19302
  • Cloudflare, Twilio, and other providers also offer free STUN servers

A STUN query is tiny (a few dozen bytes), and the response is equally small. A single STUN server can handle millions of queries per day on modest hardware.

STUN in Practice: Real-World Numbers

In typical WebRTC deployments:

  • 75-85%: Connections successfully use STUN to establish direct peer-to-peer paths
  • 15-25%: STUN fails and connections fall back to TURN relay
  • <1%: Both STUN and TURN fail due to extremely restrictive networks

This high success rate is why STUN is so valuable—it prevents the majority of calls from requiring expensive relay infrastructure.

STUN vs TURN

Understanding the difference is crucial:

  • STUN: Helps discover public IPs. Doesn't relay data. Free to operate. Works 75-85% of the time. Low latency (no relay means direct connection)
  • TURN: Relays all media when STUN fails. Expensive (bandwidth costs). Required fallback. Adds latency (data goes through relay)

Most WebRTC applications configure both: STUN servers for discovery, TURN servers as fallback. ICE tries STUN-discovered direct connections first and only uses TURN when necessary.

Security Considerations

STUN servers see your public IP, which raises minor privacy concerns. Browsers mitigate this by:

  • Requiring user consent for camera/microphone access before performing STUN queries
  • Some browsers limit or obfuscate IP exposure in privacy modes
  • WebRTC encrypts all media streams, so STUN servers can't access call content

Since STUN servers only see IP addresses and ports (not media content), the security risk is minimal compared to the functionality gained.

Why STUN Matters in 2025

STUN is the reason WebRTC can provide high-quality, low-latency video calls at scale without breaking the bank on server infrastructure. By enabling direct peer-to-peer connections for the vast majority of calls, STUN:

  • Minimizes latency (direct connections are faster than relay)
  • Reduces server costs (no relay bandwidth for 75-85% of calls)
  • Improves call quality (no relay bottleneck)
  • Enhances privacy (media doesn't pass through servers)

While newer technologies continue to evolve, STUN remains a cornerstone of WebRTC in 2025, as essential as it was when first standardized. Any WebRTC application requires STUN servers—fortunately, they're cheap to run and often available for free from public providers.

The Bottom Line

STUN is a simple but powerful protocol: it helps devices discover their public network identity so they can connect directly. While it doesn't work in all network configurations (symmetric NAT defeats it), it succeeds often enough to dramatically reduce the need for expensive relay servers.

As part of the ICE framework, STUN quietly powers the majority of WebRTC connections, enabling the browser-based video calling revolution by making peer-to-peer communication feasible despite NAT and firewalls.

References

Related Terms

TURN (Traversal Using Relays around NAT)ICE (Interactive Connectivity Establishment)NAT (Network Address Translation)
Back to Glossary