What Is WebRTC? Real-Time Audio, Video, and Data

WebRTC (Web Real-Time Communication) is an open standard — built into every modern browser — that enables peer-to-peer audio, video, and arbitrary data transfer between clients with no plugins required. It’s the technology behind video calls in Google Meet, screen sharing in browser-based tools, and live gaming data channels. The browser exposes three core APIs, and together they handle everything from capturing your camera to negotiating a direct connection across the internet.

The three core APIs

getUserMedia

getUserMedia is where every WebRTC session starts. It asks the user for permission to access the camera and microphone, then returns a MediaStream object containing the requested tracks.

const stream = await navigator.mediaDevices.getUserMedia({
  video: true,
  audio: true,
});
videoElement.srcObject = stream;

You can pass constraints to request a specific resolution, frame rate, or audio device. Once you have the stream, you feed its tracks into a peer connection.

RTCPeerConnection

RTCPeerConnection is the heart of WebRTC. It manages the actual media pipeline: codec negotiation, encryption, bandwidth adaptation, and the P2P connection itself. The two peers exchange an offer and an answer — both formatted as SDP (Session Description Protocol) blobs — to agree on codecs and network addresses.

const pc = new RTCPeerConnection({ iceServers: [{ urls: "stun:stun.l.google.com:19302" }] });

stream.getTracks().forEach(track => pc.addTrack(track, stream));

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
// send `offer` to the remote peer over your signaling channel

RTCDataChannel

RTCDataChannel runs alongside the media connection and carries arbitrary binary or text data. It behaves like a WebSocket but goes directly peer-to-peer, which makes it useful for gaming state, file transfer, or any low-latency side-channel alongside a video call.

const channel = pc.createDataChannel("chat");
channel.onmessage = (e) => console.log("received:", e.data);
channel.send("hello from peer A");

Signaling: the part WebRTC doesn’t do for you

WebRTC intentionally leaves signaling out of scope. Before two peers can connect, they need to exchange their SDP offer/answer and their ICE candidates — the candidate network addresses each peer will try. You have to build or use a signaling layer yourself. A WebSocket server is the most common choice: it relays the SDP and ICE candidates between peers without touching the media at all.

This is a frequent source of confusion: you need a server to set up a serverless connection. Once the peers have exchanged enough information and ICE succeeds, the media flows directly between them — the signaling server is no longer in the path. Understanding how a WebSocket works is useful here, as is knowing how APIs are structured if you build a REST-based signaling endpoint instead.

NAT traversal: ICE, STUN, and TURN

The “peer-to-peer” label needs a caveat. Most devices sit behind NAT routers and don’t have a public IP. ICE (Interactive Connectivity Establishment) is the framework WebRTC uses to discover a working network path between peers. It proceeds through three candidate types in order:

• Host candidates — the device’s own local IP (works only on the same LAN).
• Server-reflexive candidates — the public IP/port seen by a STUN server. STUN is a lightweight UDP service that reflects your apparent public address back to you. Free, low-cost.
• Relayed candidates — traffic routed through a TURN server when direct and STUN-assisted paths both fail. This is server-side relay, not P2P. TURN servers cost money to run and are the reliability backstop for symmetric NATs and restrictive firewalls.

In practice, 15–20% of WebRTC calls end up using TURN. Production deployments need a TURN server (or a hosted service like Twilio Network Traversal) to avoid calls that fail silently in corporate or mobile networks.

WebRTC vs. WebSocket

It helps to contrast the two directly:

	WebRTC	WebSocket
Topology	Peer-to-peer (with relay fallback)	Client–server
Media	Built-in audio/video codecs	No
Data channel	Yes (RTCDataChannel)	Yes
Connection setup	Complex (ICE, STUN/TURN, SDP)	Simple HTTP upgrade
Latency	Very low (UDP-based)	Low (TCP-based)
Use case	Video calls, P2P data	Chat, live feeds, APIs

A WebSocket connects a browser to a server over a persistent TCP channel. WebRTC connects two browsers (or a browser and a media server) directly. Server-Sent Events are a third option for simpler one-way server-push scenarios.

Security

WebRTC mandates encryption by spec. Media is encrypted with SRTP (Secure RTP), and data channels use DTLS. There’s no opt-out. Browsers also enforce that getUserMedia requires a secure context (HTTPS or localhost) — if your page is served over plain HTTP, the camera/mic APIs won’t work. DNS resolution and TLS on your signaling server are also part of a secure deployment. The JavaScript event loop governs when ICE callbacks and track events fire, which matters when debugging connection-timing issues.

The takeaway

WebRTC is a powerful but complex stack. The three APIs — getUserMedia, RTCPeerConnection, and RTCDataChannel — cover capture, connection, and data; signaling is your responsibility. “Peer-to-peer” is mostly true, but NAT traversal means you’ll need STUN servers and almost certainly TURN relay in production. For video calls or P2P data at low latency, WebRTC is the right tool; for simpler server-push or bidirectional client-server communication, reach for SSE or WebSockets instead.