WHIP and WHEP: The 2026 WebRTC Streaming Playbook

Why Fora Soft wrote this playbook

Two weeks before a launch, a client asked us why their "sub-500 ms WebRTC" vendor was delivering 1.4 seconds. The answer was that nobody had ever measured the 500 ms. It was a number copied between marketing pages until it acquired the texture of fact. That is the state of most WHIP and WHEP writing right now, and it is expensive: you scope a product feature around a latency budget that does not exist.

Fora Soft has shipped 250+ projects since 2005 with 50 in-house engineers, and real-time video is most of what we do. Worldcast Live runs HD concert streaming at 0.4–0.5 s to 10,000 simultaneous viewers on a custom WebRTC and Kurento stack. Speed.Space does remote production on LiveKit for Netflix, EA and HBO shoots. Tyxit lets musicians play together across cities at under 30 ms, live between Montreux Jazz Festival and Jazz à Vienne. For Mangomolo we built the Wowza SCTE-35 module that drives their server-side ad insertion.

So this playbook is written from the side of the table where you have to make the thing work on a Tuesday. Every standards claim below was re-checked against IETF datatracker on 19 July 2026. Every vendor claim was checked against that vendor's own docs, release notes or source tree, not against their marketing page. Where we could not verify a number, we say so instead of rounding it into confidence.

What are WHIP and WHEP

WHIP and WHEP are HTTP signalling protocols for WebRTC. WHIP, the WebRTC-HTTP Ingestion Protocol, gets a stream from an encoder into a media server. WHEP, the WebRTC-HTTP Egress Protocol, gets a stream from a media server out to a viewer. In both cases the entire negotiation is one HTTP POST carrying an SDP offer, and one response carrying an SDP answer. After that, media flows over ordinary WebRTC transport.

Quick disambiguation, because search engines struggle with this: WHIP here is not the parliamentary role or the baseball statistic. Both acronyms come from the IETF WISH working group, whose name stands for WebRTC Ingest Signaling over HTTPS.

The problem they solve is boring and real. WebRTC deliberately never specified how two endpoints exchange their SDP. That was the right call for browsers, which ship their own application code anyway. It was a disaster for streaming, where an encoder from one vendor has to talk to a media server from another. Every vendor invented a WebSocket protocol, and every combination needed a custom bridge. RTMP, for all its age, never had that problem: an OBS build from 2015 can still publish to a server written last month.

Figure 1. WHIP and WHEP are the same shape in opposite directions. The HTTP exchange sets up the session; the media never touches it.

The practical consequence is worth stating plainly, because a lot of vendor copy blurs it. WHIP does not reduce your media latency. It reduces your connection setup time and your integration cost. Anyone advertising "sub-100 ms latency" as a benefit of WHIP is describing WebRTC and putting the wrong label on it.

Standards status, July 2026

WHIP is a published IETF standard. WHEP is not, and has not moved as fast as anyone expected. Here is the state of both, checked against the IETF datatracker on 19 July 2026.

Figure 2. The asymmetry most published guides miss. One of these you can build on as frozen; the other still moves.

WHIP. Published as RFC 9725 in March 2025, Standards Track, after 16 working-group draft revisions. Authors Sergio Garcia Murillo (Millicast) and Alexandre Gouaillard (CoSMo Software). It updates RFC 8840 and RFC 8842. Frozen means frozen: you can pin an implementation to it and expect it to still interoperate in three years.

WHEP. Still draft-ietf-wish-whep-04, dated 22 June 2026, expiring 24 December 2026. Working-group state is "In WG Last Call, Revised I-D Needed". IESG state is "I-D Exists", the earliest one there is. The working group's own milestone said WHEP would go to the IESG in December 2024; that is roughly 19 months overdue. Four revisions in four years is not a dead draft, but it is not a sprint either.

What that means when you buy: vendors implement different WHEP revisions and they do not always say which. Red5's docs reference draft-03. Cloudflare's still reference draft-murillo-whep-01, a pre-working-group revision. Those are not the same protocol in the corners that matter. Ask, in writing, which revision your server and your player each implement.

Is RTMP actually dead

No, and the widely repeated claim that Adobe deprecated RTMP is false. We had this wrong in an earlier version of this article, so here is the correction with sources.

Adobe has never deprecated RTMP as a protocol. The string "RTMP" appears zero times on Adobe's Flash Player end-of-life page and zero times in Adobe's product end-of-life matrix, which retires products, not protocols. In 2023 Adobe publicly committed to the opposite: it became a founding member of the nonprofit Veovera Software Organization, which maintains Enhanced RTMP v2. That document is at version v2-2026-01-31-r2 with repository commits as recent as June 2026, and its contributor list includes Adobe, Google, Twitch, Intel, Meta and the OBS maintainers.

