Based on that info, I'd suggest a PR to allow a new→failed path, then take it once end-of-candidates is reached after zero candidates in _both_ `addIceCandidate` and `onicecandidate`, or once the PAC timer expires (absent connection), whichever is sooner. This should unblock https://github.com/w3c/webrtc-extensions/pull/81 by giving us a near-instant failure path in the common case where both peers are blocked by CSP (in contrast, if only one side is blocked, the other side could wait 39.5 seconds before failing). Of course, a peer blocked by CSP doesn't inherently need to wait for remote signals before going to failed, since it knows it can never succeed, but that would reveal that CSP is in effect, so we might want to refrain from optimizing that. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2698#issuecomment-987443817 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-configReceived on Tuesday, 7 December 2021 00:46:29 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:55 UTC