WebRTC Explained: How It Connects People Online

In this article, I tried to cover WebRTC's underlying idea. We’ll discuss, what WebRTC is, why it matters, and how it works. We'll cover the terminology needed to understand WebRTC and also how to code with WebRTC. Let’s get started !!!

What is WebRTC?

WebRTC (Web Real-Time Communication) is a technology that lets web applications and sites exchange data between browsers without requiring a middleman. It is like a magic wand that lets you make video calls, and voice chats, and share files directly between devices without needing extra apps or plugins.

Why WebRTC?

Why should you care? Because it powers all the cool things like:

• Video Calls - Zoom, Google Meet, WhatsApp, etc.

• Voice Chats - Online customer support, gaming voice chat.

• Live Streaming - Like Twitch, but for all kinds of apps.

• P2P File Sharing - Send files directly, no cloud needed.

Key WebRTC Terminologies (in simple words!)

🌎 STUN Server - “What’s my IP ??”

A STUN (Session Traversal Utilities for NAT) server helps clients discover their public IP address and determine if they are behind a NAT. This is essential for establishing direct peer-to-peer (P2P) communication.

How it works:

1. You ask the STUN server: "Hey, what's my public IP?"

2. It replies: "Here it is! Also, I checked, and you might (or might not) have some network restrictions (NAT restrictions to be specific)."

3. If all’s good, you connect directly; if not, you might need a TURN server.

📶 NAT (Network Address Translation) - “Your wifi’s bouncer”

NAT is a method used by routers to assign a public IP address to devices on a private network. It allows multiple devices to share a single public IP. To put it in simple terms; your router hides your private IP behind a public one, like a bouncer at a club. This keeps you safe but can make direct connections tricky.

The Problem:

1. Some NAT types prevent direct peer-to-peer connections.

2. Symmetric NAT allows only outbound connections, blocking incoming requests from unknown peers.

3. Symmetric NAT? Super strict bouncer – you NEED a TURN server!

↩ TURN Server - “The friendly middleman“

A TURN (Traversal Using Relays around NAT) server acts as a relay when direct P2P communication is not possible due to strict NAT restrictions.

How it works:

1. The client establishes a connection with a TURN server.

2. All media/data packets are sent to the TURN server, which then forwards them to the recipient.

3. This method ensures connectivity but adds latency and increases bandwidth usage (due to extra travel time).

🧊 ICE Candidates - “Finding the best route“

ICE is a framework used to find the best network path for establishing a connection.

The ICE process:

1. The browser gathers multiple ICE candidates, which are possible network routes (e.g., local network, STUN-discovered public IP, or TURN relay).

2. It attempts to establish a connection using the most efficient route.

3. If a direct connection fails, it falls back to using a TURN relay.

🎯 SDP - “Setting up the rules“

SDP (Session Description Protocol) is like making sure both parties speak the same language before a call. SDP is a format used to describe multimedia session parameters between peers.

Key SDP components:

1. Media types (audio, video, data)

2. Codecs (H.264, VP8, Opus, etc.)

3. Encryption details

4. Network information

The Big Problem: Finding Each Other on the Internet

The internet is huge, and every device needs an address to communicate. However, due to the limited number of IPv4 addresses, most devices don’t have a unique public IP. Instead, they sit behind something called NAT (Network Address Translation), which allows multiple devices to share a single public IP.

🔹 Why does this matter?

If a device doesn’t have a unique public address, how can another device find it and establish a direct connection?
Imagine trying to call your friend without knowing their phone number. That’s exactly the issue WebRTC faces.

🔽 Solution?

WebRTC uses a Signaling Process to help peers find each other and agree on how to communicate.

🤔 So what is this signaling process

🗺 Think of Signaling as the "Navigation System" for WebRTC

Before two peers can connect, they need to exchange:

1. IP & Port Info 📍 – "Where are you located?"

2. Media Capabilities 🎥 – "What video & audio formats do you support?"

3. Connection Control Messages 🚦 – "Hey, I’m ready!" / "Oops, I disconnected!"

Since WebRTC doesn’t define how signaling should be done developers can use:

1. XMPP/SIP (used in VoIP systems)

2. WebSockets (fast & real-time)

3. HTTP Polling (old-school, but works)

4. Even a carrier pigeon! (High latency, not recommended xD)

How does signaling work?

Both peers initially connect to a signaling server, which acts as a central meeting point. The initiator sends an offer, and upon receiving it, the receiver responds with an answer. During this exchange, they share Session Description Protocols (SDPs), which include details about media formats (such as codecs and encryption) and connection information (like IP addresses and ports). They also exchange Interactive Connectivity Establishment (ICE) candidates to determine the most efficient route for a direct connection. Once all the necessary information is agreed upon, the signaling server steps aside, allowing WebRTC to establish a seamless peer-to-peer connection.

ICE Restart: What Happens When Network Changes?

Imagine you're on a video call while walking out of your house. You switch from Wi-Fi to mobile data—but the call shouldn’t drop, right?

That’s where ICE Restart comes in!

ICE Restart = Reconnecting Without Dropping the Call

• Your device detects a network change (Wi-Fi ➝ Mobile Data).

• It renegotiates the best connection route using ICE.

• The new connection is established while the old one is still running.

• Once stable, WebRTC switches over and closes the old connection.

💡 Cool part? You don’t even notice it happening!

🎬 Final Thoughts

WebRTC might seem complex but at its core, it’s just about:

• Finding your peer - Signaling

• Choosing the best route - ICE

• Keeping the connection smooth - ICE restart

There are a lot more nuances in WebRTC about perfect negotiations, glaring, data channels, and whatnot. Maybe that’ll be an article for another time.
until then happy coding :)