WebRTC Video Conference: How Browser-Based Meetings Work

A WebRTC video conference allows participants to exchange real-time audio and video through a browser or application without relying on traditional browser plugins.

The user experience can be simple: open a meeting link, allow camera and microphone access, and join.

Behind that interface, several different systems have to work together:

• media capture;

• signaling;

• session negotiation;

• NAT and firewall traversal;

• encrypted media transport;

• multipoint media distribution.

This leads to the most important distinction:

A production conferencing system still needs signaling, meeting logic, authentication, and usually STUN, TURN, SFU, or MCU infrastructure.

WebRTC stands for Web Real-Time Communication.

It provides standardized browser and application APIs for real-time audio, video, screen sharing, and application data.

The main WebRTC interfaces include:

• getUserMedia() for camera and microphone access;

• getDisplayMedia() for screen sharing;

• RTCPeerConnection for real-time media connections;

• RTCDataChannel for application data.

A video conferencing application builds additional functionality around these components, such as:

• meeting rooms;

• participant authentication;

• moderation;

• recording;

• multipoint media distribution.

A simplified connection follows this sequence:

For a group meeting, a media server is commonly added to the path.

The browser requests access to the participant’s:

• microphone;

• camera;

• screen, when sharing is enabled.

The captured audio or video becomes media tracks that can be attached to a WebRTC connection.

At this point, however, the browser still does not know how to reach another participant.

WebRTC does not define a signaling protocol.

The application must provide its own mechanism for exchanging the information required to establish a session.

Signaling commonly uses:

• WebSocket;

• HTTPS;

• another application-specific protocol.

It can carry:

• session descriptions;

• ICE candidates;

• participant state;

• meeting-control messages.

This is an important architectural distinction:

The endpoints exchange an offer and answer describing the media session.

This negotiation determines compatible parameters such as:

• audio and video media;

• codecs;

• transport information;

• encryption parameters.

Once the endpoints know what they can exchange, they still need to find a working network path.

ICE, or Internet Connectivity Establishment, finds and tests possible network paths between participants.

This is necessary because users may be behind:

• NAT;

• corporate firewalls;

• home routers;

• VPNs;

• mobile networks.

Endpoints gather possible addresses called ICE candidates and exchange them through the signaling layer.

ICE then determines which candidate pair can actually transport media.

Once connectivity is established, WebRTC transports real-time audio and video securely.

Media uses SRTP, with DTLS used for secure key establishment.

A simplified flow is:

This transport encryption is mandatory in WebRTC.

However, encrypted WebRTC transport should not automatically be interpreted as application-level end-to-end encryption in every multipoint architecture.

ICE, STUN, and TURN are related, but they perform different jobs.

A participant behind NAT may know only its local address.

STUN helps it discover information about how it appears from outside the local network.

That information can become an ICE candidate.

Sometimes direct connectivity is impossible because of:

• restrictive NAT;

• firewall rules;

• blocked UDP;

• enterprise network policies.

TURN provides a relay.

Instead of:

the path may become:

TURN increases infrastructure and bandwidth requirements because media passes through the relay.

The key distinction is:

A two-person WebRTC call may communicate directly.

Multipoint conferencing is more complicated.

Three common architectures are:

In a full mesh conference, every participant sends media to every other participant.

With four users:

• A sends to B, C, and D;

• B sends to A, C, and D;

• and so on.

As the number of participants increases, each endpoint needs more:

• upload bandwidth;

• peer connections;

• encoding;

• decoding.

Mesh can work for small groups but becomes increasingly inefficient as meetings grow.

An SFU, or Selective Forwarding Unit, receives each participant’s stream and forwards selected streams to other participants.

The participant usually uploads once to the SFU.

The SFU then decides which streams or quality levels each receiver should get.

Clients normally create their own video layouts.

The result is:

• less server-side transcoding;

• more client-side decoding;

• potentially higher downstream bandwidth.

SFU architecture fits well with modern browsers and applications that can decode several video streams locally.

An MCU, or Multipoint Control Unit, performs more processing centrally.

It can:

• decode participant streams;

• mix audio;

• compose video layouts;

• transcode media;

• encode the resulting output.

The participant may then receive a single composed stream instead of many separate video tracks.

The trade-off is reversed:

Both TURN and SFU servers can appear between meeting participants, but they solve completely different problems.

A TURN server solves network reachability.

