- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 17 Feb 2023 23:17:15 +0000
- To: public-webrtc-logs@w3.org
> TL;DR: That's a fine modification to the algorithm if you think it makes it more readable/implementable. But the algorithm matches all possible cases, including the ones you brought up, which should return "connected". Makes sense to me, and thanks for the proving this is editorial! > > So... let's go back to your cases: > > > > - All ICE transports are in "new" or "closed", and any DTLS transport is in "connected", or > > - Any ICE transports are in "new" or "closed", and all DTLS transports are "connected" > > In both cases, since there is an ICE transport is in the "new" state, it would trigger the rule for "connecting" IF at least one is "new" it's "connecting" otherwise "connected", agreed. What remains weird perhaps is this state: - All ICE transports and DTLS transports are "closed" ...which, if it can happen outside of `pc.close()`, the spec says is "connected", when I think most people would have expected "closed". But can this happen? DTLS can receive "close_notify" alerts, but the spec isn't clear what can may cause an ICE transport to ""shut down and ... no longer responding to STUN requests."". If it can ONLY be shutdown by `pc.close()` it might help to say that, to close the gap. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2827#issuecomment-1435386340 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 17 February 2023 23:17:17 UTC