WHIP and WHEP explained: sub-second live video over plain HTTP

WebRTC has delivered sub-second video in browsers for over a decade, yet for most of that time every streaming server invented its own way to set a call up. WHIP and WHEP replace all of that with one HTTP request each way.

The problem: WebRTC never defined signalling

WebRTC specifies how media flows (ICE to find a path, DTLS to agree keys, SRTP to carry audio and video) but deliberately leaves out signalling: how the two sides swap their session descriptions (SDP) in the first place. Video calling apps use a WebSocket protocol of their own, which is fine when you write both ends.

Broadcast is different. An encoder from one vendor must talk to a server from another, and a player must talk to whatever CDN carries the stream. Without a standard handshake, hardware encoders and OBS stuck with RTMP, and WebRTC stayed a browser-only curiosity for live production.

WHIP: ingest in one POST

The WebRTC-HTTP Ingestion Protocol (published by the IETF as RFC 9725) reduces signalling to a resource you create and delete:

1. The client builds an SDP offer listing its codecs and ICE credentials, and POSTs it with Content-Type: application/sdp. A bearer token in the Authorization header says who may publish.
2. The server answers 201 Created with its SDP answer in the body and a Location header naming the session it just made.
3. ICE and DTLS run as in any WebRTC call, then media flows as SRTP over UDP.
4. The client ends the session with DELETE on that location.

That is the entire protocol. Optional extras exist, such as PATCH with trickle-ICE fragments to add candidates late and ICE restarts, but a working publisher needs only the two requests above.

WHEP: the same idea for playback

The WebRTC-HTTP Egress Protocol (an IETF working-group draft at the time of writing) mirrors WHIP for viewers: a player POSTs an offer that only receives, the server answers, and media flows the other way. A player needs no SDK, just RTCPeerConnection and fetch:

const pc = new RTCPeerConnection();
pc.addTransceiver('video', { direction: 'recvonly' });
pc.addTransceiver('audio', { direction: 'recvonly' });
pc.ontrack = (e) => (video.srcObject = e.streams[0]);

await pc.setLocalDescription(await pc.createOffer());
const res = await fetch(whepUrl, {
  method: 'POST',
  headers: { 'Content-Type': 'application/sdp' },
  body: pc.localDescription.sdp,
});
await pc.setRemoteDescription({ type: 'answer', sdp: await res.text() });

Why it matters: latency

Segment-based delivery (HLS, DASH) waits for whole chunks of video to be written, listed and fetched before a player shows them. WebRTC sends each frame as soon as it is encoded. The difference is an order of magnitude:

Sub-second delay is what makes interaction work: auctions, sport with live betting, a teacher answering a question, a guest joining a show, a camera operator steering by the picture.

What it costs

• UDP and ports. Media wants a UDP port open to viewers. Behind strict firewalls you need TCP fallback or a TURN relay.
• Stateful fan-out. Every viewer is a live, encrypted session on the server, not a cached file. A CDN cannot absorb it, so very large audiences usually get HLS while the interactive few get WebRTC.
• Codecs. Browsers send Opus audio; much of the broadcast world expects AAC. Something has to convert when a browser stream goes on to HLS or RTMP platforms.

Who speaks it today

OBS Studio publishes over WHIP since version 30. FFmpeg gained a whip muxer in its 8.x releases. Every modern browser can do both directions with the few lines of code above. On the server side, WHIP and WHEP are fast becoming the expected way in and out of any low-latency platform.