[DRAFT] Web Real-Time Communications Working Group Charter

This is draft revised charter for the W3C WebRTC Working Group for discussion in the Working Group. It has no formal standing.

The mission of the Web Real-Time Communications Working Group, part of the Ubiquitous Web Applications Activity , Group is to define client-side APIs to enable Real-Time Communications in Web browsers.

These APIs should enable building applications that can be run inside a browser, requiring no extra downloads or plugins, that allow communication between parties using audio, video and supplementary real-time communication, without having to use intervening servers (unless needed for firewall traversal, or for providing intermediary services). APIs enabling supplementary functions, such as recording, image capture and screen sharing are also in scope.

Join the Web Real-Time Communications Working Group .

This proposed charter is available on GitHub . Feel free to raise issues .

Confidentiality Proceedings are public Usual
Start date [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved)
End date 31 July 2018 [ updated ] March 2020
Charter extension See Change History .
Chairs
  • Bernard Aboba (Microsoft) [ updated ]
  • Harald Alvestrand (Google)
  • Stefan Håkansson (Ericsson)
[ updated ]
Team Contacts (FTE %: 30)
  • Dominique Hazaël-Massieux
  • Vivien Lacourba
(0.4 FTE )
Meeting Schedule Teleconferences: approximately 1 per month
Face-to-face: up to 3-4 we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year year.

Scope

Enabling real-time communications between Web browsers require the following client-side technologies to be available:

