[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 30 September 2015 [ updated ] 2022
Charter extension See Change History .
Chairs
  • Harald Alvestrand Bernard Aboba (Microsoft)
  • Stefan Håkansson Harald Alvestrand (Google)
  • Erik Lagerway [ updated] Jan-Ivar Bruaroey (Mozilla)
Team Contacts (FTE %: 30)
  • Dominique Hazaël-Massieux [ updated]
  • Vivien Lacourba [ updated] Carine Bournez
(0.4 FTE )
Meeting Schedule Teleconferences: approximately 1 per week 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:

The working group will address issues related to using these functions in various contexts on the Web platform, such as:

Until another group can take it over, the working group will also complete and maintain specifications that address the following functions:

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 between the implementations) should be demonstrated.

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 normative specification is expected to have two independent implementations of every 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 Working Group will deliver specifications that cover at least the following functions, unless they are found to be fully specified within other working groups' Working Groups' finished results:

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.
Network Management Functions
API functions to provide control on network traffic characteristics such as congestion control, bandwidth limitation, or latency.

The Working Group will deliver specifications that cover the following functions until another group becomes available to take that work over:

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, backpressure control, 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.
P2P Connection Data Access Functions
API functions to establish peer-to-peer connections between that allow Web browsers, independent of the network protocols used applications to establish the connections between peers. access and manipulate data in media streams.

The working group 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.

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

WebRTC 1.0: Real-time Communication Between Browsers
A JavaScript API to allow media to be sent to and received from another browser or device implementing the appropriate set of real-time protocols.
Expected completion: Q4 2020
Adopted Candidate Recommendation: 13 December 2019
Reference Draft: 13 December 2019 Candidate Recommendation
associated Call for Exclusion on 13-Dec-2019 ended on 11-Feb-2020
Produced under Working Group Charter: https://www.w3.org/2018/07/webrtc-charter.html
Identity for WebRTC 1.0
A JavaScript API to allow an application using WebRTC to assert an identity, and to mark media streams as only viewable by another identity
Draft State: Candidate Recommendation
Adopted Candidate Recommendation: 27-Sep-2018
Reference Draft: https://www.w3.org/TR/2018/CR-webrtc-identity-20180927/
associated Call for Exclusion on 27-Sep-2018 ended on 26-Nov-2018
Produced under Working Group Charter: https://www.w3.org/2018/07/webrtc-charter.html
Identifiers for WebRTC's Statistics API
JavaScript APIs that allow access to statistical information about a peer-to-peer connection established via the WebRTC API
Expected completion: Q2 2021
Adopted Candidate Recommendation: 31 January 2018
Reference Draft: 14 January 2020 Candidate Recommendation
associated Call for Exclusion on 14-Jan-2020 ended on 14-Mar-2020
Produced under Working Group Charter: https://www.w3.org/2018/07/webrtc-charter.html
WebRTC Priority Control API
An extension to the WebRTC 1.0 API for manipulating the network control bits (DSCP bits) of outgoing WebRTC packets and to enable queuing priority of outgoing WebRTC packets under congestion.
Adopted Working Draft: 23 January 2020
Reference Draft: https://www.w3.org/TR/2018/WD-webrtc-dscp-20180703/
associated Call for Exclusion on 03-Jul-2018 ended on 30-Nov-2018
Produced under Working Group Charter: http://www.w3.org/2015/07/webrtc-charter.html
MediaStreamTrack Content Hints
An extension to Media Capture and Streams to provide a hint on how to encode or process track media based on the type of content that is being consumed
Adopted Working Draft: 14-Feb-2020
Reference Draft: https://www.w3.org/TR/2018/WD-mst-content-hint-20180703/
associated Call for Exclusion on 03-Jul-2018 ended on 30-Nov-2018
Produced under Working Group Charter: http://www.w3.org/2015/07/webrtc-charter.html
Scalable Video Coding (SVC) Extension for WebRTC
An extension to the WebRTC 1.0 API to enable user agents to support scalable video coding (SVC)
Adopted Working Draft: 08-Apr-2020
Reference Draft: https://www.w3.org/TR/2019/WD-webrtc-svc-20191022/
associated Call for Exclusion on 22-Oct-2019 ended on 20-Mar-2020
Produced under Working Group Charter: https://www.w3.org/2018/07/webrtc-charter.html
IceTransport Extensions for WebRTC
An extension to the WebRTC 1.0 API to enable usage of ICE for establishing connections in more contexts.
Draft State: Editors Draft
WebRTC Insertable Media using Streams
A JavaScript API for processing a media stream sent via a WebRTC connection
Draft State: Editors Draft

