How WebRTC works?

Imagine you're in an important meeting, and you're asked a critical question. You try to respond, but a lag delays your reply—awkward silence fills the room, and the moment is lost. That’s where WebRTC comes in, ensuring real-time communication without any delays.

What is WebRTC?

WebRTC (Web Real-Time Communication) is a free and open-source project providing web browsers and mobile applications with real-time communication (RTC) via application programming interfaces (APIs). It allows audio and video communication and streaming to work inside web pages by allowing direct peer-to-peer communication, eliminating the need to install plugins or download native apps.

In simpler terms, WebRTC allow two users to communicate directly without any third-party or middlewares.

It uses UDP protocol to transfer data which allows users to communicate in real time without any delay but as UDP does not guarantee that data will be transferred it is not safe for file transfer as if loss of any 1 byte of data can make the file corrupt.

WebRTC is used for messages and audio video streaming where if any frame is dropped it will not make any difference.

How WebRTC works?

Let’s break it down with a story.

You and your buddy were hanging out when you spotted a girl you really liked. You told your friend about her, but were too shy to ask for her number. Your friend, being a good pal, asked her out for you and gave her your number. Now, you and the girl chat privately for hours, but in your excitement, you’ve started neglecting your friend.

WebRTC works exactly like that, where peer A (you) want to talk to peer B (girl), which can't be done directly because neither of them have any information about each other.

Peer A tells signaling server (your buddy) and then the request is sent to Peer B, if it accepts the request, the message if forwarded to peer A via signalling server once both peer agree to connect they exchange some information (phone no.) to communicate.

Once the connection is established, communication can be done directly between the peers without using a signalling server.

What are signalling servers?

A signaling server is a server-side application that performs the role of a mediator for client devices attempting to establish a communication channel. It is not involved in the direct transmission of data or media streams but plays a crucial role in connection setup, management, and termination.

How signalling servers works for WebRTC?

If A wants to connect to B he will tell the signalling server that it wants to connect to B, the server would then notify B that user A wants to connect.

User B will tell server that it’s available, which would tell user A that user b is available.

Once both A and B are ready to connect, they will share their SDP information and ice candidates via signalling server.

Once connection is established, signalling server is not used.

Read more about signalling server.

Why we use STUN servers?

A STUN server helps clients behind firewalls and NAT devices to establish direct communication with other clients by providing them with their public IP address and port number.

Once both peer agree upon connecting, they have to share some information which helps them to establish connection.

To share this information, each peer should have it first. In order to know what are the ports available, what are the ways device can send and receive the streams, all the information, IP address and ICE candidate are collected by the STUN server and send back to the client.

It's like you got a new SIM card and to know your own number you call your buddy and asks him what’s your number.

There can be more than one way to connect, so both peer negotiate over it.

How SDP helps in the negotiation?

When two devices want to establish a real-time communication session, they need to exchange information about the session. SDP comes into play during this negotiation.

SDP operates on an "offer and answer" model. One device sends an SDP offer, and the other responds with an SDP answer.

Key Elements in SDP Negotiation:

• Media Types (audio, video, data)

• Codec Information for encoding and decoding

• Network Information (addresses, ports, protocols)

• Session Description of the overall setup

Devices may go through multiple rounds of offer and answer until they agree on a set of parameters for the communication session.

Once both devices agree on the session parameters through SDP negotiation, they use this information to set up their communication, including establishing direct connections if possible.

What information is shared to establish real-time connection?

The straight forward answer is ICE (Interactive Connectivity Establishment) candidate. But the question arises, what is it?

It is a network address that a device can use to send or receive data.

One computer can have many ICE candidates to communicate, when a device wants to establish a connection it gathers a list of potential ice candidates.

This list of ice candidate include various possibilities, like local IP address, public IP address and relayed address through TURN server

Devices goes through a process of exchanging and verifying ICE candidates until they agree on the most suitable ones for communication

Once the negotiation is complete, devices use the established ICE candidates to attempt direct peer- to-peer connections.

But what if after all this, clients are unable to connect, don't worry TURN server got your back.

TURN Server

TURN (Traversal Using Relays around NAT) servers act as a relay for data when direct peer-to-peer connections aren’t possible, especially in cases where firewalls or NAT are restrictive.

How TURN Complements WebRTC:

• In scenarios where NAT or firewalls prevent direct connection, TURN servers relay data between peers.

• TURN servers work alongside STUN servers to ensure reliable WebRTC communication.

The image below illustrates how WebRTC functions.

In conclusion, WebRTC is a powerful tool for real-time communication, enabling direct, low-latency connections between users. It combines several components—signaling, STUN, TURN, ICE candidates, and SDP negotiation—to create seamless, real-time experiences.

Next time you enjoy a seamless meeting, remember—WebRTC has your back, ensuring smooth, real-time communication.

You probably have questions about how you can implement this technology. Don’t worry. Watch Hussein Nasser’s Crash Course on WebRTC.

FAQ