WHIP & WHEP: Replace RTMP in Your Streaming Stack (2026)

Why Fora Soft wrote this playbook

Fora Soft has shipped 625+ projects since 2005, and roughly 200 of them carried live or interactive video. That includes StreamLayer (interactive sports streaming used by NBC, CBS, Red Bull, Chelsea FC and Sony Music), EyeBuild (solar-powered AI surveillance with 4G/5G ingest), WorldCastLive, Mangomolo, and Tradecaster.

In the last twelve months we have migrated four production stacks off RTMP onto WHIP/WHEP, including a sports broadcaster cutting glass-to-glass latency from 6.2 s to 380 ms, and an event platform replacing a fragile RTMP→HLS→LL-HLS chain with a single mediasoup tier. The numbers, decisions and trade-offs in this article come from those projects, not from a vendor brochure.

If your encoder still pushes RTMP and your viewers still tolerate 5–30 s lag, this guide tells you what is now possible, what it costs, and how to migrate without burning your existing infrastructure.

Why RTMP is dying in 2026

RTMP — Real-Time Messaging Protocol — was built by Macromedia for Flash Player in 2002. Adobe stopped maintaining it in 2012. Flash itself was end-of-lifed in December 2020. Yet RTMP survived as the de-facto ingest standard because OBS Studio, FFmpeg, GStreamer and every hardware encoder in the world spoke it. There was no replacement.

Three things have changed since 2024:

1. The interactivity bar moved. Sports streaming, live commerce, online auctions, fan engagement and AI-powered chat overlays all need round-trip latency under one second. RTMP→HLS pipelines deliver 5–30 seconds. Even LL-HLS, the “low latency” HLS variant, sits at 3–7 seconds. StreamLayer’s data shows interactive viewers stay 33 % longer; you cannot offer interactivity if your latency floor is 6 seconds.

2. RFC 9725 finalised the alternative. WHIP — the WebRTC-HTTP Ingestion Protocol — was published as a Standards Track RFC in March 2025. It is no longer a draft. Vendors can implement it knowing the spec is frozen, and OBS Studio added native support in version 30, which means the encoder side of the equation is solved.

3. CDNs adopted it. Cloudflare Stream, AWS IVS Real-Time, Dolby OptiView, Red5 Cloud, Ant Media Server, Mux, Wowza, Millicast and Eyevinn’s open-source toolkit all now expose WHIP endpoints. Five years ago this was a research protocol. Today it is a vendor checklist item.

RTMP will not die overnight — it still works, and your downstream HLS chain still cares about how the bytes arrived. But the path forward for any interactive use case is WHIP for ingest, WHEP for playback, and a familiar HLS/DASH fallback for the cost-sensitive long tail.

What WHIP actually is — RFC 9725 in plain English

A WHIP session is one HTTP exchange followed by media on a WebRTC peer connection. There is no WebSocket, no MQTT, no proprietary signalling SDK. The encoder sends a plain HTTP POST with an SDP offer in the body and a bearer token in the Authorization header. The server responds with HTTP 201 Created, an SDP answer, and a session URL. After that, RTP packets flow over WebRTC transport (DTLS-SRTP).

In raw terms, the handshake looks like this:

POST /whip/live/streamkey 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
s=-
... (SDP offer)

---

HTTP/1.1 201 Created
Location: /whip/live/streamkey/abc123
Content-Type: application/sdp

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

---

DELETE /whip/live/streamkey/abc123 HTTP/1.1   # to terminate
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Three things make this important.

1. It is just HTTP. Any reverse proxy, load balancer, WAF, CDN, or edge function can sit in front of WHIP. You authenticate using whatever scheme your stack already supports — OAuth bearer tokens, mTLS, signed URLs. RTMP requires a separate publish-server appliance; WHIP fits the rest of your HTTP infrastructure.

2. The transport is WebRTC. Once the handshake finishes, you get NAT traversal via ICE/STUN/TURN, end-to-end SRTP encryption, congestion control via Google Congestion Control or NADA, and packet retransmission via NACK and FEC — all the modern transport features that RTMP had to bolt on through proprietary SRT or WebRTC tunnels.

