STUN and TURN Servers in WebRTC Calls Explained

WebRTC enables real-time peer-to-peer audio, video, and data communication directly between web browsers using JavaScript. However, establishing a direct peer-to-peer connection across the modern internet is challenging due to Network Address Translation (NAT) devices and restrictive firewalls. This article explains the crucial roles of Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN) servers in discovering network paths, bypassing firewall restrictions, and ensuring reliable WebRTC media exchange.

The Problem: NAT and Firewalls

In a local network, devices are assigned private IP addresses (such as 192.168.x.x or 10.x.x.x) that are not directly reachable from the public internet. Routers use NAT to map these private IP addresses to a single public IP address. When two browsers attempt to establish a direct WebRTC connection, they cannot simply share their private IP addresses because neither device can route traffic to the other’s local network. Additionally, symmetric NATs and enterprise firewalls frequently block unsolicited inbound connection attempts.

The Role of STUN Servers

A STUN (Session Traversal Utilities for NAT) server is a lightweight tool used to discover a device’s public IP address and port mapping.

During the WebRTC signaling phase: 1. The client sends a request to a public STUN server over UDP. 2. The STUN server inspects the incoming packet and determines the public IP address and port from which the request originated. 3. The STUN server sends this information back to the client as a “Server Reflexive” (srflx) candidate. 4. The client shares this public address with the remote peer via a signaling server.

Once both peers know each other’s public endpoints, they attempt to establish a direct peer-to-peer connection. STUN servers require very little bandwidth because they only assist with the initial handshake and do not process audio or video streams.

The Role of TURN Servers

While STUN handles the majority of standard NAT scenarios, it fails when one or both peers are behind a Symmetric NAT or strict corporate firewall. In Symmetric NAT, the router assigns a unique port for every external destination, rendering the STUN-discovered port useless for connecting to a different peer.

A TURN (Traversal Using Relays around NAT) server solves this problem by acting as an intermediary relay: 1. When direct connection attempts fail, the WebRTC client authenticates with a TURN server and requests an allocated relay address. 2. Both peers send their media streams to the TURN server instead of directly to each other. 3. The TURN server forwards the packets between the peers.

Because all audio, video, and data packets pass through the TURN server, it requires significant bandwidth, robust infrastructure, and authentication to prevent unauthorized usage. TURN acts as a fail-safe fallback, ensuring that WebRTC calls connect successfully in virtually any network environment.

How STUN and TURN Work Together with ICE

WebRTC uses the Interactive Connectivity Establishment (ICE) framework to orchestrate connection attempts. When configuring an RTCPeerConnection in JavaScript, developers provide a list of STUN and TURN servers within the configuration object:

const configuration = {
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    {
      urls: 'turn:turn.example.com:3478',
      username: 'user',
      credential: 'password'
    }
  ]
};

const peerConnection = new RTCPeerConnection(configuration);

ICE gathers three types of candidates: - Host candidates: The device’s local private IP address. - Server Reflexive candidates: The public IP address and port discovered via STUN. - Relay candidates: The relay IP address provided by a TURN server.

The ICE framework tests these paths in order of priority, always favoring the lowest-latency, lowest-cost direct connection (Host or STUN) and falling back to the relayed connection (TURN) only when direct communication is impossible.