The accurate history: RTMP was built by Macromedia under the internal name "Tin Can", work starting in 2000, first shipping in Flash Player 6 on 16 March 2002. Adobe acquired Macromedia in December 2005 and published the canonical specification, version 1.0, on 21 December 2012. Flash Player itself reached end of life on 31 December 2020, with content blocked from 12 January 2021. The protocol outlived its container by design, not by accident.

And it is still the only way into the platforms your marketing team cares about. YouTube's ingest protocol comparison, updated 1 June 2026, lists exactly four options: RTMP, RTMPS, HLS and DASH. No SRT. No WHIP. Twitch's developer docs list RTMP and RTMPS only; we queried its ingest endpoint list on 19 July 2026 and got both schemes back for all 14 points of presence. Twitch has run an undocumented experimental WHIP endpoint since April 2023, and OBS lists Twitch as a WHIP destination, but it is not in the developer docs and Twitch transmuxes the WebRTC stream to HLS on arrival anyway.

One more correction while we are here, because it trips up a lot of roadmap conversations: Twitch's Enhanced Broadcasting is not WebRTC. It is Enhanced RTMP multitrack, several client-side encodes multiplexed over a single RTMP connection. It went generally available in July 2024 alongside OBS 30.2, and in June 2026 Twitch raised the ceilings to 9 Mbps at 1440p HEVC and 7.5 Mbps at 1080p AVC.

What a WHIP session does

An encoder POSTs an SDP offer with a bearer token, the server answers 201 Created with an SDP answer and a session URL, and media starts. That is the whole protocol. Here is the wire exchange.

POST /whip/live/mychannel HTTP/1.1
Host: ingest.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Content-Type: application/sdp

v=0
o=- 4611734147533472881 2 IN IP4 127.0.0.1
... (SDP offer)

---

HTTP/1.1 201 Created
Location: /whip/live/mychannel/s-abc123
Content-Type: application/sdp
Link: <stun:stun.example.net>; rel="ice-server"

v=0
o=- ... (SDP answer)

---

PATCH  /whip/live/mychannel/s-abc123   # trickle ICE, if you use it
DELETE /whip/live/mychannel/s-abc123   # teardown

Three details in there are worth knowing before you write a gateway, because they are the ones people skip.

1. The Link header carries your ICE servers. RFC 9725 registered rel="ice-server" with IANA precisely so that a client does not need out-of-band TURN configuration. The RFC also warns that servers should not return TURN credentials on a CORS preflight OPTIONS request, since that turns your relay into a free credential dispenser. We have reviewed gateways that got this wrong.

2. OPTIONS is mandatory. Section 4.2 says endpoints MUST support OPTIONS for CORS and SHOULD return Accept-Post: application/sdp. If your reverse proxy swallows OPTIONS, browser-based publishers fail in a way that looks like an authentication bug for about a day.

3. Renegotiation is the weak spot. Once you are publishing, you generally cannot add tracks or change codecs through WHIP. Edge cases like ICE restarts are acknowledged soft ground in the spec. Test reconnect behaviour hard before you trust it in production, especially on mobile uplinks.

Because the signalling is plain HTTPS, the rest of your infrastructure just works: reverse proxies, load balancers, WAFs, OAuth bearer tokens, signed URLs, mTLS. That is the actual win. RTMP needed a dedicated publish appliance; WHIP is a route in your existing HTTP stack.

What a WHEP session does

WHEP is the same shape pointed the other way: a viewer POSTs to a WHEP endpoint and gets a media stream back over WebRTC. Where WHIP replaced the vendor ingest SDK, WHEP is meant to replace the vendor playback SDK.

It mostly has not, and it is worth being honest about why. There is no browser-native WHEP and none is even proposed. We checked: Chrome Status returns zero features matching WHEP, WebKit's features file has zero occurrences, and WebKit and Mozilla Bugzilla each return zero bugs. There are no standards positions filed at Mozilla, WebKit, W3C or WICG. This is structural rather than neglect. WHEP is signalling layered on RTCPeerConnection; it is not a container or a manifest format, so there is nothing for a <video src> to consume. Every WHEP player is JavaScript, and always will be.

The ecosystem gap that follows is large. hls.js pulls roughly 6.5 million npm downloads a week. The entire WHEP client field tops out near 6,000, and the most complete library, Eyevinn's webrtc-player, last shipped a functional release in April 2024. No commercial player supports generic WHEP: not THEOplayer, not Bitmovin, not JW, not Shaka, not video.js. Shaka has never had a single WHEP issue filed and is investing in Media over QUIC instead.

None of that makes WHEP a bad choice. It makes it a choice with a build cost attached. If you are shipping a web app you control, a 100-line WHEP client is genuinely a day of work and Cloudflare publishes a good reference one. If you needed a drop-in player with ABR, DRM and analytics, WHEP will not give you that, and no roadmap suggests it will soon.

