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

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 
> <mailto: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