Re: Issue 120: Calling RTCIceTransport gather with different policies - what does it mean?

Robin Raymond said: 
If you start with "all" and then "nohost", what happens?

[BA] There are multiple cases to deal with here: 

1. If gathering has completed. 
2. If gathering is in progress and the change is to a less restrictive gather policy. 
3. If gathering is in progress and the change is to a more restrictive policy. 

Case 1

Here is a WebRTC 1.0 discussion of what happens after gathering has complete: 
http://lists.w3.org/Archives/Public/public-webrtc/2014Jun/0029.html

It appears that Option 3 is the one likely to be chosen: 

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

[BA] For WebRTC 1.0 compatibility purposes, I would say that ORTC should track what is going into WebRTC 1.0.  

This implies that consent will not be revoked for candidates that would not be gathered on a restart.

Case 2

If gathering is in progress, and the new policy is less restrictive, my take would be to emit the additional candidates. 


Case 3

This is the tricky one.  If the new policy is more restrictive (e.g. "all" to "nohost'), then some candidates may have been invalidated by the new gather policy. 

Checks can be in progress (or may already have completed successfully). 

Personally, I do not see how to usefully implement a more restrictive gathering policy in mid-stream (e.g. there is no "oncandidateremoved" event).  

So I'd lean more toward the "Option 3" above in this case (e.g. new gather policy is used on the next ICE restart).

Received on Monday, 14 July 2014 18:36:28 UTC