Meeting Notes for June 11, 2019 WebRTC WG Meeting

Slides here
<https://docs.google.com/presentation/d/1UrXARLbAfwmfK686rX_9W_-FGIc62ZDwVd079wIoX7I/edit?usp=sharing>
.

WebRTC-ICE Issues

PR 22: Is there interest?

Question: How is this granularity useful? Use case: bring up TURN candidate
immediately, change nomination from the app.


Action item: Announce to the list - interest from implementers and
developers? If no interest, should we abandon it?

Media Capture Issues

PR 587: There is support for the PR.

PR 595: Does it make current implementations non-compliant? Yes, in some
cases, but not in the enumerateDevices() use case.

Can we solve this for deviceId specifically rather than for all constraints?

Support for narrowing it down of deviceId.


Action Item: Youenn to update the PR to say that empty string is a special
value for deviceId. Goal: No change for other implementers.

WebRTC-NV Use Cases

PR 21:

Untrusted JS: Implementation discussions. Reformulate to say what we want
to protect. More high-level. What exactly are the security
requirements/features?

Trusted JS: Without isolating streams. The JS is trusted, the media server
is not. The media needs to be encrypted not known by the media server.

These are two valid use cases. Obfuscating camera and microphone requires
isolated streams. Audio level may leak who is talking. What are the
security and privacy requirements? What are the use cases?


Action Item: Bernard to update the PR.

Issue 5/PR 32: There is support for the PR.

Issue 15: Want to connect with less round trips, to be able to send an
answer before setting the offer. This is useful for many other use cases.
Want to be able to disconnect and then reconnect later without signaling
again. Want to be able to listen in a worker thread. Would ORTC and QUIC
solve all of these use cases? Do you really need WebRTC for data channels?

The essence: You should be able to connect peers effectively without
involving a signaling service, and you want to be able to be connected to
multiple peers at the same time. RTCPeerConnections are expensive.

Action Item: Feross/Lenard to refine the requirements.

WebRTC-PC Issues

PR 2175: Discussions: Should it be static, promise, etc? Should it be NV or
1.0? Does it need to be in the WebRTC spec? Should it be an extension spec?
Only in some cases would “direct-connection” have an effect.

PR 14: Same as above but NV.

Support for adding this to NV. Needs review.

Issue 2167 and other slides: This was supposed to be the last chance to
propose significant changes to 1.0 but we ran out of time. Jan-Ivar's
slides here are to be the focus of next Virtual Interim in July.