The WHEP two-mode trap

WHEP allows two negotiation directions, and a client that only speaks one will not connect to a server that only speaks the other. This is the interop failure we hit most often, and it is almost absent from published writing on the topic.

Figure 3. Two legal ways to negotiate the same session. There is no automatic fallback between them.

Mode 1, client offers. The viewer builds an SDP offer, POSTs it, and gets 201 Created with the answer. One round trip, which is the fast path. The cost is that the client has no idea what the stream contains at the moment it builds the offer, so it must allocate a transceiver for every codec it might need. You end up offering video slots on an audio-only feed.

Mode 2, server offers. The viewer POSTs an empty body, the server replies with its own SDP offer, and the viewer PATCHes an answer back. Two round trips, so first frame is later. In exchange the server constrains negotiation properly, because it already knows the encoding. The draft also defines a 406 Not Acceptable counter-offer path with a default 30-second validity window, which almost nobody implements.

Now the part that bites. Janus cannot implement mode 1: its VideoRoom and Streaming plugins always generate the offer, so anything Janus-backed is mode 2 only. Meetecho's own WHEP client is mode 2 only for the same reason. Cloudflare Stream and Red5 support mode 1. MediaMTX's reference reader implements only the 201 path. Pair the wrong two and you get a connection that never establishes, with no error message that names the actual cause.

Lorenzo Miniero’s write-up at Meetecho is the only place we have found that explains this properly, with sequence diagrams. It is four years old and still the best thing written on WHEP negotiation. Read it before you pick a player.

What the latency numbers say

Plan for 0.6–1.3 s glass-to-glass through a CDN, not sub-500 ms. We used to publish the sub-500 ms figure ourselves. We went looking for its primary source and could not find one, so we are retiring it.

Figure 4. Every bar here comes from a test with published methodology. The numbers are less flattering than the marketing ones, and far more useful for planning.

Here is the audit trail, because you should be as suspicious of our numbers as of anyone else's.

The sub-500 ms claim. The IEEE Communications Surveys and Tutorials survey on low-latency streaming says WebRTC operates "typically with an end-to-end latency of under half a second" and cites the W3C and IETF WebRTC specifications. Those specifications contain no such figure. The citation does not support the number. Downstream, vendor pages cite the survey, and the number acquires authority it never earned.

The best independent measurement. Robert Reinhardt's glass-to-glass report for Streaming Media, October 2023, is the only fully disclosed head-to-head we have found: a burnt-in wall clock through six CDN vendors onto six devices, photographed simultaneously at 1/500s, with 4G and 5G emulation across 18 rounds. WebRTC came in at 1.30 s combined and 0.58 s in the best single condition. LL-HLS came in at 19.75 s, which the author himself flags as one vendor's implementation rather than a property of LL-HLS.

The only WHIP-specific test. Ceeblue published benchmarks in April 2024 using GStreamer timestamp overlays across roughly 1,628 km: WHIP in to WebRTC out at 240 ms passthrough and 300 ms transcoded, against 2,900 ms for LL-HLS and 9,800 ms for HLS over MPEG-TS. Those are vendor-run and round-trip, and their own footnote concedes the LL-HLS test used hls.js at defaults, not tuned for low latency. Useful directionally, not as a guarantee.

Where the time actually goes. The most instructive number we found is from ByteDance's ACM SIGCOMM 2025 paper on running WebRTC at Douyin scale. Replacing HTTP-FLV with WebRTC cut end-to-end latency 49.6% across 450 million sessions per test arm, and daily viewing time fell 1.28%. Their own breakdown: first mile 20–100 ms, CDN overlay 100–300 ms, last mile 20–100 ms, and viewer-side pre-buffering 2–5 s, which is nearly 90% of the total. Your player's buffer, not your protocol, is usually the problem.

And the HLS floor is arithmetic, not incompetence. The HLS specification says HOLD-BACK must be at least three times the target duration. At Apple's recommended six-second segments that is an 18-second minimum distance from the live edge, before encoding, packaging, CDN or decode. When someone tells you their HLS is 25 seconds behind, they are not doing it wrong.

Vendor support matrix

Every claim in this table was checked against the vendor's own documentation, release notes or source tree on 19 July 2026. Several rows contradict what those vendors' marketing pages say, and two rows contradict what we ourselves published earlier this year.

Two of those rows deserve a sentence more. AWS IVS is the cleanest illustration of the whole topic: an open standard on the way in, a proprietary SDK on the way out. We searched both IVS release-notes documents, 2,039 lines for Real-Time and 4,933 for Low-Latency, and "WHEP" appears zero times in either. If anyone tells you IVS speaks WHEP, ask them for the doc link.

