[webrtc-pc] iceConnectionState, selectedCandidatePair and races in Chrome Canary (#2088)

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

== iceConnectionState, selectedCandidatePair and races in Chrome Canary ==
The RTCIceTransportState's "connected" says "The RTCIceTransport has found a usable connection, but is still checking other candidate pairs to see if there is a better connection. [...]" Does usable connection imply that the RTCDtlsTransportState is "connected" or can it be "usable" before then? I'm guessing DTLS is the next layer, and that we can be "ICE-connected" before "DTLS-connected".

Being "ICE-connected" I would assume that if you perform getStats() the transport would have a selectedCandidatePair - how could we be "connected" if we don't have a selected candidate-pair? But it could also be that the candidate pair is not considered "usable" before DTLS handshake.

In Chrome's recent Canary implementation (after a CL that makes iceConnectionState more spec-compliant, including not waiting for DTLS before reporting "connected"), it seems that a side-effect of possibly being "ICE-connected" earlier is that selectedCandidatePair is not always defined on the transport stats object despite iceConnectionState == "connected". This sounds like a bug.

[The test](https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/webrtc/RTCPeerConnection-track-stats.https.html) is flaky on tip-of-tree, there are two possible outcomes:

1. transport.dtlsState is "new" and transport.selectedCandidatePair is undefined. The (not referenced but existing) candidate-pair's state is "in-progress".
2. transport.dtlsState is "connected", transport.selectedCandidatePair is defined and the referenced candidate-pair's state is "succeeded".

**Question:** Is it correct to assume that this _could_ be a valid outcome as well, and possibly is the outcome we should expect when it flakes instead of 1):

3. transport.dtlsState is "new", transport.selectedCandidatePair is defined and the referenced candidate-apir's state is "succeeded".

Is it correct to say that 1) should not be possible when we are "ICE-connected", and there is a bug in Chrome? Or should the test wait for "DTLS-connected" or for packets to start flowing before asserting that selectedCandidatePair is defined?

CC @jonasesolsson @jan-ivar @vr000m

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

Received on Tuesday, 29 January 2019 10:49:28 UTC