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

>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.)

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".



Received on Monday, 9 June 2014 00:17:22 UTC