WHIP and WHEP Explained for CTOs: Standard Ingest and Egress for WebRTC

By Stan Reshetnyk, CTO, Trembit · Last updated 21 October 2026

WHIP and WHEP are two small HTTP-based signalling protocols for live WebRTC video. WHIP (WebRTC-HTTP Ingestion Protocol) lets an encoder publish a stream to a media server by sending its SDP offer in one HTTP POST. WHEP (WebRTC-HTTP Egress Protocol) lets a player pull a stream the same way. WHIP is a published IETF standard, RFC 9725 (March 2025). As of 15 October 2026, WHEP is still an Internet-Draft. Together they standardize the handshake WebRTC deliberately left open, so encoders, servers and players from different vendors can work together.

In plain terms: these standards lower the cost of switching encoders, players and media servers, because setting up a stream no longer ties you to one vendor’s SDK. They don’t touch where most of a live-video budget goes: scaling, recording, relay (TURN) servers and access tokens. Plan for that work whichever vendor you choose.

Short on time? Jump to Should you adopt WHIP and WHEP now? or What has Trembit built?

Key takeaways

• WHIP is a finished IETF standard (RFC 9725). WHEP, its playback counterpart, is still a draft, and products implement different versions of it.
• They standardize only how a stream connection is set up. The video still travels over WebRTC, so latency stays WebRTC-class.
• Both carry video one way. They don’t replace the signalling inside a video call.
• Support is real but uneven. Check each vendor separately for publishing and for playback, and for WHEP, the draft version.
• WHIP standardizes load balancing through HTTP redirects. Routing between regions and servers is still up to you.

What problem do WHIP and WHEP solve?

WebRTC defines how media is encrypted, how peers traverse NATs and how codecs are negotiated, but not how the two sides exchange that negotiation. The WebRTC overview, RFC 8825 §3, puts client-server signalling choices among the things that “are outside the scope of the WebRTC protocol suite described in this document”. RFC 9725 opens on the same point: “WebRTC intentionally does not specify a signaling transport protocol at the application level.”

That works when one company controls both ends. In broadcasting, encoder and server usually come from different vendors, and RFC 9725 §1 says the lack of a standardized signalling mechanism “has been an obstacle” to WebRTC’s adoption in broadcasting and streaming. So each platform published its own SDK, and RTMP stayed the default ingest, with conversion to WebRTC on the server. WHIP and WHEP replace that per-vendor signalling with one HTTP pattern.

The RFC’s authors are Sergio Garcia Murillo (Millicast) and Alexandre Gouaillard (CoSMo Software).

How does a WHIP session work, step by step?

The WHIP protocol is a single SDP offer/answer exchange over HTTP, followed by optional ICE updates. RFC 9725 §3 is explicit that “SDP renegotiations are not supported in WHIP”. After setup, only ICE information can change.

An abbreviated exchange looks like this. It is illustrative, written for this article, with SDP bodies cut short:

POST /whip/live/stream-1 HTTP/1.1
Host: ingest.example.com
Authorization: Bearer eyJhbGciOi...
Content-Type: application/sdp

v=0  ...SDP offer...

HTTP/1.1 201 Created
Content-Type: application/sdp
Location: https://ingest.example.com/whip/session/9f3c1a7e
ETag: "a1b2c3"
Link: <stun:stun.example.net>; rel="ice-server"

v=0  ...SDP answer...

One security detail matters in architecture reviews. The session URL can patch or delete a live stream, so RFC 9725 §5 says endpoints “SHOULD generate URLs with enough randomness, using a cryptographically secure pseudorandom number generator”. Guessable session IDs are a real finding.

How is WHEP different, and how close is it to a standard?

WHEP mirrors WHIP for playback, with the same POST/PATCH/DELETE shape, Link headers for STUN/TURN (§4.8) and bearer tokens (§4.9.1). The difference is who makes the offer. Draft-05 §3 states: “The WHEP player always initiates the streaming session by sending an SDP offer to the WHEP endpoint.” If the server can’t accept that offer, it returns 406 Not Acceptable with an SDP counter-offer, and the player answers in an HTTP PATCH (§4.3.2).

