Real-time & Media

Real-time features — chat, live dashboards, collaborative editing, notifications, trading UIs — run on WebSockets. Every serious app eventually needs them.

The go-to protocol for server-push without WebSocket complexity. Used for AI/LLM streaming responses, live notifications, and real-time dashboards over plain HTTP.

Video calls (Meet, Zoom web), voice calls, peer-to-peer file transfer, and collaborative tools. The browser API surface for real-time A/V communication.

NAT traversal is why WebRTC calls fail. ICE is how browsers find a working path between peers. Know it when debugging call connectivity failures.

STUN is how WebRTC discovers the public-facing address for peer-to-peer connections. Every WebRTC deployment needs a STUN server.

~15-20% of WebRTC calls require TURN relay because both peers are behind symmetric NAT. Without TURN, those calls fail silently.

For gaming, live collaboration, and real-time data where WebSocket's TCP head-of-line blocking matters. Runs over QUIC so multiple streams don't block each other.

WebRTC media is always encrypted. DTLS-SRTP is the protocol that does it. Know it when troubleshooting media security negotiation or DTLS handshake failures.

Video players (YouTube, Netflix, Twitch) use MSE for adaptive streaming. Required if you build a custom media player or do in-browser video processing.

Required for any platform that distributes premium or licensed video content (streaming services, pay-per-view, licensed media).