Re: What should happen to the ICE gathering state when iceTransports is changed?

Apologies for the formatting. Copy-paste into Gmail resulted in non-WYSIWYG
behavior. Retrying:

Consider the scenario where .iceTransports is set to 'relay', and so relay
gathering occurs first; non-relay gathering only occurs after
.iceTransports is changed to 'all'. This is the scenario where a callee
wants to avoid disclosing their location (real ip address) until accepting
the call.

The flow goes something like:
- new PC({iceTransports: 'relay'})
- setRD(offer)
- createAnswer
- setLD(answer)
- onicegatheringstatechange(gathering)
- onicecandidate(relay1)
- onicecandidate(relay2)
- Possibility A: setConfiguration({iceTransports: 'all'})
- onicecandidate(null)
- onicegatheringstatechange(complete)
- Possbility B: setConfiguration({iceTransports: 'all'})

In case A, we could definitely release the gathered ICE candidates
immediately, with no issues. But in case B, does it make sense to emit
them, since gathering has completed?
Options:
1) Emit them. No state change occurs. You called this API, you deal with
it. (Simple, but may cause issues, especially if onicecandidate(null) has
triggered an end-of-candidates signal to the remote side.)
2) Transition back to gathering, emit the candidates (which will happen
immediately, necessarily), go back to complete. (Changes the meaning of a
"complete"->"gathering" transition, which previously only occurred on a new
m= line being added, or an ICE restart. May have the same issues as above,
with end-of-candidates)
3) No candidates are emitted, no state change occurs. The new type of
candidates is gathered on the next ICE restart. (Complicates the use case
above; remote side would need to re-offer with ice restart after accepting
the call. But no signaling issues, and allows changing iceTransports to a
more restrictive type.)


On Fri, Jun 6, 2014 at 6:14 PM, Justin Uberti <juberti@google.com> wrote:

> Consider the scenario where .iceTransports is set to 'relay', and so relay
> gathering occurs first; non-relay gathering only occurs after
> .iceTransports is changed to 'all'. This is the scenario where a callee
> wants to avoid disclosing their location (real ip address) until accepting
> the call.
> The flow goes something like:new PC({iceTransports:
> 'relay'})setRD(offer)createAnswersetLD(answer)onicegatheringstatechange(gathering)onicecandidate(relay1)onicecandidate(relay2)A:
> setConfiguration({iceTransports:
> 'all'})onicecandidate(null)onicegatheringstatechange(complete)B:
> setConfiguration({iceTransports: 'all'})
> In case A, we could definitely release the gathered ICE candidates
> immediately, with no issues. But in case B, does it make sense to emit
> them, since gathering has completed?
> Options:1) Emit them. No state change occurs. You called this API, you
> deal with it. (Simple, but may cause issues, especially if
> onicecandidate(null) has triggered an end-of-candidates signal to the
> remote side.)2) Transition back to gathering, emit the candidates (which
> will happen immediately, necessarily), go back to complete. (Changes the
> meaning of a "complete"->"gathering" transition, which previously only
> occurred on a new m= line being added, or an ICE restart. May have the same
> issues as above, with end-of-candidates)3) No candidates are emitted, no
> state change occurs. The new type of candidates is gathered on the next ICE
> restart. (Complicates the use case above; remote side would need to
> re-offer with ice restart after accepting the call. But no signaling
> issues, and allows changing iceTransports to a more restrictive type.)
>