Wowza is the genuinely new development. Streaming Engine 4.11, announced 17 June 2026, added both protocols and explicitly retired the proprietary client requirement, and it removed the need for sticky sessions in front of the signalling tier. That last detail matters more than it sounds if you run Kubernetes. One caveat we would want in writing before committing: every WHIP and WHEP claim Wowza makes is attached to self-hosted Engine, never to Wowza Video.

Encoders and players

Software encoders are solved. Hardware encoders are patchier than almost every article claims, including the earlier version of this one.

Software: mature enough to stop worrying about

OBS Studio shipped native WHIP output in version 30.0.0 on 12 November 2023, and added WebRTC simulcast, one to four layers, in 32.1.0 on 24 March 2026. Set Service to WHIP, paste the server URL, put your stream key in the Bearer Token field. One packaging gotcha from the OBS knowledge base: WHIP is missing from the Ubuntu 24.04 PPA build, so use the Flatpak. OBS has no WHEP playback and never has.

FFmpeg added the WHIP muxer in 8.0, released 22 August 2025, originally a Google Summer of Code project. Its own documentation still says, verbatim, "This is an experimental feature", and requires H.264 without B-frames plus Opus. There is no WHEP demuxer. If you read somewhere that FFmpeg 7.1 has WHIP, that is wrong, and we were among the people who wrote it.

GStreamer is furthest along. The current elements are whipclientsink and whipserversrc, both since 1.24 in March 2024, and whepclientsrc and whepserversink, added in 1.28 in January 2026. The older whipsink and whepsrc are deprecated, which trips up a lot of copy-pasted pipelines.

Hardware: verify before you buy

We checked manuals, firmware release notes and developer specs rather than product pages, because vendor marketing lags firmware badly in both directions. What shipped WHIP:

• Teradek Prism (Rack, Flex, Mobile, Jetpack), firmware 2.21, 16 August 2024. H.264 only, progressive only, audio forced to Opus.
• Kiloview E3 and RE-3 firmware 1.23 (October 2025), P3 firmware 1.22, N50 and N60 firmware 2.45 (8 July 2026).
• Haivision Makito X4, version 1.9, announced at IBC in September 2025.
• Videon LiveEdge 10.1, announced March 2024, built with Millicast.
• Osprey Talon, whose spec sheet lists WHIP alongside SRT and Zixi.

What did not ship WHIP, despite being listed in several widely-cited articles including our own earlier draft: AJA HELO and HELO Plus (spec sheet dated 16 July 2026 lists RTMP family, RTSP, HLS, RTP-TS and SRT; the 2,034-line manual has zero WHIP mentions), Magewell Ultra Encode (manual updated 15 April 2026, zero matches for either WHIP or WebRTC), Blackmagic Web Presenter and Streaming Encoder (RTMP and SRT only; the January 2026 developer protocol spec has no WHIP field), and Teradek VidiU in all its variants. Teradek does have WHIP. It is on Prism, not VidiU. That distinction cost somebody a purchase order somewhere.

Self-hosted options

Self-hosting starts making sense when you cross roughly three million delivered minutes a month, or when compliance rules out a managed vendor. Below that, the engineering time costs more than the bill. Here is the honest shortlist, with four corrections to what we published before.

MediaMTX is where we would start most projects now. MIT licence, around 19,500 GitHub stars, v1.19.2 in June 2026 and commits this week. Its specifications page cites RFC 9725 and the WHEP draft by name, which is a good sign about how the maintainers think. It bridges WHIP, WHEP, SRT, RTSP, RTMP, LL-HLS and Media over QUIC in one binary. There is no commercial offering, which is either the feature or the dealbreaker depending on your risk appetite.

Janus has official WHIP and WHEP, but not as plugins, and this is the correction that matters most. Meetecho ships them as external Node.js servers, janus-whip-server and janus-whep-server, both at v1.1.0 as of February 2026 and both ISC-licensed, so they do not inherit Janus's GPLv3. They were prototypes once; they were refactored into proper npm libraries in April 2025 and that caveat is now out of date. Remember the mode-2-only constraint from earlier.

Pion is a pure-Go WebRTC implementation, MIT, around 17,000 stars, active this week, with a first-party WHIP and WHEP example in the main repository. Correcting ourselves again: Pion did not come from the ion-sfu team. It is the other way round. ion-sfu is built on Pion by different developers, as its own go.mod shows, and Sean DuBois has said publicly he had nothing to do with it. Do not deploy ion-sfu in 2026 either way; its last activity was November 2021.

mediasoup has no first-party WHIP or WHEP, and that is deliberate rather than a gap. Its stated design goal is to be signalling agnostic, and a maintainer closed the WHIP request with "it is a low-level library, as such for WHIP/WHEP you need to write an app on top". There is no maintained general-purpose mediasoup WHIP gateway; the repository name search returns nothing and mediasoup-broadcaster, which several guides cite, contains zero WHIP code and last changed in December 2021. While we are correcting the record: Discord does not use mediasoup. Discord wrote its own SFU in C++ and, as of June 2026, runs a Rust rewrite on Cloudflare carrying over 80% of its voice and video traffic.

