TURN Server: What It Is, How It Works, and Where It Is Used

What Is a TURN Server

TURN Server (Traversal Using Relays around NAT) is a network service defined in RFC 5766 and updated in RFC 8656 that relays UDP and TCP traffic between two clients when direct P2P connectivity is impossible due to NAT or firewall restrictions. In the WebRTC architecture, the TURN server acts as the final fallback mechanism, guaranteeing connectivity under any network conditions.

Unlike STUN, which simply tells a client its external address, the TURN server actively participates in data transmission. Each peer establishes a connection to the TURN server and sends its media data to it. The TURN server, in turn, forwards this data to the other peer. As a result, there is no direct connection between peers — all traffic passes through the relay server, ensuring delivery even under the strictest NAT restrictions.

TURN Protocol

TURN is an extension of the STUN protocol. TURN messages use the same 20-byte header and attribute mechanism. The key difference is that TURN defines new message types (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) and attributes necessary for managing relay allocations. A client creates an allocation on the TURN server via an Allocate message, receives a relayed transport address, and uses it to send and receive data through the server.

How a TURN Server Works

The TURN server operates through the following sequence of steps. The client sends an Allocate Request with authentication (username, credential). The server verifies the credentials and creates an allocation — a temporary binding of a relayed address (IP:port on the TURN server) to the client. The server returns an Allocate Response with a relayed transport address — the address that other peers will use to send data to this client through the TURN server.

After the allocation is created, the client can send data through the TURN server using Send Indication messages or through channels (ChannelBind). When receiving data from the client, the TURN server checks permissions (authorization to send data to specific peers) and relays the data to the target peer. To receive incoming data, the client must first create a permission for the peer from which it expects data; otherwise, the TURN server will drop the incoming packet. A permission is created via a CreatePermission message specifying the peer's IP address.

Allocation and Lifetime

An allocation on the TURN server has a limited lifetime — 10 minutes by default. The client must periodically send a Refresh Request to extend the allocation. The lifetime is specified in seconds in the LIFETIME attribute. If no Refresh is received, the server removes the allocation and releases the relayed address. Recommended refresh interval — 5 minutes (300 seconds) to guard against Refresh packet loss.

Configuring a TURN Server in WebRTC

In WebRTC, the TURN server is configured via the RTCPeerConnection configuration in the iceServers array. TURN servers can use UDP, TCP, or TLS transport. Authentication typically uses time-limited credentials (TURN credentials) generated on the application server with a restricted validity period.

Consider an example of TURN server configuration in JavaScript with HMAC-SHA1 token authentication.

async function createPeerConnection(turnServerUrl) {
    const credentials = await fetchTurnCredentials();

    const config = {
        iceServers: [
            {
                urls: "stun:stun.l.google.com:19302"
            },
            {
                urls: turnServerUrl,
                username: credentials.username,
                credential: credentials.credential
            }
        ],
        iceTransportPolicy: "all"
    };

    return new RTCPeerConnection(config);
}

async function fetchTurnCredentials() {
    const response = await fetch("/api/turn-credentials");
    return response.json();
}

const turnUrl = "turn:turn.example.com:3478";
const pc = await createPeerConnection(turnUrl);

In this example, the TURN server is specified together with a STUN server in a single ICE configuration. The ICE process first attempts to use host candidates and srflx candidates obtained from STUN. If direct connectivity fails, ICE automatically switches to the relay candidate obtained from the TURN server. The parameter iceTransportPolicy: "all" enables relay candidates — the alternative value "relay" disables all candidates except TURN, which is useful for testing.

TURN Server Authentication

To prevent unauthorized use, the TURN server requires authentication. The standard approach is time-limited credentials generated on the application server using HMAC-SHA1. The application server encrypts the username with the TURN server's secret key and returns the username and credential to the client. The client passes them into the RTCPeerConnection configuration, and the browser uses them when creating an allocation on the TURN server. When the credentials expire, the client obtains new ones from the application server.

TURN vs STUN: Comparison

TURN and STUN solve related NAT traversal tasks but differ fundamentally in mechanism and cost. TURN relays traffic, acting as an intermediary, while STUN only helps determine the external address for a direct P2P connection. The choice between them depends on the peer NAT type and performance requirements.

In practice, the TURN server is used only for connections where P2P is impossible. According to Google (WebRTC statistics, 2023), approximately 15–20% of all WebRTC connections require TURN relay. The remaining 80–85% establish connectivity through STUN or local host candidates. When designing an application, you should budget for TURN traffic at 15–20% of total media volume if your audience includes users from corporate networks and regions with strict NAT restrictions.

TURN Server Cost and Performance

The TURN server consumes significant resources since all media traffic passes through it. Each active call with TURN relay uses the server's bandwidth equal to the total media traffic throughput (incoming + outgoing stream). For an HD video call (720p), this can be 1.5–2.5 Mbps per connection in each direction, totaling 3–5 Mbps of overall traffic through the TURN server.

There are several deployment options for TURN infrastructure. Free public TURN servers are not recommended for production due to lack of quality and security guarantees. Commercial providers (Twilio Network Traversal Service, Xirsys, Metered) offer TURN as a service with per-gigabyte pricing — typical cost is $0.005–0.02 per gigabyte. Self-hosting with coturn (open-source TURN server) requires a server with sufficient bandwidth capacity and monitoring setup.

• coturn — the most popular open-source TURN server, used in most production systems, supports UDP, TCP, TLS and DTLS transport.
• Twilio — a commercial service providing TURN + STUN with traffic-based pricing and authentication via time-limited tokens.
• Xirsys — a specialized TURN provider with a global server network and detailed usage analytics.
• Metered.ca — a TURN service with a free limit of up to 50 GB per month and pay-as-you-go beyond that.
• Self-hosted coturn — full control over configuration, but requires server administration and monitoring setup.

When choosing a TURN server solution, consider user geography, traffic cost, and security requirements. For applications with thousands of concurrent calls, self-hosted coturn on servers with a wide channel (1+ Gbps) may be more cost-effective than commercial providers. For small projects with dozens of users, commercial TURN services are preferable due to the lack of administration and monitoring overhead.