Remove no parameters support when creating a peer connection object

RESOLVED WONTFIX

Status

()

Core
WebRTC
RESOLVED WONTFIX
5 years ago
3 years ago

People

(Reporter: jsmith, Unassigned)

Tracking

({compat})

Trunk
compat
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [WebRTC][blocking-webrtc-][spec-issue])

(Reporter)

Description

5 years ago
If I execute the following line:

var pc = new mozRTCPeerConnection();

This will create a peer connection object with using the Mozilla STUN server to do remote communication. Although it's a good idea to provide a workflow to allow developers to utilize a STUN server for peer connection testing, I don't think this belongs embedded in the API for Peer Connection in itself, because this poses a compatibility risk with Chrome - Chrome doesn't have a concept of a no parameters option, so this implementation choice will only ever work in Firefox.

I think what we should do here is remove support for no parameters to point to Mozilla's STUN server and instead evangelize in developer docs that we have a sample STUN server developers can use for peer connection testing.
(Reporter)

Updated

5 years ago
Keywords: compat
Whiteboard: [WebRTC][blocking-webrtc-][spec-issue]
Note the following support in about:config for this:

  media.peerconnection.default_iceservers      = [{"url": "stun:23.21.150.121"}]
  media.peerconnection.use_document_iceservers = true

There are two features here:
 1) Provides apps access to a user-settable default.
 2) Lets users override apps with STUN/TURN servers that they prefer/trust/pay for

(We can obviously keep 2 without 1)

This seems better (more user-centric) than what Chrome offers, so maybe we should push for having it in the standard instead?

As for the compatibility risk, given that apps that follow the standard are compatible, I would weigh risk against benefit. Firefox has other unique differences, like "let" instead of "var" that are incompatible.
To clarify: my point is that pointing developers to a Mozilla server is not equivalent to this feature, so we would loose functionality by taking this away.

Come to think of it, this may not be a standards issue yet (I know I raised it). The standard says there is a configuration parameter, but it doesn't say how many servers are required in the array, or what happens if you specify zero servers in the array, or what happens if none of the servers specified are working right now. It doesn't even limit the browser to the servers specified. So I think we're into browser-dependent territory.

Everything you say about there being a cost to browser-differences is still true.
(Reporter)

Comment 3

5 years ago
(In reply to Jan-Ivar Bruaroey [:jib] from comment #1)
> Note the following support in about:config for this:
> 
>   media.peerconnection.default_iceservers      = [{"url":
> "stun:23.21.150.121"}]
>   media.peerconnection.use_document_iceservers = true
> 
> There are two features here:
>  1) Provides apps access to a user-settable default.

I'd only expect a power user who knows the exact about:config preferences to set this. Given that there's already a way to control the server on the web, I'd more likely expect the typical case to be passing in custom iceServers in the constructor, not modifying the prefs.

>  2) Lets users override apps with STUN/TURN servers that they
> prefer/trust/pay for

Is this actually safe? I would initially expect that a developer should be the one to control this, not the end-user.

> 
> (We can obviously keep 2 without 1)
> 
> This seems better (more user-centric) than what Chrome offers, so maybe we
> should push for having it in the standard instead?

I think this would be awkward to put this into a DOM spec - the gecko engine in this case gains control of what server to use in a non-webby way. If Chrome implemented this, I would expect likewise for them to use their own custom STUN server respectively.
We'd need input from jesup and ekr to challenge this feature, so I'm bringing them in here. For now I'll try to answer as best I can from my understanding of things.

I think the goal here is to give everyone the same experience, regardless of firewall.

In an ideal world there would be no need for STUN or TURN servers. The need for STUN and TURN arise in certain network configurations, and as such can be viewed as a client configuration issue as much as an app issue. Much like proxy servers, no-one *wants* to deal with them, not users and not web-developers.

As such, STUN and TURN are problems to be solved. To a web-developer, TURN users are inherently costlier. If TURN users can make themselves indistinguishable from STUN users, offloading bandwidth, would a web-developer would welcome that?

As an end-user, if I need TURN, I might be looking at a second-rate web experience, with free "STUN-only" services unavailable to me, or I might have to "pay-to-play" for what others get for free, at *each individual site*. That would stink. If Firefox let me substitute my own TURN, then I could pay once and get a good one (that I trust), then be treated like everyone else on the web.

I like webby too, but putting the whole burden of TURN on apps, I fear will lead smaller devs to simply skip it, which does not promote the same experience to everyone.

As an end-user, or a web-developer, I don't see why a browser wanting to help out here is bad (obviously, about:config is not the end GUI for anything).
Locally-defined TURN servers are critical, as corporate or educational networks might only allow traffic to transit their firewall via a corporate TURN server, or if they have a symmetric firewall they might supply a local TURN server for their users (which since it's local, wouldn't cost them more than running it on a network-facing server).
This is covered in other bugs on the mozilla stun server (no deprecated) and prefs to allow local user-defined servers
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.