↓Skip to main content
  1. Posts/

WebRTC Deep Dive: ICE, TURN, and SFU

·3 mins
Table of Contents

If you’ve ever joined a Google Meet call, participated in an online game with voice chat, or watched a live stream in your browser, you’ve likely used WebRTC without even realizing it.

It’s the technology that enables real-time, peer-to-peer communication directly in browsers and apps - no plugins required.

Behind the scenes, however, making two devices talk to each other across the internet is more complex than it sounds. Firewalls, NAT devices, and varying network conditions make direct connections challenging.

This is where ICE, TURN, and SFU come in.

ICE - The Connection Negotiator #

ICE (Interactive Connectivity Establishment) is responsible for figuring out how two peers can best connect to each other.

It does this by collecting possible connection options - called candidates - and testing them until it finds one that works.

There are three types of candidates:

  • Host candidates: Local IP addresses (e.g., 192.168.1.5). Works if both peers are on the same network.
  • Server reflexive candidates: Public IP addresses discovered via a STUN server.
  • Relay candidates: IP addresses provided by a TURN server when direct routes fail.

ICE tries the best candidates first (usually direct connections) and falls back to less optimal ones if needed.

ICE Open Source Implementations #

TURN - The Reliable Relay #

TURN (Traversal Using Relays around NAT) is the fallback option when a direct peer-to-peer connection isn’t possible - often because of strict firewalls or certain types of NAT.

In this case, the media stream is relayed through a TURN server.

While TURN guarantees connectivity, it comes at a cost:

  • Higher latency (because traffic goes through an extra hop)
  • Increased bandwidth usage on the server
  • Operational cost for running a high-bandwidth service

For production deployments, having a TURN server is essential to ensure your application works in all network environments.

TURN servers Open Source Implementations #

  • coturn - TURN and STUN Server implementation using C
  • restund - Lightweight option also implemented in C

SFU - The Bandwidth Optimizer for Group Calls #

In one-to-one calls, direct peer-to-peer works fine. But for group calls, sending multiple streams from each participant to all others quickly becomes inefficient.

An SFU (Selective Forwarding Unit) solves this problem.

With an SFU:

  1. Each participant sends one media stream to the SFU
  2. The SFU forwards that stream to other participants
  3. The SFU may send different quality versions depending on the recipient’s connection

This greatly reduces the upload bandwidth requirement for participants and improves call scalability.

SFUs Open Source Implementations #

Putting It All Together #

A production-ready WebRTC deployment often looks like this:

  1. Signaling Server - Exchanges session descriptions and ICE candidates between peers
  2. STUN/TURN Server - Handles NAT traversal and relaying when necessary
  3. SFU (Optional) - For multi-party calls, optimizes bandwidth usage
  4. Application Server - Manages rooms, authentication, and user states

Example Flow: #

Browser A ↔ ICE ↔ (STUN/TURN if needed) ↔ Browser B

Browser A → SFU → Multiple Participants

Final Thoughts #

WebRTC is often called a “peer-to-peer” technology, but in practice, most real-world systems rely on a mix of ICE, TURN, and often SFU to work reliably.

  • ICE finds the best path.
  • TURN guarantees a connection when direct paths fail.
  • SFU keeps group calls efficient.

Understanding these components isn’t just about building WebRTC apps - it’s about knowing how to make them work everywhere, for everyone.