The Working Group will continue work on the following specifications until another group take them over:

Media Capture and Streams
JavaScript APIs that allow local media, including audio and video, to be requested from a platform
Adopted Candidate Recommendation: 02-Jul-2019
Reference Draft: https://www.w3.org/TR/2019/CR-mediacapture-streams-20190702/
associated Call for Exclusion on 02-Jul-2019 ended on 31-Aug-2019
Produced under Working Group Charter: https://www.w3.org/2018/07/webrtc-charter.html
MediaStream Recording
a JavaScript API to record MediaStreams
Expected completion: Q1 2021
Adopted Working Draft: 21-Jun-2017
Reference Draft: https://www.w3.org/TR/2013/WD-mediastream-recording-20130205/
associated Call for Exclusion on 06-Feb-2013 ended on 06-Jul-2013
Produced under Working Group Charter: http://www.w3.org/2011/04/webrtc-charter.html
MediaStream Image Capture
a JavaScript API to capture still images from a video MediaStream
Adopted Working Draft: 21-Jun-2017
Reference Draft: https://www.w3.org/TR/2013/WD-image-capture-20130709/
associated Call for Exclusion on 09-Jul-2013 ended on 06-Dec-2013
Produced under Working Group Charter: http://www.w3.org/2011/04/webrtc-charter.html
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
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
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: 19-Nov-2019
Reference Draft: https://www.w3.org/TR/2015/WD-screen-capture-20150210/
associated Call for Exclusion on 10-Feb-2015 ended on 10-Jul-2015
Produced under Working Group Charter: http://www.w3.org/2011/04/webrtc-charter.html
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

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.

This work is done in collaboration with the IETF. The W3C will define defines 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.

In addition to the work items identified above, the Working Group will consider developing further extensions to the WebRTC 1.0 core API. 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 is maintained to identify the functionality that needs new API for realization.

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 are assured at all times that they know can control what media they are transmitting, local devices an application can access for capturing media, and are able to find out who they are transmitting media to. at any time revoke that access.

Similarly, all the deliverables must address issues of security - this includes, but is not limited to, ensuring that arbitrary UDP packets cannot be sent to arbitrary destinations and ports. 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. specifications
  • Non-normative group notes