OvenMediaEngine takes WHIP in and does not speak WHEP at all. Its source tree has a whip module and no whep module anywhere, and its own docs describe playback as a "Self-Defined Signaling Protocol". That is the exact inverse of what you want WHEP for. Two other things to price in: AirenSoft renamed itself OvenMedia Labs in January 2026, and in June 2026 it announced hardware acceleration is moving out of the open-source build into Enterprise. It is AGPL-3.0-only with an active compliance-notice programme.

Reference architecture for production

Most production stacks we build are not "all WebRTC" or "all HLS". They are one ingest with two delivery tiers, because the audience is not homogeneous and neither is the economics.

Figure 5. One ingest, one SFU mesh, two delivery tiers. The optional fork exists only if you need DVR, ABR, DRM or smart TVs.

Encoder. OBS 30+ or FFmpeg 8.0 for software, Teradek Prism or Kiloview for hardware. One URL, one bearer token, no SDK.

WHIP gateway. A stateless HTTP service that validates the token, applies rate limits, pins the SDP so a contributor cannot negotiate a codec your players lack, and forwards to the SFU. We usually write this in Go or Node behind nginx. Overhead is single-digit milliseconds.

SFU mesh. Where the broadcast actually lives, forwarding RTP without re-encoding. One origin per broadcast, edges near the viewers, RTP relayed between them. For anything above a few thousand concurrent viewers, read our note on scaling to a million viewers before you size this.

The fork. An FFmpeg process pulls RTP off the SFU and produces an LL-HLS ladder for the cost-sensitive tail, DVR and VOD. Note the one vendor where you cannot do this: Cloudflare Stream forbids mixing, so a WHIP input cannot also serve HLS on the same live input. That restriction has surprised two clients of ours.

Cost model, arithmetic shown

Take a live tier delivering 1,050,000 viewer-minutes a month, which is roughly 12,000 peak concurrent viewers watching an average of 38 minutes across 14 hours of live windows a week. Here is the arithmetic on both sides, with 2026 prices.

Managed, on Cloudflare Stream. Delivery is $1 per 1,000 minutes, so 1,050,000 ÷ 1,000 × $1 = $1,050 a month. Add 30-day DVR retention at $5 per 1,000 minutes stored; a library of 240 live hours is 14,400 minutes, so 14,400 ÷ 1,000 × $5 = $72. Total roughly $1,122 a month with nothing to operate. Ingest and encoding are free.

Managed, on AWS IVS Real-Time. Billing is participant-hours, not minutes delivered. 1,050,000 minutes is 17,500 participant-hours. First 10,000 at $0.0720 = $720; the next 7,500 at $0.0660 = $495. Total $1,215 a month, plus composition if you need it. Close to Cloudflare, and you give up WHEP.

Self-hosted, on Hetzner. This is where our old numbers broke. Hetzner raised prices on 15 June 2026: an AX102 is now €257.30 a month net plus €129 setup, up from roughly €105 in prior years. Two SFU nodes at €257.30 = €514.60. Add one TURN node at about €100 and a 0.2 FTE operations share at roughly $2,400. Call it $3,050 a month all in, and note that traffic on the 1 Gbit/s port is unlimited, which is the entire reason anyone puts up with the Falkenstein-or-Helsinki constraint.

Figure 6. The crossover sits near 3 million delivered minutes a month. Below it, managed wins on total cost including your time.

So the crossover is around 3 million delivered minutes a month, not the 4 million we previously published, and the reason it moved is Hetzner's price increase rather than anything about the protocols. At 1.05 million minutes, managed wins by roughly 2.7 times. Run the same arithmetic with your own numbers before you believe ours.

One number that dwarfs all of this if you get it wrong: egress. A saturated 1 Gbit/s port moves about 324 TB a month. That same 324 TB out of AWS EC2 in us-east-1, at $0.090 per GB for the first tier, is roughly $29,400 a month. Against €257.30 with zero traffic charges. If you self-host WebRTC on a hyperscaler without a negotiated egress rate, the servers are a rounding error and the bandwidth is the whole bill.

And budget for TURN separately. Roughly 15–20% of sessions cannot establish a direct path and fall back to relay, and one relayed 1080p stream costs 2–4 Mbps in each direction on your TURN node. On a 12,000 viewer peak that is 1,800 to 2,400 relayed sessions. TURN is not a rounding error either.

Where WebRTC stops paying

WebRTC delivery scales linearly with viewers. HLS amortises across CDN caches. That single difference sets the ceiling.

