Re: [webrtc-pc] State gaps in connectionState algorithm (#2827)

> 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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Friday, 17 February 2023 23:17:17 UTC