W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2014

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

From: Jim Barnett <1jhbarnett@gmail.com>
Date: Sun, 08 Jun 2014 17:51:56 -0400
Message-ID: <5394DAFC.7090100@gmail.com>
To: public-webrtc@w3.org
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
Received on Sunday, 8 June 2014 21:52:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:59 UTC