Re: Use of getDefaultIceServers

If using the Chrome admin tools or "just working out of the box like a
proxy" is a hard requirement then my suggestions are not applicable and we
don't have to spend any more time on them.
But from my point of view it still sounds like an application-specific
problem.

"In the getDefaultIceServers proposal, the IBM network administrator can
configure the user's browser through normal Chrome admin tools, the Cisco
application could read the configuration using getDefaultIceServers, and
the Google host wouldn't have to care about anything at all."

The Cisco application could, instead of using getDefaultIceServers(), have
an IBM-specific setting specified by an IBM administrator who has an
account on the Cisco website. Cisco would know that an IBM user is
connecting either because the user is signed in to the website or because
the user clicked an IBM-specific URL (
cisco.com/meeting/ibm-user/google-conference-code). The setting could
either 1) simply say what the ICE server is, or 2) say what IBM server to
ask what the ICE server is. With 2) you could dynamically get different ICE
servers depending on your location, server loads, time of day, etc. Throw
in usernames into the mix and you could get even more creative, running all
the IBM-specific logic you want that neither Cisco or Google knows anything
about.

The only assumption I'm making is that the conferencing service cares about
this use case and that the administrator has an account on the conferencing
service. The rest is an application-specific problem.

Otherwise I can take a backseat to these discussions.

On Sat, Jan 26, 2019 at 12:01 AM Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> Harald said:
>
>
> "In the getDefaultIceServers proposal, the IBM network administrator can
> configure the user's browser through normal Chrome admin tools, the Cisco
> application could read the configuration using getDefaultIceServers, and
> the Google host wouldn't have to care about anything at all."
>
>
> [BA] The problem is that the scenario is challenging for service
> operators. While it is up to the application whether to utilize the relay
> supplied by the network administrator, the network admin may have
> configured the network so as to block alternative relays, or the
> application may have been written so as to require the use of its own
> servers.  For a service operator to make a decision whether to utilize the
> network administrator-provided relay, it needs metrics and error handling
> information, but without implementations of onicecandidateerror and
> RTCIceTransport-related methods/attributes, this is challenging.
> ------------------------------
> *From:* Harald Alvestrand <harald@alvestrand.no>
> *Sent:* Friday, January 25, 2019 2:41:56 PM
> *To:* Henrik Boström
> *Cc:* public-webrtc@w3.org
> *Subject:* Re: Use of getDefaultIceServers
>
> On 01/25/2019 04:18 PM, Henrik Boström wrote:
>
> I'm still not convinced that this is within the scope of what we should be
> doing. Are we encouraging users to go into browser settings in order to
> make full use of a website? Are we encouraging users to pass down special
> flags to their browser? Why are we solving the issue on this layer, why is
> it not up to the application where to connect to?
>
> In other contexts you would sign in to the website, enter some code or
> configure settings in the website. Or if you want things to "just work for
> anybody clicking the link", why not save the configuration server-side and
> get configuration-specific URLs? foo.com/bar-enterprise
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffoo.com%2Fbar-enterprise&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C353a3ab6b3be4a0896ef08d683168e18%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636840530237877741&sdata=dlH5MnSsF6kaOYRs%2BFV4nsaLva8meTj5KkMctkcEZwU%3D&reserved=0>
> or bar-enterprise.foo.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbar-enterprise.foo.com&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C353a3ab6b3be4a0896ef08d683168e18%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636840530237887753&sdata=mXlbew89TazTdDyaqf0%2BWaLki45o5pTvRVwSwg0uISs%3D&reserved=0>
> .
>
>
> One of the scenarios is that of an user at IBM callling into a conference
> hosted by Google on a Cisco conference engine.
> The configuration needed is specific to IBM's network, and neither Cisco
> nor Google has any idea what that configuration may be, or even if it's the
> same configuration as yesterday. (Replace IBM, Google and Cisco with any
> names you want to. I'm just using some familiar ones.)
>
> Who would get that information from IBM's network administratior to the
> server-side configuration, and whose URL would it be stored under?
>
> In the getDefaultIceServers proposal, the IBM network administrator can
> configure the user's browser through normal Chrome admin tools, the Cisco
> application could read the configuration using getDefaultIceServers, and
> the Google host wouldn't have to care about anything at all.
>
> Note: I'm not that sure the extension is worth implementing, but I don't
> want to spend time discussing alternate proposals where I don't see how to
> make them work.
>
> Harald
>
>
> On Wed, Jan 23, 2019 at 10:43 PM Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
> Den 23.01.2019 19:15, skrev Cullen Jennings (fluffy):
> >
> > So just wanted to put on list a few key things about this
> >
> > 1) the goal here is to allow an app to discover a local TURN server run
> by enterprises that allows connectivity through the firewall
> >
> > 2) the app has no prior relation with the enterprise so it is not like
> every enterprise can go and configure the address of their TURN server for
> every WebRTC app that might use this. That would be fine for the huge apps
> like WebEX but it is a very huge barrier of entry for smaller new apps.
> That’s not the way to grow an ecosystem.
> >
> > How I see this is working is:
> >
> > a) The TURN server(s) are configured into the browser via an non
> specified way. It could be how HTTP proxy gets configured, it could just be
> the disk, it could have a UI too.
>
> For Chrome, the natural thing to do would be to include an item in the
> org console - probably settable via chrome://flags, but the site admin
> could set the flag for every Chrome browser run by a registered user in
> his domain.
>
> >
> > b) If the TURN server is usable from the point in the network, the
> browser reports it in the getDefaultIceServers function
> >
> > c) if the apps wants to use it, it passes it back as the browser as one
> of the TURN servers to use
> >
> > We can brainstorm solutions to this but in the past, we did that and
> came to this. The problem was no good way to all a JS app to auto discover
> things about the local network. I do think there are many ways to skin this
> cat and I’m not married to any particular one.
> >
> > An alternative solution was that the browser always use the configured
> TURN servers and ignore the JS provided ones. This does not work for apps
> where the app requires a particular TURN server. The TURN server may be
> embedded into a conference server and you have to use that one on. Or the
> TURN server may be the way gets in and out of the data center. For whatever
> reason, some apps only work with their turn servers. I could live without
> this but when we talked about it before, there seemed to be people that
> were not happy with the browser changing the TURN servers without
> interaction with the app.
> >
> > This does add to the fingerprint info - maybe. If the the browser only
> reports it when it is reachable, then it only gets reported when the
> browser is inside an enterprise that runs a TURN server. However, the IP
> address block of the HTTP requests probably reveals the same info in just
> about ever use case so it’s not clear this does increase the fingerprint.
> However, this is well worth more discussion.
> >
> > Cisco would like to see this functionality and has said so many time in
> the past. We are not the only people that have. It is pretty easy to
> implement in browsers. It may not matter much for apps not used in
> enterprises. But if web apps fail in an enterprise, then one needs to
> develop mobile and desktop apps which remove the need to do a web app.
>
> As to Youenn's suggestion of hiding the exact list - we have added APIs
> and stats that return the URL of the TURN/STUN servers used. So either
> we prevent debugging of issues with bad server configs, or we accept
> that the list of STUN/TURN servers will be revealed (which is perfectly
> sensible when there are no "hidden" servers - the app already knows.)
>
>
> --
> Surveillance is pervasive. Go Dark.
>
>