<!DOCTYPE html>
<html lang="en">
<head>
<title>[DRAFT] Web Real-Time Communications Working Group Charter</title>
<link rel="stylesheet" href="http://www.w3.org/2005/10/w3cdoc.css" type="text/css" media="screen"/>
<link rel="stylesheet" type="text/css" href="http://www.w3.org/Guide/pubrules-style.css"/>
<link rel="stylesheet" type="text/css" href="http://www.w3.org/2006/02/charter-style.css"/>
</head>
<body>
<ul id="navbar" style="font-size: small"><li><a href="#scope">Scope</a></li><li><a href="#deliverables">Deliverables</a></li><li><a href="#coordination">Dependencies and Liaisons</a></li><li><a href="#participation">Participation</a></li><li><a href="#communication">Communication</a></li><li><a href="#decisions">Decision Policy</a></li><li><a href="#patentpolicy">Patent
Policy
</a></li><li><a href="#about">About this Charter</a></li></ul>
<p><a href="http://www.w3.org/" shape="rect"><img alt="W3C" height="48" src="/Icons/w3c_home" width="72"/></a> <a class="domainlogo" href="/Interaction/" shape="rect"><img src="http://www.w3.org/Icons/interaction" alt="Interaction Domain"/></a> </p>
<h1 id="title">[DRAFT] Web Real-Time Communications Working Group Charter</h1>
<p><em>Status: this is a draft charter based on ongoing discussions with Harald Alvestrand, following up on the <a href="http://rtc-web.alvestrand.com/">RTC Web Workshop in October 2010</a>.</em></p>
<p class="mission">The
<strong>mission</strong> of the Web Real-Time Communications Working Group, part of
the <a href="http://www.w3.org/2006/rwc/">Rich Web Client Activity</a>, is to define client-side APIs to enable Real Time Communications in Web browsers.</p>
<p>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).</p>
<div class="noprint">
<p class="join">Join the
Web Real-Time Communications Working Group.</p>
</div>
<table class="summary-table"><tr id="Duration"><th rowspan="1" colspan="1">End date</th><td rowspan="1" colspan="1">31 February 2013</td></tr><tr><th rowspan="1" colspan="1">Confidentiality</th><td rowspan="1" colspan="1">Proceedings are <a href="/2005/10/Process-20051014/comm.html#confidentiality-levels" shape="rect">
public
</a></td></tr><tr><th rowspan="1" colspan="1">Initial Chairs</th><td rowspan="1" colspan="1"><span class="toadd">CHAIR INFO</span></td></tr><tr><th rowspan="1" colspan="1">Initial Team Contacts<br/>
(FTE %: 10)</th><td rowspan="1" colspan="1"><span class="toadd">TEAM CONTACT INFO</span></td></tr><tr><th rowspan="1" colspan="1">Usual Meeting Schedule</th><td rowspan="1" colspan="1">Teleconferences: Weekly
<br/>
Face-to-face:
3-4 per year </td></tr></table>
<div class="scope">
<h2 id="scope">Scope</h2>
<p>Enabling real-time communications between Web browsers require the following client-side technologies to be available:</p>
<ul>
<li>Device discovery and capability exploration (currently in scope for the <a href="http://www.w3.org/2009/dap/">Device APIs & Policy Working Group</a>)</li>
<li>Capture of media from local devices (camera and microphone) (currently in scope for the <a href="http://www.w3.org/2009/dap/">Device APIs & Policy Working Group</a>)</li>
<li>Encoding and other processing of those media streams,</li>
<li>Establishing direct peer-to-peer connections, including firewall/NAT traversal</li>
<li>Decoding and processing (including echo cancelling, stream synchronization and a number of other functions) of those streams at the incoming end,</li>
<li>Delivery to the user of those media streams via local screens and audio output devices (partially covered with HTML5)</li>
</ul>
<h3>Success Criteria</h3>
<p>To advance to Proposed Recommendation, each specification is expected to have two independent implementations of each feature defined in the specification.</p>
<p>To advance to Proposed Recommendation, interoperability between the independent implementations (that is, bidirectional audio and video communication between the implementations) should be demonstrated.</p>
<div>
<h3>Out of Scope</h3>
<p>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.</p>
<p>The definition of codecs for audio and video is out of scope.</p>
</div>
</div>
<div>
<h2 id="deliverables">Deliverables</h2>
<h3>Recommendation-Track Deliverables</h3>
<p>The working group will deliver at least the following specifications, unless they are found to be fully specified within other working groups' finished results:</p>
<dl>
<dt>Media Stream API</dt>
<dd>An API to manipulate media streams, 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</dd>
<dt>Audio Stream API</dt>
<dd>An extension of the stream API to process audio streams, to enable features such as automatic gain control, mute functions and echo cancellation.</dd>
<dt>Video Stream API</dt>
<dd>An extension of the stream API to process video streams, to enable features such as bandwidth limiting, image manipulation or "video mute"</dd>
<dt>Functional Component API</dt>
<dd>An API that allows to query for the components present in an implementation, instantiate them, and connect them to media streams.</dd>
<dt>P2P Connection API</dt>
<dd>An API to establish peer-to-peer connections between Web browsers</dd>
<dt>Profile</dt>
<dd>A minimum profile to which complete implementations should adhere, including standard components that must be available, codecs that need to be supported, and network protoocols that can be connected to.</dd>
</dl>
<p>
The specified APIs 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 what media they are transmitting, and are able to find out who they are transmitting media to.</t>
<div id="ig-other-deliverables">
<h3>Other Deliverables</h3>
<p>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. </p>
<p>Other non-normative documents may be created such as:</p>
<ul>
<li>Primers</li>
<li>Requirements and use case document for specifications.</li>
<li>Non-normative group notes</li>
</ul>
<p>Given sufficient resources, this Working Group should review other working groups' deliverables that are identified as being relevant to the Working Group's mission. </p>
</div>
<h3>Milestones</h3>
<p>Note: The actual production of some of the deliverables may follow a different timeline. The group will document any schedule changes on the <a href="@@@">group home page</a>.</p>
<p>@@@</p>
</div>
<div class="dependencies">
<h2 id="coordination">Dependencies and Liaisons</h2>
<h3>W3C Groups</h3>
<dl>
<dt><a href="http://www.w3.org/html/wg/">HTML Working Group</a></dt>
<dd>The HTML Working Group defines a number of markup elements and APIs that serves as the basis on which the RTC APIs will be developed; in particular, the outcome of this group might require extensions to the <code><audio></code> and <code><video></code> tags</dd>
<dt><a href="http://www.w3.org/2008/webapps/">Web Applications Working Group</a></dt>
<dd>Some of the Web Applications Working Group APIs (such as the Web Sockets API) are likely to serve as inspiration or starting points for the APIs developed by the RTC Working Group.</dd>
<dt><a href="http://www.w3.org/2009/dap/">Device APIs & Policy Working Group</a></dt>
<dd>The DAP Working Group on Media Capture APIs will require coordination across the two groups.</dd>
<dt><a href="http://www.w3.org/2010/web-notifications/">Web Notifications Working Group</a></dt>
<dd>The abilty of notifying users of incoming communications made possible by the work in the Web Notifications Working Group will be critical to the deployment of Web Real Time Communications.</dd>
<dt><a href="http://www.w3.org/2005/Incubator/audio/">Audio Incubator Group</a></dt>
<dd>The API under development in the Audio Incubator Group is relevant to the expected work on an Audio Stream API</dd>
<dt>
<a href="http://www.w3.org/WAI/PF/" shape="rect">WAI Protocols and Formats Working Group</a></dt>
<dd>Reviews from the WAI PF Working Group will be required to ensure the APIs allow to create an accessible user experience.</dd>
</dl>
<h3>External Groups</h3>
<dl>
<dt>@@@ IETF group on related protocol</dt>
<dd>The RTC APIs developed by this group will build upon the protocols and formats developed in the IETF @@@ Working Group.</dd>
<dt>IETF CODEC group</dt>
<dd>One possible audio codec for use with this API is the one being developed in the IETF.</dt>
</dl>
</div>
<div class="participation">
<h2 id="participation">Participation</h2>
<p>To be successful, the Web Real-Time Communications Working Group is expected to have <span class="example">10 or more</span> active participants for its
duration. Effective participation to Web Real-Time Communications Working Group is expected to consume
<span class="example">one work day per week</span> for each
participant; <span class="example">two days per week</span> for
editors. The Web Real-Time Communications Working Group will
allocate also the necessary resources for building Test
Suites for each specification.</p>
<p>Participants are reminded of the <a href="/2005/10/Process-20051014/groups.html#good-standing" shape="rect">
Good Standing requirements</a> of the W3C Process.</p>
</div>
<div class="communication">
<h2 id="communication">Communication</h2>
<p>This group primarily conducts its work on the public
mailing list <span class="toadd">LIST NAME</span>.
<span class="toadd">Provide information about additional
Member-only lists that are used for administrative purposes.</span>
</p>
<p>Information about the group (deliverables, participants,
face-to-face
meetings, teleconferences, etc.) is
available from the Web Real-Time Communications Working Group home
page.</p>
</div>
<div class="decisions">
<h2 id="decisions">Decision Policy</h2>
<p>As explained in the Process Document (<a href="/Consortium/Process/policies#Consensus" shape="rect">section
3.3</a>), this group will seek to make decisions when there
is consensus. 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.</p>
</div>
<div class="patent">
<h2 id="patentpolicy">Patent
Policy
</h2>
<p>This Working Group operates under the <a href="/Consortium/Patent-Policy-20040205/" shape="rect">W3C
Patent Policy</a> (5 February 2004 Version). 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.</p>
<p>For more information about disclosure obligations for
this group, please see the <a href="/2004/01/pp-impl/" shape="rect">W3C
Patent Policy Implementation</a>.</p>
</div>
<h2 id="about">About this Charter</h2>
<p>This charter for the Web Real-Time Communications Working Group has been created according to
<a href="/Consortium/Process/groups#GAGeneral" shape="rect">section
6.2</a> of the <a href="/Consortium/Process" shape="rect">Process
Document</a>. 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.</p>
<hr/>
<address>Dominique Hazaël-Massieux, based on initial input from Harald Alvestrand
</address>
<p class="copyright"><a rel="Copyright" href="/Consortium/Legal/ipr-notice#Copyright" shape="rect">Copyright</a>©
2010 <a href="/" shape="rect"><acronym title="World Wide Web Consortium">W3C</acronym></a>
<sup>®</sup> (<a href="http://www.csail.mit.edu/" shape="rect"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a> ,
<a href="http://www.ercim.org/" shape="rect"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>
, <a href="http://www.keio.ac.jp/" shape="rect">Keio</a>), All Rights
Reserved.</p>
<p>$Date: 2011-01-06 11:52:39 $</p>
</body>
</html>