An HLS segment requested by the ten-thousandth viewer is usually already in an edge cache, so it costs a cache hit. A WHEP session for the ten-thousandth viewer is a new peer connection with its own encrypted RTP flow, its own congestion control and its own slice of SFU CPU. Nothing about the ten-thousandth is cheaper than the first. The commonly cited break-even for a passive audience sits somewhere around 5,000 to 10,000 concurrent viewers, and we would treat that as an order of magnitude rather than a threshold.

This is why almost every large deployment we have seen ends up hybrid: WHEP for the tier that needs to interact, LL-HLS for the tier that just watches — the topology we break down stage by stage in our low latency live streaming playbook. It is also why ByteDance's SIGCOMM paper is worth reading even though Douyin is nothing like your product. They cut latency by half at planetary scale and daily viewing time went down 1.28%. Lower latency is not automatically a better product; it is a better product only where something in the experience was breaking because of the delay.

The honest test: name the moment in your product that breaks at two seconds. A bet placed after the goal. A bid that arrives too late. A tutor answering a question. A buy button on a live sale. If you can name it, the WebRTC tier pays for itself for the users who touch that moment. If you cannot, you are buying latency you will not monetise.

Is Media over QUIC the end

No, but it is the reason to keep your architecture forkable. This is the question every technical buyer asks and no ranking article answers, so here is our read.

Media over QUIC is an IETF effort to build media transport directly on QUIC, with the aim of getting CDN-style fan-out and WebRTC-style latency in one protocol. The momentum is real: Shaka Player shipped MoQT draft-16 in July 2026, MediaMTX bridges MoQ today, Ant Media added a MoQ plugin in May 2026, and Red5 has a MoQ beta for enterprise customers. Meetecho and webrtcHacks have both been publishing about it through 2025 and 2026.

It is also years from being something you can buy. The transport drafts are still moving, browser support is experimental, and there is no equivalent of the OBS-ships-it-natively moment that made WHIP practical. WHIP is a published RFC with an encoder ecosystem shipping today. MoQ is a bet on 2028.

Our position, and it is a position rather than a hedge: ship WHIP now, keep your SFU boundary clean, and do not sign anything longer than three years with a vendor whose entire value is proprietary signalling. If MoQ lands the way its proponents expect, the piece you will replace is the transport under your SFU, not your ingest contract or your product. That is a survivable migration. Building your product logic into a vendor SDK is not.

Mini case: Worldcast Live

Worldcast Live streams HD concerts, and the brief was the hard version of this problem: performers in different cities playing together in real time, in front of a paying audience, with full-duplex audio. A five-second delay does not degrade that product. It makes it impossible.

What we built. A custom WebRTC and Kurento architecture rather than an RTMP chain, with five audio channels, 1.5 Gb/s for genuine HD, and dynamic quality adjustment so a viewer on a poor connection degrades instead of stalling. On top of that, a white-label Multiple Venue Streaming plugin that syncs one live stream across several websites at once, plus pay-per-view ticketing and donations so the platform could actually charge for what it delivered.

The outcome. Sub-second latency at 0.4–0.5 s, sustained across 10,000 simultaneous viewers. That was one of the first deployments to hold sub-second at that concurrency, and it is the number that made remote performers playing together viable at all.

One honest caveat, since this article is about WHIP: Worldcast Live predates WHIP, so its signalling is custom rather than standards-based. If we built it today we would use WHIP for ingest and keep the same SFU design, and we would spend the time we saved on signalling glue somewhere more useful. Want a similar assessment of your stack? Book a 30-minute call and we will sketch it.

A five-week migration plan

When the existing stack is simple, one ingest and one viewer surface with no betting or commerce overlay constraints, migration compresses to about five weeks. Longer if you are also replacing hardware.

The single most valuable hour in that plan is the week-one audit of who else consumes your RTMP origin. We have watched a cutover go perfectly and take the ad-insertion pipeline down with it, because nobody had a list.

Five questions to decide

Q1. Name the feature that breaks above two seconds. Live betting, auctions, a two-way telehealth visit, classroom question and answer, a synced fan overlay, a live-sale buy button. If you can name it and point at the revenue attached, WHIP and WHEP are justified. If you cannot name it, stop here and spend the money on your player buffer instead; ByteDance's numbers suggest you will get more from that.

Q2. What is on the encoder side? OBS 30+, FFmpeg 8.0, GStreamer 1.24+, Teradek Prism, Kiloview, Haivision Makito X4, Videon or Osprey means you start on Monday. AJA, Magewell, Blackmagic or Teradek VidiU means you either replace hardware or run a local RTMP-to-WHIP bridge. Check the actual firmware release notes, not the product page.

Q3. Who owns the playback surface? Your own web app means a WHEP client is a day of work. A third-party player, a smart-TV app or an OEM surface means WHEP is not available to you and you are looking at a vendor SDK or an HLS fork. There is no commercial player with generic WHEP support, and none is coming.