3. It is encoder-agnostic. OBS 30 ships with native WHIP. FFmpeg has the whip muxer in its 7.x branch. GStreamer’s webrtcsink + whipclientsink both work. Hardware encoders from AJA, Magewell, BlackMagic and TeradECK have shipped firmware updates with WHIP. You no longer need a vendor SDK to push to a media server.

What WHEP is — the egress twin

WHEP — WebRTC-HTTP Egress Protocol — is the playback complement. The viewer sends a POST with their SDP offer to a WHEP endpoint, gets an SDP answer back, and a media stream flows over WebRTC. From a player’s perspective, it is the same simplicity that WHIP brings to the encoder.

Where WHIP is now an RFC, WHEP is still an IETF Internet-Draft — but the spec is stable, and Cloudflare Stream, OvenMediaEngine, AWS IVS, Dolby OptiView and most managed vendors implement it interoperably. We use WHEP in production today; we treat it as “done” for engineering purposes even though the official ratification ribbon is not on it yet.

WHEP gives you sub-second playback — under 1 s end-to-end on a tuned deployment — to an unlimited number of viewers if you fan out through an SFU mesh. The classic objection — “WebRTC does not scale past a few hundred viewers” — is no longer true with origin-shield SFU topologies and CDN-grade WHEP origins (Cloudflare reports unlimited concurrent viewers on their Stream WebRTC offering).

Latency benchmark — RTMP vs LL-HLS vs WHIP

Glass-to-glass latency is the only measurement that matters. We instrument it by overlaying a high-precision timestamp on the source frame, capturing the rendered viewer frame, and measuring the delta. Numbers below are from our 2025-2026 production deployments, sampled across 14 days, multiple regions, and three different encoder profiles. They align with the public benchmarks from Cloudflare and Streaming Media Magazine.

The 200–500 ms range covers everything from the encoder’s last frame buffer to the viewer’s display. About 80–120 ms goes to encode + WebRTC pacing, 30–60 ms to network, 30–100 ms to SFU forwarding, and the rest to decode + display. If you tune the GOP (1 s for live mode), prefer hardware-accelerated H.264 baseline, and run an SFU geographically near the viewer, the lower bound holds reliably.

For comparison, WebRTC native peer-to-peer (no SFU, no WHIP envelope) hits roughly the same 0.2–0.5 s — meaning WHIP/WHEP add no measurable latency over a handcrafted WebRTC stack while removing the entire signalling-layer complexity.

Reference architecture — what production looks like

A production WHIP/WHEP deployment has five horizontal layers: encoder, ingest gateway, SFU mesh, packaging fork, and viewer. Each box has a single job, and most failure modes live at the boundaries.

The five layers in detail

1. Encoder. OBS Studio 30+ for desktop creators, FFmpeg 7+ for headless workflows, hardware encoders from AJA, Magewell, BlackMagic, TeradECK or Haivision for studios. The encoder pushes WHIP to a single configured URL with a bearer token. There is no TCP keep-alive nightmare and no Flash-era handshake.

2. WHIP gateway. A thin HTTP service that authenticates the bearer token, applies rate limits, optionally rewrites the SDP (for example, to force VP8/H.264 codec parameters), and forwards the SDP offer to the SFU. We typically run this as a stateless Go or Node service behind nginx; latency overhead is single-digit milliseconds.

3. SFU mesh. The Selective Forwarding Unit is where the broadcast actually lives — it forwards RTP packets from the publisher to all subscribers without re-encoding. mediasoup, LiveKit, Janus, Jitsi, Ant Media, Pion-based custom builds, all viable. For interactive sports streaming or any >1k concurrent broadcast, we deploy SFUs in a mesh: one origin SFU per broadcast, edge SFUs in the user’s region, RTP relayed between them.

4. Packaging fork. Most production deployments do not pick “all WHEP” or “all HLS.” They run an optional FFmpeg-based transcoder pulling RTP off the SFU and producing a 3–5 s LL-HLS ABR ladder for the cost-sensitive long tail of viewers, while interactive viewers get WHEP. DVR / VOD comes off the same fork.

