What is WebRTC?
WebRTC (Web Real-Time Communications) is a browser standard for peer-to-peer audio, video, and data. It was built for video calls — Google Meet, Zoom web, Discord voice — but the same stack powers sub-second one-to-many live streaming.
Where LLHLS pushes live latency down to 2–4 seconds, WebRTC can deliver sub-second glass-to-glass. The trade-off is complexity, cache un-friendliness, and scaling characteristics that are very different from HTTP.
How WebRTC differs from HTTP streaming
| | HLS / LLHLS | WebRTC | | --- | --- | --- | | Transport | TCP (HTTP/1.1 or HTTP/2) | UDP (via ICE) | | Latency | 2–30 seconds | Sub-second (under 1s) | | CDN-cacheable | Yes | No — direct peer or SFU | | Scale model | HTTP cache hierarchy | Media server replication | | Encryption | TLS | DTLS + SRTP (mandatory) | | NAT traversal | Not needed (HTTPS) | Required (STUN + TURN) | | Manifest | M3U8 / MPD | Signalled SDP, no manifest |
A WebRTC session involves an ICE handshake (peers exchange candidate IP:port pairs, try direct connection, fall back to a TURN relay if needed) and a DTLS handshake for encryption. Signalling typically runs over WebSocket or HTTP.
Because media flows over UDP, packet loss is handled by retransmission hints (NACK), forward error correction (FEC), and just skipping late packets — never by blocking the stream.
When WebRTC is worth it
- Auctions. Bidders need to see the auctioneer's lot call instantly.
- Interactive co-watching. Two-way conversation + shared video.
- Real-time sports betting. Odds and the event need to line up.
- Game streaming. Cloud gaming, remote desktop.
Anything where you couldn't hold a conversation at the observed latency is where WebRTC wins. Anywhere else, LLHLS is cheaper to scale.
Why WebRTC doesn't replace HLS
- No CDN caching. Every viewer maintains a direct session to a media server. Scaling to millions requires a mesh of SFUs (Selective Forwarding Units) with cross-origin replication.
- No trivial live recording. You record the incoming feed server-side; you can't just cache HTTP bytes.
- Firewall friction. Corporate networks sometimes block UDP. TURN-over-TLS exists but adds latency.
- Protocol churn. WebRTC is a big surface area (ICE, SDP, RTP/RTCP, DTLS, SCTP) with browser implementation quirks.
For one-to-many live at scale, the industry default is LLHLS. For interactive, WebRTC.
WHIP and WHEP
Two IETF standards (2023) that put a clean HTTP façade over WebRTC:
- WHIP (WebRTC-HTTP Ingestion Protocol) — encoders POST an SDP offer, get an answer, push RTP. Replaces RTMP for WebRTC ingest.
- WHEP (WebRTC-HTTP Egress Protocol) — viewers POST an SDP offer, get an answer, pull RTP. Replaces the bespoke signalling every WebRTC server used to invent.
WHIP/WHEP make WebRTC playback feel as simple as "hit a URL" — the complexity hides behind a single POST.
WebRTC on Hakari
Enable webrtc in your stream's playback protocols. The playback URL is the signalling endpoint:
https://stream.hakari.cloud/app/<streamKey>
Open it in the dashboard player (which handles WHEP signalling + DTLS + RTP for you) or integrate with OvenPlayer / Shaka Player's WebRTC support.
Browser support
Every modern browser — Chrome, Edge, Firefox, Safari 11+ — ships WebRTC natively. Mobile: iOS Safari 11+, Android Chrome, React Native via libraries.
Scaling note
WebRTC viewers maintain a live session — they're not pulling from a cache. High-concurrency WebRTC sessions need a scale-out media server tier, which is on our enterprise plans. For viewer counts in the thousands+ on a public-facing live stream, LLHLS is the right default; use WebRTC for the interactive subset.
Signed playback + WebRTC
WebRTC signalling on Hakari respects signed playback — the ?policy=&signature= query params apply to the signalling URL the same way they apply to HLS playlists. Unsigned signalling requests return 401 when enforcement is on.