W3C WebRTC
WG Meeting
January 18, 2022
8 AM - 10 AM
1
Chairs: Bernard Aboba
Harald Alvestrand
Jan-Ivar Bruaroey
W3C WG IPR Policy
2
Welcome!
3
About this Virtual Meeting
4
W3C Code of Conduct
5
Virtual Interim Meeting Tips
This session is being recorded
6
Understanding Document Status
7
Recent CfAs and CfCs
8
Recent CfAs and CfCs (Cont’d)
9
Issues for Discussion Today
Time control:
10
WebRTC-NV Use Cases
(Tim Panton & Kegan Dougal)
End Time: 8:35 AM
11
WebRTC-NV Use Cases
PR (https://github.com/w3c/webrtc-nv-use-cases/pull/73) merged�to reflect Dec-21 interim discussion:
Please review and provide your thoughts. Preview:
https://pr-preview.s3.amazonaws.com/pipe/webrtc-nv-use-cases/pull/73.html ��Invited expert input on “3.4 Decentralized messaging” �Thanks to Kegan from matrix for agreeing to help us.
�
12
Background: Matrix
13
History of P2P Matrix
14
P2P Matrix Architecture
Pinecone (our P2P overlay network) works in a range of environments
15
Design Considerations and Constraints
16
Anti-goals
17
Proposals (one of, preferred first)
For prototyping with WebRTC in-browser, we’ll probably use libp2p initially.
18
Discussion (End Time: 8:35 AM)
19
mediacapture-transform (Harald)
End Time: 08:55 AM
20
Mediacapture-Transform: FPWD
This specification has been adopted by the WG.
The next step is First Public Working Draft publication.
FPWD publication triggers licensing requirements on WG members.
21
WD publication requirements
https://www.w3.org/2021/Process-20211102/#RecsWD
22
Open issues on this spec
23
Suggested dispositions (1)
24
Suggested disposition (2)
25
Call For Consensus for FPWD
In my opinion, none of the issues are blocking for issuing a FPWD CfC.
Obvious WG disagreements are documented; other issues are not important enough to block FPWD publication.
We should issue the CfC right after this meeting.
26
CfC - possible responses
We will ask for members to respond in one of two ways:
If there are objections, we will discuss and attempt to resolve the issues, and evaluate afterwards whether we need a new CfC or not.
If there are none, we will ask W3C to publish this document as a FPWD.
Raising and resolving editorial issues can be done at any time.
27
Discussion (End Time: 08:55 AM)
28
WebRTC-Extensions (Bernard)
End Time: 9:10 AM
29
30
31
await Promise.all([
sender.generateKeyFrame()/transformer.generateKeyFrame(),
sender.transform.setEncryptionKey(newKey, newKeyId)
])
32
Discussion (End Time: 9:10 AM)
33
Capture Handle (Elad)
End Time: 09:50 AM
34
Capture Handle - Reminder 1/2
Presently, the user knows what they chose to capture, but VC-App does not. The VC-App cannot do much more than pipe the pixels to remote users.
Assume a video-conferencing application (VC-App) is display-capturing another tab, where a slides-presenting application lives (Slides-App).
What if the user, while engaged with VC-App, wishes to navigate Slides-App to the next slide? The user would have to switch tabs. Repeatedly.�Quite distracting.
35
Capture Handle - Reminder 2/2
I have previously proposed a mechanism that allows applications to declare their identity to capturing applications. This allows cooperating applications to bootstrap communication.
For example, given shared cloud infrastructure, the capturee can advertise its ID. When the capturer gets that ID, it can send the captured messages via that infrastructure. These messages can be simple (prev/next-slide) or arbitrarily complex.
Example follows.
36
Capture Handle Identity - Example 1/2 (Capturee)
37
function onPageLoaded() {
...
setCaptureHandleConfig({
// Expose the origin of the THIS document.
exposeOrigin: true,
// Expose some ID meaningful in a shared cloud infrastructure.
handle: getSessionId(),
// Allow anyone to read the above info (origin and handle).
permittedOrigins: ['*']
});
...
}
Capture Handle Identity - Example 2/2 (Capturer)
38
function startCapture() {
const stream = await navigator.mediaDevices.getDisplayMedia();
const [track] = stream.getVideoTracks();
if (track.getCaptureHandle) { // Feature detection.
// Subscribe to notifications of the capture-handle changing.
track.oncapturehandlechange = (event) => {
OnNewCaptureHandle(event.captureHandle());
};
// Read the current capture-handle.
OnNewCaptureHandle(track.getCaptureHandle());
}
}
function OnNewCaptureHandle(captureHandle) {
if (captureHandle.origin != 'slides-3000.com')
return;
// Exposes prev/next buttons to the user. When clicked, these send
// a message to some REST API, where |sessionId| indicates that the
// message has to be relayed to the Slides 3000 session in question.
ExposeSlides300Controls(captureHandle.handle);
}
Capture Handle Actions
39
The aforementioned proposal works for closely cooperating applications.
What about less tightly bound applications?
We can do something there, too, using another mechanism. Namely, the capturee could advertise what actions it supports (e.g. prev/next), and the capturer could expose user-facing controls based on that.
It’s an open question whether these the two mechanisms belong together. Let’s name them for the time being:
Capture Handle Actions API (Capturee)
40
We define a set of supported actions:
CaptureActions := [“first”, “prev”, “next”, “last”, ...]
We expose a control for top-level documents to declare the actions they support. (Throws if called from non-top-level document.)
MediaDevices.setSupportedCaptureActions([“prev”, “next”]);
We expose a control for top-level documents to set a handler.
MediaDevices.setCaptureActionsHandler(handler);
Open question - besides the action, what else should be contained in the events which are passed to the handler. Origin of sender? Opaque source identifier?
Capture Handle Actions API (Capturer)
41
On the video MediaStreamTrack returned by getDisplayMedia(), we expose:
// Returns set of actions supported by the application
// associated with the video track.
// (If not a video track associated with tab-capture - empty.)
MediaStreamTrack.getSupportedCaptureActions();
// If this MediaStreamTrack is a video track associated with
// tab-capture, and if the top-level document in that tab
// registered a CaptureActionsHandler, fire an event for that
// handler with this |capture_action|.
MediaStreamTrack.sendCaptureAction(capture_action);
Capture Handle Actions API - Known “Issue”
42
Note that the captured tab’s top-level frame could be navigated at any time. This means that the message sent from the capturer to the capturee could be asynchronously delivered to an “unintended” recipient. However, since this mechanism (Capture Handle Actions) is intended for use when the capturer/capturee do not know each other anyway, and have no other channel for communication, this is not an issue; the process is user-controlled, and this edge case is equivalent to the user pressing “next slide” on their keyboard at an inopportune time in a single-tab experience. Put another way, it’s orthogonal to the capture.
The mechanism of Capture Handle Identity is robust to captured-tab navigation.
Capture Handle - Need for Both APIs
43
We have previously discussed why the Identification mechanism would still be needed even if the Actions mechanism is introduced. To recap some arguments briefly:
Discussion (End Time: 09:50 AM)
44
Thank you
Special thanks to:
WG Participants, Editors & Chairs
45