Earlier drafts did this differently, and that is the interoperability trap. In draft-murillo-whep-01 (October 2022) §4.2, a player could send a POST with no body; the server returned its own offer in the 201, and the player answered by PATCH. Draft-05 has no empty-POST mode. Cloudflare Stream’s documentation (last updated 15 October 2026) names draft-murillo-whep-01 as its WHEP version and lists “Server and client offer modes”. Two products can both “support WHEP” while implementing different flows, so test the exact player/server pair you plan to ship.

Servers advertise extensions in Link headers, and players ignore unknown ones (§4.10). Draft-05 never mentions simulcast or SVC: in playback, choosing a viewer’s quality layer is a server-side forwarding decision, left to the server or extensions.

Status as of 21 October 2026. The IETF datatracker lists draft-ietf-wish-whep-05 (dated 12 October 2026). The working group has submitted it to the IESG for publication. It is in “AD Evaluation”, the Area Director review step before wider IESG review, and since 15 October the Area Director has asked for a revised draft, so a -06 may follow. It is intended as a Proposed Standard. It has no RFC number yet.

What can’t WHIP and WHEP do?

Two-way calls. The WISH working group charter scopes the work to “one-way WebRTC-based audiovisual sessions between broadcasting tools and real-time media broadcast networks”. It also says support for bidirectional uses such as video conferencing “is not in scope for the WISH working group”. In a meeting app they won’t carry signalling for interactive participants. They can still serve one-way legs around a meeting, such as a view-only audience or a broadcast out of the room.

More than one stream per session, or changes mid-session. WHIP “only supports a single MediaStream” (§4.4.2), and so does WHEP (draft-05 §4.6.2). Neither allows SDP renegotiation (RFC 9725 §3; draft-05 §3 and §4.5.3). A second camera or a screen share means a new session.

Guaranteed simulcast or SVC. RFC 9725 §4.8 says simulcast “MAY be supported”, and that there is “no universal negotiation mechanism in SDP for SVC”. Ask vendors directly.

Most of what happens around the handshake. Neither standard covers token issuance and rotation, TURN provisioning, recording, HLS/DASH transcoding, cross-region routing, server-to-server cascading or viewer analytics. Edge load balancing is the exception, through the redirect and 503 rules in §4.5.

So “supports WHIP” can describe very different pipelines. Cloudflare Stream’s page (last updated 15 October 2026) says WHIP and WHEP “must be used together”: WHIP inputs can’t be recorded or played over HLS/DASH, and RTMP or SRT inputs can’t be played over WHEP. That is one product’s architecture, not a flaw in the standard.

Who supports WHIP and WHEP today?

This is a verified subset, not a market survey: a row appears only where the project’s own documentation confirms support, so a missing name (MediaMTX, SRS, Ant Media, Wowza and others) is unchecked, not judged. Fetched 14 October 2026 (Cloudflare 15 October); alphabetical, no ranking. Red5 is a Trembit partner; it is listed on the same footing as every other vendor.

“Not listed” means the source doesn’t mention it. We have not compared WHIP draft-06 with RFC 9725; if a vendor cites a pre-RFC draft, ask whether it tracks the RFC. For choosing a streaming partner, see our guide to evaluating live streaming development companies.

Where do WHIP and WHEP fit next to RTMP, SRT, HLS and MoQ?

What WHIP trades away compared with RTMP and SRT:

• Codecs. WHIP carries WebRTC codecs. FFmpeg’s own whip muxer docs say: “Ensure that you use H.264 without B frames and Opus for the audio codec.” Encoder presets built on AAC audio or B-frames need changing.
• Behaviour under loss. WebRTC is designed around low latency, so it adapts bitrate and tolerates loss rather than waiting for retransmissions. RTMP (over TCP) and SRT (with retransmission) put complete delivery first, at the cost of delay.
• Rule of thumb. Use WHIP when you need sub-second, browser-compatible ingest. Use SRT or RTMP when you need broadcast codecs or quality-first contribution.

