v151 · webrtc · sctp

Reliable vs Unreliable Streams

Open a data channel over a real same-page loopback with per-channel options — ordered, maxRetransmits, maxPacketLifeTime, or a pre-negotiated id — then echo a message and read back the effective RTCDataChannel configuration. These controls are adjacent to SNAP, not values carried in a=sctp-init.

This is a live RTCDataChannel, not a simulation. On a lossless same-page loopback a successful echo does not demonstrate loss, retransmission, or ordering behavior. The page reads the channel object's per-channel configuration and performs one real echo; reliability semantics require controlled loss/reordering evidence on a network test.

channel configuration
closed
Open a channel to read its effective per-channel configuration.

message log

— nothing sent yet —

the reliability knobs

The RTCPeerConnection.createDataChannel() options map straight onto SCTP behaviour:

// Fully reliable and in-order — the default
pc.createDataChannel("chat");

// Unordered but still reliable
pc.createDataChannel("chat", { ordered: false });

// Partially reliable: give up after 0 retransmits
pc.createDataChannel("telemetry", { ordered: false, maxRetransmits: 0 });

// Partially reliable: give up after 50 ms
pc.createDataChannel("cursor", { ordered: false, maxPacketLifeTime: 50 });

// Pre-negotiated: both sides agree the id out of band — no in-band open handshake
pc.createDataChannel("control", { negotiated: true, id: 7 });

SNAP proposes moving association-level SCTP INIT values into SDP. It does not move ordered, partial-reliability, channel id, or RTCDataChannel.protocol into a=sctp-init. A channel created with negotiated: true is a separate DCEP choice: both applications arrange the same id out of band instead of using the in-band channel-open handshake.

see also

references