Sorry for the noise but +1000.

I completely agree with @steely-glint.

WebRTC is the only way of implementing ultra-low-latency real-time streaming on the Web. WebRTC is increasingly used for one-way real-time streams, rather than for two-way communications.

Requiring user permission for ICE candidate discovery is perfectly reasonable. However, doing that via getUserMedia is a round hole, and assumes that all WebRTC applications are round pegs. My consumer-only application seems to be a square peg.

Perhaps we can have a dedicated permissions request mechanism for cases where GUM isn't used.

Completely agreed. A permission request just for creating PeerConnections would fix this.

Another datapoint here :) I work on a project where we provide a web application that can connect to a smartphone app and exchange data. We are perfectly fine asking the user for "permission to establish a direct connection", but "please let us access your microphone and camera in order to load data from your smartphone" is definitely a no-go, no matter how much you explain it to the user.

When the alternative is using TURN servers to relay all data, then what is the point of using WebRTC in the first place?

Now, I can already hear "but there is NAT hair-pinning!". But:

1. There are more routers that don't support NAT hair-pinning than you would think. The amusing result is that a relay connection is being established when both are in the same network. And a direct connection is being established only when both aren't in the same network.
2. Quite a substantial amount of ISPs (often cable providers) use DS-Lite where NAT hair-pinning lets all IPv4 data flow to the DS-Lite Gateway and back again. Which of course applies all limits of your broadband connection.

@steely-glint @lgrahl It seems that several use cases may have a requirement for support of one-way media and related permissions support. This requirement comes up not only in IoT, but in scenarios such as MOOCs (where gUM may not be called until the student asks a question).

I'd also argue that overloading gUM as a universal permissions mechanism for WebRTC 1.0 is becoming unworkable. So we probably need to address the permissions issue for WebRTC 1.0 as well as NV.

We're having a lot of issues with the new Chrome 77 update and connecting our end users to our deployed IoT devices with a one way connection... Any update on this? Asking a user for microphone/camera to connect them to their toaster is undoable 😂. Is there anything we can do in the meantime to fix our product?

@bfitec can you file a bug at http://crbug.com? Chrome should be able to reach your device without any additional permissions.

@bfitec If you do file a bug - please let me know - I'd be happy to chime in.
Alternatively email me and I'd be happy to discuss mitigations.

@steely-glint would you be willing to do a post on webrtchacks regarding this? If you control one of the endpoints a direct connection should be possible with or without mDNS.

TBH I think the OP description on this issue is incorrect; no new API surface is needed for these scenarios. @steely-glint, please clarify or close this issue.

@juberti I've had problems connecting over a relay after Chrome 77. Chrome is telling my STUN/TURN servers that the browser "hostCandidate" is null (hostCandidate: "[0:0:0:x:x:x:x:x]:58670") then the STUN/TURN says something around about 'Host lookup failed' preventing my relay from establishing the connection. I'm really frustrated, our business relies on this so I would really appreciate any help and hope it doesn't necessitate us waiting on another Chrome update.

Here is the w3c description of hostCandidate (https://w3c.github.io/webrtc-pc/#attributes-6):

hostCandidate of type DOMString, readonly

The hostCandidate attribute is the local IP address and port used to communicate with the STUN or TURN server.

On a multihomed system, multiple interfaces may be used to contact the server, and this attribute allows the application to figure out on which one the failure occurred.

If use of multiple interfaces has been prohibited for privacy reasons, this attribute will be set to 0.0.0.0:0 or [::]:0, as appropriate.

Chrome doesn't send hostCandidate to the TURN servers; that's provided to the JS application.

Also, do you know who is looking up hostCandidate? That seems rather strange too.

@bfitec, any more thoughts on this?

Putting mDNS aside, I think this is also (if not mainly) about mode 1 vs mode 2/3 (or "default mode" vs "best available mode"). The above mentioned use cases should also be able to leverage themself into the "best available mode" just as gUM usually does nowadays. And that issue can be resolved by e.g. w3c/webrtc-pc#2175 or merging #14.

While that makes sense in theory, I think you'll need to show a more specific need regarding why the current APIs are insufficient. I actually think this particular bug is underspecified and perhaps should be closed.

I've stumbled on an interesting example - admittedly under tested, since I don't have access to the relevant hardware ;-)
The latest Tesla software update ships with chromium as the browser with working webRTC, but no input media (as far as I can tell) or mdns. This means that a smartphone inside the tesla can't send webRTC video directly to the screen, it has to use an external TURN server.
I'd be happy to work with an owner to help specify this bug!

I don't follow the reasoning. The Tesla implementation should hand out host IPs, right? And if not, the smartphone will. So what's the issue?

Sorry, to be clear, both ends of this scenario are browsers. I am assuming that the smartphone is running latest chrome.
The tesla has a web browser (URL bar and all) which is a port of chromium - so I assume when they upgrade to 78 then it won't send host IPs unless it has GUM - which it won't since it has no User Media available (as far as I can tell).
Chrome/safari on smartphone won't supply host candidates unless we do GUM (which is the subject of this bug).

I'd be very surprised if tesla added mdns support to the MCU's os.

OK, that helps. But still, Tesla and phone will both be on separate cell networks and a direct host-host connection won't be possible, right? (unless you're sitting in your garage with wifi)

Turns out that the video tag is disabled unless you are in 'park' so being on wifi (or tethered to the smartphone) is a pretty plausible situation.

Tethering a Tesla to a smartphone seems like a true corner case; if you could do the reverse it would be a more plausible scenario. Regardless, I agree with the meta-point; when both ends support only mDNS, a direct connection is not possible in some cases. (Suggest the bug title and description be updated accordingly.)