5. Viewer. Browsers (Chrome, Edge, Safari, Firefox) play WHEP natively through any of the open-source clients (Eyevinn’s WHIP/WHEP toolkit, the LiveKit JS SDK, Cloudflare’s reference player). iOS and Android use the platform’s WebRTC stack. Smart TVs use a hybrid of HLS for traditional STBs and WebView-based WebRTC for newer Android TV / WebOS panels.

Vendor matrix — who supports WHIP/WHEP today

As of May 2026, every major media vendor and CDN supports WHIP for ingest. WHEP coverage is slightly thinner because a number of vendors still ship proprietary WebRTC SDKs for playback alongside the open WHEP endpoint — but interoperability is good enough that you can mix and match.

A note on AWS IVS Real-Time: WHIP is officially supported for ingest, but for playback Amazon still leans on its proprietary IVS Player SDK. The WHEP endpoint is available but considered a secondary path. If your client is the IVS Player JavaScript SDK or iOS/Android SDK, you get the same low latency without touching WHEP directly.

Self-hosted: mediasoup, Janus, Eyevinn, LiveKit

Self-hosting is the right call when you cross roughly 10–15 k WebRTC minutes per month, or when you have compliance constraints (HIPAA, GDPR data residency) that managed CDNs cannot satisfy without expensive enterprise tiers. Below is the shortlist we recommend in 2026.

mediasoup. A C++ SFU with a Node.js control plane. Battle-tested, used in production by Discord, Mozilla Hubs and several Fora Soft clients. WHIP/WHEP support comes via the official mediasoup-broadcaster companion or third-party gateway services. Small operational footprint; brutal performance.

LiveKit (open source). Self-hosted LiveKit gives you the same SFU as LiveKit Cloud minus the monthly bill. Native Ingress (WHIP) and Egress (WHEP) endpoints. Same SDKs as the cloud version. Operationally heavier than mediasoup — you run a Redis-backed control plane, room servers and TURN relays — but it ships out of the box with AI-agent integrations, which matters if you intend to add voice AI later. Our LiveKit AI agents playbook covers that follow-on path.

Janus Gateway. The veteran. C-based, plug-in architecture, WHIP plug-in is mature. Janus shines when you need exotic behaviour (multi-tenant routing rules, custom RTP rewriting, SIP gateway) but the operational model is more involved than mediasoup.

Eyevinn open-source toolkit. A reference WHIP server, WHIP client, WHEP server and WHEP player, all Apache-licensed. We use it for proof-of-concepts and for stitching custom routing on top of an existing SFU. Not designed for production scale on its own, but invaluable for testing and for teams who want to learn the spec hands-on.

Pion. A pure-Go WebRTC stack from the team behind ION-SFU. Strong choice when your ops team prefers Go binaries to managing a Node/C++ control plane, and when you want sub-millisecond control over RTP rewriting.

Cost model — managed vs self-hosted at scale

Here is the math from a real 2025 deployment we shipped: a sports broadcaster with peak concurrency around 12 000 viewers, average watch time 38 minutes, and 14 hours per week of live windows. Total monthly delivered viewer-minutes: roughly 1 050 000.

Managed scenario (Cloudflare Stream): at $0.001 per minute delivered, 1.05 M minutes × $0.001 ≈ $1 050 / month for delivery. Add 2 TB of storage at $5 per 1 000 minutes stored (assume 30-day DVR retention), roughly $200 / month. Total: ~$1 250 / month, no infra to manage. Below 1 M minutes, this is the cheapest option.

Self-hosted scenario (mediasoup on Hetzner AX): three regional SFUs (US East, EU Central, APAC) each on AX102 servers ($230 / month per node), two TURN relays ($90 / month each), one transcoder for ABR fallback ($230 / month), one control-plane node ($90 / month). Hetzner egress is included to 20 TB / month per node. Hardware cost: about $1 240 / month. Add 0.3 senior engineer for operations: ~$3 500 / month at typical full-loaded cost. Total: roughly $4 700 / month at this scale.

Cross-over point. For this concurrent-viewer pattern, managed wins until you exceed about 4 M delivered minutes per month — which corresponds to roughly 50 k peak concurrent viewers on a single 1.5-hour event. Above that, the per-minute pricing of managed CDNs starts to dominate, and self-hosted infrastructure with depreciated engineering effort wins by a factor of 2 to 4.

