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

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 23 Jan 2014 13:32:48 +0100
Message-ID: <52E10BF0.6060707@alvestrand.no>
To: public-webrtc@w3.org
On 01/23/2014 07:52 AM, Adam Bergkvist wrote:
> On 2014-01-23 02:49, Justin Uberti wrote:
>>
>> On Wed, Jan 22, 2014 at 4:01 AM, Adam Bergkvist
>> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> 
>> wrote:
>>
>>     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?
>
> Yes (it would have to be a getter method though)
>
>>     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.
>
> Let's document this is the spec. We can change it if it's turns out to 
> be the wrong approach.
>
> The only remaining question mark is what can go wrong when setting 
> iceServers. What do we have except SyntaxError on unparsable urls. Any 
> invalid combinations of protocol, username and credential?

We have follow-on bugs such as invalid credentials that are discovered 
when trying to contact the TURN server. But it's unrealistic to have 
those as return values from updateIce.
Received on Thursday, 23 January 2014 12:33:19 UTC

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