Members of the Advisory Committee, thank you for the opportunity to bring you up to date on the status of the WEBRTC Working Group, on behalf of the Chairs: Bernard Aboba (your presenter today), Harald Alvestrand and Jan-Ivar Bruaroey.

What we’re chartered to do. Finishing WebRTC 1.0 is our highest priority. Beyond this, we are developing requirements for “WebRTC-Next Version Use Cases”, which require new APIs, as well as protocol work. We are also working on supporting specifications, such as WebRTC-Stats, which provides telemetry for WebRTC applications, specifications for audio output and media recording and the acquisition of media from devices, screens, DOM elements and the like.

What our environment demands. With much of the world is “sheltering in place”, WebRTC has become essential to daily life. The usage of realtime communications has skyrocketed, jumping by an order of magnitude, and so it is critical that WebRTC “just work” across all browsers and networks.

Looking forward, we are seeing demand for low level access to both encoded and raw audio and video. We have also discussed new data access approaches, such as peer-to-peer data exchange in workers.

Finally, with “low latency streaming” technology used in Cloud Gaming as well as Large Meeting scenarios, it appears that “streaming media” and “realtime communications” scenarios are converging, raising the question of whether a unified set of tools can enable both streaming and realtime media scenarios on the Web.

WebRTC 1.0 The WebRTC 1.0 specification has been recycled at CR and we now are preparing a “final CR”. The features that are considered “at risk” (not yet implemented in any browser) have been identified and are being removed or moved to other specifications.

We measure progress toward Proposed Recommendation in two ways: via the Web Platform Tests, which measure API conformance, and via the confluence map, which measures implementation completeness. The WPT tests show many issues, but also lots of interoperability. One of our current projects is to assess the test coverage of advanced features such as simulcast. These features are difficult to test in WPT because they involve at least three parties: two browsers and a conferencing server. Recently we have added a simulcast loopback test in WPT, and are looking to evolve it to improve coverage.

Another way we measure progress is via the confluence map, which tracks implementation completeness. This shows steady progress in the last year. All features not marked as “at risk” have been implemented in at least one browser. Prior to the pandemic, we expected that many of the features implemented in only one browser would be ported to other browsers by fall of this year. The Pandemic has slowed progress somewhat.

Measurements indicate that much of the usage of the WebRTC API comes from “trackers” (applications which don’t call both setLocalDescription and setRemoteDescription). So security and privacy concerns have risen in importance. Privacy concerns relate to address snooping and port scanning is a security issue. Address snooping has been addressed by limiting access to candidate addresses in the absence of permissions. Addressing port scanning will require implementation changes, and some additions to the security and privacy section of the specification.

Media capture and streams. Media Capture and Streams has been recycled at CR. The WPT test results show many features working in 75 percent of browsers, and the overall sense is that this API works.

There are also privacy concerns relating to fingerprinting, because the “application picker model” enables an application with permission to access information on all devices so that it can present its own interface to the user. In contrast, the Screen Capture specification utilizes a “Browser Picker” model where the application, once granted permission, only gets information relating to devices selected by the user. The working group is currently discussing how to transition from the “Application Picker” model to the “Browser Picker” model without breaking applications. Jan-Ivar Bruaroey of Firefox is leading the effort on this.

Note - interoperability matrix run for Chrome seems bogus.

WebRTC NV Use Cases. The Next Version use cases fall into two categories: new use cases and improvements to existing use cases identified in RFC 7478, the original WebRTC Use Cases document. Within improvements to existing use cases, we have enhancements to multi-party online games with voice, enhancements to large video conferences, and enhancements for applications running on mobile devices. Two specifications have been developed to address these use cases: WebRTC-SVC which extends WebRTC to support Scalable Video Coding, and WebRTC-ICE, which provides low level control of NAT traversal.

For new use cases we have peer-to-peer file sharing which uses the WebRTC data channel, an “Internet of Things” use case for devices such as smart speakers or doorbell cameras and use cases requiring access to raw video such as “funny hats”, and “machine learning” models. There is also a Virtual Reality Gaming use case, where metadata is sent along with the media, and a secure video conferencing use case. These last two use cases require access to encoded media.

WebTransport and WebCodecs. Today, streaming and realtime media use different APIs for discovery and control of codecs as well as different transport protocols. The WebTransport and WebCodecs specifications are being incubated in WICG to answer the question whether a single set of APIs and protocols can be provided to address both scenarios.

WebTransport aims to provide transports for both streaming and realtime scenarios. This is achieved by leveraging QUIC reliable streams (used for file transfers and conventional streaming) as well as unreliable datagram transport (used for realtime communications and low-latency streaming). Design of the WebTransport protocols is handled in the IETF WEBTRANS Working Group, and the Charter for a corresponding W3C WebTransport Working Group is under development.

WebCodecs, in the early stages of incubation, is an attempt to provide unified support for codec capability discovery as well as low-level access to encoded and raw media for both streaming and realtime communications scenarios. Functionality not covered by either WebCodecs or WebTransport, such as packetization, would be handled in WebAssembly.

This presentation has provided a bird's eye view of the WEBRTC Working Group. The bird that most reminds me of the WEBRTC WG is the Roseate Spoonbill, a rose colored bird that, at a distance, might be mistaken for a Flamingo. The Roseate Spoonbill is said to be “gorgeous at a distance, but bizarre up close”. Like the Spoonbill, WebRTC APIs may appear simple at a high level, but are quite complex for application developers. With its distinctive bill that resembles a long spoon, the Spoonbill can be said to be a bit “Nosy”, reflecting some of WEBRTC’s privacy concerns. Our hope is that the next generation of media technologies is less complex as well as being less “nosy”.

Thank you for your time. I would also like to thank the W3C Staff, and the participants, editors and chairs of the WEBRTC Working Group.