Q4. What is the volume? Under about 3 million delivered minutes a month, managed wins on total cost once you price your own engineers honestly. Above that, self-hosted wins, provided you have someone who can carry an on-call rotation for a media server. That last clause is the real gate, not the arithmetic.

Q5. What are the compliance constraints? HIPAA, GDPR residency, FedRAMP or a contractual on-premise clause pushes you to self-hosted inside your own VPC. Managed vendors do offer enterprise tiers with a BAA and regional residency, but the price step is steep enough to change the answer to Q4. Our HIPAA-compliant video platform guide covers the architecture in detail.

If four of five point the same way, that is your answer. If they split, the split is usually between Q1 and Q4, and the resolution is almost always hybrid rather than a compromise on either.

Pitfalls to avoid

1. Believing a WHEP compliance claim without a revision number. Covered above, and it is still the one that costs the most. Two vendors can both be honestly "WHEP compliant" against drafts that do not interoperate. Get the revision and the offer mode in writing.

2. Under-provisioning TURN. Symmetric NAT on mobile carriers and enterprise firewalls means 15–20% of viewers cannot establish a direct path. One node in one region gives you a single point of failure and a bandwidth bill nobody forecast. Run TURN in at least three regions, on port 443 over TCP as well as UDP, and budget relay bandwidth at 30–40% of your delivery total.

3. Letting the encoder pick the codec. WHIP negotiates whatever both ends support. OBS can now offer AV1 and H.265; FFmpeg may choose something your Safari viewers cannot decode. H.265 over WebRTC works in Chrome 136+ and Safari 18+ and not at all in Firefox or Edge. Pin the SDP in your gateway and stop thinking about it.

4. Assuming the archive is as good as the stream. WebRTC discards late data by design, which is exactly what you want live and exactly what you do not want in a recording. If archive quality matters more than live latency for some of your content, keep an RTMP or SRT path for that content. webrtcHacks made this point in 2023 and it is still the trade-off people discover after the fact.

5. Buying a WHIP-shaped door. Some vendors expose a WHIP endpoint and then require their own SDK for low-latency playback. That is a managed service wearing a standard as a hat. Test the WHEP path and the open-source playback options before signing anything multi-year, and check whether ingest and egress are contractually coupled the way Cloudflare's are.

KPIs to measure

Quality KPIs. Glass-to-glass at p50 and p95, measured with a burnt-in timestamp and a camera rather than network timing. Target p50 under 1.0 s and p95 under 1.5 s through a CDN; be sceptical of anyone promising better without showing their method. First-frame time on viewer join under 800 ms. Freeze rate, the share of seconds where playback paused, under 0.3%.

Business KPIs. Average view duration, but read it against ByteDance's warning that latency reduction can move it the wrong way. Drop-off in the first 30 seconds after join, which is the cleanest proxy for "does this stream look alive"; a healthy WHEP path lands at 2–3%. For betting or commerce, in-play conversion rate is the only metric that tells you whether the latency spend paid for itself.

Reliability KPIs. WHIP gateway uptime at 99.95%. SFU peak-hour CPU and bandwidth headroom below 70%. TURN utilisation below 60%, so a symmetric-NAT spike has somewhere to go. Mean time to recovery on encoder reconnect under three seconds, measured from lost connection to viewers seeing frames again, not from the reconnect log line.

When NOT to use WHIP and WHEP

Linear OTT and VOD libraries. If the dominant behaviour is "watch this 45-minute episode whenever", nobody cares that the stream started ten seconds ago. HLS through a normal CDN stays cheaper, simpler and more cacheable. WHIP can still help on the contribution leg without touching the viewer side.

Large passive audiences with near-zero ARPU. Free-to-watch, ad-supported, millions of viewers: the per-viewer cost of WebRTC delivery is a multiple of HLS through a CDN, and the interactivity benefit is not being sold to anyone. Hybrid is the answer, with WHEP reserved for subscribers.

Smart-TV-first audiences. Older sets have no WebRTC playback and no WHEP client. If most of your viewing is Roku, legacy Fire TV, LG WebOS before 2022 or Samsung Tizen before 2023, keep LL-HLS. There is no clever way around this one.

Anywhere DRM or a full ABR ladder is contractual. WHEP has no DRM story and no manifest for a ladder. If a studio deal requires Widevine or PlayReady, that content goes through the packager, full stop.

4K HDR contribution over satellite or a bonded field link. SRT plus a downstream packager is the safer pick. WebRTC congestion control was not designed for multi-megabit fixed-rate contribution; SRT's retransmission behaviour is more predictable for that profile. Use both: SRT into a regional hub, WHIP from the hub into the SFU.

FAQ

What is the difference between WHIP and WHEP?

