Clarify order of events when the SCTP transport is closed

[jan-ivar]

When we added transport objects we cleaned up event firing on them in #2283. But we left out SCTP transport.

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

1. closed
   
2. datachannel closing procedure:
   

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]

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