SPED stands for STUN Protocol for Embedding DTLS. It carries DTLS handshake flights inside the STUN binding requests and responses that ICE is already exchanging, so encryption setup runs in parallel with connectivity checks instead of waiting for them to finish.
It is one of the components of WARP, and it is the one that affects media rather than data.
The problem: two handshakes done sequentially
WebRTC setup runs ICE first, then DTLS. ICE probes candidate pairs with STUN binding requests until one answers. Only once a pair is nominated does DTLS start its handshake on that pair.
Both are round trip exchanges over the same path between the same two endpoints, and they are strictly sequential. DTLS waits for a result ICE already has.
SPED's answer is to notice that ICE's packets have room in them, and to put the DTLS handshake inside packets that were going to be sent anyway.
What it buys
With DTLS 1.2, SPED takes three round trips down to two. With DTLS 1.3, it can bring connection setup down from two RTTs to one, depending on the direction of the handshake.
On lossy networks the impact gets significant. The draft's own benchmark appendix puts vanilla DTLS 1.3 at 25% packet loss at a p95 setup latency of 2,560 ms. SPED at the same loss rate: 750 ms. On a good network SPED saves a round trip. On a bad one it removes the multi-second tail, which is where users actually notice.
For an application whose users are on mobile, in a conference hall, or on hotel wifi, the gains should be noticeable.
When an engineer would care
SPED is the WARP component that touches every WebRTC connection, because every connection does ICE and DTLS whether or not it opens a data channel.
- Any application where join time is a product metric
- Voice agents, where a person is waiting for a machine to start talking
- Anything running over mobile or contested wifi, where the tail latency matters more than the median
Where it stands (August 2026)
draft-hancke-webrtc-sped-00, published 2 March 2026. It has not been updated or adopted by a working group yet.
Implementation-wise, SPED is the most complicated piece of WARP's plan. It is guarded behind a field trial in libWebRTC and Chrome, and there were incompatible changes to the wire protocol after the M144 release.
Pion has work in progress spanning its STUN, ICE, DTLS and WebRTC layers, which indicates how complex the required changes are: the ICE agent and the DTLS stack have to hand packets to each other, and most implementations have carefully kept those apart.
Additional reading
- draft-hancke-webrtc-sped-00 - the SPED draft, including the benchmark appendix
- draft-uberti-tsvwg-warp-00 - WARP, the umbrella spec
- SPED slides, IETF 125 avtcore
- Pion WARP tracking issue - implementation progress
