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

Re: ACTION-95: Constraints usage in the WebRTC spec

From: Justin Uberti <juberti@google.com>
Date: Wed, 22 Jan 2014 17:49:57 -0800
Message-ID: <CAOJ7v-22AdRBHUMHA2kaVcpNgS4+2yDd-zS9SM-y65ix9h3tuA@mail.gmail.com>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, Jan 22, 2014 at 4:01 AM, Adam Bergkvist <adam.bergkvist@ericsson.com
> wrote:

> Hi
>
> Since RTCConfiguration is a dictionary (where you can omit keys) it can
> simply be done as:
>
> pc.updateIce({ "iceTransports": newValue });
>

Yes, of course. Thanks for reminding me.


> The other values could then be left unchanged. I anyhow think we need to
> make the configuration, or the components of the configuration, gettable
> from the object when it has been created.
>

Are you suggesting adding a pc.configuration getter?

>
> The other question remains. What happens if I do:
>
> pc.updateIce({ "iceServers": totallyNewListOfServers });
>

I think that the new list of servers should replace the previous list, but
no other actions should happen at that time. Upon the next transition back
to a "gathering" state, the new ICE servers should be used; if the app
wants that to happen immediately, it should do an ICE restart. With this
approach, .iceServers is idempotent.


>
> /Adam
>
>
> On 2014-01-21 20:29, Justin Uberti wrote:
>
>> With this API, how would one change just the |iceTransports| param?
>> Would you have to remember the last set of iceServers and supply them
>> again? Or should we make the current RTCConfiguration gettable from the
>> PC object?
>>
>>
>> On Tue, Jan 21, 2014 at 1:41 AM, Adam Bergkvist
>> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote:
>>
>>     On 2013-11-26 15:33, Adam Bergkvist wrote:
>>
>>         ## IceTransports
>>         Used with PeerConnection() Constructor and updateIce()
>>
>>         Controls which types of candidates the ICE agent is allowed to
>> use.
>>
>>         The possible values are "none", "relay" and "all". If a browser,
>> for
>>         some special reason, is configured to not support all these
>>         values, that
>>         might be a reason to have it as a constraint.
>>
>>         Proposal: Move to RTCConfiguration?
>>
>>
>>     updateIce() is changing from
>>
>>     void updateIce (optional RTCConfiguration configuration, optional
>>     MediaConstraints constraints);
>>
>>     to
>>
>>     void updateIce (RTCConfiguration configuration);
>>
>>     Both arguments used to be optional, but unless someone comes up with
>>     a reason why you would like to run updateIce() with no arguments,
>>     I'll make the first argument mandatory as well.
>>
>>     To the real question.. Does updateIce() accept changes to everything
>>     in the RTCConfiguration dictionary?
>>
>>     dictionary RTCConfiguration {
>>          sequence<RTCIceServer> iceServers;
>>          RTCIceTransports       iceTransports = all;
>>     }
>>
>>     /Adam
>>
>>
>>
>
Received on Thursday, 23 January 2014 01:50:44 UTC

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