WARP stands for WebRTC Abridged Roundtrip Protocol. It is an umbrella specification that bundles three separate optimizations to cut WebRTC connection setup from six network round trips down to two: one signaling round trip and one media round trip.
WARP defines no new protocol of its own. It names the existing handshakes that run one after another during setup, points at the drafts that fix each of them, and describes what happens when all of them are applied together.
The problem: four handshakes, one after the other
Getting a WebRTC connection up means completing four separate handshakes in sequence. Nothing overlaps, because each layer waits for the one below it to finish.
| Step | Protocol | Cost |
|---|---|---|
| Session negotiation | SDP offer/answer | 1 RTT |
| Connectivity | ICE checks | 1 RTT |
| Encryption | DTLS 1.2 four-way handshake | 2 RTT |
| Transport | SCTP four-way init with auth cookie | 2 RTT |
Six round trips before a data channel opens. On a local network that is invisible, but across a long-haul path it is close to a second of nothing happening, and every one of those round trips is a chance for a lost packet to add a retransmission timeout on top.
The three pieces
WARP is the sum of three changes, each specified elsewhere.
- SNAP removes 2 RTT. SCTP's four-way init exists to defend against denial of service with an auth cookie. Running over DTLS, WebRTC already has that protection, so SNAP moves SCTP's initialization parameters into the SDP offer/answer where both sides learn them before any packet flows.
- SPED removes 1 RTT. It carries DTLS handshake records inside the STUN binding requests ICE is already sending, so the encryption handshake runs in parallel with connectivity checks instead of after them.
- DTLS 1.3 removes 1 RTT. It replaces the two round trip DTLS 1.2 handshake with a one round trip one. SPED then hides most of what remains inside ICE.
Applied together: 1 signaling round trip, 1 media round trip.
What is actually shipping (August 2026)
The three pieces sit at three different maturity levels.
- DTLS 1.3 is enabled by default in Chrome. Nothing to do. Enabling it does not disable DTLS 1.2, so a media server that has not been updated still negotiates down and keeps its two round trips
- SNAP is behind a Chrome origin trial, milestones 151 through 156, Finch feature
WebRtcSctpSnap. Available to measure. Off by default - SPED is draft only, behind a field trial in libWebRTC with implementation work under way in Pion. No browser exposes it by default yet
So "most of the benefits are available today" holds in the narrow sense that DTLS 1.3 is on and SNAP can be turned on.
Both remaining drafts also need a peer that speaks them. In a browser-to-SFU deployment that means the media server needs to support them as well to reap the benefits.
Where it stands in the IETF
draft-uberti-tsvwg-warp-00, published 22 July 2026, expiring 23 January 2027.
SNAP and SPED remain separate individual drafts of their own. Fast session setup matters a great deal to voice agents, where a person is waiting for a machine to start talking, which is a large part of why this is moving now.
Realistically: three separate documents have to advance through the IETF, browsers have to ship two of them by default, and media servers have to follow.
Additional reading
- draft-uberti-tsvwg-warp-00 - the WARP draft itself
- draft-hancke-tsvwg-snap - SNAP
- draft-hancke-webrtc-sped - SPED
- Pion WARP tracking issue - implementation progress across STUN, ICE, DTLS and SCTP
