[webrtc-pc] Clarify/strengthen timing invariants of candidates not firing before SLD(offer) (#2199)

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

== Clarify/strengthen timing invariants of candidates not firing before SLD(offer) ==
Based on a [discussion in this crbug](https://bugs.chromium.org/p/chromium/issues/detail?id=960718#c15), we've found that Firefox's behavior to avoid ice candidates racing with offer/answer is desirable, and seems to be following the broad intent of the spec and the desired API properties espoused, even if there's no explicit prose to guarantee it. Since it's not clear that the spec mandates this behavior, so we're opening an issue to enshrine it.

Firefox guarantees icecandidate always fires AFTER the SLD(offer) success callback, so even if users do:

    pc.onicecandidate = e => io.send(e.candidate);

    await pc.setLocalDescription(await pc.createOffer());
    io.send(pc.localDescription);

We guarantee the following signaling order:
```
    offer candidate candidate candidate
```
and in the other direction:
```
    answer candidate candidate candidate
```
That is, candidates always follow the offer/answer they belong to, a nice invariant. You'll never see this in Firefox:
```
    candidate offer candidate candidate
```
Which is a good thing, as it would cause addIceCandidate to throw InvalidStateError, unless you queued the candidates, which defeats the purpose of trickle ICE in the first place.

From my limited tests with https://jsfiddle.net/jib1/vfnc26mL/ it would appear Chrome has this invariant as well? At least I was not able to provoke otherwise. I get:
```
SLD(offer) success
pc1 candidate
pc1 candidate
pc1 candidate
pc1 candidate
pc1 candidate
SLD(answer) success
pc2 candidate
pc2 candidate
pc2 candidate
```

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

Received on Thursday, 30 May 2019 14:06:53 UTC