WebRTC: How Interactive Live Video Works

Updated 10 November 2026 · Standard formula, shown below

WebRTC is a set of web technologies for real-time communication, including interactive audio, video, and data exchange between browsers and compatible applications. It lets a page request camera or microphone access, establish a connection, and send live media with low delay; this guide explains what happens behind the scenes and where WebRTC is useful.

What WebRTC means

WebRTC stands for Web Real-Time Communication. It is a standard name, not slang or an informal expression. The term describes a suite of browser APIs and communication protocols rather than one codec, app, or standalone video service. In a sentence: “The support team uses WebRTC for a live video call in the browser.”

The technology grew out of work to bring real-time communication into the web platform without requiring a separate plug-in. Google acquired the company Global IP Solutions in 2010 and contributed technology that helped start the open-source WebRTC project. The World Wide Web Consortium (W3C) develops the JavaScript API specifications, while the Internet Engineering Task Force (IETF) standardizes associated protocols. WebRTC is supported by mainstream browsers, though feature details and policies can vary.

“Interactive live video” is a useful description, but WebRTC is not limited to video. It can carry microphone audio, camera video, screen content, and arbitrary application data. Nor does the name guarantee a direct connection between two devices: network conditions often require intermediary servers.

How a WebRTC session works

A web page uses JavaScript APIs to obtain media and create a peer connection. The participants then exchange setup information through a separate signaling channel. Signaling is not prescribed as one WebRTC protocol; an application might use a web server and WebSocket, for example.

Request media. The page can call getUserMedia() to ask for camera or microphone access, or use getDisplayMedia() for screen sharing where supported. The browser prompts the user and enforces permission rules.
Prepare the connection. The application creates an RTCPeerConnection, adds media tracks or configures data channels, and negotiates compatible formats and connection parameters.
Exchange setup details. The peers send session descriptions and network candidates through the application’s signaling service. These messages help them agree on media settings and discover possible routes.
Find a viable network path. ICE (Interactive Connectivity Establishment) tests candidate routes. STUN can help a device learn its public-facing network address; TURN relays traffic when a direct route cannot be established.
Send and receive. Once connected, media is generally transported using encrypted RTP (SRTP). The receiving browser decodes and plays the streams, adapting to changing network conditions.

This negotiation is why a call can take a moment to connect even when the video itself is low-latency. The signaling service helps participants meet and exchange connection information; it does not necessarily carry the live media.

Why WebRTC is used for interactive video

WebRTC is suited to conversations and other two-way experiences where a delay of several seconds would feel disruptive. Common examples include browser-based meetings, remote support, telehealth communication, live tutoring, multiplayer voice chat, and video calling embedded in a service website. It can also support one-to-many broadcasts, though large audiences often call for a media server or a different distribution approach.

Low-latency interaction: participants can talk over one another naturally, unlike many conventional streaming workflows designed to buffer and deliver video steadily.
Browser integration: users can often join without installing a dedicated plug-in. A site still needs to provide a compatible interface and request the right permissions.
Flexible media: applications can combine audio, video, screen sharing, and data messages such as chat or control signals.
Network adaptation: WebRTC implementations can respond to changing bandwidth and packet loss, although adaptation cannot eliminate the effects of a poor connection.

Direct connections, servers, and scale

“Peer-to-peer” is often associated with WebRTC, but it does not mean every call sends media directly between users. A direct path may work when network routing and firewalls permit it. If it does not, TURN can relay the encrypted traffic. Relaying makes connectivity more reliable but consumes server bandwidth and can add network distance.

For group calls, applications commonly use a Selective Forwarding Unit (SFU), which receives streams and forwards selected streams to participants. This can be more practical than having every participant send separate media to every other participant. A Multipoint Control Unit (MCU) instead combines media streams in some systems. WebRTC defines the browser communication building blocks, not a universal group-call architecture; the service provider chooses how to handle signaling, relaying, recording, and scale.

Permissions, privacy, and common problems

Camera, microphone, and screen capture are sensitive capabilities. Browsers require user permission, and access is generally restricted to secure contexts such as HTTPS, with localhost treated as a development exception. Users should grant access only to sites they trust, check which device is selected, and stop sharing when finished. A web page cannot silently bypass the browser’s permission controls.

If a call fails, the cause may be outside the media code. Check that the browser has permission, the intended camera or microphone is selected, and no other application is monopolizing the device. Then try a supported, up-to-date browser and a network that allows real-time traffic. Corporate firewalls, VPNs, restrictive Wi-Fi, missing TURN capacity, or blocked UDP traffic can prevent a usable route; an administrator or service operator may need to investigate.

Other symptoms have different causes. One-way audio can point to device selection, muted tracks, or a connection problem. Frozen or blurry video can result from limited bandwidth, CPU load, packet loss, or the sender’s camera. A successful connection does not prove that the remote person is who they claim to be: WebRTC encrypts media in transit, but identity verification and account security depend on the application.

WebRTC compared with other ways to deliver video

WebRTC is a strong fit when viewers need to respond immediately, but it is not automatically the best choice for every video. Traditional HTTP streaming formats such as HLS or MPEG-DASH are commonly used to distribute a live or recorded stream to large audiences. They can use ordinary web delivery infrastructure and tolerate more buffering, but often have higher latency than an interactive call.

In practice, the distinction is about the job: use a real-time communication design for conversation, remote control, or audience participation; consider segmented streaming for a large one-way broadcast where a modest delay is acceptable. Hybrid services may use WebRTC for speakers or interactive viewers and a streaming format for the wider audience. The right approach depends on audience size, latency needs, device support, network conditions, and operating costs.

Frequently Asked Questions

Is WebRTC free?
WebRTC is an open web technology, and browser APIs do not carry a per-call license fee. Building and operating a service can still require signaling servers, TURN relays, media infrastructure, development, and bandwidth.

Does WebRTC require an app?
Not necessarily. Compatible browsers can provide WebRTC features to a website, but users need a supported browser and the site must implement the call interface. Some services also offer native apps.

Does WebRTC work without the internet?
It can communicate over a local network if the application can exchange signaling information and the devices can reach one another. Calls across separate networks generally need internet connectivity or another routed network.

Is WebRTC encrypted?
WebRTC media transport uses encryption, commonly SRTP, and data channels use secure transport. Encryption protects traffic in transit, but it does not by itself verify a participant’s identity or prevent an application from handling media at a relay or recording endpoint.

Why does a WebRTC call need TURN?
Some routers, firewalls, or network configurations prevent a direct connection. A TURN server relays traffic to help the call connect when available direct routes fail; the relay operator must provide enough capacity.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.