[webrtc-pc] Clarify order of events when the SCTP transport is closed (#3022)

jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc:

== Clarify order of events when the SCTP transport is closed ==
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](https://w3c.github.io/webrtc-pc/#idl-def-RTCSctpTransportState.closed)
    <img width="794" alt="image" src="https://github.com/user-attachments/assets/6bce17b5-96bf-43d4-963e-c8ea453adbbc">
2. [datachannel closing procedure](https://w3c.github.io/webrtc-pc/#data-transport-closing-procedure):
    <img width="822" alt="image" src="https://github.com/user-attachments/assets/1be55420-8a8e-4b47-b6e7-feb2becd8de3">

Separate tasks may be fine — though a website with 65535 datachannels which 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](https://www.rfc-editor.org/rfc/rfc8831#section-6.2) 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"_.


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


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

Received on Wednesday, 13 November 2024 18:43:43 UTC