Re: Suggestion for changes to IceGatherer to make it possible to signal IceParameters without gathering

On Fri, Nov 27, 2015 at 3:43 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> Some questions:
> A. For adapter.js, is the idea to delay calling the start() method until
> setLocalDescription() so that onlocalcandidate events only start firing
> then? If so, how would an ICE candidate pool be created prior to that? Is
> the idea to call start() but not set the onlocalcandidate event handler
> until later?
>
> With the current API, is it viable to construct an IceGatherer but delay
> attaching the onlocalcandidate event handler until IceCandidates are desired
> ​?
>

​Yes, that's possible, however:

1.  It's clunky.

2.  It has the side effect that just to generate some text (an offer), you
have to start gathering candidates, which means STUN and TURN network
traffic.  Now, I suppose we could tell the gatherer "gather with policy ==
none right now" and then later say "ok, gather with policy == all".  But
that's even more clunky.


​


> ​
>



>
> B. If we have a static way of creating IceParameters, wouldn't
> IceParameters have to be changed from a dictionary to an interface with
> read-only attributes to prevent the application from changing the
> ufrag/password before passing it back as an argument?
>
​
Well, the remote IceParameters have to be provided by the JS.  But I see
your point for local parameters.  However, it seems really easy to
implement a "blow up if given values you haven't given out".  That's how it
works in WebRTC 1.0 already.


>
> We also have several issues open on related topics:
> 1. Changing IceServers:
> https://github.com/openpeer/ortc/issues/244
> 2. Ice re-gathering: https://github.com/openpeer/ortc/issues/165
> 3. Lack of a "none" gatherPolicy:
> https://github.com/openpeer/ortc/issues/224
>
> The premise of Issue 224 is that the gatherPolicy passed in the
> IceGatherer constructor determines whether the IceGatherer gathers upon
> construction or not (if "none" is passed).  Therefore a start() method
> would need a gatherPolicy argument so as to allow setting a policy
> different from "none".  If we go with Peter's proposal, we would not need a
> "none" gatherPolicy, and could forgo the argument to start(), correct?
>

​I think you're right.  We either have a none policy or a start method.  I
prefer the latter.  It's less clunky.​


> Issue 244 argues that it could be useful to change IceServers, and
> therefore that a method is needed to change the gatherPolicy that can be
> called multiple times, not just a start() method with no gatherPolicy
> argument that can only be called once.  Do you believe it is useful to be
> able to change IceServers, or can we pass on this for now?
>

​If you change IceServers, doesn't that effectively requ​ire a new
IceGatherer (unless we support continual gathering of candidates)?  I think
in WebRTC 1.0, a change to IceServers won't have an effect until the next
ICE restart.  But I could be wrong.


> Issue 165 takes this even one step further by arguing for re-gathering
> (not just resetting of the
> ​g​
> atherPolicy). However this goes beyond the current (or even the proposed)
> ICE protocol specs. Can we leave this out of scope for ORTC 1.1?
>

​I think continual gathering of candidates should be left out of scope.  We
should stick to "if you need to re-gather (change of policy or ICE servers
or ufrag/pwd), make a new gatherer".  ​


​However, the start() method allows flexibility of in the future, if we
want to re-start gathering with the same gatherer object, we could do so by
allowing start() to be called more than once.  But I still think that's out
of scope for 1.1.​



>
>
> > On Nov 20, 2015, at 10:26 AM, Philipp Hancke <fippo@goodadvice.pages.de>
> wrote:
> >
> > [...]
> >> I think these two things would resolve all the issues that Philipp
> Hancke
> >> found while writing the shim and also provide more flexibility to all
> >> applications with very little additional complexity in the
> specification or
> >> implementation.
> >
> > +1
> >
> > One thing I would strongly prefer to avoid here is allowing people to
> 'hardcode' the usernameFragment and password in their applications in order
> to minimize the amount of information that has to be exchanged (c.f.
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwebrtchacks.com%2fthe-minimum-viable-sdp%2f&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c5666bac2b3d24bdfbb7708d2f1d81828%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8rwDYPMgS2BKbLyR9VOCVsW3VvfeFXSty7sLHfyI6zE%3d
> -- this would be 16+22 characters that could be 'saved').
> >
>
>