Skip to main content
typ relay

Relay Candidate

Server required

A relay candidate is an IP:port on a TURN server that forwards media on behalf of the client. Used as last resort when direct P2P (host) and STUN-discovered (srflx) paths both fail – typically behind symmetric NAT, strict firewalls, or corporate proxies. Relay adds latency and bandwidth cost but guarantees connectivity. TURN is defined in RFC 8656.

How it works

TURN (Traversal Using Relays around NAT, RFC 8656) relay candidates are gathered by allocating a port on a TURN server. All media passes through the TURN server – the remote peer connects to the TURN server's relay address, and the TURN server forwards packets to and from the client.

Gathering process: 1. ICE agent sends TURN Allocate request to TURN server (with credentials) 2. TURN server allocates a port on its public IP 3. ICE agent creates a relay candidate with the TURN server's public address 4. During connectivity checks, permissions and channel bindings are set up on the TURN server

TURN authentication: RFC 8656 §9. TURN uses long-term credential mechanism (username + HMAC-SHA1 password). For production, generate time-limited TURN credentials server-side and send them to clients via your signaling server – never hardcode credentials in client code.

When relay is necessary: - Symmetric NAT (each destination gets a different external port) - Strict corporate firewalls (only TCP/443 outbound allowed) - Mobile networks with carrier-grade NAT - Estimated ~20–30% of real-world WebRTC connections require TURN

Cost of relay: - Bandwidth: all media passes through your TURN server – 1 Mbps video × 2 (in + out) × participants - Latency: typically +20–50 ms per hop - Infrastructure: Coturn is the standard open-source TURN server

TURN over TCP/TLS: for environments that block UDP (firewalls, corporate proxies), TURN can operate over TCP port 443 (TLS) using urls: "turns:turn.example.com:443?transport=tcp".

SDP Example

# Relay candidate in SDP
a=candidate:3 1 UDP 16777215 203.0.113.100 49152 typ relay
  raddr 203.0.113.1 rport 54321 generation 0
#                ^ TURN server's public address (relay address)
#     raddr/rport: the srflx candidate for this TURN allocation

# TURN server config (with time-limited credentials):
const pc = new RTCPeerConnection({
  iceServers: [{
    urls: [
      "turn:turn.example.com:3478",
      "turns:turn.example.com:443?transport=tcp"  // TCP fallback
    ],
    username: "time-limited-user",
    credential: "hmac-sha1-password"
  }]
});

Pros

  • +Guarantees connectivity regardless of NAT type or firewall
  • +Works through symmetric NAT, corporate firewalls, and UDP-blocking networks
  • +TURN over TLS/TCP (port 443) bypasses almost all firewalls

Cons

  • !Highest latency – all media passes through relay server
  • !Bandwidth cost – TURN server carries full media load
  • !Infrastructure cost – you must run your own TURN server for production
  • !Lowest ICE priority – only used when host and srflx fail

Priority

Lowest (0 × 2^24 + 65535 × 2^8 + (256-component))

See Also