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

What you are suggesting is actually #3 in my list of options - the
gathering sequence with the new .iceTransports doesn't happen until the
next ICE restart (which is done via createOffer, or a remote ICE restart
request).

#1 would result in the local candidates being emitted immediately.


On Sun, Jun 8, 2014 at 5:16 PM, Makaraju, Maridi Raju (Raju) <
Raju.Makaraju@alcatel-lucent.com> 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.)
> >
> <Raju>
>
> IMHO Option 1 more appropriate and it fits with the overall design of the
> APIs; i.e. if the end of ICE was already triggered then, change gathering
> state, emit the candidates but no further action (like doing ICE checks or
> updating local SDP) should be taken by browser until user calls
> createOffer(). If end of ICE is not triggered then newly emitted candidates
> will happily piggyback on createOffer (or tricke ice).
>
> From my understanding changing iceTransports share similar API behavior as
> two, but not limited, use cases below.
> - changing remote destination via setRD, which triggers ice restart.
> - adding a new media stream/track. Triggers ice restart for that stream.
>
> In any of these cases I see the following flow:
> 1. user calls a trigger API (setConfig for iceTransport change, setRD for
> remote media change, addTrack/Stream to add a new stream/track).
> 2. Browser processes the API. While doing so it won't disrupt the current
> media. This processing includes emitting new candidates, preparing for ice
> restart, adding stream/track etc. At the end browser does callbacks to
> inform the applications about these changes.
> 3. At this point it is up to the application to make the next API call to
> follow up on the earlier request. This API could be
> createOffer()/createAnswer()/setLD()/setRD() etc. If the application does
> not do this then the earlier "temp" changes done by browser will remain
> temp and wait until user calls relevant APIs. Earlier media configuration
> will remain active until the sequence is completed (via createAnswer/setLD
> or createOffer/setLD/setRD).
>
> If application fails to do createOffer() while adding "relay" transport
> then next time createOffer() is done to add a track/stream, for example,
> the new candidates will be made part of the new SDP.
>
> To summarize, application is in control and as Justin mentioned "You
> called this API, you deal with it"; and "You have to follow up with it".
>
> </Raju>
>
> BR
> Raju
>