WebRTC (Web Real-Time Communication) is a set of browser APIs and network protocols for real-time audio, video and data exchange between peers. Among Web APIs it is unusual because it is not a single interface but a stack: JavaScript objects such as RTCPeerConnection, getUserMedia and RTCDataChannel sit on top of a standardized transport that handles NAT traversal, encryption and congestion control.
The defining property of WebRTC is latency measured in hundreds of milliseconds rather than seconds. That makes it the standard basis for video calls, screen sharing, cloud gaming and low-latency live streaming in the browser, without any plug-in.
The WebRTC API surface
Applications use three main interfaces, plus helper objects for statistics and encoding control. The table lists them with their responsibilities.
| Interface | Purpose | Typical use |
|---|---|---|
| getUserMedia | Captures camera and microphone | Local media stream for a call |
| getDisplayMedia | Captures a screen, window or tab | Screen sharing |
| RTCPeerConnection | Manages the connection to one peer | Negotiation, transport, media tracks |
| RTCDataChannel | Sends arbitrary data over the peer link | Chat, file transfer, game state |
| getStats | Reports transport and media metrics | Quality monitoring |
Media capture requires a secure context and explicit user permission. Browsers show an indicator while the camera or microphone is active, and permission prompts cannot be bypassed by script.
Signaling, ICE, STUN and TURN
WebRTC deliberately does not define signaling. Before two peers can connect, they must exchange SDP offers and answers, which describe codecs and media, and ICE candidates, which describe possible network addresses. Applications carry these messages over any channel they choose, most often a WebSocket server.
ICE (Interactive Connectivity Establishment) then tests candidate pairs to find a working path. Because most devices sit behind NAT, ICE relies on two kinds of helper servers whose roles are often confused.
| Candidate type | Source | Cost and behavior |
|---|---|---|
| Host | Local interface address | Free, works on the same network |
| Server reflexive | Public address learned through STUN | Cheap, fails behind symmetric NAT |
| Relay | Address allocated on a TURN server | Always works, relays all media bandwidth |
A STUN server only tells a client its public address and carries no media, so it is inexpensive. A TURN server relays every packet when direct paths fail, which happens on restrictive corporate and mobile networks. Production services that skip TURN lose a noticeable share of calls on such networks, so a TURN deployment, ideally reachable over TLS on port 443, is essential.
Transport, codecs and security
Media travels over SRTP on UDP, keyed through DTLS, so every WebRTC session is encrypted by mandatory design; there is no unencrypted mode. Data channels use SCTP over DTLS and can be configured as reliable and ordered or as unreliable for latency-sensitive data such as game input.
Browsers must support Opus for audio and both VP8 and H.264 for video; VP9 and AV1 are widely available as well. Congestion control adapts the bitrate continuously, typically from a few hundred kilobits to several megabits per second per video stream, depending on available bandwidth and resolution.
Applications can shape quality through encoding parameters on each sender, such as maximum bitrate, frame rate and resolution scaling. For screen sharing, a content hint of detail or text tells the encoder to preserve sharpness at a lower frame rate, while camera video favors motion smoothness. Choosing these settings per track matters more for perceived quality than the codec choice itself.
WebRTC compared with WebSocket and server-sent events
WebRTC is often compared with other real-time Web APIs, but it solves a different problem: peer-to-peer media and data with minimal delay, rather than client-to-server messaging.
| Technology | Topology | Transport | Best fit |
|---|---|---|---|
| WebRTC | Peer to peer or via media server | UDP with DTLS and SRTP | Calls, streaming, low-latency data |
| WebSocket | Client to server | TCP | Chat, signaling, live updates |
| Server-sent events | Server to client only | HTTP stream | Notifications, feeds |
| Web push | Server to device via push service | Push protocol | Messages when page is closed |
In practice these technologies complement each other: a WebRTC application usually needs a WebSocket connection for signaling, and server-sent events may deliver presence updates around the call.
Scaling beyond two participants
Pure peer-to-peer connections scale poorly because each participant must upload a separate stream to every other participant. Group applications therefore adopt one of three server topologies.
| Topology | How it works | Practical limit |
|---|---|---|
| Mesh | Every peer connects to every peer | About four to six participants |
| SFU | Server forwards streams without decoding | Dozens of active senders, many viewers |
| MCU | Server decodes and mixes into one stream | Many participants, high server CPU |
The selective forwarding unit (SFU) is the dominant architecture today. Combined with simulcast, where a sender encodes several resolutions at once, it lets the server deliver a suitable quality to each receiver.
Common pitfalls
- Deploying without TURN, which causes silent connection failures on restrictive networks.
- Ignoring renegotiation, so adding a screen-share track breaks the session.
- Exposing local addresses; modern browsers use mDNS host candidates to limit this leakage.
- Not monitoring getStats, which hides packet loss, jitter and round-trip time problems.
- Expecting server-side recording for free; recording requires a media server in the path.
Most of these failures surface only under real network conditions. Testing on a single office network hides NAT and firewall problems, so teams should test across mobile, home and corporate networks before launch and keep connection success rates visible in monitoring.
Explained without jargon
WebRTC is what lets two browsers talk to each other directly, with sound, video or data, almost without delay. When you join a video call from a link without installing anything, this technology is usually doing the work.
A server still helps the two sides find each other, a bit like an operator connecting a telephone call. After that, the conversation flows as directly as the network allows, and it is always encrypted.
A typical use case
A telehealth provider needs browser-based video consultations between doctors and patients, with no app installation. Patients connect from home networks, hospital guest networks and mobile data.
The team uses getUserMedia for capture, a WebSocket service for signaling and an SFU for consultations that include an interpreter. Early tests show that some patients on mobile networks cannot connect at all; adding a TURN server reachable over TLS on port 443 resolves those failures. Monitoring through getStats flags sessions where packet loss exceeds a few percent, and the application then lowers video resolution automatically.
The result is a consultation that starts from a single link, with audio delay low enough for natural conversation and encryption applied to every stream.