What WebRTC is
WebRTC (Web Real-Time Communication) is a set of open technologies built into most modern web browsers that allow audio, video and arbitrary data to be exchanged between endpoints with very little delay. It is the foundation of many browser-based meetings and calls, and it can also be used for interactive broadcasts where fractions of a second matter.
The design goal is different from that of on-demand streaming. A typical streaming service prepares video in advance, cuts it into segments and lets each viewer’s player buffer ahead. WebRTC is built for conversation: media is sent continuously and played almost at once, with little or no buffering, because a call that lags by several seconds is unusable.
The basic building blocks
A WebRTC session combines several parts.
- Capturing media. The browser asks permission to use a camera and microphone, and the user must allow it.
- Compressing media. Audio and video are encoded using codecs the browsers support. Real-time use favours codecs and settings that encode quickly, since a long look-ahead would add delay. The fundamentals are the same as described in video codecs, but tuned for speed over maximum efficiency.
- Transporting media. Media travels in small packets over protocols that tolerate loss rather than wait for retransmission. Encryption is a built-in part of the standard, so media is protected in transit between endpoints.
- Adapting to conditions. The sender continually estimates available bandwidth and adjusts quality, frame rate or resolution, a real-time cousin of the adaptive bitrate idea.
How two browsers connect
Two people behind home routers cannot simply dial each other, because most devices do not have public addresses and routers block unsolicited incoming traffic. WebRTC deals with this in stages.
Signaling. Before any media flows, the two sides need to exchange descriptions of what they can do and how to reach each other. WebRTC deliberately does not define how this exchange happens; applications use their own server, typically over a standard web connection. The signaling server only helps the participants meet and does not carry the video.
Finding a path. Each side gathers possible network addresses and tries them in turn, using a process called ICE. It uses helper servers: a STUN server lets a device discover its public-facing address, which often allows a direct connection.
Relaying when needed. If a direct route fails, for example behind strict firewalls or certain network setups, traffic is relayed through a TURN server. Relays work reliably but add cost, since the provider has to carry the media, and can add a little delay.
When it works directly, the media goes peer to peer, taking a short path with no intermediary.
Why peer-to-peer alone does not scale
Direct connections suit one-to-one calls well. Group calls strain them: in a full mesh, every participant sends a separate copy of their video to every other, so the upload burden grows quickly with each person added. Most devices and home connections cannot keep up beyond a handful of participants.
Services therefore commonly insert a server in the middle. One widely used design is a selective forwarding unit: each participant sends one stream (or a few versions of it) to the server, which forwards the appropriate ones to everyone else without fully decoding them. Another is a mixing server that combines everyone’s video into one composite stream, which lowers the load on participants’ devices but costs more computing power at the service. Either way, the architecture is no longer purely peer to peer, though the same WebRTC technology is used.
For large audiences, forwarding servers can still struggle when tens of thousands of viewers each need their own live connection. That is why broadcasts to big audiences more often use segment-based delivery over content delivery networks, accepting extra delay in exchange for scale. How much delay, and how it can be trimmed, is covered in stream latency. Some services combine the two, using real-time delivery for a small interactive group and ordinary streaming for the wider audience.
Where it is used
Typical uses include video meetings and webinars, support calls, remote collaboration tools, online tutoring and telehealth-style consultations (where the technology serves the call and does not itself make any claim about care quality). It also appears in cloud gaming experiments, interactive auctions and live events where audience participation matters. Some live streaming tools use it for contribution, sending the stream from the creator’s browser to the platform with less delay than older methods.
Strengths and limits
Strengths. Delay can be a fraction of a second under good conditions. It needs no plugin in supporting browsers, uses open specifications, and includes encryption by default.
Limits.
- Quality depends heavily on the network, and packet loss shows up as freezes or artifacts.
- Scaling to big audiences is harder and generally costlier than segment-based delivery.
- Protected content with DRM protection is awkward to combine with a real-time design, so premium on-demand video seldom uses it.
- Real-time encoders sacrifice some compression efficiency, so for the same quality the bitrate is often higher than for pre-processed streaming video.
- Behaviour can vary between browsers and devices, so applications need testing across them.
A useful way to remember the difference
Segment-based streaming tries to make the viewing experience smooth and scalable by being willing to wait. WebRTC tries to make the interaction immediate by being willing to drop data. Which is appropriate depends on whether people are watching or talking, and how many of them there are.