[webrtc-pc] Should SCTP transport enter "closed" state when DTLS transport does? (#2360)

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

== Should SCTP transport enter "closed" state when DTLS transport does? ==
The spec says about SCTP transport state "closed":

A task is queued to update the [[SctpTransportState]] slot to "closed" when a SHUTDOWN or ABORT chunk is received or when the SCTP association has been closed intentionally, such as by closing the peer connection or applying a remote description that rejects data or changes the SCTP port.

It is not clear what should happen if the DTLS transport enters "closed" or "failed" state.
I suggest we update the spec to say "In addtion, the [[SctpTransportState]] slot is updated to "closed" when the DTLS transport enters "closed" or "failed" state".

I think queueing a task is the wrong thing here - if changes in DTLS state trigger changes to SCTP state, I think we'd want to have them happen "simultaneously" - the DTLS statechange handler should see the SCTP state as already changed.



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