There is a third option: hybrid. Run self-hosted SFUs for the “known load” portion of your audience — the daily news feed, the recurring classroom — and fall over to a managed WHIP/WHEP service like Cloudflare Stream for unpredictable spikes (a flash sale, a viral moment, a sports playoff). We have shipped this pattern for two clients in 2025; it caps the worst-case cost without requiring you to over-provision SFUs.

Mini case — from RTMP to WHIP in 12 weeks

A regional sports broadcaster came to us in October 2024 with a familiar problem. Their RTMP→HLS pipeline gave viewers a 6.2 s lag, which destroyed the integrity of their live betting product — viewers were placing bets on plays the home audience had already seen. Re-platforming was off the table; they had a contract with their incumbent streaming SaaS that ran another 18 months.

The 12-week plan. Weeks 1–2 we instrumented the existing RTMP path with timestamp overlays and logged glass-to-glass at p50 and p95 across four regions. Median was 6.2 s, p95 was 9.4 s. Weeks 3–5 we deployed a parallel WHIP gateway in front of a self-hosted mediasoup SFU on Hetzner AX102, leaving the legacy RTMP path untouched. Weeks 6–8 the broadcaster shifted 5 % of traffic to the new path through their feature flag system; we monitored for stability and tuned the GOP, jitter buffer and TURN relay distribution. Weeks 9–11 we rolled to 25 %, then 60 %, then 100 %. Week 12 was rollback rehearsal and on-call training.

Outcome. Median glass-to-glass dropped from 6.2 s to 380 ms. p95 dropped from 9.4 s to 720 ms. Live-betting hold rate (the percentage of bets placed during the in-play window) increased 19 %. The viewer drop-off in the first 30 seconds of stream join — a metric that tracks “is this stream alive?” perception — dropped from 11 % to 3 %. Want a similar assessment? Book a 30-minute call and we will sketch the equivalent plan for your stack.

5-week migration plan

When the existing stack is simpler — one ingest, one viewer surface, no betting / commerce overlay constraints — the migration compresses to about five weeks. Here is the canonical week-by-week.

A decision framework — pick WHIP in five questions

Q1. Does any user-visible feature break above 2 s of latency? Live betting, online auctions, telehealth two-way visit, classroom Q&A, in-stream chat synced to a play, fan reactions on a sports overlay — all break. If you have one of these, WHIP is mandatory, not optional.

Q2. What is the encoder side? If your contributors are on OBS, FFmpeg, or hardware encoders from AJA/Magewell/BlackMagic, WHIP works today, no SDK install. If they are on legacy proprietary apps with custom RTMP firmware, plan an encoder upgrade in parallel.

Q3. What is the viewer side? Browsers and mobile WebViews handle WHEP natively. Smart-TV STBs and older Connected-TV apps may still require an HLS fork. If your audience is 70 %+ smart-TV, you will keep an HLS path either way; WHIP still helps you compress the broadcast pipeline upstream.

Q4. What is the volume? Below 100 k delivered minutes/month, managed (Cloudflare/AWS IVS/Mux) wins on total cost. 100 k–4 M minutes/month, managed still wins because of unloaded engineering cost. Above 4 M, self-hosting starts to dominate.

Q5. What are the compliance constraints? HIPAA, GDPR data residency, FedRAMP, or strict on-premise contractual clauses change the answer. Self-hosted in your VPC with mediasoup or LiveKit OSS is the easiest path. Several managed vendors offer enterprise tiers with BAA + EU residency, but the price step is substantial — budget 3× the standard rate.

Pitfalls to avoid

1. TURN under-provisioning. Symmetric NAT on mobile carriers means a non-trivial percentage of viewers cannot establish a peer-to-peer ICE candidate. They fall back to TURN relay. If your TURN cluster is one node in one region, you have a single point of failure and a massive bandwidth bill. Run TURN in at least three regions and budget bandwidth at 30–40 % of your delivery total.

2. Codec negotiation surprises. WHIP allows the encoder and server to negotiate any codec they both support. OBS defaults to H.264 baseline, which is fine. FFmpeg may pick H.265 or VP9 if you do not pin the SDP. The client side sometimes does not support the negotiated codec, especially on older Safari builds. Always pin the SDP offer in your gateway.

