SNAP offer/answer procedures

offerer procedure

Generating the initial offer (§5.2)

If the offering endpoint has created a WebRTC data channel, it MUST let its SCTP implementation generate the serialized INIT chunk it would normally send over the network, base64-encode the bytes, and add them to the data m= section as an a=sctp-init line.

Processing the answer (§5.5)

1. If the answer negotiated a data m= section, the offerer parses the a=sctp-init line, if present.
2. Improperly base64-encoded data results in an error.
3. The offerer passes the decoded bytes to its SCTP implementation, which validates the INIT chunk format; bytes that are not a valid SCTP INIT chunk result in an error.
4. If the answer carries no a=sctp-init, the peer does not support (or declined) SNAP — the classic SCTP four-way handshake proceeds once DTLS is up.

answerer procedure

Processing the offer (§5.3)

1. If the answering endpoint negotiates a data m= section, it parses the a=sctp-init line from the offer, if present.
2. Improperly base64-encoded data results in an error.
3. The answerer informs its SCTP implementation of the byte string; the SCTP implementation validates the INIT chunk format, and a byte string that is not a valid SCTP INIT chunk results in an error.

Generating the answer (§5.4)

• An endpoint not supporting the extension MUST NOT include an a=sctp-init attribute in its answer.
• If the answerer negotiated a data m= section and detected a valid a=sctp-init in the offer, it MUST let its SCTP implementation generate the serialized INIT chunk it would normally send, base64-encode it, and add it to the answer’s data m= section.

modifying the session (§5.6)

• Subsequent offers and answers MUST include the a=sctp-init line with the same value as in the initial negotiation.
• A remote offer MAY negotiate a new a=sctp-init value only in conjunction with:
  • a new SCTP association, as described in RFC 8841 §9.3, or
  • a new DTLS association, as described in RFC 8842 §5.5.
• Attempting to add an sctp-init attribute to an existing SCTP association results in an error.

Illustrative re-offer sketch (gendn-derived from the §5.6 rules, not a verbatim draft example — the draft's only worked example, §7, covers the initial negotiation):

# Subsequent re-offer: the attribute line repeats unchanged
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
a=sctp-init:<same base64 value as in the initial offer>

the SCTP state shortcut (§6)

This is where the time saving comes from: DCEP channel-open messages can flow immediately after DTLS, instead of after two more round trips of SCTP handshake. Because SCTP runs inside DTLS (RFC 8261), skipping the anti-half-open handshake adds no new amplification exposure (draft §8; see the overview security section).

example negotiation (§7)

The offering client generates its INIT chunk (Initiate Tag 0x896cdd1d, a_rwnd 0x00500000, 65535 outbound/inbound streams, Initial TSN 0xe079651d, Forward-TSN + RECONFIG extensions — field-by-field decode on the attribute page) and offers:

v=0
o=- 8389853828849686268 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=ice-ufrag:UgEn
a=ice-pwd:f/+ugRILrIUlAkSmkStnZb/h
a=ice-options:trickle
a=fingerprint:sha-256
          6A:15:F0:08:9C:55:51:CD:55:27:BD:0D:FB:14:DD:41:
          F6:8C:82:9F:CA:AD:DA:E7:04:61:6F:A9:FF:99:2D:7A
a=setup:actpass
a=mid:0
a=sctp-port:5000
a=max-message-size:262144
a=sctp-init:AQAAHols3R0AUAAA/////+B5ZR3AAAAEgAgABoLA

The answering client generates its own INIT chunk (Initiate Tag 0x5fb37474, Initial TSN 0xa1aadc74, same window/stream/extension parameters) and answers:

v=0
o=- 6156433258406980035 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=ice-ufrag:thzM
a=ice-pwd:YT278C3KYFmsedR5+OzE9OQY
a=ice-options:trickle
a=fingerprint:sha-256
          AC:48:A1:C4:78:6D:6D:46:63:BB:7D:70:E4:B8:5D:C4:
          E8:6E:66:40:8C:81:31:D3:9C:34:32:9A:C3:6B:BB:AE
a=setup:active
a=mid:0
a=sctp-port:5000
a=max-message-size:262144
a=sctp-init:AQAAHl+zdHQAUAAA/////6Gq3HTAAAAEgAgABoLA

negotiation lifecycle at a glance

compatibility

see also

• Feature overview — WebRTC Data Channel: SCTP Negotiation Acceleration Protocol
• The a=sctp-init SDP attribute
• IETF datatracker — draft-hancke-tsvwg-snap (source + issue tracker)
• RFC 9260 §5.1 — normal association setup (the steps being skipped)
• ChromeStatus — 5137946677215232