W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2014

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

From: Justin Uberti <juberti@google.com>
Date: Sun, 8 Jun 2014 18:42:20 -0700
Message-ID: <CAOJ7v-0b1Lsony0ChFKRy9wRqoirtE=nZb8EjCiFDrQ-9jk6pA@mail.gmail.com>
To: Jim Barnett <1jhbarnett@gmail.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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
>
>
Received on Monday, 9 June 2014 01:43:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:40 UTC