search

w3c / webrtc-pc

WebRTC 1.0 API
https://w3c.github.io/webrtc-pc/
Other
439 stars 115 forks source link

Clarify order of events when the SCTP transport is closed #3022

Open jan-ivar opened 1 week ago

jan-ivar commented 1 week ago

When we added transport objects we cleaned up event firing on them in https://github.com/w3c/webrtc-pc/issues/2283. But we left out SCTP transport.

We currently update [[SctpTransportState]] and (each) datachannel [[ReadyState]] in separately queued tasks:

  1. closed image
  2. datachannel closing procedure: image

Separate tasks may be fine — though a website with 65535 datachannels would have 65535 events fired on it — but we should at minimum clarify the order vis-à-vis the [[SctpTransportState]] update. There is room for interpretation of which task to queue first. Step 1 might be to see what browsers are doing.

It might also be good to clarify whether SCTP ABORT closes all datachannels.

RFC 8831 supports this "If an SCTP association is closed in a graceful way, all of its data channels are closed. In case of a non-graceful teardown, all data channels are also closed, ..."

Graceful (as opposed to abrupt) seems to be largely about that it "ensures no messages are lost".

dontcallmedom-bot commented 6 days ago

This issue had an associated resolution in WebRTC November 19 2024 meeting – 19 November 2024 (Issue #3022: Clarify order of events when the SCTP transport is closed):

RESOLUTION: Proceed with PR to fire sctp closed on transport object and then on individual channels