Success Criteria To advance to Proposed Recommendation, each specification is expected The working group will address issues related to have two independent implementations of each feature defined using these functions in various contexts on the specification. To advance to Proposed Recommendation, interoperability between the independent implementations (that is, bidirectional audio Web platform, such as:

Out of Scope

The definition of the network protocols used to establish the connections between peers is out of scope for this group; in general, it is expected that protocols considerations will be handled in the IETF.

The definition of any new codecs for audio and video is out of scope.

Success Criteria

To advance to Proposed Recommendation, each specification is expected to have two independent implementations of each feature defined in the specification.

To advance to Proposed Recommendation, interoperability between the independent implementations (that is, bidirectional audio and video communication as well as data transfer between the implementations) should be demonstrated.

Deliverables

More detailed milestones and updated publication schedules are available on the group home page .

Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.

Recommendation-Track Deliverables Normative Specifications

The Working Group will deliver specifications that cover at least the following functions, unless they are found to be fully specified within other Working Groups' finished results:

Media Stream Functions
API functions to manipulate media streams for interactive real-time communications, connecting various processing functions to each other, and to media devices and network connections, including media manipulation functions for e.g. allowing to synchronize streams. Supplementary functions such as recording of media streams are also in scope.
Audio Stream Functions
An extension of the Media Stream Functions to process audio streams, to enable features such as automatic gain control, mute functions and echo cancellation.
Video Stream Functions
An extension of the Media Stream Functions to process video streams, to enable features such as bandwidth limiting, image manipulation or "video mute".
Functional Component Functions
API functions that allow to query for the components present in an implementation, instantiate them, and connect them to media streams.
Data Access Functions
API functions that allow Web applications to access and manipulate data in media streams.
Data Transfer Functions
API functions to provide interfaces that enable the transfer of data between peers, Included in this category are API functions for message-based as well as stream-based communications.
The WG will consider any necessary API changes or extensions to enable use of more than one data transfer protocol to support the data transfer functions.
P2P Connection Functions
API functions to provide interfaces that enable the conveyance of parameters necessary to establish peer to peer connections, based on the protocols selected by the IETF RTCWeb Working Group. Included in this category are also API functions to allow identification of the peer.

The Working Group may decide to group the specified functions in one or more specifications. specifications, and to develop extensions to its existing specifications to bring additional functionality identified as needed.

The Working Group has already started and will continue work on the following specifications:

WebRTC 1.0: Real-time Communication Between Browsers
JavaScript APIs to allow media and data to be sent to and received from another browser or device implementing the appropriate set of real-time protocols
Identifiers for WebRTC's Statistics API
Adopted Candidate Recommendation: Candidate Recommendation 02 November 2017 JavaScript APIs that allow access to statistical information about a peer-to-peer connection established via the WebRTC API
as well as
Reference Draft: Candidate Recommendation 02 November 2017
associated Call for Exclusion on the following specifications jointly developed with the Device APIs 02 November 2017 ended on 01 January 2018
Produced under 2015 WebRTC Working Group : Charter
Media Capture and Streams
JavaScript APIs that allow local media, including audio and video, to be requested from a platform
Adopted Candidate Recommendation: Candidate Recommendation 03 October 2017
Reference Draft: Candidate Recommendation 03 October 2017
associated Call for Exclusion on 03 October 2017 ended on 02 December 2017
Produced under 2015 WebRTC Working Group Charter
MediaStream Recording
a JavaScript API to record MediaStreams
Adopted Working Draft: 21 June 2017
Reference Draft: Working Draft 08 September 2015
associated Call for Exclusion on 06 February 2013 ended on 05 July 2013
Produced under 2011 WebRTC Working Group Charter
MediaStream Image Capture
a JavaScript API to capture still images from a video MediaStream
Adopted Working Draft: 21 June 2017
Reference Draft: Working Draft 09 July 2013
associated Call for Exclusion on 09 July 2013 ended on 06 December 2013
Produced under 2011 WebRTC Working Group Charter
Media Capture Depth Stream Extensions
An extension to the Media Capture and Streams API to capture depth streams (e.g. from 3D cameras)
Adopted Working Draft: 18 April 2017 Media Capture from DOM Elements
Reference Draft: Working Draft 08 December 2015
associated Call for Exclusion on 07 October 2014 ended on 06 March 2015
Produced under 2011 WebRTC Working Group Charter
Identifiers for WebRTC's Statistics API
An extension to DOM elements to JavaScript APIs that allow access to capture statistical information about a media stream from their content peer-to-peer connection established via the WebRTC API
Adopted Working Draft: 31 January 2018
Reference Draft: Working Draft 21 October 2014
associated Call for Exclusion on 23 October 2014 ended on 20 March 2015
Produced under 2011 WebRTC Working Group Charter
Audio Output Devices API
JavaScript APIs that let a Web application manage how audio is rendered on the user audio output devices
Adopted Candidate Recommendation: Candidate Recommendation 03 October 2017
Reference Draft: Candidate Recommendation 03 October 2017
associated Call for Exclusion on 03 October 2017 ended on 02 December 2017
Produced under 2015 WebRTC Working Group Charter
Screen Capture
An extension to the Media Capture and Streams API to use a user's display, or parts thereof, as the source of a MediaStream.
Adopted Working Draft: 14 July 2016
Reference Draft: Working Draft 10 February 2015
associated Call for Exclusion on 10 February 2015 ended on 10 July 2015
Produced under 2011 WebRTC Working Group Charter
Media Capture from DOM Elements
An extension to DOM elements to allow to capture a media stream from their content
Adopted Working Draft: 06 September 2017
Reference Draft: Working Draft 19 February 2015
associated Call for Exclusion on 19 February 2015 ended on 19 July 2015
Produced under 2011 WebRTC Working Group Charter
DSCP Control API
An extension to the WebRTC 1.0 API to enable experimentation with QoS marking.
Draft state: Editor's draft

The preferred mode of adding new features is by means of extension specifications, rather than new features in the existing specs. At appropriate times, the WG may choose to redistribute the work between chartered documents - by splitting, merging or repartitioning the work as appropriate.

By the end of the charter period, the WG expects to have a small number of "core" specifications, which allows useful applications to be built using only those specifications, and a series of "extension" specifications that extend the applicability of the APIs specified to more applications.

This work will be done in collaboration with the IETF. The W3C will define APIs to ensure that application developers can control the components or the architecture for selection and profiling of the wire protocols that will be have been produced by the IETF Real-Time Communication in WEB-browsers (RTCWeb) Working Group. While the specified API Functions will not constrain implementations into supporting a specific profile, they will be compatible with the Profile that will be is specified by the RTCWeb Working Group.

The highest priority of the group in this charter period will be to get the core recommendations progressed towards Recommendation status.

As the name indicates, WebRTC 1.0: Real-time Communication Between Browsers is a first version of APIs for real-time communication, sometimes referred to as the PeerConnection API. The activities in the ORTC (Object Real-time Communications) Community Group indicate that there is interest in additional APIs to provide more direct control over WebRTC than what the PeerConnection API offers.

In recognition of this interest, the Working Group will, once WebRTC 1.0: Real-time Communication Between Browsers reaches Candidate Recommendation, intends to start work on a new set of object-oriented APIs for real-time communication.

In developing these new APIs, the Working Group will adhere to the following principles:

  • Direct control: The new APIs are intended to provide direct control over the details of real-time communication, where the application can directly specify how information should be transmitted, without any built-in negotiation semantics.
  • Standalone operation: The new APIs will be complete enough to allow applications to write solely to the new APIs to complete common tasks.
  • Backwards-compatibility: The new APIs will extend the WebRTC 1.0 APIs, rather than replace them. Applications that use the PeerConnection API will continue to function, unless there is a clear and compelling reason to deprecate specific 1.0 functionality.
  • Feature independence: Features may be introduced in the new APIs that are not available when using the PeerConnection API.

A use-case document will be developed to clarify the functionality that the new APIs are to provide.

The Working Group will take the work done by the ORTC Community Group as a source of input, and when contemplating similar APIs in the Working Group, make efforts to align with the ORTC CG on API methodologies and nomenclature. This may include scheduled design meetings with relevant WG and CG stakeholders to foster convergence of the APIs.

The specified API Functions and the requirements on their implementation must offer functionality that ensures that users' expectations of privacy and control over their devices are met - this includes, but is not limited to, ensuring that users can control what local devices an application can access for capturing media, and are able to at any time revoke that access.

Similarly, all the deliverables must address issues of security. The security and privacy goals and requirements will be developed in coordination harmonized with those developed by the IETF RTCWeb Working Group.

Similarly, all deliverables must address issues of accessibility including relevant requirements listed in the Media User Accessibility Requirements document (MAUR) , such as multiple well-synchronized instances of the same media type. The accessibility goals and requirements will be developed in coordination with the Accessible Platform Architectures Working Group .

Other Deliverables

A comprehensive test suite for all features of a specification is necessary to ensure the specification's robustness, consistency, and implementability, and to promote interoperability between User Agents. Therefore, each specification must have a companion test suite, which should be completed by the end of the Last Call phase, and must be completed, with an implementation report, before transition from Candidate Recommendation to Proposed Recommendation. Additional tests may be added to the test suite at any stage of the Recommendation track, and the maintenance of a implementation report is encouraged.

In particular, since WebRTC deals with communications, specific attention will be brought to the interoperability testing of the WebRTC API implementations (both browser-to-browser and browser-to-native).

Other non-normative documents may be created such as:

  • Primers
  • Requirements and use case document for specifications
  • Non-normative group notes

Given sufficient resources, this Working Group should review other Working Groups' deliverables that are identified as being relevant to the Working Group's mission.

Milestones Timeline

Milestones Note:

The group's home page provides current data about all of the group's specifications. Although the group will document significant changes from expects all of its active deliverables to progress during this initial schedule on charter period, the group home page . Specification FPWD CR PR Rec charter does not include detailed milestone data for each specification because such data is speculative and easily becomes out of date. The Working Group does expect the following to occur:

  • Media Capture and Streams 2011-10-27 Q3 2015 Q1 2016 Streams: updated Candidate Recommendation in Q2 2016 WebRTC 1.0: Real-time Communication Between Browsers 2011-10-27 Q4 2015 2018, Proposed Recommendation in Q4 2016 2018, Recommendation in Q1 2017 MediaStream Recording 2013-02-25 2019
  • WebRTC 1.0: updated Candidate Recommendation in Q4 2015 2018, Proposed Recommendation in Q3 2016 Q1 2017 2019, Recommendation in Q4 2019
  • MediaStream Image Capture 2013-07-09 Q2 2016 Q2 2017 Q3 2017 Media Capture Depth Stream Extensions 2014-10-07 Q2 2016 Q2 2017 Recording: Candidate Recommendation in Q3 2017 Identifiers for WebRTC's Statistics API 2014-10-21 Q4 2015 Q4 2016 Q1 2017 2018
  • Media Capture from From DOM Elements 2015-02-19 Q4 2015 Element: Candidate Recommendation in Q3 2016 2018
  • Screen Capture: Candidate Recommendation in Q4 2016 Audio Output Devices API 2015-02-10 Q3 2015 2018
  • Identifiers for WebRTC Statistics: Candidate Recommendation in Q2 2016 2018, Proposed Recommendation in Q3 2016 Screen Capture 2015-02-10 2019, Recommendation in Q4 2015 2019
  • Object-oriented APIs: First Public Working Draft in Q3 2016 Q4 2016 WebRTC next version Q1 2016 2018, Candidate Recommendation in Q2 2017 Q4 2017 Q1 2018 2019
Dependencies and Liaisons

Coordination

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG . Invitation for review must be issued during each major standards-track document transition, including FPWD and at least 3 months before CR , and should be issued when major changes occur in a specification.

Additional technical coordination with the following Groups will be made, per the W3C Process Document :

W3C Groups

HTML Web Platform Working Group
The HTML Web Platform Working Group defines a number of markup elements and APIs that serves as the basis on which the RTC APIs have been developed; in particular, several specifications of this group extends the <audio> and <video> elements. Web Applications Working Group Some of the Web Applications Working Group APIs (such as the Web Sockets API) have served as inspiration or starting points for the APIs developed by the WebRTC Working Group. The work on Push Notifications provides an important feature for many WebRTC use cases. developed. In addition, all the APIs developed by this group are based on WebIDL which the Web Applications Platform Working Group is specifying.
Device APIs Devices and Sensors Working Group
The Device APIs Devices and Sensors Working Group jointly develops the media capture-related APIs to access sensors which have similarities with this group. APIs needed to access media devices. The group was also initially involved in the design of the media capture APIs.
Audio Working Group
The API developed by the Audio Working Group builds upon the MediaStream object built by this group; further collaboration on the management of audio output device is expected.
Web Application Security Working Group
The Web Application Security Working Group is developing guidance on APIs that expose sensitive information, and an API to manage permissions, both of which matter to several of this group specifications.
Web Cryptography Working Group WebRTC connections are encrypted end-to-end; collaboration is expected with the Web Cryptography Working Group on exposing and manipulating some of the cryptography functions used. Second Screen Presentation Working Group
The Second Screen Presentation Working Group is developing APIs to allow rendering of media on secondary devices; potential overlap with features enabled by the Audio Output Devices API will need to be looked at.
WAI Protocols and Formats Web Performance Working Group
Reviews from the WAI PF The Web Performance Working Group will be required to ensure the APIs allow to create an accessible user experience. share goals and characteristics with the WebRTC Statistics API.
Web Media and TV Entertainment Interest Group
Work on gathering use cases and requirements for Home Networking scenarios within the Web Media and TV Entertainment Interest Group may uncover aspects that affect the design of real-time communications functions. The WebRTC Working Group will coordinate with the Web and TV Interest Group on these use cases and requirements as appropriate.

External Organizations

Privacy Interest Group IETF Applications and Real-Time Area (ART)
Several of the specifications The RTC APIs developed by this group have potential impact on will build upon the privacy protocols and formats developed in the IETF RTCWeb Working Group. Subsequent to the termination of that WG, this WG will liaise with other groups of users; reviews from the privacy ART area and elsewhere in the IETF as appropriate; of particular interest group will be sought on these specifications. are the MMUSIC, AVTEXT, ICE and QUIC working groups.
Web Security Interest IETF Transport Area Working Group (TSVWG)
Several of the specifications developed by this group have a complex impact The TSVWG develops SCTP on the security model of the Web; reviews from the Web Security Interest Group will be sought. which WebRTC data channels relies.
External Groups
IETF Real-Time Communication in WEB-browsers group Web Hypertext Application Technology Working Group (RTCWeb) (WHATWG)
The RTC APIs developed by this group will build upon potentially reference the protocols Fetch, Streams and formats developed in the IETF RTCWeb Working Group, which will in general handle dependencies to other IETF Working Groups. API specifications maintained by the WHATWG

Participation

To be successful, the Web Real-Time Communications this Working Group is expected to have 10 6 or more active participants for its duration. Effective participation to Web Real-Time Communications Working Group is duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to consume one work contribute half of a working day per week towards the Working Group. There is no minimum requirement for each participant; two days per week for editors. other Participants.

The Web Real-Time Communications Working Group will allocate group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication .

The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the necessary resources terms of the W3C Patent Policy .

Communication

Technical discussions for building Test Suites this Working Group are conducted in public : the meeting minutes from teleconference and face-to-face meetings will be archived for each specification. public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on a public repository, and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.

Participants are reminded of Information about the Good Standing requirements group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the WebRTC Working Group home page.

Most WebRTC Working Group teleconferences will focus on discussion of the W3C Process. particular specifications, and will be conducted on an as-needed basis.

Communication

This group primarily conducts its technical work in its repositories' GitHub issues and on the its public mailing list public-webrtc@w3.org ( archives ). The public is invited to review, discuss and contribute to this work.

The group uses may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and participants members of the group, for Member-only member-only discussions in special cases when a particular participant requests such a discussion.

Information about the group (deliverables, participants, face-to-face meetings, teleconferences, etc.) is available from the Web Real-Time Communications Working Group home page .

Decision Policy

As explained in the Process Document ( section 3.3 ), this This group will seek to make decisions when there is consensus. When the Chair puts a question through consensus and observes dissent, after due consideration process, per the W3C Process Document (section 3.3 ). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of different opinions, the Chair should record a decision (possibly after a formal vote) group and any objections, other reviewers, and move on. consensus emerges with little formal voting being required.

After mailing list and other informal discussion, substantive change proposals should be submitted as GitHub pull requests. These can come from the editors or from WG members.

Chairs are responsible for determining whether or not there is WG consensus for the changes contained in a pull request.

Editors are responsible for “curating” the pull requests to reject frivolous ones and substantive ones that the Chairs have determined do not comply with the IPR policies.

In cases where the editors make substantive changes without WG consensus, those changes must be labelled labeled as provisional. The chairs are responsible for resolving the status of such changes.

When the Chair puts a question and observes dissent, after due consideration of different opinions, the Chair should record a decision (possibly after a formal vote) and any objections, and move on.

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

All decisions made by the group should be considered resolved unless and until new information becomes available, or unless reopened at the discretion of the Chairs or the Director.

This charter is written in accordance with the W3C Process Document (Section 3.4, Votes) , and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). Version updated 1 August 2017). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis. For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation .

Licensing

This Working Group will use the W3C Software and Document license for all its deliverables.

About this Charter

This charter for the Web Real-Time Communications Working Group has been created according to section 6.2 5.2 of the Process Document . In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Charter History

This charter updates and replaces the first WebRTC Working Group charter approved in 2011. This charter was udpated on September 13 2016 to reflect the change of Chairs The following table lists details of all changes from the group, as Erik Lagerway stepped down, having chaired since June 2015. initial charter, per the W3C Process Document (section 5.2.3) :

Charter Period Start Date End Date Changes
Initial Charter 5 May 2011 30 September 2015 N/A
Rechartered 27 July 2015 31 March 2018 This charter ought to have been udpated on February 3 2017 to reflect reflected the addition of Bernard Aboba (Microsoft) as co-chair actual split of the various features identified in well-defined specifications, and added WebRTC NV in scope for the group. This charter was udpated on March 29 2018 to reflect a 2 months charter extension from March 31st 2018 to May 31st 2018. This charter was udpated on June 1st 2018 to reflect a 2 months charter extension from May 31st 2018 to July 31st 2018.
Rechartered @@@ @@@ @@@