WHIP vs WHEP: Ingest, Playback & Standards Status | Callaba

WHIP sends WebRTC media into a service; WHEP delivers WebRTC media from a service to a viewer. They use HTTP resources to simplify WebRTC signaling, but they are not mirror-image URLs and they do not replace ICE, DTLS-SRTP, RTP/RTCP, codec negotiation or session authorization. Their current standards status also differs.

Direction changes the client and server roles

WHIP is the standardized ingest path

RFC 9725, published in March 2025, defines the WebRTC-HTTP Ingestion Protocol. A WHIP client is the encoder or producer. It sends an initial SDP offer in an HTTPS POST with content type application/sdp; the endpoint returns 201 Created, an SDP answer and a Location header identifying the new session resource.

After ICE and DTLS setup, media flows from the producer to the media server. The client uses the session URL for supported ICE operations and sends DELETE to terminate it. WHIP does not support SDP renegotiation that changes media sections after the initial exchange. Design contribution switching, track changes and restarts around that constraint instead of assuming a permanent call-like signaling channel.

WHEP is the evolving playback counterpart

The current WHEP working-group draft describes HTTP-based WebRTC playback from a media server to a viewer. As an Internet-Draft, it is a working document rather than a published standard. Pin the supported draft version in integration tests and recheck the IETF status before claiming interoperability.

In draft -04, the WHEP player sends an SDP offer to the endpoint. The server can accept it with 201 Created and an SDP answer, or return 406 Not Acceptable with a counter-offer that the player answers using PATCH on the session resource. Older prototypes and descriptions may follow a different exchange, so a product label alone does not prove compatibility with -04.

Compare the contracts, not just the acronyms

Endpoint URLs and session URLs have different lifetimes

The configured endpoint creates sessions; the returned Location identifies one allocated session. Store the session URL only for that session and do not construct it from assumptions. Follow allowed redirects and origin rules exactly as the selected specification defines, while refusing an unexpected downgrade from HTTPS.

Record endpoint response code, response content type, Location, session age and termination result without logging bearer tokens or SDP credentials. A leaked session URL may enable unwanted control operations, so treat it as sensitive operational data.

Bearer tokens authorize HTTP, not media quality

WHIP clients must implement bearer-token authentication support, although an endpoint may choose whether to require it. Token syntax and issuance remain application responsibilities. WHEP draft -04 also defines bearer-token behavior. Issue short-lived, audience-bound credentials through a trusted backend and prevent a viewer token from creating ingest sessions or selecting unrelated streams.

Authentication success proves only that the HTTP action was allowed. Continue through ICE state, selected candidate pair, DTLS state, inbound or outbound RTP bytes, frame counters and the rendered result.

Codec and simulcast policy still need negotiation

Neither acronym means that any WebRTC codec will work. Capture the complete SDP offer and answer with secrets redacted. Compare codecs, profiles, payload types, audio channels, RTP header extensions, feedback, simulcast layers and media directions. If the event requires video, an audio-only ingest is not a partial success.

Define what the service does with simulcast or scalable layers: preserve, select, transcode or reject them. Load-test the chosen combination because media-server cost and viewer capacity depend on that decision.

Test direct and relayed ICE paths

A lab on one LAN does not exercise production NAT and firewall behavior. Test host, server-reflexive and TURN-relayed candidate paths from representative networks. Record selected pair type, round-trip time, packet loss, bytes, first-frame time and recovery after a brief network change.

Separate HTTP availability from ICE availability. A reachable endpoint can return a valid SDP answer while every candidate path fails. Conversely, a media path can continue briefly while a control request fails; define cleanup and resource expiry for both graceful DELETE and abandoned sessions.

Build an interoperability acceptance matrix

1. Pin status and version. Record RFC 9725 for WHIP and the exact WHEP draft implemented.
2. Validate HTTP. Test content types, response codes, Location handling, redirects and DELETE.
3. Validate authorization. Accept the intended token and deny expired, wrong-audience and cross-stream tokens.
4. Validate SDP. Exercise codecs, media directions, rejected tracks and WHEP counter-offers.
5. Validate media. Prove ICE, DTLS, RTP, first frame, audio and sustained counters.
6. Validate failure cleanup. Drop the client without DELETE and confirm session resources expire.