- From: Peter Thatcher <pthatcher@google.com>
- Date: Thu, 10 Dec 2015 16:39:47 -0800
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Cc: Philipp Hancke <fippo@goodadvice.pages.de>, "public-ortc@w3.org" <public-ortc@w3.org>
- Message-ID: <CAJrXDUHVweZn6O41Kywma30-HD_Pfa8NuHGZRvBiqskZ8gMT4A@mail.gmail.com>
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 require 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'). > > > >
Received on Friday, 11 December 2015 00:40:58 UTC