3. Forgotten downstream consumers. RTMP often feeds more than the viewer player — downstream analytics, ad insertion (SCTE-35 markers), DVR archival, captioning services, social re-broadcasting. Audit every consumer of your RTMP origin before decommissioning, or you will discover the analytics dashboard went blank only after the cutover.

4. Bandwidth congestion control mis-tuning. WebRTC uses Google Congestion Control (GCC) by default. On a clean fibre link it works well; on a saturated mobile link, GCC can over-aggressively drop bitrate, leaving you with a 240p stream when 720p would have held. Tune the minimum encode bitrate floor and the BWE smoother window for your audience profile.

5. SDK lock-in by another name. Some “WHIP-compatible” vendors expose a WHIP endpoint but require their proprietary SDK on the player side to unlock low-latency mode. That is not the open standard; it is a managed service with a WHIP-shaped door. Audit the WHEP path and the available open-source playback options before signing a multi-year contract.

KPIs to measure

Quality KPIs. Glass-to-glass latency p50 (target: < 500 ms) and p95 (target: < 1.0 s). First-frame time on viewer join (target: < 800 ms). Freeze rate — percentage of seconds where playback paused (target: < 0.3 %). PSNR or VMAF score against the source frame, sampled every 30 seconds.

Business KPIs. Average view duration — expect a 10–30 % lift on interactive use cases when latency drops below 1 s. Drop-off in the first 30 seconds of stream join (target: < 4 %, a healthy WHEP path normally lands at 2–3 %). For betting / commerce: in-play conversion rate, which is the most direct indicator that latency is no longer breaking the buying decision.

Reliability KPIs. WHIP gateway uptime (target: 99.95 %). SFU peak-hour CPU and bandwidth headroom (target: < 70 % peak). TURN relay utilisation (target: < 60 % peak so you have headroom for symmetric-NAT spikes). Mean time to recovery on encoder reconnect (target: < 3 s; this is the time from encoder lost-connection to viewer back-on-stream).

When NOT to migrate

Linear-OTT replays and VOD libraries. If your dominant use case is “watch this 45-minute episode whenever you want,” your viewer does not care if the stream started 10 seconds ago or now. HLS plus a normal CDN remains cheaper, simpler and more cacheable than WHEP. WHIP can still help you on the contribution side — pulling content from the studio into your VOD pipeline — without changing the viewer side.

Hyper-cost-sensitive ad-supported broadcast. If your ARPU is near zero (free-to-watch, ad-supported, live news) and your audience is millions, the per-minute cost of WebRTC delivery exceeds HLS-via-CDN by roughly 2–5×. The interactivity benefits do not justify the bill. A hybrid — WHEP for premium subscribers, LL-HLS for free tier — is often the right answer.

Smart-TV-only audiences. Older smart-TVs do not support WebRTC playback. If your audience is 70 %+ Roku, Fire TV legacy, LG WebOS pre-2022 or Samsung Tizen pre-2023, keep the LL-HLS path. WHIP on the ingest side can still benefit you (better contribution latency upstream of the packager), but the viewer-side win evaporates.

Single-source contribution at extreme bitrate. If you are doing 4K HDR contribution from a remote field truck on satellite uplink, SRT plus a downstream packager is still the safer pick. WebRTC’s congestion control was not designed for multi-megabit fixed-rate contribution paths; SRT’s ARQ-based recovery is more predictable for that profile.

FAQ

What to Read Next

Ready to retire RTMP?

RTMP brought the live-streaming industry from a 30-second floor to a 5-second floor over twenty years. WHIP and WHEP take that floor below 500 ms in a 5-week project, with no proprietary SDK on the encoder side, no signalling layer to write, and no vendor lock-in unless you choose it. RFC 9725 made the migration safe to invest in; OBS Studio and the major CDNs made it cheap to start.

If your product has a moment that breaks at 2 s of latency — a bet, a bid, a buy, a question, a play — the upgrade is now strictly mandatory. The only remaining question is managed vs self-hosted, and that one resolves with five questions and a viewer-minutes spreadsheet.