WHEP standardises subscribing to a WebRTC stream the way WHIP standardises publishing. The player POSTs an SDP offer (or in some implementations, receives an offer to answer) to a known URL; the server responds with the SDP needed to complete the PeerConnection and a session URL for ICE candidate exchange and teardown. Once negotiation completes, media flows over WebRTC and the latency drops to the WebRTC norm of 200 ms to 1 s.
The point of WHEP is interoperability. Before WHEP each WebRTC egress vendor had its own signalling protocol — vendor-specific SDKs were required to play a stream. With WHEP, any compliant player can pull from any compliant server. By 2026 implementations exist in OvenPlayer, Cloudflare Stream's player, Mux, LiveKit's client, and several open-source players including a WHEP plugin for Video.js.
WHEP and WHIP are usually deployed together: a publisher pushes via WHIP, the server fans out via WHEP, and the round-trip from publisher screen to viewer screen stays under a second. This pair is the most direct successor to RTMP+HLS for live workflows where latency matters. Adoption through 2026 is still concentrated in low-latency-first services (sports betting, auctions, classrooms, esports); mainstream OTT continues to use LL-HLS/DASH because the 2–4 s window is acceptable and the CDN economics are better.
