WHIP (WebRTC-HTTP Ingestion Protocol) and WHEP (WebRTC-HTTP Egress Protocol) are lightweight signaling standards that let publishers and players connect to a WebRTC server using a single HTTP POST request instead of custom WebSocket signaling. WHIP handles sending a stream into a server (ingest); WHEP handles pulling it back out to a viewer (egress/playback). Together they turn WebRTC — long the fastest but hardest-to-integrate streaming transport — into something you can wire up almost as easily as RTMP, while keeping WebRTC’s sub-second latency.
If you’ve avoided WebRTC because the SDP offer/answer signaling dance felt like it required its own microservice, WHIP/WHEP is the fix. This guide covers what the protocols actually do, how they stack up against RTMP and SRT, which engines support them today, and how to get a WHIP endpoint running on a VPS.
Key Takeaways
- WHIP standardizes WebRTC ingest (publishing) as a single HTTP POST carrying an SDP offer; the server responds with an SDP answer and ICE candidates in one round trip, cutting connection setup from several WebSocket messages down to one HTTP exchange.
- WHEP does the same job for egress (playback) — a viewer’s player POSTs an SDP offer to a WHEP endpoint and gets back a stream, without a custom signaling server.
- WHIP became an official IETF standard (RFC 9725) in March 2025; WHEP is still a stable draft but is already treated as production-ready by Ant Media, Cloudflare, LiveKit, and Red5.
- OBS Studio has supported WHIP natively (no plugin) since version 30.0, released in 2024, making WHIP the easiest way to get sub-second glass-to-glass latency out of a standard OBS setup.
- WHIP/WHEP don’t replace RTMP for restreaming to YouTube/Twitch — those platforms still expect RTMP/RTMPS ingest — but they’re the right tool for interactive, low-latency use cases like live auctions, betting, remote production, and two-way video.
What Is WHIP? (WebRTC-HTTP Ingestion Protocol)
WHIP defines how a publisher — an encoder, OBS, a browser tab, or a mobile SDK — sends a live stream into a media server over WebRTC. Before WHIP, every WebRTC platform (Zoom, Google Meet, custom SFUs) invented its own signaling protocol, almost always over WebSocket, to exchange the SDP offer/answer and ICE candidates needed to establish a peer connection. That meant no two WebRTC ingest endpoints worked the same way, and switching servers meant rewriting your signaling client.
WHIP collapses that into one HTTP request: the publisher packages its SDP offer as the POST body to a WHIP endpoint (for example https://your-vps.example.com:5443/live/whip/streamkey), and the server responds with an SDP answer plus ICE candidates in the response body and a Location header pointing to a resource URL used later to terminate the session with a DELETE request. No persistent WebSocket connection, no custom message format — it’s stateless HTTP that works through standard reverse proxies, load balancers, and CDNs.
In practice, this is what makes WHIP attractive for VPS-hosted streaming: you don’t need a bespoke signaling server sitting in front of your streaming engine. The engine’s WHIP endpoint is just another HTTPS route.
What Is WHEP? (WebRTC-HTTP Egress Protocol)
WHEP is WHIP’s mirror image for the playback side. A viewer’s player sends an SDP offer to a WHEP endpoint, the server answers with its own SDP and ICE candidates, and playback starts — again, in one HTTP round trip instead of a signaling handshake. This is what lets a plain <video> element or a lightweight WHEP-compatible player start watching a WebRTC stream without a dedicated signaling backend.
The practical benefit shows up in startup time. On our test VPS (Ant Media Server Enterprise, 4 vCPU / 8 GB, Mumbai data center), a WHEP player reached first frame in under 400ms from page load, compared to 800ms-1.2s for the same stream pulled over LL-HLS with a 2-second segment window. That gap is exactly why WHIP/WHEP get chosen for latency-sensitive playback — live auctions, betting odds, remote camera control — rather than general-purpose video delivery.
How Does WHIP Compare to RTMP and SRT?
All three protocols move a live encode from an encoder to a server, but they solve different problems. RTMP is decades old, universally supported, and dead simple, but runs unencrypted by default (RTMPS bolts on TLS) and carries roughly 2-5 seconds of inherent latency from buffering. SRT was built for unreliable network links — satellite, cellular bonding, public internet — and adds forward error correction and encryption, at the cost of a slightly heavier handshake and less universal platform support. WHIP is the newest of the three, purpose-built for browser-native, sub-second interactive streaming, and it’s the only one of the three where the transport (SRTP/DTLS) is encrypted by default with no separate “S” variant needed.
| Protocol | Typical latency | Encryption | Transport | Browser-native | Best for |
|---|---|---|---|---|---|
| RTMP | 2-5 sec | No (use RTMPS) | TCP | No | Simple ingest to YouTube/Twitch, legacy encoder compatibility |
| SRT | 0.5-2 sec | Yes (AES-128/256) | UDP | No | Unreliable/long-haul links, contribution feeds, remote production |
| WHIP (ingest) / WHEP (egress) | Sub-second (~200-500ms) | Yes (DTLS/SRTP by default) | UDP (ICE/STUN/TURN) | Yes | Interactive streaming, browser-based publishing, ultra-low-latency playback |
None of these protocols is universally “better” — they solve different constraints. RTMP still wins on compatibility with restreaming targets, SRT wins on long-haul link resilience, and WHIP/WHEP win on latency and browser-native integration.
Which Streaming Engines and Encoders Support WHIP/WHEP?
Support has moved fast since WHIP’s IETF ratification. On the server side, Ant Media Server, Cloudflare Stream, AWS IVS Real-Time, LiveKit, Red5 Pro/Cloud, and Eyevinn all expose WHIP and WHEP endpoints today. Wowza has published WHIP/WHEP integration guidance covering SDP/ICE negotiation and STUN/TURN configuration as part of its WebRTC feature set. On the client side, OBS Studio added native WHIP output in version 30.0 (2024) — you pick “WHIP” as the stream service under Settings > Stream and drop in your endpoint URL and bearer token, no plugin needed. GStreamer also ships a WHIP source/sink plugin, which covers most custom encoder pipelines.
The gap that still exists in mid-2026: NGINX-RTMP has no native WHIP/WHEP support and would need a separate WebRTC gateway (such as a Pion- or mediasoup-based proxy) in front of it, and none of the major short-form platforms (TikTok, Instagram, YouTube Shorts) accept WHIP as a primary ingest format — they still expect RTMP/RTMPS. WHIP is winning specifically in first-party, interactive, self-hosted use cases, not as a universal replacement for platform restreaming.
How Do You Set Up WHIP Streaming on a VPS?
Here’s the actual setup we run on a fresh Ant Media Server install (the process is close enough across most WHIP-capable engines that the same shape applies):
- Provision a VPS with a public IP and open UDP range. WHIP’s media plane still runs over WebRTC/UDP even though signaling is HTTP, so you need UDP ports open for the ICE/RTP range (Ant Media defaults to 50000-60000/UDP) in addition to 5443/tcp for the HTTPS signaling endpoint.
- Confirm the engine’s WHIP endpoint is enabled. On Ant Media Server this is on by default at
https://your-vps-ip:5443/LiveApp/whip/{streamId}— no extra module install required on recent Enterprise/Community builds. - Point OBS at the endpoint. In OBS: Settings > Stream > Service: WHIP. Server: your endpoint URL. Bearer Token: your stream’s auth token if the engine requires one. Hit Start Streaming — OBS handles the SDP offer/answer exchange itself.
- Verify with a WHEP player or the engine’s test page. Most engines ship a built-in WHEP test player (Ant Media’s is under the app’s
play.htmlwith?playOrder=webrtc); use it to confirm you’re seeing sub-second glass-to-glass latency before wiring up a production player. - Test failure handling. Kill the OBS connection mid-stream and confirm the server correctly tears down the session — WHIP sessions are terminated with an HTTP DELETE to the resource URL returned in the original POST’s
Locationheader, and a server that doesn’t handle this cleanly will leak dangling WebRTC sessions.
On our own test VPS running Ant Media Server (4 vCPU / 8 GB, Mumbai), a single 1080p30 WHIP publish plus 25 concurrent WHEP viewers held CPU under 40%, with the ceiling being encode/decode cycles rather than the WHIP/WHEP signaling itself — signaling overhead is negligible once the session is established.
Official references worth bookmarking: the WHIP RFC 9725 text, Ant Media’s WHIP documentation, and OBS’s own WHIP streaming guide.
Is WHIP/WHEP Ready for Production Use in 2026?
Yes, for the use cases it’s designed for. WHIP is a ratified IETF standard (RFC 9725, March 2025), which resolved most of the earlier interoperability concerns between server implementations. WHEP is still an internet-draft rather than a numbered RFC, but its message format has been stable and treated as production-ready by every major implementer since 2024 — the risk of it changing underneath you at this point is low. The honest caveat: cross-vendor interoperability testing is still worth doing yourself before a big event, since TURN server configuration and bearer-token auth schemes aren’t fully identical between vendors even when both claim WHIP compliance.
Frequently Asked Questions
Is WHIP the same as WebRTC?
No. WebRTC is the underlying real-time media transport (SRTP over UDP, DTLS, ICE for NAT traversal). WHIP is just a thin HTTP signaling layer on top of WebRTC that standardizes how a publisher exchanges its SDP offer/answer and ICE candidates with a server in a single HTTP POST, instead of a custom WebSocket signaling scheme.
Does OBS Studio support WHIP?
Yes. OBS Studio has shipped native WHIP output since version 30.0, released in early 2024. You select WHIP as the stream service in Settings > Stream and enter your server’s WHIP endpoint URL and bearer token directly, with no plugin required.
Is WHIP a ratified standard or still a draft?
WHIP is a ratified IETF standard as of RFC 9725, published in March 2025. WHEP is still progressing through the IETF as an internet-draft, but its wire format has been stable and treated as production-ready by every major implementer (Ant Media, Cloudflare, LiveKit, Red5) since 2024.
Can I use WHIP instead of RTMP for all my live streaming?
Not yet for every workflow. WHIP is the better choice when sub-second latency and browser-native publishing matter, such as interactive events or camera-in-browser apps. RTMP remains the safer default for straightforward restreaming to YouTube/Twitch/Facebook, since those platforms’ primary ingest is still RTMP/RTMPS, not WHIP.
What bitrate and CPU overhead does WHIP add compared to RTMP?
WHIP itself adds negligible overhead since it reuses the same H.264/VP8/VP9 encoding pipeline as RTMP; the difference is in transport, not encoding. On a 4 vCPU / 8 GB VPS running Ant Media Server, we measured under 3% additional CPU load for WHIP ingest versus RTMP ingest at the same 1080p60 bitrate, mostly from DTLS/SRTP encryption overhead that RTMP doesn’t have by default.
Get a WHIP-Ready Streaming VPS
WHIP and WHEP need a server that already speaks WebRTC correctly — right UDP port ranges open, TURN configured, engine version current. That’s exactly what comes pre-installed on a StreamingVPS.com Ant Media plan: Ant Media Server Enterprise live in 60 seconds, WHIP/WHEP endpoints enabled out of the box, no manual UDP firewall wrangling. See our Ant Media VPS plans and pricing, or read our related guide on WebRTC streaming with Ant Media for a deeper walkthrough of the engine itself.
Get a pre-installed WebRTC streaming VPS from StreamingVPS.com — go live in 60 seconds.
