v151 · webrtc · data channel

WebRTC Data Channel: SCTP Negotiation Acceleration Protocol

WebRTC data channels run SCTP over a DTLS association. The standard SCTP handshake costs extra round trips before the first channel can open. The expired SNAP -00 Internet-Draft proposes embedding each endpoint’s SCTP INIT parameters in SDP as a=sctp-init, reducing establishment by up to two network round trips. The proposal adds no JavaScript API, but its SDP attribute is visible to application signalling code.

concepts

  1. Open-Latency Lab

    Run a real same-page RTCPeerConnection loopback and time createDataChannel → open. The interval includes signalling, ICE, DTLS, SCTP, and channel establishment; SNAP proposes removing only the SCTP handshake portion, so this is not a direct measurement of its RTT saving.

  2. SDP & SCTP Inspector

    Generate a real offer with createOffer() and dissect the SCTP negotiation lines it carries: the m=application … UDP/DTLS/SCTP line, a=sctp-port, a=max-message-size, a=setup, a=fingerprint — and probe for the SNAP a=sctp-init attribute itself, honestly reporting present or absent.

  3. Reliable vs Unreliable Streams

    Open data channels with different per-channel settings — ordered, maxRetransmits, maxPacketLifeTime, and pre-negotiated id — then echo a message and inspect the live channel. These are adjacent RTCDataChannel/DCEP controls, not the association-level SCTP INIT parameters SNAP carries in SDP.

why acceleration matters

For real-time apps — game state, collaborative cursors, file transfer signalling — the time to open the first data channel can be user-visible latency. The classic flow completes DTLS and then uses the SCTP INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK handshake before DCEP opens an in-band channel. SNAP proposes exchanging serialized INIT chunks in the existing SDP offer/answer; if both endpoints negotiate valid values, the draft says they should consider the SCTP association established once DTLS finishes. It reports a saving of up to two round trips. ICE, DTLS, DCEP, per-channel reliability settings, and application signalling remain separate work.

Availability, per the ChromeStatus API (updated 2026-06-30): SNAP is an origin trial on desktop in Chrome 151–156, with public registration (origin-trial id 3793719736106221569); no default-on milestone is recorded yet (status text “Proposed”). The runtime feature is WebRtcSctpSnap (status experimental). Its documented specification is draft-hancke-tsvwg-snap-00, an Internet-Draft that expired on 2 July 2026: work in progress, not an RFC. Attribute names and procedures may be updated, replaced, or abandoned.

references