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: Mon, 9 Jun 2014 10:16:02 -0700
Message-ID: <CAOJ7v-2nqes4FtoTsiTdmSQdAbKMoekPP7nVGFFfn9ddS--zww@mail.gmail.com>
To: Jim Barnett <1jhbarnett@gmail.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
The emerging consensus seems to be for #3, and I also find this to be the
easiest-to-understand solution.

Barring any dissenting opinions, I will update JSEP accordingly soon.

On Mon, Jun 9, 2014 at 6:56 AM, Jim Barnett <1jhbarnett@gmail.com> wrote:

>  Option 1 is bad, I think, because it breaks/violates the state machine  -
> we shouldn't emit ICE candidates when state is 'complete'.  Options 2 and 3
> are both compatible with the state machine and hence a lot better than 1.
> I don't see the problem with requiring an ICE restart in option 3, so it
> seems somewhat better to me.  Option 2 adds an implicit transition to the
> state machine and that makes the system harder to understand.  (I mean
> "implicit" in the sense that it's not obvious that what the app has done
> would cause that transition.)  It's best if complete==>gathering happens
> only under a few well defined circumstances.
> On 6/8/2014 9:42 PM, Justin Uberti wrote:
> 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
> --
> Jim Barnett
> Genesys
Received on Monday, 9 June 2014 17:16:49 UTC

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