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

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

From: Justin Uberti <juberti@google.com>
Date: Fri, 6 Jun 2014 18:14:54 -0700
Message-ID: <CAOJ7v-1fGZ7Vx_-NA_N6V2MdwaKrf-axbP+u5-FcfwV_gX_h9A@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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:
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.)
Received on Saturday, 7 June 2014 01:15:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:40 UTC