- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 Nov 2019 10:22:54 +0000
- To: public-webrtc-logs@w3.org
> 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". They are different protocols and, IMHO, mixing their states will make things even more complicated. Also, replacing a DTLS transport is feasible, so this would limit us somewhat. I'd say let SCTP fail on its own with its own timers. Implementations can fiddle with SCTP timers to slightly improve UX. In practice, most implementations are more keen to listen to ICE going into `failed` or `disconnected` for too long anyway and not fiddle with a dozen other state changes of the stack. By my own experience within an app, reacting to all state changes instead of just the ICE ones can be incredibly hard to get right without causing side effects. > I think queueing a task is the wrong thing here Queued dispatching of state changes is almost always a demon portal, so I agree with that. > When the SCTP transport state goes to "closed", I think all datachannels using this transport should also go to "closed". I don't think the spec says that either. Haven't found anything explicitly saying it but all SCTP streams will close and thus this should be triggered: https://w3c.github.io/webrtc-pc/#announcing-a-data-channel-as-closed We can make it more clear if desired. -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2360#issuecomment-554952087 using your GitHub account
Received on Monday, 18 November 2019 10:22:56 UTC