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

In A, setConfiguration happens before the end of gathering. In B,
setConfiguration happens afterwards.


On Sun, Jun 8, 2014 at 2:51 PM, Jim Barnett <1jhbarnett@gmail.com> wrote:

> Maybe it's just my email reader, but I have trouble parsing your example.
>  Are A and B supposed to be two different continuations of the initial
> sequence of operations?  B looks like it is a subset of A.
>
>
> On 6/6/2014 9:14 PM, Justin Uberti 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.)
>>
>
> --
> Jim Barnett
> Genesys
>
>