An SFU solves multipoint media distribution.

TURN does not normally:

• choose which speaker to forward;

• manage conference layouts;

• select video layers based on meeting context.

An SFU understands the conferencing media topology.

A production system may use both:

if the participant cannot directly reach the media server.

A useful way to understand WebRTC conferencing is to separate the control plane from the media plane.

Handles:

• authentication;

• room joining;

• signaling;

• participant state;

• permissions;

• moderation.

Handles:

• microphone audio;

• camera video;

• screen sharing;

• media feedback;

• quality adaptation.

These paths may use completely different servers.

For example:

while media travels:

or:

“Peer-to-peer” does not mean “serverless.”

A production WebRTC video conferencing system may contain:

Not every deployment needs every component.

Video conferencing networks constantly change.

A participant may encounter:

• Wi-Fi congestion;

• packet loss;

• changing mobile coverage;

• VPN overhead;

• competing traffic.

A WebRTC system can respond by changing:

• bitrate;

• resolution;

• frame rate;

• selected media streams;

• scalable video layers.

This is where the media architecture matters.

An SFU may stop sending a high-resolution stream when a participant is displayed only as a thumbnail.

WebRTC can transport screen sharing in addition to camera and microphone media.

The browser first captures:

• the entire screen;

• a window;

• a browser tab,

depending on browser capabilities and user permission.

The resulting content becomes another video track.

How it is distributed depends on the conferencing architecture.

An SFU may forward screen sharing as a separate stream.

WebRTC requires secure communication.

Important parts include:

Web applications generally need a secure context before browsers permit access to sensitive media APIs.

Used to establish secure session keys.

Protects real-time audio and video.

WebRTC transport security does not replace:

• authentication;

• authorization;

• meeting access policies;

• secure signaling;

• server security.

UDP is generally preferred for real-time media because retransmitting old video packets can be less useful than delivering newer packets quickly.

Some corporate networks block UDP.

In these situations, WebRTC connectivity may use TURN over TCP or TLS.

This improves the probability that a meeting can connect, but real-time performance may be less predictable because TCP retransmissions can increase latency under packet loss.

A production deployment should therefore test:

• direct UDP;

• TURN/UDP;

• TURN/TCP;

• TURN/TLS;

Likely areas to investigate:

• NAT;

• firewall rules;

• ICE configuration;

• TURN availability.

The signaling path may be working while the media path is blocked.

Remember:

Enterprise networks may block or restrict UDP.

A properly configured TURN fallback becomes important.

A full mesh architecture may be exhausting:

• upload bandwidth;

• CPU;

• peer connection capacity.

A media server may be required.

This can be normal adaptation to:

• bandwidth changes;

• packet loss;

• selected simulcast stream;

• selected SVC layer.

Screen sharing is a separate captured media track and may have different:

• resolution;

• frame rate;

• encoding;

• bandwidth requirements.

It does not.

The application must provide the signaling layer.

Media may pass through:

• TURN;

• SFU;

• MCU.

STUN assists connectivity discovery.

TURN relays traffic.

TURN solves connectivity.

SFU solves conference media distribution.

The number of peer connections and media streams grows quickly as participants are added.

HTTPS protects web traffic and signaling when used there.

Real-time WebRTC media has its own DTLS-SRTP/SRTP security mechanisms.

A system that works during development on one LAN may behave very differently across:

• NAT;

• VPN;

• mobile connections;

• enterprise firewalls.

It is a real-time audio/video conference that uses WebRTC technologies for media capture, connectivity, and secure media transport.

A simple peer-to-peer media connection may not require a central media server, but real conferencing applications generally need signaling and frequently STUN, TURN, SFU, or MCU infrastructure.

It supports peer-to-peer connections, but WebRTC media can also travel through TURN relays, SFUs, or MCUs.

STUN helps an endpoint discover connectivity information.

TURN relays media when a usable direct path cannot be established.

WebRTC is the real-time communication framework used by endpoints.

An SFU is a server architecture for distributing media between participants in multipoint conferences.

A WebRTC video conference is more than two browsers exchanging camera video.

A typical architecture combines:

WebRTC standardizes important parts of this chain, but it does not define the complete conferencing system.

The four distinctions that make WebRTC architecture easier to understand are:

• signaling is not media transport;

• STUN is not TURN;

• TURN is not an SFU;

• WebRTC is not a complete video conferencing platform.