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

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
>