Why This Matters
Before WHIP, every WebRTC ingest deployment was a custom job. Each platform invented its own signalling protocol — Janus had one, mediasoup had another, LiveKit a third, Millicast a fourth, Twilio a fifth — and an encoder that worked with one vendor would not work with another without a vendor-specific SDK or plugin. WebRTC the media layer was an open standard, but WebRTC the contribution path was vendor-locked. That single problem kept the broadcast industry on RTMP for two decades.
WHIP fixes the problem with the smallest possible footprint: a single HTTP POST replaces a dozen custom signalling protocols. An encoder that speaks WHIP can push to any server that speaks WHIP, full stop. The same OBS instance you point at Cloudflare Stream today can point at AWS IVS tomorrow, at Dolby Millicast on Friday, and at a self-hosted Ant Media on Saturday, without changing anything except the URL and the Bearer token. That portability is the reason the protocol matters. This article is the canonical reference on WHIP for engineers, product people, and architects choosing a contribution stack in 2026: what RFC 9725 actually says (with section numbers), how the four HTTP verbs work, what trickle ICE and ICE restarts buy you, why the latency floor is what it is, where WHIP wins and loses against SRT and RTMPS, and which platforms and encoders accept it today.
What WHIP Is — In One Page
WHIP, the WebRTC-HTTP Ingestion Protocol, is a thin HTTP layer that wraps the WebRTC offer/answer signalling exchange. The protocol does only one thing: it gives an encoder a standardised way to publish a single WebRTC media session to a server, and to tear that session down when it is finished. Everything else — the media transport, the codecs, the encryption, the congestion control — is plain WebRTC, defined by the existing W3C and IETF specifications. The genius of WHIP is the size of the surface area. The full operational protocol is four HTTP verbs against two resource URLs.
The two URLs are the WHIP endpoint URL (where the encoder POSTs to begin a session) and the WHIP session URL (returned in the Location header of the 201 response, and used for everything that follows). The four verbs are POST (to begin a session), DELETE (to end one), PATCH (to update ICE state during the session), and OPTIONS (for CORS preflight and capability discovery). That is the whole protocol — the rest of RFC 9725 is precise definitions of what each request and response must contain.
Mechanically: the encoder generates an SDP offer for a single WebRTC PeerConnection (one bundled audio + video media stream, send-only direction, DTLS-SRTP encryption negotiated), serialises the offer to text, and sends it as the body of an HTTP POST request with Content-Type: application/sdp to the WHIP endpoint URL. The server validates the offer, gathers its own ICE candidates, generates an SDP answer with the full set of server candidates already in place, and returns the answer as application/sdp in a 201 Created response. The response carries two important headers: a Location header that points at the newly created WHIP session resource, and an ETag header that identifies the current ICE session state (used later to gate ICE restart requests). The client now has everything it needs to complete the ICE handshake; once ICE concludes and DTLS finishes its handshake, media starts flowing over SRTP.
To terminate the session cleanly, the encoder sends an HTTP DELETE to the session URL; the server returns 200 OK, tears down the ICE/DTLS state, and frees the media resources. If the encoder simply disappears, the server detects the loss via WebRTC's own keepalive and ICE-connectivity-check timers and tears the session down on its own.
The wire transport is whatever WebRTC uses — UDP with ICE candidates of host / server-reflexive / relayed type, DTLS for encryption, SRTP for media — which means WHIP inherits WebRTC's NAT traversal story (STUN/TURN, explored in detail in our NAT article) and WebRTC's congestion control (transport-wide congestion control, abbreviated TWCC, plus the receiver-side bandwidth estimator). The protocol is HTTP/1.1 or HTTP/2 — RFC 9725 does not mandate a version, and both are deployed in production.
Figure 1. The complete WHIP session, end to end. POST creates the session and returns the session URL plus an ETag; PATCH updates ICE state during the session; DELETE tears the session down. Media rides on standard WebRTC machinery underneath.
The Short Version of How WHIP Got Here
Before 2020, every WebRTC contribution path was a custom integration. WebRTC the standard, published by the W3C and the IETF between 2011 and 2018, defined the media layer (PeerConnection, RTCDataChannel, the SDP grammar, DTLS-SRTP, ICE/STUN/TURN) but deliberately left the signalling out of scope. The W3C's reasoning was that signalling requirements vary by application — a video conferencing app needs different signalling than a one-way broadcast — and that vendors should choose the right tool for each case. In practice, the freedom translated into a fragmented ecosystem. Every WebRTC server vendor invented its own signalling: Janus used WebSocket plus a JSON protocol, mediasoup used a request/response JSON protocol over WebSocket, Twilio used its proprietary signalling SDK, Vidyo had its own, Tokbox had its own, and so on. An encoder that wanted to contribute to a WebRTC pipeline needed a vendor-specific SDK for each target server.
In late 2020, Sergio Garcia Murillo at Millicast and Alex Gouaillard at CoSMo Software submitted the first WHIP Internet-Draft (draft-ietf-wish-whip-00) to the IETF, proposing a uniform HTTP-based signalling layer for the specific case of one-way contribution. The proposal was deliberately minimal: do not try to standardise signalling in general, just standardise the single most common case — an encoder pushing one media stream to a server — and let the harder cases stay vendor-specific. The IETF chartered the WISH working group in 2021 to take the work through standardisation. Sixteen drafts and three and a half years later, the working group consensus draft cleared IESG review and was published as RFC 9725 in March 2025.
RFC 9725 is "Standards Track" status — the highest category in the IETF process, currently published at the "Proposed Standard" maturity level. The document also formally updates two earlier RFCs (RFC 8840 for trickle ICE and RFC 8842 for the DTLS-SRTP setup negotiation) to clarify their behaviour inside a WHIP session. The document's authoritative URL is https://www.rfc-editor.org/rfc/rfc9725; section numbers we cite below refer to the published RFC, not to any of the expired drafts.
A useful historical contrast: the SRT standardisation effort, in parallel, never made it past Internet-Draft. The drafts expired in 2022 and SRT today is governed by the union of an expired draft and a reference implementation. WHIP took the opposite path. Garcia Murillo and Gouaillard kept the scope intentionally narrow, kept the surface area tiny, and shepherded the document through the IETF process to formal RFC publication. The result is a stable specification that vendors can build against, with a normative document number ("RFC 9725") that compliance regimes and standards-focused organisations can reference. That distinction matters in broadcast-industry procurement.
The Four HTTP Verbs — What Each One Does
The protocol's surface area is four HTTP verbs against two resource URLs. The rest of this section walks through each verb in the order an encoder uses them.
POST — begin a session (RFC 9725 §4.2)
The encoder generates an SDP offer for a single WebRTC PeerConnection and sends it as the body of an HTTP POST request to the WHIP endpoint URL. The request must carry Content-Type: application/sdp; if it does not, the server "MUST reject the HTTP POST request with an appropriate 4xx error response" (§4.2). The SDP offer has constraints — the direction is sendonly or sendrecv; recvonly and inactive directions are explicitly forbidden in client offers; the session must bundle all media into a single transport (§4.4.1); and exactly one MediaStream is permitted (§4.4.2). Within those constraints, anything legal in WebRTC is legal in the WHIP offer.
The server validates the offer and generates an SDP answer. The answer's direction is always recvonly. The server gathers all of its own ICE candidates before responding — RFC 9725 §4.3.2 states the answer SHALL contain the full list of server candidates — so the client receives a complete candidate set in the answer body and does not need to wait for further server signalling. The server returns the answer in a 201 Created response with Content-Type: application/sdp and the answer in the body. Two response headers carry the rest of the session's identity: a Location header pointing at the WHIP session URL (the URL used for PATCH and DELETE later), and, if the server supports ICE restarts, an ETag header carrying a "unique strong entity-tag identifying the ICE session" (§4.3.1).
Status codes other than 201 indicate failure modes the client should expect: a 4xx if the offer is malformed or the bearer token is missing, a 5xx if the server cannot allocate media resources, and various 3xx redirects (§4.5) that the client is expected to follow. The full set is enumerated in §4.2 and §4.7 of the RFC.
DELETE — end a session (RFC 9725 §4.2)
When the encoder is done, it sends an HTTP DELETE to the WHIP session URL (the URL the server returned in the Location header of the original POST). The server tears down the ICE and DTLS sessions, releases the media resources, and returns 200 OK. The DELETE is the only clean way to end a session; if the encoder disappears without sending one, the server falls back to WebRTC's own keepalive and ICE-connectivity-check timers, which typically detect the loss within a few seconds and tear down state on the server side.
PATCH — update ICE state mid-session (RFC 9725 §4.3.1)
PATCH is the verb that updates ICE state during an active session. There are exactly two reasons to send a PATCH: to trickle additional ICE candidates that the client has gathered after the initial POST (trickle ICE, §4.3.2), or to restart ICE because the network path has changed underneath the session (ICE restart, §4.3.3). The body in both cases is Content-Type: application/trickle-ice-sdpfrag — the trickle-ICE SDP fragment format defined by RFC 8840 — and the request must carry an If-Match header whose value is either the most recent ETag the server returned, or the literal * for an unconditional restart.
The response codes encode the server's interpretation:
204 No Content— a trickle-ICE PATCH (new candidates only) succeeded; the response carries no body and no new ETag.200 OKwith a new SDP answer fragment and a new ETag — an ICE restart succeeded; the client should adopt the new candidate set.405 Method Not Allowed— the server does not support PATCH on this session resource at all (i.e., neither trickle ICE nor ICE restart is supported).422 Unprocessable Content— the server supports one of the two operations but not the other (§4.3.3); the PATCH cannot be handled.412 Precondition Failed— theIf-MatchETag does not match the current session state (the ICE session has changed since the client last saw it).428 Precondition Required— the request did not carry anIf-Matchheader at all.
The ETag mechanism is the key piece of state machinery in the protocol — it is what lets the client know whether its mental model of the ICE session is still valid, and it is what lets a server safely reject a restart attempt that races with another restart in flight.
OPTIONS — capability discovery and CORS preflight (RFC 9725 §4.1)
OPTIONS is the verb used for two purposes. First, CORS preflight: a browser that wants to POST to a WHIP endpoint will issue an OPTIONS request first, and RFC 9725 requires the WHIP endpoint to handle the preflight with the appropriate Access-Control-Allow-Origin headers. Second, capability discovery: a 200 OK to an OPTIONS request SHOULD include Accept-Post: application/sdp to announce that the endpoint accepts SDP POSTs. Recent OBS Studio releases use the OPTIONS response to gather server ICE candidates before the POST, shaving a round-trip off the connection setup; the pattern was added in OBS 30.2 in mid-2025 and is now a common optimisation.
Trickle ICE And ICE Restart — Why Both Matter
WebRTC's ICE machinery is responsible for picking the best network path between the two endpoints. The classical version of ICE (RFC 8445) assumes both sides exchange their full candidate lists in the SDP offer/answer, then begin connectivity checks. Trickle ICE (RFC 8840) relaxes this assumption — candidates can be exchanged incrementally as they are discovered, which is faster because the client does not have to wait for its full candidate-gathering cycle to complete before sending the offer.
WHIP supports trickle ICE through the PATCH verb. The server's behaviour is asymmetric: server-side candidates are always delivered fully in the initial 201 response (§4.3.2 says "the WHIP endpoint SHALL gather all the ICE candidates ... before responding"), and only the client trickles. The reason is pragmatic: the server typically has stable, well-known public addresses and its candidate gathering is trivial; the client may be behind a NAT, gathering server-reflexive and relayed candidates over multiple network round-trips, and benefits more from trickling.
ICE restart is the harder case. During a session, the underlying network can change — a mobile encoder hands off between cellular and Wi-Fi, a roaming laptop changes IP address, a NAT binding expires — and the existing ICE session becomes invalid. ICE restart asks both sides to gather a fresh set of candidates and re-perform the connectivity checks while keeping the media path alive. In WHIP, the client initiates the restart by sending a PATCH whose If-Match value is * (the unconditional form, per §4.3.3) and whose body contains a fresh ice-ufrag and ice-pwd plus the new candidate set. The server responds with a new SDP fragment, a new ETag, and the restart proceeds.
A subtle but important detail: §4.3.3 says trickle ICE and ICE restart are both RECOMMENDED but not REQUIRED, and the protocol carries a clean way for a server that supports only one to reject the other (the 422 response). In 2026, every major server we have tested supports both — Cloudflare Stream added ICE restart and trickle ICE support in early 2025, AWS IVS Real-Time has had both since GA, Dolby Millicast has had both since 2024, and Ant Media has had both since v2.10. A self-hosted media server (Janus, mediasoup, LiveKit) may or may not, depending on the version; check the release notes before assuming.
Authentication — Bearer Tokens And Why You Should Always Use Them
RFC 9725 §4.7 mandates that all WHIP endpoints, sessions, and clients MUST support HTTP authentication as specified in Section 11 of RFC 9110. Section 4.7.1 then mandates bearer-token authentication specifically: "bearer token authentication ... MUST be supported by all WHIP entities." That means every compliant WHIP server understands the Authorization: Bearer header, and every compliant client knows how to send it.
In practice, every production WHIP deployment uses a Bearer token. The encoder is configured with the WHIP endpoint URL and a token (often delivered together as the URL plus a ?token=... query parameter for convenience, but the canonical form is the header). The server validates the token on every request — POST, PATCH, DELETE — and rejects unauthenticated requests with a 401 or 403. RFC 9725 explicitly clarifies that the token "MUST NOT be sent in any request" if the client has not been configured with one, which closes a small footgun where an unauthenticated client could leak a default header value.
The token's lifecycle is out of scope for the RFC — the spec deliberately does not say how a token is issued, rotated, or revoked. In practice the patterns are familiar from any other HTTP API: short-lived JWTs signed by the platform's auth service (Cloudflare Stream, Dolby Millicast, AWS IVS), long-lived API keys (most self-hosted servers in default configuration), or per-session signed URLs (some CDNs front their WHIP endpoint with a signing layer). Treat the token like any other API credential: rotate it periodically, scope it to the minimum permissions needed, and store it in a secrets manager.
The cryptographic protection on the wire is twofold: HTTPS protects the signalling (the SDP offer, the SDP answer, the bearer token, the candidate exchanges), and DTLS-SRTP protects the media (the WebRTC PeerConnection's DTLS handshake produces SRTP master keys that encrypt every media packet end-to-end). Both layers are mandatory in production deployments; §5 (Security Considerations) of the RFC says HTTPS SHALL be used. There is no plaintext mode.
What The Latency Floor Actually Is
WebRTC's design budget for end-to-end latency is famously aggressive — the conferencing use case targets sub-300-ms glass-to-glass — and WHIP inherits that budget. The realistic number for a contribution path on a clean network in 2026 is between 200 milliseconds and 800 milliseconds of glass-to-glass latency, depending on how the path is configured.
The arithmetic, out loud. A typical encoder produces frames at 30 fps, which means one frame arrives every 33 ms. Add the encoder's own pipeline latency (typically 30 to 100 ms for hardware H.264, 50 to 150 ms for software H.264, more for HEVC or AV1), DTLS-SRTP packetisation, the actual network round-trip from encoder to server (5 to 100 ms for a same-region path; 100 to 200 ms transatlantic), the server's jitter buffer (typically 100 to 300 ms in WebRTC, configurable), and the downstream packaging plus player buffer if the stream is going to viewers. The cleanest contribution-only path — encoder to server, then the server hands the media to a sub-second-latency delivery protocol — runs 200 to 600 ms; a path that converts to HLS at the receiving side adds the HLS budget (typically 4 to 10 seconds) on top.
The trade against SRT is direct. SRT typically configures a 200–500 ms latency budget for a same-country wired path, and its arithmetic adds the GOP closure delay and the HLS packaging delay on top — total glass-to-glass for SRT-to-HLS is often 8 to 12 seconds. WHIP's typical glass-to-glass on a similar path, ending in a WebRTC delivery layer (WHEP on the receiving side), is closer to 400 to 800 ms. The difference is roughly an order of magnitude — and it is the only difference that makes the WHIP-versus-SRT choice unambiguous.
| Configuration | Glass-to-glass | Notes |
|---|---|---|
| WHIP → WHEP, same-region wired | 200–500 ms | The lowest-latency contribution+delivery path in 2026. |
| WHIP → WHEP, transatlantic wired | 400–800 ms | The transatlantic RTT eats most of the additional budget. |
| WHIP → server → LL-HLS delivery | 3–6 s | The LL-HLS packager dominates. |
| WHIP → server → HLS delivery | 8–12 s | Equivalent to SRT in the same configuration. |
| SRT → server → LL-HLS delivery | 4–7 s | The SRT latency budget plus LL-HLS packaging. |
| SRT → server → HLS delivery | 8–14 s | The classical broadcast-on-internet baseline. |
| RTMPS → server → HLS delivery | 10–20 s | The legacy social-platform default. |
Common Mistakes — The Things That Break WHIP In Production
A short list of the failures we see most often when bringing up a new WHIP contribution link. Most of them are configuration mismatches, not bugs in the protocol.
Pitfall 1: ICE failure because TURN is not configured. WebRTC needs a TURN server when both endpoints are behind symmetric NATs that prevent direct peer-to-peer connectivity. Every production WHIP deployment must ship a TURN server (or use the platform's hosted TURN, e.g., Cloudflare's anycast TURN, Twilio's TURN, or a Coturn cluster). The single most common failure pattern is the encoder reporting "ICE failed" because no TURN candidates were returned in the SDP answer. The fix is either to configure the WHIP server to advertise a TURN URL, or to use the platform's TURN. See our NAT/STUN/TURN article for the underlying mechanism.
Pitfall 2: HTTPS not enforced. RFC 9725 §5 says HTTPS SHALL be used. A few self-hosted servers ship a plaintext-HTTP mode for local development convenience; never deploy that mode in production. Cleartext SDP exposes the bearer token on the wire (it travels in the Authorization header of the POST), and a leaked token grants ingest rights to any attacker on the path. Use HTTPS, with a valid certificate, on every WHIP endpoint.
Pitfall 3: Bearer token in the URL query string. Some vendors document a "convenience" form where the bearer token is appended to the URL as a query parameter. The form is not part of RFC 9725, and using it leaks the token to every HTTP intermediary that logs URLs (load balancers, proxies, CDN edge logs, browser history). Use the Authorization: Bearer header instead. If the vendor documentation insists on the query parameter, push back; the header is the canonical form.
Pitfall 4: Codec mismatch with the server. WHIP carries whatever codecs the SDP offer/answer negotiate. If the encoder offers H.265 (HEVC) and the server only accepts H.264 (AVC), the offer is rejected. As of mid-2026, the broadly compatible codecs are H.264 (universal), VP8 (most servers), and Opus (universal audio); H.265, VP9, and AV1 support is rising but uneven. Check the platform's accepted codec list before configuring the encoder; a mismatch fails fast but leaves a confusing error message.
Pitfall 5: Trickle ICE not supported on the server. Older WHIP server implementations (some still in production from the 2022–2023 era) do not support PATCH at all, and respond with 405 Method Not Allowed to any trickle. OBS Studio 30+ and other modern encoders default to using trickle ICE, and a 405 from the server breaks the connection. The fix is either to upgrade the server or to disable trickle ICE on the client — OBS exposes the toggle as "Enable trickle ICE" in the WebRTC service settings. In practice, every commercial platform we test in 2026 supports trickle ICE; the issue arises only with older self-hosted servers.
Pitfall 6: TURN bandwidth costs. Every relayed media packet (i.e., packets that go through a TURN server because the direct path failed) costs TURN egress bandwidth. For a 6 Mbps stream that ends up fully relayed (a worst-case symmetric-NAT scenario), 6 Mbps of TURN egress is a real bill. Major cloud platforms charge $0.05 to $0.40 per GB of TURN egress in 2026, which is the same order as CDN egress. Plan for TURN bandwidth in the cost model; do not assume the connection will always go direct.
What Platforms Actually Support WHIP In 2026
The table below summarises WHIP ingest support across the platforms we encounter in client engagements in 2026. The data is current as of May 2026; cross-check vendor documentation for the latest status before final architecture decisions.
| Platform | WHIP ingest | RTMPS ingest | SRT ingest | Notes |
|---|---|---|---|---|
| Cloudflare Stream | Yes (GA) | Yes | Yes | Trickle ICE and ICE restart both supported; bearer-token auth; first cloud platform to ship WHIP and WHEP both. |
| AWS Elemental MediaLive (Anywhere) | Yes (GA) | Yes | Yes | WHIP added in 2025; pairs with MediaConnect for SRT and MediaPackage for delivery. |
| AWS IVS Real-Time | Yes (GA) | No | No | Real-Time product line is WebRTC-first; standard IVS uses RTMPS. |
| Dolby Millicast | Yes (GA) | Yes | Yes | The protocol's first commercial home; co-author Garcia Murillo was at Millicast. |
| Mux Live | Yes (GA) | Yes | Yes | Three-protocol single ingest endpoint. |
| Wowza Streaming Engine | Yes | Yes | Yes | Self-hosted; WHIP added in late 2023. |
| Ant Media Server | Yes (GA) | Yes | Yes | WHIP added in v2.10 (mid-2024); both managed and self-hosted. |
| THEO Technologies (LiveSync) | Yes (GA) | Yes | Yes | WHIP integration with HESP for sub-second end-to-end. |
| Vimeo Livestream | Yes | Yes | Yes | Three-protocol endpoint. |
| Nimble Streamer | Yes | Yes | Yes | Self-hosted; WHIP added in 2024. |
| Janus | Yes (plugin) | No | No | Self-hosted SFU; WHIP plugin from the community since 2022. |
| mediasoup | Yes (community) | No | No | Self-hosted SFU; community WHIP gateways exist. |
| LiveKit | Yes (GA) | No | No | Cloud and self-hosted; WHIP supported alongside LiveKit's native SDK. |
| YouTube Live | No | Yes | No | RTMPS-only. |
| Twitch | No | Yes | No | RTMPS-only; previously experimented with SRT. |
| Facebook Live | No | Yes | No | RTMPS-only. |
| Kick | No | Yes | No | RTMPS-only. |
| TikTok Live | No | Yes | No | RTMPS-only. |
RTCPeerConnection).
A Worked Example — Pushing OBS To Cloudflare Stream Over WHIP
Let us trace one concrete configuration. We are pushing a 1080p30 H.264 stream at 6 Mbps from OBS Studio 30.2 on a Mac mini with a wired Ethernet uplink to Cloudflare Stream's WHIP endpoint, then playing the stream back via WHEP in a browser tab on the same network for end-to-end latency measurement.
In OBS, the configuration is straightforward. Settings → Stream → Service: "WHIP". Server: https://customer-. Bearer token: the production token from the Cloudflare dashboard. Settings → Output: x264, CBR, 6 Mbps, keyframe interval 2 seconds (B-frames disabled, because WebRTC's default codec profile does not negotiate B-frames). Settings → Audio: Opus, 48 kHz, 128 kbps. That is the whole encoder setup.
OBS issues an HTTP OPTIONS request to the endpoint first (the OBS 30.2+ optimisation), receives the server's TURN URL list back in the response, and gathers its host and server-reflexive candidates against that TURN. It then issues an HTTP POST with Content-Type: application/sdp, Authorization: Bearer , and the SDP offer in the body. The offer declares two media sections — one for the video (H.264 baseline, send-only, with the SRT and SRTCP feedback extensions enabled), one for the audio (Opus, send-only) — bundled together over a single ICE transport. Cloudflare's WHIP endpoint validates the offer, gathers its full set of ICE candidates (host candidates in every Cloudflare PoP region plus the TURN relay), generates the SDP answer with recvonly media sections and the full candidate list, and returns 201 Created with Location: /webrtc/sessions/ and ETag: "abc123...".
OBS receives the answer, sets it on the PeerConnection, ICE begins, and a connectivity check succeeds against a Cloudflare host candidate in the same region (round-trip time roughly 15 ms). DTLS handshake completes in two round-trips (~30 ms). SRTP keys are derived, and media starts flowing. End-to-end latency from glass to glass, measured by displaying a millisecond-resolution clock on the source camera and reading it in the WHEP-side browser tab: approximately 380 ms.
During the session, OBS gathers one additional server-reflexive candidate (the public-IP discovery completes after the initial POST) and issues a PATCH with Content-Type: application/trickle-ice-sdpfrag, If-Match: "abc123...", and the candidate in the body. Cloudflare responds with 204 No Content (a successful trickle update, no new ETag). The session runs for 90 minutes uninterrupted; at the end, OBS issues DELETE /webrtc/sessions/ with the bearer token; Cloudflare responds 200 OK and tears the session down.
Compare the same path running over RTMPS. RTMPS to Cloudflare Stream, then Cloudflare's HLS packager, then the browser-side HLS player buffer: glass-to-glass latency is approximately 12 seconds. The protocol shape is the same — push contribution from encoder to cloud — and the end-user observation of the stream's content is the same. The latency difference is one and a half orders of magnitude. That difference is the entire reason to use WHIP.
Figure 2. The same source camera, the same Cloudflare Stream service, two contribution-and-delivery stacks. WHIP plus WHEP delivers roughly 380 ms glass-to-glass on a clean wired path; RTMPS plus HLS delivers roughly 12 seconds. The latency difference is the only reason to choose WHIP over RTMPS.
When To Choose WHIP — A Decision Framework
WHIP is the right contribution choice in a specific set of conditions. The framework below is the one we walk clients through when sketching a 2026 contribution architecture.
Choose WHIP when: (a) the latency budget is under one second glass-to-glass on at least the contribution-plus-delivery legs; (b) the path between encoder and server is wired or a healthy 5G/Wi-Fi link with under 1% expected packet loss; (c) the target platform has shipped WHIP support (Cloudflare Stream, AWS IVS Real-Time, Dolby Millicast, Mux Live, MediaLive, Ant Media, LiveKit, Wowza, THEO, or any of the self-hosted servers above); and (d) the encoder ecosystem supports WHIP (OBS 30+, FFmpeg 7, Larix Broadcaster, Wirecast, or any of the hardware encoders shipping WHIP in 2026 — Magewell Pro Convert WHIP-enabled models, AJA HELO Plus with 2025 firmware, Teradek with 2025 firmware, Haivision Pro 460 with 2024+ firmware).
Choose SRT when: the contribution path is lossy (satellite, hostile cellular, transcontinental at peak congestion), or the encoder is a traditional broadcast appliance that does not speak WebRTC. SRT's selective retransmission and longer latency budget recover from loss patterns where WebRTC degrades.
Choose RTMPS when: the destination is a consumer social platform (YouTube, Twitch, Facebook, Kick, TikTok) that mandates RTMPS for ingest. The protocol is technically inferior but operationally non-negotiable for those targets.
Choose RIST when: a SMPTE-standards-compliance requirement explicitly mandates a SMPTE TR-06 specification; or the existing broadcast pipeline is RIST-native.
Figure 3. The 2026 contribution decision tree. RTMPS for consumer social, SRT for lossy paths, WHIP for sub-second on clean paths, RIST when SMPTE compliance demands it.
Where Fora Soft Fits In
We have shipped WHIP-based contribution stacks across several verticals since the protocol stabilised: telemedicine deployments where a clinical camera pushes to a central WebRTC server for sub-second remote consultation; e-learning live-class recording rigs where instructors push to a WHIP endpoint that fans out via WHEP plus LL-HLS; live shopping and auction products where the host pushes to a WHIP endpoint and the audience watches over a sub-second-latency delivery path; AR/VR live-event streaming where the WHIP path keeps end-to-end latency inside the budget that human comfort requires. The pattern is consistent: when the contribution path is clean and latency dominates, WHIP is the right tool, and the RFC's small surface makes it cheap to integrate against several backends in one product.
What To Read Next
- SRT — The Professional Standard For Public-Internet Contribution — the lossy-path alternative; longer latency, much stronger loss recovery.
- WHEP — WebRTC Egress For Sub-Second Delivery — the companion delivery protocol; pair with WHIP for end-to-end sub-second.
- Picking An Ingest Protocol In 2026 — the full decision tree across all five modern contribution protocols.
CTA
Talk to a streaming engineer · See our case studies · Download the WHIP integration checklist (PDF)
References
- RFC 9725 — WebRTC-HTTP Ingestion Protocol (WHIP), S. Garcia Murillo and A. Gouaillard, IETF Standards Track, March 2025 (Proposed Standard). The canonical specification. Section references throughout this article (§4.1 HTTP Usage, §4.2 Ingest Session Setup, §4.3 ICE Support, §4.7 Auth, §5 Security Considerations) point at this document.
- RFC 8840 — A SIP Usage Of The Trickle ICE Mechanism, IETF, January 2021. The trickle-ICE SDP fragment format used by WHIP PATCH bodies (
application/trickle-ice-sdpfrag). RFC 9725 updates this document. - RFC 8842 — Session Description Protocol (SDP) Offer/Answer Considerations For Datagram Transport Layer Security (DTLS) And The Secure Real-time Transport Protocol (SRTP), IETF, January 2021. The DTLS-SRTP setup negotiation rules WHIP relies on. RFC 9725 also updates this.
- RFC 8445 — Interactive Connectivity Establishment (ICE), IETF, July 2018. The base ICE protocol on which WHIP's connectivity exchange runs.
- RFC 9110 — HTTP Semantics, IETF, June 2022. The HTTP authentication framework WHIP §4.7 references.
- RFC 6750 — The OAuth 2.0 Authorization Framework: Bearer Token Usage, IETF, October 2012. The bearer-token semantics WHIP §4.7.1 normatively references.
- IETF WISH Working Group archive, IETF. The chartering documents, mailing-list archive, and draft history for the standardisation work.
- IANA WHIP URN Sub-namespace Registry, IANA. The registry of URN identifiers defined by RFC 9725 §6 (link relation
ice-server, WHIP URNs, extension URNs). - OBS Studio Knowledge Base — WHIP Streaming Guide, OBS Project, retrieved May 2026. The reference implementation guide for the most widely deployed encoder.
- OBS Studio Pull Request #7926 — Add WebRTC (WHIP) Output Support, GitHub, merged 2023. The original WHIP implementation in OBS, by
kc5nra. - OBS Studio Pull Request #13021 — Add Trickle ICE Support For WHIP, GitHub, merged 2025. The trickle-ICE addition; useful for understanding the deployed-in-production behaviour.
- Cloudflare Stream — WebRTC (Beta) Documentation, Cloudflare, retrieved May 2026. The platform documentation for Cloudflare's WHIP/WHEP implementation, including trickle ICE and ICE restart support.
- Cloudflare Stream Changelog — Trickle ICE Support For WHIP And WHEP, Cloudflare, 2025. The release notes for the trickle-ICE addition on Cloudflare's WHIP/WHEP endpoints.
- AWS IVS Real-Time User Guide — WHIP Publishing, Amazon Web Services, retrieved May 2026. AWS's documentation for using WHIP with OBS to publish to IVS Real-Time.
- Ant Media Server — WHIP Guide, Ant Media, retrieved May 2026. The self-hosted server's documentation for WHIP, including the v2.10 release that added support.
- WebRTC Cracks The WHIP On OBS, webrtcHacks (Chad Hart), 2023. The community engineering overview of the OBS WHIP integration.