WHIP is ingest, moving a stream from a publisher into a media server. WHEP is egress, moving a stream from a media server out to a viewer. Both use one HTTP POST carrying an SDP offer. WHIP is always client-offers; WHEP allows client-offers and server-offers, which is a real interop hazard.

Are WHIP and WHEP official standards?

WHIP is: RFC 9725, IETF Standards Track, published March 2025. WHEP is not: it is draft-ietf-wish-whep-04, revised 22 June 2026, in Working Group Last Call, expiring 24 December 2026. Most articles you will find call both of them drafts, which has been wrong for over a year.

Does WHIP make my stream lower-latency?

No. WHIP and WHEP are signalling only. Media latency comes from WebRTC. What they cut is connection setup time, roughly one HTTP round trip instead of a WebSocket handshake plus multi-step negotiation, and the integration cost of a proprietary SDK.

Does OBS support WHIP?

Yes, natively since OBS Studio 30.0.0 in November 2023. Set Service to WHIP, enter the server URL, and put your stream key in the Bearer Token field. Simulcast with one to four layers arrived in OBS 32.1.0 in March 2026. OBS has no WHEP playback. On Ubuntu 24.04 use the Flatpak, because the PPA build omits WHIP.

Can I stream to YouTube or Twitch using WHIP?

Not as a general creator. YouTube ingests only RTMP, RTMPS, HLS and DASH as of June 2026. Twitch documents RTMP and RTMPS only, though it has run an undocumented experimental WHIP endpoint since April 2023. Plan a parallel RTMP path for platform distribution.

Which codecs work over WHIP and WHEP?

That depends on the server, not the protocol, which mandates none. H.264 plus Opus is the safe universal baseline. Cloudflare Stream accepts VP9, VP8 and H.264 Constrained Baseline 3.1 only. AWS IVS requires H.264 Baseline with no B-frames. H.265 over WebRTC works in Chrome 136+ and Safari 18+ and not in Firefox or Edge.

Do I need a TURN server?

In production, almost always. STUN alone succeeds in roughly 80–85% of network conditions. The remaining 15–20%, mostly symmetric NAT on mobile carriers plus enterprise firewalls and VPNs, need a relay. Budget 2–4 Mbps in each direction per relayed 1080p session.

Does WebRTC delivery scale to large audiences?

Technically yes through cascaded SFUs, economically not past a point. WebRTC costs scale linearly with viewers while HLS amortises across CDN caches. The common break-even for a passive audience sits around 5,000 to 10,000 concurrent viewers, above which most production stacks go hybrid.

Can I ingest with WHIP and play back with HLS?

On most media servers yes, including MediaMTX, Wowza, Ant Media and OvenMediaEngine. On Cloudflare Stream no: its docs state that WHIP and WHEP must be used together, so you cannot ingest WHIP and deliver HLS on the same live input. Check this before you pick a vendor, not after.

Why will my OBS WHIP stream not connect?

The most common causes, in order: a self-signed TLS certificate, which OBS refuses with no override; a wrong or missing bearer token; a server that needs TURN which is not configured; and Linux packaging on Ubuntu 24.04. Intermittent freezing is usually uplink instability rather than the protocol.

How does WHIP compare to SRT?

Different jobs. SRT is a contribution protocol for moving a signal across a lossy network with a tunable buffer and retransmission. WHIP is an ingest protocol for getting a signal into a WebRTC media server with sub-second delivery. Many stacks use both: SRT into a regional hub, then WHIP into the SFU.

How much does a WHIP migration cost?

For a single-ingest stack on managed infrastructure, budget five to seven weeks of one senior WebRTC engineer plus design and operations review. For a self-hosted MediaMTX or Janus deployment, eight to twelve weeks plus an SRE for monitoring and TURN. Infrastructure costs are in the cost model section above.

What to Read Next

Ready to retire RTMP

RTMP took live streaming from a 30-second floor to a five-second floor and it is still, in 2026, the only way into YouTube and Twitch. It is not deprecated and it is not going away. What changed is that there is now a published standard, RFC 9725, for getting a stream into a WebRTC media server without a vendor SDK, and an encoder ecosystem that ships it: OBS since 2023, FFmpeg since 2025, GStreamer, Teradek Prism, Kiloview, Haivision.

The honest version of the pitch is narrower than the marketing version. You are buying 0.6 to 1.3 seconds instead of 5 to 30, at a delivery cost that scales linearly with viewers, in exchange for writing your own player and asking two vendors a hard question about WHEP offer modes. Where you have a moment that breaks at two seconds, that trade is obviously worth it. Where you do not, it is a tax.

If you can name the moment, the migration is five weeks and the decision is really just managed versus self-hosted at your volume. We build these for a living and we are happy to argue with your numbers. If you want the wider engineering context first, our Learn deep dive on WHEP egress goes further into the spec, and our custom development team is who you would actually be working with.