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

In WebRTC 1.0 (see:  http://w3c.github.io/webrtc-pc), we now have RTCPeerConnection.setConfiguration(RTCConfiguration configuration) which means that configuration attributes can be changed: 

dictionary RTCConfiguration {
             sequence<RTCIceServer>   iceServers;
             RTCIceTransportPolicy    iceTransportPolicy = "all";
             RTCBundlePolicy          bundlePolicy = "balanced";
             RTCRtcpMuxPolicy         rtcpMuxPolicy = "require";
             DOMString                peerIdentity;
             sequence<RTCCertificate> certificates;
             unsigned short           iceCandidatePoolSize = 0;
};

To maintain WebRTC 1.0 compatibility, this seems to imply that ORTC API needs to be able to change iceServers (Issue 244). 
________________________________________
From: Robin Raymond [robin@hookflash.com]
Sent: Tuesday, December 01, 2015 11:50 AM
To: Philipp Hancke; Bernard Aboba
Cc: public-ortc@w3.org
Subject: Re: Suggestion for changes to IceGatherer to make it possible to signal IceParameters without gathering

A. Yes, you can delay adding the handler. Alternatively, you can add the handler but ignore the event until you are ready and then call “getLocalCandidates()” to get all the candidates at the moment you are ready to process them (as opposed to pooling them yourself).

B. I do not like interfaces for simple structured data, see issue https://github.com/openpeer/ortc/issues/289 I do not see a reason to make those interfaces, so no.

1. issue 244: I added a comment. Those are transport options not gatherer options.
2. Issue 165: Yes, I believe we need a (re-)gather method to be able to change properties.
3. “none” is a transport policy, not a gather policy.

-Robin


On November 27, 2015 at 6:44:52 PM, Bernard Aboba (bernard.aboba@microsoft.com<mailto: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?

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?

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?

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?

Issue 165 takes this even one step further by arguing for re-gathering (not just resetting of the fatherPolicy). However this goes beyond the current (or even the proposed) ICE protocol specs. Can we leave this out of scope for ORTC 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 Tuesday, 1 December 2015 20:36:06 UTC