RE: API for browser to provide TURN servers

The defaultIceServers method was added after observations that Firefox was using default servers if none were configured by the app. The behavior was a little obscure and overwriting it required configuring and empty list of iceServers. See issue #263 [1]

As discussed, the problem with default ICE servers is that they are not transparent to the app, unlike RETURN servers, which act more like a proxy. An app might need to use its own TURN servers for media to flow, knowing that any browser provided servers would fail.

The defaultIceServers API added in PR #365 [2] allows the application to retrieve these default ICE servers and use them if it wants to. Before someone asks, the fingerprintability issue was considered, but since these default servers could be trivially retrieved from the stats API after gathering, it really doesn't increase the fingerprint surface [3].

Now to come back to the original question, i.e. what constitutes default ICE servers? Is it a hardcoded / built-in list pointing to servers possibly maintained by the browser vendor, or is it a list that can be provisioned by enterprises for example? In Firefox, the defaults are based on an about:config value, so they can clearly be provisioned.

I think the answer is, it's the UA's choice, as it really doesn't matter from an application's perspective, they're just defaults. I do expect other UAs to go the same route as Firefox, simply because it offers more flexibility than a hardcoded list.

Mathieu

[1] https://github.com/w3c/webrtc-pc/issues/263

[2] https://github.com/w3c/webrtc-pc/pull/365/files

[3] http://www.w3.org/2015/10/29-webrtc-minutes.html


-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Tuesday, December 8, 2015 15:46
To: public-webrtc@w3.org
Subject: Re: API for browser to provide TURN servers

Den 08. des. 2015 23:15, skrev Alexandre GOUAILLARD:
> @emil,
> 
> yes, it was my understanding that return was the way for enterprise to 
> provide **discoverable** turn server, and thus the JS API was 
> something else. Lots of time was spend in the discussion to say that 
> this API was NOT return, and that return was more like a proxy or a 
> vpn, and dealt with by the browser directly, without interaction with the web app.
> 
> Now, stefan confirmed that the API to provide ICE servers to the App 
> was indeed discussed. We had actually checked the spec before asking, 
> and nothing there hint at how this list is populated in the first 
> place. My
> understanding: browser hardcode it. Mathieu understanding: enterprise 
> have a way to populate this list. Anybody remembers/knows?

The only context in which those configured-within-the-browser servers make sense are corporate contexts.

Browsers deployed in corporate contexts (or even browser profiles under administrated domains) tend to have lots of ways to set things.

See https://support.google.com/chrome/a/answer/188446?hl=en for one example.

Received on Wednesday, 9 December 2015 01:25:07 UTC