WebRTC Data Channel: SCTP Negotiation Acceleration Protocol

at a glance

why it exists

WebRTC data channels run SCTP (RFC 9260) encapsulated in DTLS (RFC 8261), per the data-channel framework in RFC 8831. SCTP establishes associations with a four-way handshake (INIT / INIT ACK / COOKIE ECHO / COOKIE ACK) whose purpose is protection against half-open (SYN-flood) attacks. In WebRTC that protection is redundant: the DTLS layer underneath already provides a secure, encrypted channel that prevents half-open attacks — but the handshake still costs up to two round trips before the first DCEP open message can flow:

classic (draft §1)                     with SNAP (draft §1)
─────────────                          ─────────
SDP Offer ---------------->            SDP Offer (sctp-init) --->
<--1-- SDP Answer --------            <--1-- SDP Answer (sctp-init)
<--2-- ICE checks --------            <--2-- ICE checks --------
DTLS handshake (3,4) ----->            DTLS handshake (3,4) ----->
SCTP INIT ---------------->            DCEP (Open Channel) --->
<--5-- SCTP INIT ACK ------            <----- DCEP ACK ----------
SCTP COOKIE ECHO -------->
<--6-- SCTP COOKIE ACK ----
DCEP (Open Channel) --->
<----- DCEP ACK ----------

The draft notes that RFC 9260 allows the COOKIE ECHO and COOKIE ACK packets to carry data, so the second saved RTT “is not strictly necessary but was observed in practice” — the real-world saving is up to two RTTs, with one RTT saved even when data piggybacking works.

how it works

SNAP is negotiated entirely inside SDP offer/answer — no JavaScript surface changes:

1. An endpoint that has created a WebRTC data channel MUST have its SCTP implementation serialize the INIT chunk it would normally send, base64-encode it, and add it as an a=sctp-init line to the data m= section of its offer (offerer procedure).
2. The answerer parses and validates the attribute (base64 decoding, then SCTP-level INIT chunk validation — both are error paths), and if valid, responds with its own a=sctp-init (answerer procedure). An endpoint not supporting the extension MUST NOT include the attribute in its answer — the classic handshake then runs, so SNAP is strictly additive and backwards-compatible.
3. When both sides negotiated a=sctp-init, both SHOULD consider the SCTP association ESTABLISHED as soon as the DTLS handshake finishes, skipping steps A–E of RFC 9260 §5.1 — no COOKIE-WAIT state, no T1-init timer (SCTP state shortcut).

The attribute itself — syntax, placement rules, worked decode, renegotiation constraints, and IANA status — is documented on the a=sctp-init reference page.

examples

There is no new JavaScript to call — the observable change is in the SDP your RTCPeerConnection produces and consumes. Create a data channel before negotiating, then inspect the offer:

const pc = new RTCPeerConnection();
const dc = pc.createDataChannel("chat"); // triggers the data m= section
await pc.setLocalDescription(await pc.createOffer());
console.log(pc.localDescription.sdp.includes("a=sctp-init:"));
// true when SNAP is active (origin-trial token present, feature on)

An a=sctp-init line in a negotiated data m= section (full exchange on the offer/answer page):

m=application 9 UDP/DTLS/SCTP webrtc-datachannel
...
a=sctp-port:5000
a=max-message-size:262144
a=sctp-init:AQAAHols3R0AUAAA/////+B5ZR3AAAAEgAgABoLA

browser compatibility

Interim table: SNAP has no BCD entry and the draft is not a adopted standard, so rows above cite the Intent to Experiment directly. The underlying data-channel API is fully interoperable — BCD api/RTCDataChannel.json: Chrome 24+, Firefox 22+, Safari 11+ — and a non-SNAP peer simply falls back to the classic handshake (the answer omits the attribute).

security & privacy

• Amplification: SNAP removes SCTP’s anti-amplification mechanism (the four-way handshake) to accelerate startup. The draft argues this adds no new amplification risk because SCTP runs atop DTLS (RFC 8261): junk SCTP traffic fails DTLS decryption.
• Initiate Tag exposure: the SDP now reveals the SCTP INIT chunk contents, including the Initiate Tag. Per the draft this introduces no new concern because SCTP-over-DTLS protects against the off-path attacks described in RFC 9260 §5.3.1.
• Application-layer mutation: exposing the INIT chunk to the application (JavaScript / the signaling channel) lets it add or remove variable-length parameters. Removing one is equivalent to the peer not supporting that parameter; adding an unsupported one is equivalent to receiving a packet for an unnegotiated feature — the draft assesses neither as a new security risk.

specifications

see also

• gendn — the a=sctp-init SDP attribute
• gendn — SNAP offer/answer procedures and the SCTP state shortcut
• Chrome Platform Status — this feature
• blink-dev — Intent to Experiment (OT 151–156)
• WebRTC issue 426480601 — accelerate data channel setup with SNAP
• Chrome Platform Showcase — interactive demos for this feature
• MDN — RTCDataChannel (the unchanged JS surface)