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
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.
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.
- ✓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