draft-ietf-rtcweb-overview-00.txt   draft-ietf-rtcweb-overview-01.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track July 1, 2011 Intended status: Standards Track August 24, 2011
Expires: January 2, 2012 Expires: February 25, 2012
Overview: Real Time Protocols for Brower-based Applications Overview: Real Time Protocols for Brower-based Applications
draft-ietf-rtcweb-overview-00 draft-ietf-rtcweb-overview-01
Abstract Abstract
This document gives an overview and context of a protocol suite This document gives an overview and context of a protocol suite
intended for use with real-time applications that can be deployed in intended for use with real-time applications that can be deployed in
browsers - "real time communication on the Web". browsers - "real time communication on the Web".
It intends to serve as a starting and coordination point to make sure It intends to serve as a starting and coordination point to make sure
all the parts that are needed to achieve this goal are findable, and all the parts that are needed to achieve this goal are findable, and
that the parts that belong in the Internet protocol suite are fully that the parts that belong in the Internet protocol suite are fully
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2012. This Internet-Draft will expire on February 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 13 skipping to change at page 3, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Principles and Terminology . . . . . . . . . . . . . . . . . . 5 2. Principles and Terminology . . . . . . . . . . . . . . . . . . 5
2.1. Goals of this document . . . . . . . . . . . . . . . . . . 5 2.1. Goals of this document . . . . . . . . . . . . . . . . . . 5
2.2. Relationship between API and protocol . . . . . . . . . . 5 2.2. Relationship between API and protocol . . . . . . . . . . 5
2.3. On interoperability and innovation . . . . . . . . . . . . 6 2.3. On interoperability and innovation . . . . . . . . . . . . 6
2.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
3. Functionality groups . . . . . . . . . . . . . . . . . . . . . 7 3. Architecture and Functionality groups . . . . . . . . . . . . 8
4. Data transport . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Data transport . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Data framing and securing . . . . . . . . . . . . . . . . . . 9 5. Data framing and securing . . . . . . . . . . . . . . . . . . 12
6. Data formats . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Data formats . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Connection management . . . . . . . . . . . . . . . . . . . . 9 7. Connection management . . . . . . . . . . . . . . . . . . . . 12
8. Presentation and control . . . . . . . . . . . . . . . . . . . 10 8. Presentation and control . . . . . . . . . . . . . . . . . . . 13
9. Local system support functions . . . . . . . . . . . . . . . . 10 9. Local system support functions . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . . 12 13.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 15
A.1. Changes from A.1. Changes from
draft-alvestrand-dispatch-rtcweb-datagram-00 to -01 . . . 12 draft-alvestrand-dispatch-rtcweb-datagram-00 to -01 . . . 16
A.2. Changes from draft-alvestrand-dispatch-01 to A.2. Changes from draft-alvestrand-dispatch-01 to
draft-alvestrand-rtcweb-overview-00 . . . . . . . . . . . 13 draft-alvestrand-rtcweb-overview-00 . . . . . . . . . . . 16
A.3. Changes from draft-alvestrand-rtcweb-00 to -01 . . . . . . 13 A.3. Changes from draft-alvestrand-rtcweb-00 to -01 . . . . . . 16
A.4. Changes from draft-alvestrand-rtcweb-overview-01 to A.4. Changes from draft-alvestrand-rtcweb-overview-01 to
draft-ietf-rtcweb-overview-00 . . . . . . . . . . . . . . 13 draft-ietf-rtcweb-overview-00 . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.5. Changes from draft-ietf-rtcweb-overview -00 to -01 . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Internet was, from very early in its lifetime, considered a The Internet was, from very early in its lifetime, considered a
possible vehicle for the deployment of real-time, interactive possible vehicle for the deployment of real-time, interactive
applications - with the most easily imaginable being audio applications - with the most easily imaginable being audio
conversations (aka "Internet telephony") and videoconferencing. conversations (aka "Internet telephony") and videoconferencing.
The first attempts to build this were dependent on special networks, The first attempts to build this were dependent on special networks,
special hardware and custom-built software, often at very high prices special hardware and custom-built software, often at very high prices
skipping to change at page 5, line 38 skipping to change at page 5, line 38
By reading this document and the documents it refers to, it should be By reading this document and the documents it refers to, it should be
possible to have all information needed to implement an RTCWEB possible to have all information needed to implement an RTCWEB
compatible implementation. compatible implementation.
2.2. Relationship between API and protocol 2.2. Relationship between API and protocol
The total RTCWEB/WEBRTC effort consists of two pieces: The total RTCWEB/WEBRTC effort consists of two pieces:
o A protocol specification, done in the IETF o A protocol specification, done in the IETF
o A Javascript API specification, done in the W3C o A Javascript API specification, done in the W3C [webrtc-api]
Together, these two specifications aim to provide an environment Together, these two specifications aim to provide an environment
where Javascript embedded in any page, viewed in any compatible where Javascript embedded in any page, viewed in any compatible
browser, when suitably authorized by its user, is able to set up browser, when suitably authorized by its user, is able to set up
communication using audio, video and auxiliary data, where the communication using audio, video and auxiliary data, where the
browser environment does not constrain the types of application in browser environment does not constrain the types of application in
which this functionality can be used. which this functionality can be used.
The protocol specification does not assume that all implementations The protocol specification does not assume that all implementations
implement this API; it is not intended to be possible by observing implement this API; it is not intended to be possible by observing
skipping to change at page 7, line 9 skipping to change at page 7, line 9
part of the communications partnership, you have to implement the part of the communications partnership, you have to implement the
standard "and then some" - that "and then some" usually being called standard "and then some" - that "and then some" usually being called
a profile of some sort; in the version most antithetical to the a profile of some sort; in the version most antithetical to the
Internet ethos, that "and then some" consists of having to use a Internet ethos, that "and then some" consists of having to use a
specific vendor's product only. specific vendor's product only.
2.4. Terminology 2.4. Terminology
The following terms are used in this document, and as far as possible The following terms are used in this document, and as far as possible
across the documents specifying the RTCWEB suite, in the specific across the documents specifying the RTCWEB suite, in the specific
meanings given here. Other terms are used in their commonly used meanings given here. Not all terms are used in this document. Other
meaning. terms are used in their commonly used meaning.
The list is in alphabetical order. The list is in alphabetical order.
Agent: Undefined term. See "SDP Agent" and "ICE Agent".
API: Application Programming Interface - a specification of a set of API: Application Programming Interface - a specification of a set of
calls and events, usually tied to a programming language or an calls and events, usually tied to a programming language or an
abstract formal specification such as WebIDL, with its defined abstract formal specification such as WebIDL, with its defined
semantics. semantics.
ICE Agent: An implementation of the ICE [RFC5245] protocol. An ICE
Agent may also be an SDP Agent, but there exist ICE Agents that do
not use SDP (for instance those that use Jingle).
Interactive: Communication between multiple parties, where the Interactive: Communication between multiple parties, where the
expectation is that an action from one party can cause a reaction expectation is that an action from one party can cause a reaction
by another party, and the reaction can be observed by the first by another party, and the reaction can be observed by the first
party, with the total time required for the action/reaction/ party, with the total time required for the action/reaction/
observation is on the order of no more than hundreds of observation is on the order of no more than hundreds of
milliseconds. milliseconds.
Media: Audio and video content. Not to be confused with Media: Audio and video content. Not to be confused with
"transmission media" such as wires. "transmission media" such as wires.
Media path: The path that media data follows from one browser to
another.
Protocol: A specification of a set of data units, their Protocol: A specification of a set of data units, their
representation, and rules for their transmission, with their representation, and rules for their transmission, with their
defined semantics. A protocol is usually thought of as going defined semantics. A protocol is usually thought of as going
between systems. between systems.
Real-time media: Media where generation of content and display of Real-time media: Media where generation of content and display of
content are intended to occur closely together in time (on the content are intended to occur closely together in time (on the
order of no more than hundreds of milliseconds). order of no more than hundreds of milliseconds).
SDP Agent: The protocol implementation involved in the SDP offer/
answer exchange, as defined in [RFC3264] section 3.
Signaling: Communication that happens in order to establish, manage
and control media paths.
Signaling Path: The communication channels used between entities
participating in signalling to transfer signaling. There may be
more entities in the signaling path than in the media path.
NOTE: Where common definitions exist for these terms, those NOTE: Where common definitions exist for these terms, those
definitions should be used to the greatest extent possible. definitions should be used to the greatest extent possible.
TODO: Extend this list with other terms that might prove slippery. TODO: Extend this list with other terms that might prove slippery.
3. Functionality groups 3. Architecture and Functionality groups
The functionality groups that are needed can be specified, more or The model of real-time support for browser-based applications does
less from the bottom up, as: not envisage that the browser will contain all the functions that
need to be performed in order to have a function such as a telephone
or a videoconferencing unit; the vision is that the browser will have
the functions that are needed for a Web application, working in
conjunction with its backend servers, to implement these functions.
This means that two vital interfaces need specification: The
protocols that browsers talk to each other, without any intervening
servers, and the APIs that are offered for a Javascript application
to take advantage of the browser's functionality.
+------------------------+ On-the-wire
| | Protocols
| Servers |--------->
| |
| |
+------------------------+
^
|
|
| HTTP/
| Websockets
|
|
+----------------------------+
| Javascript/HTML/CSS |
+----------------------------+
Other ^ ^RTC
APIs | |APIs
+---|-----------------|------+
| | | |
| +---------+|
| | Browser || On-the-wire
| Browser | RTC || Protocols
| | Function|----------->
| | ||
| | ||
| +---------+|
+---------------------|------+
|
V
Native OS Services
Figure 1: Browser Model
As for all protocol and API specifications, there is no restriction
that the protocols can only be used to talk to another browser; since
they are fully specified, any device that implements the protocols
faithfully should be able to interoperate with the application
running in the browser.
A commonly imagined model of deployment is the one depicted below.
+-----------+ +-----------+
| Web | | Web |
| | Signalling | |
| |-------------| |
| Server | path | Server |
| | | |
+-----------+ +-----------+
/ \
/ \ Proprietary over
/ \ HTTP/Websockets
/ \
/ Proprietary over \
/ HTTP/Websockets \
/ \
+-----------+ +-----------+
|JS/HTML/CSS| |JS/HTML/CSS|
+-----------+ +-----------+
+-----------+ +-----------+
| | | |
| | | |
| Browser | ------------------------- | Browser |
| | Media path | |
| | | |
+-----------+ +-----------+
Figure 2: Browser RTC Trapezoid
If the two Web servers are operated by different entities, the
signalling path needs to be standardized too; for example, both
servers might implement SIP, and the servers would talk SIP to each
other, and each would translate between the SIP protocol and their
proprietary representation for sending to their application running
in the browser.
On this sketch, the critical part to note is that the media path
("low path") goes directly between the browsers, so it has to be
conformant to the specifications of the RTCWEB protocol suite; the
signalling path ("high path") goes via servers that can modify,
translate or massage the signals as needed.
The functionality groups that are needed in the browser can be
specified, more or less from the bottom up, as:
o Data transport: TCP, UDP and the means to securely set up o Data transport: TCP, UDP and the means to securely set up
connections between entities, as well as the functions for connections between entities, as well as the functions for
deciding when to send data: Congestion management, bandwidth deciding when to send data: Congestion management, bandwidth
estimation and so on. estimation and so on.
o Data framing: RTP and other data formats that serve as containers, o Data framing: RTP and other data formats that serve as containers,
and their functions for data confidentiality and integrity. and their functions for data confidentiality and integrity.
o Data formats: Codec specifications, format specifications and o Data formats: Codec specifications, format specifications and
skipping to change at page 10, line 38 skipping to change at page 13, line 38
characteristics for which these facilities are useful, without characteristics for which these facilities are useful, without
requiring them to be implemented a certain way. requiring them to be implemented a certain way.
Local functions include echo cancellation, volume control, camera Local functions include echo cancellation, volume control, camera
management including focus, zoom, pan/tilt controls (if available), management including focus, zoom, pan/tilt controls (if available),
and more. and more.
Certain parts of the system SHOULD conform to certain properties, for Certain parts of the system SHOULD conform to certain properties, for
instance: instance:
o Echo cancellation should be good enough that feedback (defined as o Echo cancellation should be good enough to achieve the suppression
a rising volume of sound with no local sound input) does not of acoustical feedback loops below a perceptually noticeable
occur. level.
o Privacy concerns must be satisfied; for instance, if remote o Privacy concerns must be satisfied; for instance, if remote
control of camera is offered, the APIs should be available to let control of camera is offered, the APIs should be available to let
the local participant to figure out who's controlling the camera, the local participant to figure out who's controlling the camera,
and possibly decide to revoke the permission for camera usage. and possibly decide to revoke the permission for camera usage.
o Automatic gain control, if present, should normalize a speaking o Automatic gain control, if present, should normalize a speaking
voice into <whatever dB metrics makes sense here - most important voice into <whatever dB metrics makes sense here - most important
that we have one only> that we have one only>
o
The requirements on RTCWEB systems in this category are found in The requirements on RTCWEB systems in this category are found in
<WORKING GROUP DRAFT "MEDIA PROCESSING">. <WORKING GROUP DRAFT "MEDIA PROCESSING">.
10. IANA Considerations 10. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
skipping to change at page 11, line 45 skipping to change at page 14, line 43
participants are who they say they are (when positive participants are who they say they are (when positive
identification is appropriate), or that their identity cannot be identification is appropriate), or that their identity cannot be
uncovered (when anonymity is a goal of the application). uncovered (when anonymity is a goal of the application).
The security analysis, and the requirements derived from that The security analysis, and the requirements derived from that
analysis, is contained in <WORKING GROUP DRAFT "SECURITY">. analysis, is contained in <WORKING GROUP DRAFT "SECURITY">.
12. Acknowledgements 12. Acknowledgements
The number of people who have taken part in the discussions The number of people who have taken part in the discussions
surroounding this draft are too numerous to list, or even to surrounding this draft are too numerous to list, or even to identify.
identify. The ones below have made special, identifiable The ones below have made special, identifiable contributions; this
contributions; this does not mean that others' contributions are less does not mean that others' contributions are less important.
important.
Thanks to Cary Bran, Cullen Jennings, Colin Perkins, Magnus Thanks to Cary Bran, Cullen Jennings, Colin Perkins, Magnus
Westerlund and Joerg Ott, who offered techincal contributions on Westerlund and Joerg Ott, who offered technical contributions on
various versions of the draft. various versions of the draft.
Thanks to Jonathan Rosenberg, Matthew Kaufman and others at Skype for
the draft I lifted the ASCII drawings from.
Thanks to Justin Uberti and Simon Leinen for document review. Thanks to Justin Uberti and Simon Leinen for document review.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
13.2. Informative References 13.2. Informative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF", [RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, October 2004. BCP 95, RFC 3935, October 2004.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[webrtc-api]
Bergkvist, Burnett, Jennings, Narayanan, "WebRTC 1.0:
Real-time Communication Between Browsers", August 2011.
Available at
http://dev.w3.org/2011/webrtc/editor/webrtc.html
Appendix A. Change log Appendix A. Change log
This section may be deleted by the RFC Editor when preparing for This section may be deleted by the RFC Editor when preparing for
publication. publication.
A.1. Changes from draft-alvestrand-dispatch-rtcweb-datagram-00 to -01 A.1. Changes from draft-alvestrand-dispatch-rtcweb-datagram-00 to -01
Added section "On interoperability and innovation" Added section "On interoperability and innovation"
Added data confidentiality and integrity to the "data framing" layer Added data confidentiality and integrity to the "data framing" layer
skipping to change at page 13, line 33 skipping to change at page 17, line 5
Spell-checked document. Spell-checked document.
A.4. Changes from draft-alvestrand-rtcweb-overview-01 to A.4. Changes from draft-alvestrand-rtcweb-overview-01 to
draft-ietf-rtcweb-overview-00 draft-ietf-rtcweb-overview-00
Changed draft name and document date. Changed draft name and document date.
Removed unused references Removed unused references
A.5. Changes from draft-ietf-rtcweb-overview -00 to -01
Added architecture figures to section 2.
Changed the description of "echo cancellation" under "local system
support functions".
Added a few more definitions.
Author's Address Author's Address
Harald T. Alvestrand Harald T. Alvestrand
Google Google
Kungsbron 2 Kungsbron 2
Stockholm, 11122 Stockholm, 11122
Sweden Sweden
Email: harald@alvestrand.no Email: harald@alvestrand.no
 End of changes. 23 change blocks. 
39 lines changed or deleted 178 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/