Two delivery patterns cover most products. WHIP in, HLS out suits broadcast-scale audiences who can accept some seconds of delay. WHIP in, WHEP out suits interactive audiences (auctions, live shopping, trading rooms). Latency tiers are covered in when WebRTC latency is mandatory and when it’s overkill.

Media over QUIC (MoQ) is a different layer: a separate transport, not WebRTC signalling. See our MoQ vs WebRTC comparison.

The parts around the handshake (adaptive bitrate delivery, protocol bridging, broadcast integration) are what our live streaming team builds.

Should you adopt WHIP and WHEP now, and should you build or buy?

• Adopt WHIP now if you control the encoders (OBS, FFmpeg, GStreamer) or want to stop shipping a vendor ingest SDK to broadcasters, and your codecs fit WebRTC. The spec is final and those encoders support it.
• Adopt WHEP after checking the revision. Confirm which draft and offer mode your server and player each implement, and test that exact pair.
• Keep RTMP or SRT ingest during migration, so existing broadcasters keep working.
• Ask every vendor: Which directions? Which WHEP revision, and does WHIP track RFC 9725? Trickle ICE and ICE restart? TURN credentials in Link headers? Can a WHIP input be recorded or repackaged to HLS? Simulcast?

Either way, you still own token issuance and expiry, TURN capacity and its cost, recording, ABR transcoding if you also serve HLS, scale-out and monitoring.

Buy means a managed service from the table: fastest start, vendor-set limits. Build means your own media server with a WHIP/WHEP front end, through custom WebRTC development; see our LiveKit vs mediasoup comparison and our guide to SFU, MCU and P2P architectures. WHIP and WHEP reduce the coupling between that server and your encoders and players. They don’t remove the rest of the switching cost.

What has Trembit built in production ingest?

To be clear about the limits first: we have not yet delivered a WHIP or WHEP integration for a client, so this article rests on the specs and vendor documentation, not a field report. What we have built is work around the handshake:

• Live commerce streaming with adaptive bitrate. For Livebazaar, a live video shopping platform, we deployed Wowza Streaming Engine with adaptive bitrate for variable network conditions. A WHIP ingest could sit in front of a pipeline like this. It would not replace the adaptive bitrate layer.
• Protocol bridges into WebRTC. For a US government agency’s video conferencing platform, we built an RTSP-to-WebRTC bridge on Janus that brings live IP-camera feeds into conference sessions. Earlier, we wrote up converting an RTMP drone feed to WebRTC. That post is from 2022, so treat it as an example, not current guidance.
• Sub-second broadcast. For Bullpit, a streaming platform for trading communities, we integrated Millicast as the WebRTC broadcast layer, delivering sub-second video to thousands of concurrent viewers.

None of this work was the signalling handshake. It was adaptive bitrate delivery, protocol bridging and broadcast-layer integration, the part WHIP and WHEP leave to you.

FAQ

Is WHIP an official standard? Yes. WHIP is RFC 9725, a Standards Track (Proposed Standard) IETF document published in March 2025. It updates RFC 8840 and RFC 8842.

Is WHEP a standard yet? Not yet. As of 21 October 2026, WHEP is draft-ietf-wish-whep-05, in Area Director evaluation at the IESG with a revised draft requested, intended as a Proposed Standard. Products implement different draft revisions, so check each component.

Does WHIP replace RTMP? It gives encoders a WebRTC-native ingest option, and OBS Studio has shipped WHIP output since 30.0 (November 2023). RTMP’s installed base and codec flexibility mean most teams will run both for a while.

Does WHIP support simulcast? It can: RFC 9725 allows simulcast but does not require it. Confirm support with each encoder and server.

Do I need WHIP/WHEP if I already use my media-server vendor’s SDK? Not for your own interactive clients. WHIP matters when broadcasters bring their own tools, or when you want to change servers later without rewriting every client.

Pressure-test your ingest path

If you are weighing WHIP against RTMP or SRT, checking whether a WHEP player and server will actually connect, or deciding between managed ingest and your own server, book a free 30-minute call with our WebRTC consulting team. Bring your current ingest path (encoders, protocols, latency target) and the decision you’re stuck on, or bring your CTO and the vendor quote you’re comparing. We’ll pressure-test it with you. No deck, no pitch.