Version 6 Name: Real-Time Communication in WEB-browsers (RTCWeb) There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc directly between two peers within web-browsers. This so far requires non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browser. The goal is to enable innovation on top of a set of basic components used in establishing browser to browser communication and ensuring interoperability for a high-quality real-time communications experiences within the browser. One component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients. This work will be done in collaboration with the W3C. The collaboration will be done with substantial amounts of informal communications, but also using established liaison agreements at key points of the development. This WG will produce requirements for a selection and profile of on the wire protocols and identify what information elements are necessary in the API in order for the defined components to function properly. The W3C will be responsible for defining APIs to ensure that application developers can control the components. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming. To accomplish direct connectivity between two clients some set of reachability information will be need to be exchanged between the clients. This reachability information is then used by ICE as a NAT and firewall traversal mechanism in an attempt to establish direct or relayed connection. In addition to establishing communication channels between the clients, negotiation needs to occur between the clients on how to use this communication channel in the session, i.e. session management. There will be a need to implement certain functionalities of the real-time media in the browser for performance reasons. Thus these needed to be defined so that interoperable communication is possible. RTP and SRTP will be used for media transport, but which RTP extensions and features to be supported will need to be selected as well as mandatory to implement codecs. The goal of having a mandatory codec list is to prevent negotiation failure, not to preempt or prevent negotiation. Security is complicated as few assumptions can be made about the application using these components through the API provided by the browser. The transmission of media or other data traffic towards a destination could be used as an attack on a target. The complete list of security goals and requirements will need to be developed by the WG. The security model needs to be agreed to with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients. Interoperability with existing real-time media systems is desirable. However, the cost of achieving such interoperability needs to be weighted against the potential benefit. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The work will identity state information and events about what is happening that need to be exposed in the API. These events and state need to include information such as: receiving DTMF in the RTP, RTP and RTCP statistics, and the security state of RTP sessions. The WG will perform the following work: Define the communication model in detail, including how session management is to occur within the model. Define a security model that describes the security goals and how the communication model can achieve these goals. Define how NAT and Firewall traversal is to occur. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media. Define a set of media formats that shall or should be supported by a client to improve interoperability. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. Provide W3C requirements on the API that comes from the communication model and the selected components and protocols that are part of the solution. This work will be done primarily by using already defined protocols or functionalities. In certain cases additional protocol work will be required, but only such work that is explicitly called out in this charter is allowed. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with suitable charter or request for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, LOST, Geolocation, IM & Presence, Resource Priority. RTP Payload formats will not be done in this WG. The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers. Milestones: Sept 2011 Architecture and Threat Model to IESG as Informational Sept 2011 Scenarios document sent to IESG as Informational Dec 2011 Profile specification to IESG as PS Apr 2012 Mapping document submitted to the IESG as Informational (if needed)