WebRTC: Real-Time Communication in the Browser
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.
| Property | WebRTC (P2P) | SFU/MCU |
|---|---|---|
| Latency | Very Low | Low |
| Scaling | Limited (small groups) | Excellent (100+ users) |
| Best For | 1:1 or small group calls | Large meetings |
| Bandwidth | Efficient (direct) | Higher (server relay) |
WebRTC (P2P)
Latency
Very Low
Scaling
Limited (small groups)
Best For
1:1 or small group calls
Bandwidth
Efficient (direct)
SFU/MCU
Latency
Low
Scaling
Excellent (100+ users)
Best For
Large meetings
Bandwidth
Higher (server relay)
Common questions
- ›“Explain the WebRTC connection flow.”
- ›“What is the role of signaling in WebRTC?”
- ›“When do you need TURN servers?”
- ›“How do you handle reconnection in WebRTC?”
What interviewers look for
- End-to-end understanding of signaling + ICE + media flow
- Knowledge of STUN/TURN and NAT traversal
- Production awareness (reconnection, scaling, cleanup)
- Security and privacy considerations
Short answer (60 sec)
WebRTC enables direct peer-to-peer audio/video/data. Requires signaling for discovery, STUN for NAT traversal, and TURN as fallback. Use RTCPeerConnection, getUserMedia, and data channels.
Detailed answer (senior level)
The flow is: capture media → create offer/answer via signaling → exchange ICE candidates → establish RTCPeerConnection → add tracks and data channels. STUN helps discover public IPs; TURN relays when direct fails. Production requires reconnection logic, resource cleanup, and careful scaling strategy.
- Forgetting to set local/remote descriptions before sending
- Not handling ICE candidates properly
- No reconnection or connection state monitoring
- Leaking media tracks (not calling stop())
- Using WebRTC for large group calls without SFU
- ✓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
Related web fundamentals topics
Continue with closely related browser and frontend engineering concepts.