Given sufficient resources, this Working Group should review other working groups' 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 LC CR PR Rec RTC API Functions Q3 2011 Q2 2012 Q4 2012 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:

  • WebRTC 1.0: Recommendation in Q4 2012 2020
  • Media Capture and STreams: Recommendation in Q1 2013 2021
  • Identifiers for WebRTC Statistics: Recommendation in Q2 2021
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 Media Working Group
The HTML Media Working Group defines a number of markup elements and develops client-side media processing APIs and features that serves as the basis on which the RTC APIs will be developed; in particular, the outcome of this group might require extensions are likely to intersect with the <audio> and <video> tags WebRTC Working Group developments.
Web Applications
WebTransport Working Group
Some of the Web Applications The WebTransport Working Group APIs (such as the Web Sockets API) are likely to serve as inspiration or starting points for the APIs developed develops a client/server API that has been inspired by the RTC Working Group. WebRTC datachannels and may inform their future evolution.
Device APIs & Policy Audio Working Group
The DAP API developed by the Audio Working Group builds upon the MediaStream object built by this group; further collaboration on Media Capture APIs will require coordination across the two groups. management of audio output device is expected.
Web Notifications Application Security Working Group
The abilty of notifying users of incoming communications made possible by the work in the Web Notifications Application Security Working Group will be critical is developing guidance on APIs that expose sensitive information, and an API to the deployment manage permissions, both of Web Real Time Communications. which matter to several of this group specifications.
Audio Incubator Second Screen Working Group
The API under development in the Audio Incubator Second Screen Presentation Working Group is relevant developing APIs to the expected work allow rendering of media on an secondary devices; potential overlap with features enabled by the Audio Stream 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 RTC WebRTC Working Group will coordinate with the Web and TV Interest Group on these use cases and requirements as appropriate.
Web and Networks Interest Group
The Web & Networks Interest Group is looking at how network and applications intersect, a common pattern in the WebRTC architecture.
Accessible Platform Architectures Working Group
The Accessible Platform Architectures identifies use cases for users with disabilities and reviews technologies to avoid unintentional introduction of barriers. Its Media Accessibility User Requirements and Real-Time Communication Accessibility User Requirements provide important input to the work of this group.

External Groups Organizations

IETF Applications and Real-Time Communication in WEB-browsers group Area (RTCWeb) (ART)
The RTC APIs developed by this group will build upon the 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 the ART area and elsewhere in the IETF as appropriate; of particular interest are the MMUSIC, AVTEXT, ICE and QUIC working groups.
IETF CODEC group Transport Area Working Group (TSVWG)
The TSVWG develops SCTP on which WebRTC data channels relies.
Web Hypertext Application Technology Working Group (WHATWG)
One possible audio codec for use with The RTC APIs developed by this API is group will potentially reference the one being developed in Fetch, Streams and other API specifications maintained by the IETF. 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 the necessary resources for building Test Suites welcomes non-Members to contribute technical submissions for each specification. consideration upon their agreement to the terms of the W3C Patent Policy .

Participants in the group are reminded of required (by the Good Standing requirements W3C Process of ) to follow the W3C Process. Code of Ethics and Professional Conduct .

Communication

Technical discussions for this Working Group are conducted in public : the meeting minutes from teleconference and face-to-face meetings will be archived for 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.

Information about the 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 particular specifications, and will be conducted on an as-needed basis.

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 through consensus and due 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 the group and other reviewers, and 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 consensus. 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 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, GitHub issue 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 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 .

If the Director approves the proposed W3C Patent Policy (Draft dated 23 June 2020) , without making subtantives changes following the Advisory Committee review , this charter will be updated in place to use the updated Patent Policy.

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 was prepared as part of discussions related to the RTC Web Workshop in October 2010 . This charter is a revision The following table lists details of the initial charter reviewed by W3C Membership. Main all changes since initial version are a clarification of from the expectation in terms of usual meeting schedule, a clarification of initial charter, per the relationship between W3C and IETF groups and a new liaison with the Web and TV Interest Group for coordination on home networking scenarios. The milestones section was also completed. 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 was updated on March 13 2012 to reflect reflected the change actual split of Staff Contact the various features identified in well-defined specifications, and added WebRTC NV in scope for the group.
Rechartered 24 July 2018 30 September 2020 This charter was proposed an updated on March 6 2013 to reflect the change of the end timeline for completion of the charter from February 28 2013 to February 28 2015. This charter was updated WebRTC 1.0 and more details on March 25 2015 to reflect the change of the end of the charter from February 28 2015 WebRTC NV work developed as extensions to June the core APIs
Rechartered @@@ 30 2015. September 2022 This charter was updated on June 18 2015 to reflect the addition of proposed a new Staff Contact final timeline for completing WebRTC 1.0 and a new co-Chair and the change more detailed picture of extensions to the end of core APIs, while opening the charter from June 30 2015 way for the media work to September 30 2015. be moved to a separate Working Group