draft-ietf-rtcweb-overview-01.txt   draft-ietf-rtcweb-overview-02.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track August 24, 2011 Intended status: Standards Track September 28, 2011
Expires: February 25, 2012 Expires: March 31, 2012
Overview: Real Time Protocols for Brower-based Applications Overview: Real Time Protocols for Brower-based Applications
draft-ietf-rtcweb-overview-01 draft-ietf-rtcweb-overview-02
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
specified and on the right publication track. specified and on the right publication track.
This work is an attempt to synthesize the input of many people, but This work is an attempt to synthesize the input of many people, but
makes no claims to fully represent the views of any of them. All makes no claims to fully represent the views of any of them. All
parts of the document should be regarded as open for discussion, parts of the document should be regarded as open for discussion,
unless the RTCWEB chairs have declared consensus on an item. unless the RTCWEB chairs have declared consensus on an item.
This document is a candidate to become a work item of the RTCWEB This document is a work item of the RTCWEB working group.
working group.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
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 February 25, 2012. This Internet-Draft will expire on March 31, 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 17 skipping to change at page 3, line 17
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. Architecture and Functionality groups . . . . . . . . . . . . 8 3. Architecture and Functionality groups . . . . . . . . . . . . 8
4. Data transport . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Data transport . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Data framing and securing . . . . . . . . . . . . . . . . . . 12 5. Data framing and securing . . . . . . . . . . . . . . . . . . 12
6. Data formats . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Data formats . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Connection management . . . . . . . . . . . . . . . . . . . . 12 7. Connection management . . . . . . . . . . . . . . . . . . . . 13
8. Presentation and control . . . . . . . . . . . . . . . . . . . 13 8. Presentation and control . . . . . . . . . . . . . . . . . . . 13
9. Local system support functions . . . . . . . . . . . . . . . . 13 9. Local system support functions . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16
A.1. Changes from A.1. Changes from
draft-alvestrand-dispatch-rtcweb-datagram-00 to -01 . . . 16 draft-alvestrand-dispatch-rtcweb-datagram-00 to -01 . . . 17
A.2. Changes from draft-alvestrand-dispatch-01 to A.2. Changes from draft-alvestrand-dispatch-01 to
draft-alvestrand-rtcweb-overview-00 . . . . . . . . . . . 16 draft-alvestrand-rtcweb-overview-00 . . . . . . . . . . . 17
A.3. Changes from draft-alvestrand-rtcweb-00 to -01 . . . . . . 16 A.3. Changes from draft-alvestrand-rtcweb-00 to -01 . . . . . . 17
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 . . . . . . . . . . . . . . 16 draft-ietf-rtcweb-overview-00 . . . . . . . . . . . . . . 17
A.5. Changes from draft-ietf-rtcweb-overview -00 to -01 . . . . 17 A.5. Changes from draft-ietf-rtcweb-overview -00 to -01 . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 A.6. Changes from draft-ietf-rtcweb-overview -01 to -02 . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
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 4, line 51 skipping to change at page 4, line 51
had to be downloaded and installed separately from the browser; in had to be downloaded and installed separately from the browser; in
the development of HTML5, much promise is seen by the possibility of the development of HTML5, much promise is seen by the possibility of
making those interfaces available in a standardized way within the making those interfaces available in a standardized way within the
browser. browser.
This memo specifies a set of building blocks that can be made This memo specifies a set of building blocks that can be made
accessible and controllable through a Javascript API interface in a accessible and controllable through a Javascript API interface in a
browser, and which together form a necessary and sufficient set of browser, and which together form a necessary and sufficient set of
functions to allow the use of interactive audio and video in functions to allow the use of interactive audio and video in
applications that communicate directly between browsers across the applications that communicate directly between browsers across the
Internet. Internet. The resulting protocol suite is intended to enable all the
applications that are described as required scenarios in the RTCWEB
use cases document [I-D.ietf-rtcweb-use-cases-and-requirements].
Other efforts, for instance the W3C WebRTC, Web Applications and Other efforts, for instance the W3C WebRTC, Web Applications and
Device API working groups, focus on making standardized APIs and Device API working groups, focus on making standardized APIs and
interfaces available, within or alongside the HTML5 effort, for those interfaces available, within or alongside the HTML5 effort, for those
functions; this memo concentrates on specifying the protocols and functions; this memo concentrates on specifying the protocols and
subprotocols that are needed to specify the interactions that happen subprotocols that are needed to specify the interactions that happen
across the network. across the network.
2. Principles and Terminology 2. Principles and Terminology
skipping to change at page 10, line 33 skipping to change at page 10, line 33
| | | | | | | |
| | | | | | | |
| Browser | ------------------------- | Browser | | Browser | ------------------------- | Browser |
| | Media path | | | | Media path | |
| | | | | | | |
+-----------+ +-----------+ +-----------+ +-----------+
Figure 2: Browser RTC Trapezoid Figure 2: Browser RTC Trapezoid
If the two Web servers are operated by different entities, the If the two Web servers are operated by different entities, the
signalling path needs to be standardized too; for example, both signalling path needs to be agreed upon, either by standardization or
servers might implement SIP, and the servers would talk SIP to each by other means of agreement; for example, both servers might
other, and each would translate between the SIP protocol and their implement SIP, and the servers would talk SIP to each other, and each
proprietary representation for sending to their application running would translate between the SIP protocol and their proprietary
in the browser. representation for sending to their application running in the
browser. This part is outside the scope of the RTCWEB standars
suite.
On this sketch, the critical part to note is that the media path On this drawing, the critical part to note is that the media path
("low path") goes directly between the browsers, so it has to be ("low path") goes directly between the browsers, so it has to be
conformant to the specifications of the RTCWEB protocol suite; the conformant to the specifications of the RTCWEB protocol suite; the
signalling path ("high path") goes via servers that can modify, signalling path ("high path") goes via servers that can modify,
translate or massage the signals as needed. translate or massage the signals as needed.
The functionality groups that are needed in the browser can be The functionality groups that are needed in the browser can be
specified, more or less from the bottom up, as: 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
skipping to change at page 12, line 19 skipping to change at page 12, line 19
of the communication, and the interaction with any intermediate of the communication, and the interaction with any intermediate
entities that handle the data, but do not modify it (such as TURN entities that handle the data, but do not modify it (such as TURN
relays). relays).
It includes necessary functions for congestion control: When not to It includes necessary functions for congestion control: When not to
send data. send data.
The data transport protocols used by RTCWEB are described in <WORKING The data transport protocols used by RTCWEB are described in <WORKING
GROUP DRAFT "TRANSPORTS">. GROUP DRAFT "TRANSPORTS">.
The interactions with intermediate boxes, such as firewalls, relays ICE is required for all media paths that use UDP; in addition to the
and NAT boxes, is described in <WORKING GROUP DRAFT "PEER TO PEER ability to pass NAT boxes, ICE fulfils the need for guaranteeing that
CONNECTIVITY">. the media path is going to an UDP port that is willing to receive the
data.
The details of interactions with intermediate boxes, such as
firewalls, relays and NAT boxes, is described in <WORKING GROUP DRAFT
"PEER TO PEER CONNECTIVITY">.
5. Data framing and securing 5. Data framing and securing
SRTP [RFC3550] is used for transport of all real-time media. The format for media transport is RTP [RFC3550]. Implementation of
SRTP [RFC3711] is required for all implementations.
The detailed considerations for usage of functions from RTP and SRTP, The detailed considerations for usage of functions from RTP and SRTP
as well as for non-media real-time data, are given in <WORKING GROUP are given in [I-D.ietf-rtcweb-rtp-usage]. Key negotiation for SRTP
DRAFT "MEDIA TRANSPORTS">. is described in <MISSING>. Transfer of data that is not in RTP
format is described in <MISSING>.
6. Data formats 6. Data formats
The intent of this specification is to allow each communications The intent of this specification is to allow each communications
event to use the data formats that are best suited for that event to use the data formats that are best suited for that
particular instance, where a format is supported by both sides of the particular instance, where a format is supported by both sides of the
connection. However, a minimum standard is greatly helpful in order connection. However, a minimum standard is greatly helpful in order
to ensure that communication can be achieved. This document to ensure that communication can be achieved. This document
specifies a minimum baseline that will be supported by all specifies a minimum baseline that will be supported by all
implementations of this specification, and leaves further codecs to implementations of this specification, and leaves further codecs to
skipping to change at page 13, line 6 skipping to change at page 13, line 12
The mandatory to implement codecs, as well as any profiling The mandatory to implement codecs, as well as any profiling
requirements for both mandatory and optional codecs, is described in requirements for both mandatory and optional codecs, is described in
<WORKING GROUP DRAFT "MEDIA PROCESSING">. <WORKING GROUP DRAFT "MEDIA PROCESSING">.
7. Connection management 7. Connection management
The methods, mechanisms and requirements for setting up, negotiating The methods, mechanisms and requirements for setting up, negotiating
and tearing down connections is a large subject, and one where it is and tearing down connections is a large subject, and one where it is
desirable to have both interoperability and freedom to innovate. desirable to have both interoperability and freedom to innovate.
The following principles apply:
1. The media negotiations will be done using the same SDP offer/
answer semantics that are used in SIP [RFC3264], in such a way
that it is possible to build a signalling gateway between SIP and
the RTCWEB media negotiation.
2. It will be possible to gateway between legacy SIP devices that
support ICE and appropriate RTP / SDP mechanisms and codecs
without using a media gateway. A signaling gateway to convert
between the signaling on the web side to the SIP signaling may be
needed.
3. When a new codec is specified, and the SDP for the new codec is
specified in the MMUSIC WG, no other standardization would should
be required for it to be possible to use that in the web
browsers. Adding new codecs which might have new SDP parameters
should not change the APIs between the browser and javascript
application. As soon as the browsers support the new codecs, old
applications written before the codecs were specified should
automatically be able to use the new codecs where appropriate
with no changes to the JS applications.
The particular choices made for RTCWEB are described in <WORKING The particular choices made for RTCWEB are described in <WORKING
GROUP DRAFT "SIGNALING AND NEGOTIATION">. GROUP DRAFT "SIGNALING AND NEGOTIATION">.
8. Presentation and control 8. Presentation and control
The most important part of control is the user's control over the The most important part of control is the user's control over the
browser's interaction with input/output devices and communications browser's interaction with input/output devices and communications
channels. It is important that the user have some way of figuring channels. It is important that the user have some way of figuring
out where his audio, video or texting is being sent, for what out where his audio, video or texting is being sent, for what
purported reason, and what guarantees are made by the parties that purported reason, and what guarantees are made by the parties that
form part of this control channel. This is largely a local function form part of this control channel. This is largely a local function
between the browser, the underlying operating system and the user between the browser, the underlying operating system and the user
interface; this is being worked on as part of the W3C API effort. interface; this is being worked on as part of the W3C API effort, and
<INSERT REFERENCE TO W3C API SPEC WHEN AVAILABLE> will be part of [webrtc-api]
9. Local system support functions 9. Local system support functions
These are characterized by the fact that the quality of these These are characterized by the fact that the quality of these
functions strongly influences the user experience, but the exact functions strongly influences the user experience, but the exact
algorithm does not need coordination. In some cases (for instance algorithm does not need coordination. In some cases (for instance
echo cancellation, as described below), the overall system definition echo cancellation, as described below), the overall system definition
may need to specify that the overall system needs to have some may need to specify that the overall system needs to have some
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.
skipping to change at page 14, line 38 skipping to change at page 15, line 23
himself participates in, and to get reassurances from the other himself participates in, and to get reassurances from the other
parties to the communication that they promise that appropriate parties to the communication that they promise that appropriate
measures are taken. measures are taken.
o Security of the partners' identity: verifying that the o Security of the partners' identity: verifying that the
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 [I-D.ietf-rtcweb-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
surrounding this draft are too numerous to list, or even to identify. surrounding this draft are too numerous to list, or even to identify.
The ones below have made special, identifiable contributions; this The ones below have made special, identifiable contributions; this
does not mean that others' contributions are less important. does not mean that others' contributions are less 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 technical 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 Thanks to Jonathan Rosenberg, Matthew Kaufman and others at Skype for
the draft I lifted the ASCII drawings from. the ASCII drawings in section 1.
Thanks to Justin Uberti and Simon Leinen for document review. Thanks to Justin Uberti, Henry Sinnreich, Colin Perkins and Simon
Leinen for document review.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "RTP Requirements
for RTC-Web", draft-ietf-rtcweb-rtp-usage-00 (work in
progress), September 2011.
[I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for RTC-Web",
draft-ietf-rtcweb-security-00 (work in progress),
September 2011.
[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.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[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.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
13.2. Informative References 13.2. Informative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [I-D.ietf-rtcweb-use-cases-and-requirements]
with Session Description Protocol (SDP)", RFC 3264, Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
June 2002. Time Communication Use-cases and Requirements",
draft-ietf-rtcweb-use-cases-and-requirements-05 (work in
progress), September 2011.
[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 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
April 2010. April 2010.
[webrtc-api] [webrtc-api]
skipping to change at page 17, line 14 skipping to change at page 18, line 14
A.5. Changes from draft-ietf-rtcweb-overview -00 to -01 A.5. Changes from draft-ietf-rtcweb-overview -00 to -01
Added architecture figures to section 2. Added architecture figures to section 2.
Changed the description of "echo cancellation" under "local system Changed the description of "echo cancellation" under "local system
support functions". support functions".
Added a few more definitions. Added a few more definitions.
A.6. Changes from draft-ietf-rtcweb-overview -01 to -02
Added pointers to use cases, security and rtp-usage drafts (now WG
drafts).
Changed description of SRTP from mandatory-to-use to mandatory-to-
implement.
Added the "3 principles of negotiation" to the connection management
section.
Added an explicit statement that ICE is required for both NAT and
consent-to-receive.
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. 27 change blocks. 
39 lines changed or deleted 108 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/