PR Request for Web Real-Time Communications webrtc

[dontcallmedom]

Document title, URLs, estimated publication date

WebRTC 1.0: Real-Time Communication Between Browsers
https://w3c.github.io/webrtc-pc/webrtc.html
Publication date: shortly after approval

Abstract

This document defines a set of ECMAScript APIs in WebIDL to allow media to be sent to and received from another browser or device implementing the appropriate set of real-time protocols. This specification is being developed in conjunction with a protocol specification developed by the IETF RTCWEB group and an API specification to get access to local media devices.

Status

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

The API is based on preliminary work done in the WHATWG.

The specification is feature complete and is expected to be stable with no further substantive change. Since the previous Candidate Recommendation Snapshot, the voiceActivityFlag featured who had been marked at risk has been removed from the specification.

Its associated test suite has been used to build an implementation report of the API.

This document was published by the Web Real-Time Communications Working Group as a Proposed Recommendation. This document is intended to become a W3C Recommendation.

GitHub Issues are preferred for discussion of this specification. Alternatively, you can send comments to our mailing list. Please send them to [email protected] (archives).

Publication as a Proposed Recommendation does not imply endorsement by the W3C Membership.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The W3C Membership and other interested parties are invited to review the document and send comments through @@@. Advisory Committee Representatives should consult their WBS questionnaires. Note that substantive technical comments were expected during the Candidate Recommendation review period that ended 24 September 2020.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 15 September 2020 W3C Process Document.

Link to group's decision to request transition

https://lists.w3.org/Archives/Public/public-webrtc/2020Nov/0066.html

Changes

22 non-substantive pull requests were merged since the previous Candidate Recommendation Snapshot.

A minor but implementation-impacting change was also merged to correct a bug, after implementors confirmed their intent to align with the said change:
w3c/webrtc-pc#2611
w3c/webrtc-pc#2603

Requirements satisfied

No change since the last transition to CR

Dependencies met

Normative dependency to W3C specs who haven't reached PR yet:

• File API (WD)
• GETUSERMEDIA (CR)
• WebRTC Stats (CR)
• WEBIDL

Dependency to WHATWG: Living Standards

• DOM
• Fetch
• HTML
• Infra

Dependency to IETF documents in RFC Ed queue:

• BUNDLE
• JSEP
• MMUSIC-RID
• MMUSIC-SIMULCAST
• RTCWEB-RTP
• SCTP-SDP
• TRICKLE-ICE

The Working Group estimates that these dependencies are unlikely to create disruption for WebRTC implementations.

Wide Review

No change since the last transition to CR. See the note about a still pending privacy issue below.

Issues addressed

The Working Group addressed 13 non-substantive issues since the previous Candidate Recommendation snapshot.

A privacy-related issue (getCapabilities and its fingerprint impact) requires coordinated cross-group cross-spec mitigations which the Working Group does not expect to address it in the timeframe of WebRTC 1.0 and has thus moved to its next generation work:
w3c/webrtc-extensions#54

Formal Objections

None

Implementation

Every feature not marked at risk of the WebRTC 1.0 specification has been demonstrably and independently implemented in two browsers:

• A few mandatory-to-implement stats which have not been implemented anywhere, but are not critical to real-world interoperability and which implementers are committed to provide in the upcoming weeks.
• The RTCSctpTransport and RTCIceTransport interfaces have been implemented in only one current browser; other browser vendors have indicated their intent to eventually ship these, and these interfaces have also received implementation experience outside of current browsers (in the old Edge Spartan, in orclib, in the Meedooze server).
• RTCRtpSender.setStreams() is only implmented in a single browser, but is expected to land in more browsers in the near future.
• the closing event for RTCDataChannel is implemented in only one browser, but is expected to land in more browsers in the near future.
• the way browsers report errors occuring during WebRTC operations is not fully aligned with the specification (e.g. using OperationError instead of RTCError, or using SyntaxError instead of InvalidAccessError)

Given the implementors commitment for these features and given their relative low real-world interoperability impact, the Working Group is confident that these implementation gaps are unlikely to require substantive change to the specification as implementations catch up. Should this prove necessary, the Working Group will take advantage of the 2020 W3C Process for normative correction of bugs.

As a result of this implementation analysis, the WebRTC Working Group estimates that the implementations of the current WebRTC 1.0 are sufficient to proceed with publication as a W3C Recommendation under the 2020 W3C Process.

See the implementation report for more details.

Patent disclosures

None

[swickr]

Looking at w3c/webrtc-extensions#54 as it seems the current sync API is acknowledged to not always be able to return accurate information. I wonder if it would be better to take the time to design the async API call, address the fingerprinting concern, and do another CR Update rather than publish a Recommendation with both a privacy and a logical flaw. How long might this take, understanding that we would also need to demonstrate implementability?

Some of the IETF normative references are long expired, though there are apparently updates in the RFC ed queue. What are the underlying issues for these being expired documents?

In the implementation report there are several entries in which the notes cell is outlined in red. What is the significance of that notation?

[dontcallmedom]

Looking at w3c/webrtc-extensions#54 as it seems the current sync API is acknowledged to not always be able to return accurate information. I wonder if it would be better to take the time to design the async API call, address the fingerprinting concern, and do another CR Update rather than publish a Recommendation with both a privacy and a logical flaw. How long might this take, understanding that we would also need to demonstrate implementability?

There is no consensus in the group (and in particular among implementors) that w3c/webrtc-extensions#54 is a problem that needs addressing; recent discussions have also highlighted that this would likely be fixed very differently than making the call asynchronous, since there is Media Capabilities proposal under discussion that would likely work better. Conversely, the current synchronous API is too widely used and adopted for us to consider removing it in a short-to-medium timeframe.

With regard to privacy, as indicated above, fixing it is a many months effort at the very least, with no clear roadmap at this point; as my reference to Media Capabilities illustrates, it has many moving pieces that are at very different level of maturity and stability than WebRTC 1.0, which is why we think it is better addressed in a different release cycle.

Some of the IETF normative references are long expired, though there are apparently updates in the RFC ed queue. What are the underlying issues for these being expired documents?

I'm not sure which updates you're referring to - as far as I could determine, all the relevant specs are either in AUTH48 or AUTH48-DONE states, which (if I understand right) means they need their authors attention for one last round of review. In any case, given the broad adoption of the protocols & APIs, backwards-incompatible changes in the said IETF specs at this stage of their maturity seem extremely unlikely.

In the implementation report there are several entries in which the notes cell is outlined in red. What is the significance of that notation?

The dangers of a living implementation report! the cells outlined in red are ones that have appeared since the transition request was submitted, which itself means they correspond to test cases that have been added to the suite since the request was submitted; in the context of this transition request, I submit they are a demonstration of the group's commitment to keep improving its test suite and implementations over time (from a quick glance, they do not highlight any new implementation gap)

[swickr]

Transition approved.

Thanks for this explanation, Dom. Please make a snapshot of the implementation report and cite this in the SoTD. (You may also link to the live implementation report as well.)

[plehegar]

https://www.w3.org/TR/2020/PR-webrtc-20201215/