IETF 82 Proceedings

Introduction  |  Area, Working Goup & BoF Reports  |  Plenaries  |  Training  |  Internet Research Task Force

Real-Time Communication in WEB-browsers (rtcweb) (WG)

Minutes  | Audio Archives  |  Jabber Logs  |  Mailing List Archives

Additional information is available at tools.ietf.org/wg/rtcweb

Chair(s):

Real-time Applications and Infrastructure Area Director(s):

* The Real-time Applications and Infrastructure Area Directors were seated during the IETF 65.

Real-time Applications and Infrastructure Area Advisor:

Meeting Slides

Internet-Drafts:

No Request For Comments

Charter (as of 2011-12-09)

There are a number of proprietary implementations that provide direct
interactive rich communication using audio, video, collaboration,
games, etc. between two peers' web-browsers. These are not
interoperable, as they require 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 browsers. The goal is to enable innovation on
top of a set of basic components. One core component is to enable
real-time media like audio and video, a second is to enable data
transfer directly between clients.

This work will be done in collaboration with the W3C. The IETF WG
will produce architecture and requirements for selection and profiling
of the on the wire protocols. The architecture needs to be coordinated
with W3C. The IETF WG work will identify state information and events
that need to be exposed in the APIs as input to W3C. The W3C will be
responsible for defining APIs to ensure that application developers
can control the components. We will reach out to the developer
community for consultation and early feedback on implementation.

The security and privacy goals and requirements will be developed by
the WG. The security model needs to be coordinated 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 need extensions, additions or replacement, and
thus some support for negotiation between clients is required.

The WG will perform the following work:

1. Define the communication model in detail, including how session
management is to occur within the model.

2. Define a security model that describes the security and privacy
goals and specifies the security protocol mechanisms necessary
to achieve those goals.

3. Define the solution - protocols and API requirements - for
firewall and NAT traversal.

4. Define which media functions and extensions shall be supported in
the client and their usage for real-time media, including media
adaptation to ensure congestion safe usage.

5. Define what functionalities in the solution, such as media codecs,
security algorithms, etc., can be extended and how the
extensibility mechanisms works.

6. Define a set of media formats that must or should be supported by
a client to improve interoperability.

7. Define how non media data is transported between clients in a
secure and congestion safe way.

8. Provide W3C input for the APIs that comes from the communication
model and the selected components and protocols that are part of
the solution.

9. The group will consider options for interworking with legacy VoIP
equipment.

This work will be done primarily by using already defined protocols or
functionalities. If there is identification of missing protocols or
functionalities, such work can be requested to be done in another
working group with a suitable charter or by requests for chartering it
in this WG or another WG. The following topics will be out of scope
for the initial phase of the WG: RTSP, RSVP, NSIS, Location services,
Resource Priority, and IM & Presence specific features.

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 consider the possibility of
defining a browser component that implements an existing session
negotiation and management protocol. 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.

Goals and Milestones:

Oct 2011  Send Use Cases (draft-ietf-rtcweb-use-cases-and-requirements), Overview (draft-ietf-rtcweb-overview), Security and Privacy Documents (I-D) to W3C
Dec 2011  Send Use Cases (draft-ietf-rtcweb-use-cases-and-requirements) document to IESG for publication as Informational
Apr 2012  Send W3C input on what requirements the current solution has on API(s)
May 2012  Send Overview (draft-ietf-rtcweb-overview), Security and Privacy Model documents to IESG for publication as Informational
May 2012  Send Signalling and Negotiation, and NAT Traversal to IESG for publication as Proposed Standard
Jun 2012  Send Media Transport, Media Processing, and Codecs to IESG for publication as Proposed Standard
Jun 2012  Send Datagram Transport for non-media data to IESG for publication as Proposed Standard

Internet SocietyAMSHome - Tools Team - Datatracker - Web Site Usage Statistics - IASA - IAB - RFC Editor - IANA - IRTF - IETF Trust - ISOC - Store - Contact Us
Secretariat services provided by Association Management Solutions, LLC (AMS).
Please send problem reports to: ietf-action@ietf.org.