WebRTC Essentials: Understanding Core Concepts

In this article, we’ll explore the fundamentals of WebRTC, break down its core concepts, and walk through the process of establishing real-time video and audio streams directly between browsers.

WebRTC (Web Real-Time Communication) is an open-source project and framework that enables web and mobile applications to capture and stream audio, video, and arbitrary data directly between peers.

The beauty of WebRTC lies in its ability to facilitate this exchange without requiring an intermediary server for the media flow, significantly reducing latency and server costs.

To understand how WebRTC operates in real-world environments, we need to examine five key pillars: NAT, STUN, TURN, ICE and SDP.

Every device has both a public and a private IP address. While the public IP is used for internet-wide communication, devices within a local network use private IP addresses. NAT (Network Address Translation) is the mechanism that translates your private address into a public one, allowing local devices to communicate with the outside world.

Read more about NAT here: RFC 2663

A STUN (Session Traversal Utilities for NAT) server is used to discover a user’s public identity on the internet. When Client A sends a request to a STUN server, the server responds with the user’s public IP address and port. These parameters are then shared with Client B, enabling the two peers to establish a direct communication path.

Read more about STUN servers here: RFC 8489

Sometimes, firewalls or complex symmetric NATs prevent a direct peer-to-peer connection. In these cases, a TURN (Traversal Using Relays around NAT) server acts as a bridge or relay. It receives the media stream from Client A and forwards it to Client B (and vice versa). While this introduces a server into the media path, it ensures the connection remains successful when all else fails.

Read more about TURN servers here: RFC 5766

STUN and TURN diagram

ICE (Interactive Connectivity Establishment) is the framework that manages the actual connection process. While STUN and TURN are tools for discovering IP/port pairs, ICE is the “coordinator” that evaluates all available paths. It prioritize the most direct connection (STUN) and automatically falls back to a relay (TURN) if necessary, ensuring a stable and robust link.

Read more about ICE here: RFC 6544

One of the core concepts is SDP (Session Description Protocol) is a formal declaration of a media session’s parameters. It ensures that both devices understand the technical requirements of the communication. For example, SDP negotiates whether the session is audio-only or includes video, which codecs (like VP8 or H.264) are supported, and the specific network transport settings required.

You can read more about SDP here: RFC 8866

In the next topic, we will implement a hands-on example to demonstrate how to create an RTC connection and stream live media between two peers.