What Is WebRTC?

WebRTC in Plain English

WebRTC stands for Web Real-Time Communication. It is a set of browser APIs and network protocols that allow two endpoints to exchange audio, video, and arbitrary data with very low delay. The most familiar examples are video meetings, browser-based phone calls, telehealth sessions, online classrooms, customer support widgets, and screen sharing tools.

The important idea is that WebRTC is not just a single protocol. It is a full stack: device capture APIs for microphone, camera, and screen; codecs for compressing media; signaling data that describes a session; NAT traversal tools that find a route through home routers and firewalls; encrypted media transport; congestion control; and optional data channels for non-media traffic.

What Makes WebRTC Different From Normal HTTP

Traditional web pages use HTTP's request-response model: the browser asks, the server answers. That is perfect for loading documents and APIs, but poor for live conversation. A video call cannot wait for the browser to repeatedly ask, "Do you have the next slice of audio yet?" WebRTC creates a long-lived, low-latency path where both sides can send media continuously.

Unlike a standard HTTP API, a WebRTC call also adapts constantly. If Wi-Fi gets noisy, available bandwidth falls, packet loss rises, or the CPU is overloaded, the sender can lower resolution, change bitrate, prioritize audio, or retransmit selected packets. A good WebRTC app feels graceful under imperfect network conditions because it is designed for real-time tradeoffs instead of perfect file delivery.

The WebRTC Connection Flow

A WebRTC session usually begins inside application code. One peer creates an offer that describes supported codecs, media tracks, encryption fingerprints, and network candidates. That offer is sent to the other peer through a signaling channel. WebRTC does not mandate the signaling transport; applications commonly use HTTPS, WebSocket, SIP, or a custom backend. The receiving peer creates an answer and sends it back the same way.

After offer and answer exchange, both sides run ICE, short for Interactive Connectivity Establishment. ICE gathers possible network paths called candidates: local private addresses, public addresses discovered through STUN, and relay addresses provided by TURN. The peers test these candidates and choose the best working pair. If a direct path works, media can flow peer to peer. If NAT, corporate firewalls, or mobile carrier behavior blocks it, a TURN relay carries the traffic.

STUN, TURN, and ICE

Media Transport, Codecs, and Encryption

WebRTC audio and video usually travel over RTP with encryption through SRTP. Key negotiation uses DTLS, so media encryption is built into the stack rather than added as an optional feature. For audio, Opus is the dominant codec because it handles speech, music, packet loss, and changing bitrates extremely well. For video, WebRTC implementations commonly support codecs such as VP8, VP9, H.264, and AV1 depending on browser and hardware capabilities.

Real-time media is not transported like a file download. If an old video packet arrives too late, it may be useless because the playback moment has already passed. WebRTC therefore balances retransmission, forward error correction, jitter buffering, bitrate adaptation, and frame dropping. The goal is not perfect delivery; it is understandable speech, smooth motion, and low interaction delay.

Data Channels

WebRTC can carry more than audio and video. Data channels let peers exchange arbitrary application data through SCTP over DTLS. A data channel can be reliable like TCP, unreliable like UDP, ordered, unordered, or tuned somewhere between. This makes it useful for multiplayer game state, collaborative cursors, whiteboard strokes, low-latency file transfer, device control messages, and companion data during a call.

Data channels are especially powerful because they can use the same peer connection machinery as media. The same ICE, STUN, TURN, and encryption stack finds the route and protects the traffic. For browser applications that need low-latency bidirectional messages without routing every byte through a central app server, WebRTC data channels are a serious alternative to WebSocket.

WebRTC Architecture: Peer-to-Peer, SFU, and MCU

A one-to-one call often uses a direct peer-to-peer path. Group calls are more complicated. If every participant sends video directly to every other participant, bandwidth and CPU requirements grow quickly. Most modern conferencing platforms use an SFU, or Selective Forwarding Unit. Each participant sends one or a few encoded streams to the SFU, and the SFU forwards the right streams to other participants without fully decoding and re-encoding everything.

An MCU, or Multipoint Control Unit, takes a heavier approach: it receives streams, decodes them, mixes or composites them, and sends a single combined stream back. This can simplify client devices but costs more server CPU and may reduce quality. SFU designs are now common because they preserve quality and scale better for interactive meetings.

Network Quality and WebRTC Performance

WebRTC quality depends more on latency, jitter, and packet loss than raw bandwidth. A 1080p video call may need only a few Mbps, but it needs those packets to arrive predictably. High jitter causes uneven arrival times, which forces the receiver to buffer more audio and video. Packet loss can create robotic audio, frozen video, or sudden resolution drops. Bufferbloat can make calls feel delayed whenever someone else on the network uploads a file or starts a cloud backup.

For better calls, use Ethernet where possible, stay close to the router on Wi-Fi, avoid congested 2.4 GHz channels, and keep upload usage under control. On busy home networks, router features such as SQM or carefully configured QoS can help by preventing large uploads and downloads from filling queues and delaying real-time packets.

Privacy and IP Address Exposure

WebRTC has a privacy wrinkle: ICE candidate gathering is designed to discover possible network paths, and those candidates can include local, public, and relay-related addresses. That behavior helps calls connect, but it also created the class of issues known as WebRTC IP leaks, especially for VPN users. Modern browsers have mitigations such as mDNS host candidates, and many VPN clients include WebRTC leak protection, but the underlying tradeoff remains: WebRTC needs network path information to work well.

Applications should request camera and microphone access only when necessary, use secure signaling, avoid exposing unnecessary candidate details to untrusted scripts, and provide clear device controls. Users should keep browsers updated and verify VPN leak protection when privacy is a priority.

Frequently Asked Questions

What is WebRTC used for?

WebRTC is used for browser-based video calls, voice calls, screen sharing, live interviews, remote support, online classrooms, multiplayer games, low-latency file transfer, and real-time data channels between browsers or apps.

Is WebRTC peer to peer?

WebRTC prefers a direct peer-to-peer media path when NAT and firewall conditions allow it. If a direct path cannot be established, the call can relay through a TURN server. Large conferencing systems may also route media through an SFU to support group calls efficiently.

Does WebRTC need a server?

Yes, but not always for the media itself. WebRTC needs signaling so peers can exchange session descriptions and network candidates. It usually also needs STUN servers for NAT discovery and TURN servers as a fallback relay. The actual audio, video, or data may flow directly peer to peer when possible.

Is WebRTC encrypted?

Yes. WebRTC media is encrypted by default using SRTP, with keys negotiated through DTLS. WebRTC data channels use SCTP over DTLS. Applications still need secure signaling, usually over HTTPS or WSS, so that attackers cannot tamper with session negotiation.

Why does WebRTC sometimes reveal IP addresses?

WebRTC's ICE negotiation gathers local, public, and relay candidates so it can find a working path between peers. In some configurations, that candidate gathering can expose local or public IP details to a website. Browser privacy controls, mDNS host candidates, VPN leak protection, and careful app design reduce this risk.