Web Fundamentals

WebRTC: Real-Time Communication in the Browser

hardWeb Fundamentals

WebRTC: Real-Time Communication in the Browser

Learn the interview-ready mental model, practical trade-offs, and production patterns for this web fundamentals topic.

Topic content

TL;DRWebRTC enables direct peer-to-peer audio, video, and data. Requires signaling for discovery, STUN/TURN for NAT traversal, and careful connection management.
Very High Signal
Google
Meta
Netflix
Agoda
Apple
30-Second Answerstart every interview with this

WebRTC allows browsers to establish direct peer-to-peer connections for audio, video, and arbitrary data without plugins. It consists of media capture, signaling (offer/answer + ICE candidates), and RTCPeerConnection. Understanding STUN/TURN, reconnection, and scaling is essential for production use.

The two phones need to find each other (signaling), discover how to connect through networks/firewalls (STUN/TURN), and then talk directly (peer connection). The signaling server is like a mutual friend who introduces them but doesn’t stay on the call.

Media Capture (getUserMedia)
Signaling (Offer/Answer + ICE)
STUN/TURN NAT Traversal
Peer Connection Established
Media + Data Channels Flow

1WebRTC Core Architecture

RTCPeerConnection manages the connection. Media streams come from getUserMedia() or getDisplayMedia(). Signaling (not part of the spec) exchanges SDP offers/answers and ICE candidates.

2Signaling: Offer/Answer & ICE Exchange

Peers exchange connection metadata via a signaling server (WebSocket/HTTP). ICE candidates handle network traversal.

3Media Streams & Device Control

Capture camera/mic with constraints. Add tracks to peer connection. Handle track events, muting, and device switching.

4Data Channels

Bidirectional peer-to-peer data transfer for chat, file sharing, or game state. Supports reliable and unreliable modes.

5STUN, TURN & NAT Traversal

STUN discovers public IPs. TURN relays when direct connection fails. Production apps need both.

Key Takeaways
  • WebRTC = peer-to-peer media + data in the browser
  • Signaling is required but not part of the spec
  • STUN for discovery, TURN for relay fallback
  • Always clean up tracks and close connections
  • Implement robust reconnection logic
  • Use data channels for file sharing and custom data
  • For large meetings, combine with SFU architecture