[webrtc-stats] Add SCTP association capability stats to getStats() (#821)

JoTurk has just created a new issue for https://github.com/w3c/webrtc-stats:

== Add SCTP association capability stats to getStats() ==
Applications using WebRTC data channels may want to adapt their sending strategy based on negotiated SCTP association capabilities. This is  especially true with message interleaving (RFC-8260, currently enabled by default in Firefox).

For example, if SCTP message interleaving is enabled, an application can safely batch larger messages without causing the same send-side head-of-line blocking behavior. If interleaving is not enabled, the application may prefer smaller chunks, different batching thresholds, fewer concurrent large sends, or / and application-level scheduling.

Today this can be observable in browser-to-non-browser cases when the non-browser endpoint exposes SCTP association metadata. For example, At Pion we're adding getStats exposure for negotiated SCTP features including interleaving, partial reliability mode, and zero-checksum send/receive state: https://github.com/pion/webrtc/pull/3424

The problem is with browser-to-browser WebRTC, the web application has no interoperable way to determine whether SCTP message interleaving was negotiated. `RTCSctpTransport` exposes `state`, `maxMessageSize`, and `maxChannels`, but not SCTP association capabilities such as message interleaving. `RTCDataChannelStats` just exposes per-channel counters,.

Applications can make adaptive decisions when one side is a non-browser endpoint, but cannot make the same decisions in browser-to-browser deployments.

## Proposed addition

Expose SCTP association-level stats, for example:

```
dictionary RTCSctpTransportStats : RTCStats {
  DOMString transportId;
  RTCSctpTransportState state;
  boolean messageInterleavingEnabled;
  DOMString partialReliabilityMode;
  boolean zeroChecksumSendingEnabled;
  boolean zeroChecksumReceivingEnabled;
};

Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/821 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 18 May 2026 20:53:09 UTC