draft-ietf-rtcweb-overview-05.txt   draft-ietf-rtcweb-overview-06.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track December 14, 2012 Intended status: Standards Track February 20, 2013
Expires: June 17, 2013 Expires: August 24, 2013
Overview: Real Time Protocols for Brower-based Applications Overview: Real Time Protocols for Brower-based Applications
draft-ietf-rtcweb-overview-05 draft-ietf-rtcweb-overview-06
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 document is a work item of the RTCWEB working group. This document is a work item of the RTCWEB working group.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 17, 2013. This Internet-Draft will expire on August 24, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Principles and Terminology . . . . . . . . . . . . . . . . . . 5 2. Principles and Terminology . . . . . . . . . . . . . . . . . . 4
2.1. Goals of this document . . . . . . . . . . . . . . . . . . 5 2.1. Goals of this document . . . . . . . . . . . . . . . . . . 4
2.2. Relationship between API and protocol . . . . . . . . . . 5 2.2. Relationship between API and protocol . . . . . . . . . . 4
2.3. On interoperability and innovation . . . . . . . . . . . . 6 2.3. On interoperability and innovation . . . . . . . . . . . . 5
2.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Architecture and Functionality groups . . . . . . . . . . . . 8 3. Architecture and Functionality groups . . . . . . . . . . . . 7
4. Data transport . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Data transport . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Data framing and securing . . . . . . . . . . . . . . . . . . 13 5. Data framing and securing . . . . . . . . . . . . . . . . . . 12
6. Data formats . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Data formats . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Connection management . . . . . . . . . . . . . . . . . . . . 13 7. Connection management . . . . . . . . . . . . . . . . . . . . 12
8. Presentation and control . . . . . . . . . . . . . . . . . . . 14 8. Presentation and control . . . . . . . . . . . . . . . . . . . 13
9. Local system support functions . . . . . . . . . . . . . . . . 14 9. Local system support functions . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Transport and Middlebox specification . . . . . . . . 19 Appendix A. Transport and Middlebox specification . . . . . . . . 18
A.1. System-provided interfaces . . . . . . . . . . . . . . . . 19 A.1. System-provided interfaces . . . . . . . . . . . . . . . . 18
A.2. Middle box related functions . . . . . . . . . . . . . . . 19 A.2. Middle box related functions . . . . . . . . . . . . . . . 18
A.3. Transport protocols implemented . . . . . . . . . . . . . 20 A.3. Transport protocols implemented . . . . . . . . . . . . . 19
Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 19
B.1. Changes from B.1. Changes from
draft-alvestrand-dispatch-rtcweb-datagram-00 to -01 . . . 20 draft-alvestrand-dispatch-rtcweb-datagram-00 to -01 . . . 19
B.2. Changes from draft-alvestrand-dispatch-01 to B.2. Changes from draft-alvestrand-dispatch-01 to
draft-alvestrand-rtcweb-overview-00 . . . . . . . . . . . 20 draft-alvestrand-rtcweb-overview-00 . . . . . . . . . . . 19
B.3. Changes from draft-alvestrand-rtcweb-00 to -01 . . . . . . 20 B.3. Changes from draft-alvestrand-rtcweb-00 to -01 . . . . . . 19
B.4. Changes from draft-alvestrand-rtcweb-overview-01 to B.4. Changes from draft-alvestrand-rtcweb-overview-01 to
draft-ietf-rtcweb-overview-00 . . . . . . . . . . . . . . 21 draft-ietf-rtcweb-overview-00 . . . . . . . . . . . . . . 20
B.5. Changes from -00 to -01 of draft-ietf-rtcweb-overview . . 21 B.5. Changes from -00 to -01 of draft-ietf-rtcweb-overview . . 20
B.6. Changes from -01 to -02 of draft-ietf-rtcweb-overview . . 21 B.6. Changes from -01 to -02 of draft-ietf-rtcweb-overview . . 20
B.7. Changes from -02 to -03 of draft-ietf-rtcweb-overview . . 21 B.7. Changes from -02 to -03 of draft-ietf-rtcweb-overview . . 20
B.8. Changes from -03 to -04 of draft-ietf-rtcweb-overview . . 22 B.8. Changes from -03 to -04 of draft-ietf-rtcweb-overview . . 21
B.9. Changes from -04 to -05 of draft-ietf-rtcweb-overview . . 22 B.9. Changes from -04 to -05 of draft-ietf-rtcweb-overview . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 B.10. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
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 video conferencing. conversations (aka "Internet telephony") and video conferencing.
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 37 skipping to change at page 4, line 37
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
[W3C.WD-webrtc-20120209] [W3C.WD-webrtc-20120209][W3C.WD-mediacapture-streams-20120628]
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 necessary for implement this API; it is not intended to be necessary for
skipping to change at page 14, line 36 skipping to change at page 13, line 36
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, and interface; this is being worked on as part of the W3C API effort, and
will be part of the peer connection API [W3C.WD-webrtc-20120209], and will be part of the peer connection API [W3C.WD-webrtc-20120209], and
the device control API [getusermedia]. Considerations for the the media capture API [W3C.WD-mediacapture-streams-20120628].
implications of wanting to identify correspondents are described in Considerations for the implications of wanting to identify
[I-D.rescorla-rtcweb-generic-idp] (not a WG item). correspondents are described in [I-D.rescorla-rtcweb-generic-idp]
(not a WG item).
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 influence the user experience, but the exact functions strongly influence 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 15, line 20 skipping to change at page 14, line 22
o Echo cancellation should be good enough to achieve the suppression o Echo cancellation should be good enough to achieve the suppression
of acoustical feedback loops below a perceptually noticeable of acoustical feedback loops below a perceptually noticeable
level. 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 figure out who's controlling the camera, and the local participant figure out who's controlling the camera, and
possibly decide to revoke the permission for camera usage. 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 a reasonable dB range.
that we have one only>
The requirements on RTCWEB systems in this category are found in The requirements on RTCWEB systems with regard to audio processing
<WORKING GROUP DRAFT "MEDIA PROCESSING">; the proposed API for are found in [I-D.ietf-rtcweb-audio]; the proposed API for control of
control of local devices are found in [getusermedia]. local devices are found in [W3C.WD-mediacapture-streams-20120628].
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.
11. Security Considerations 11. Security Considerations
skipping to change at page 16, line 28 skipping to change at page 15, line 28
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 ASCII drawings in section 1. the ASCII drawings in section 1.
Thanks to Eric Rescorla, Justin Uberti, Henry Sinnreich, Colin Thanks to Eric Rescorla, Justin Uberti, Henry Sinnreich, Colin
Perkins and Simon Leinen for document review, ad to Heath Matlock for Perkins, Bjoern Hoehrmann and Simon Leinen for document review, and
grammatical review. to Heath Matlock for grammatical review.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-mmusic-sctp-sdp] [I-D.ietf-mmusic-sctp-sdp]
Loreto, S. and G. Camarillo, "Stream Control Transmission Loreto, S. and G. Camarillo, "Stream Control Transmission
Protocol (SCTP)-Based Media Transport in the Session Protocol (SCTP)-Based Media Transport in the Session
Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-01 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-03
(work in progress), March 2012. (work in progress), January 2013.
[I-D.ietf-rtcweb-audio]
Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
Requirements", draft-ietf-rtcweb-audio-01 (work in
progress), November 2012.
[I-D.ietf-rtcweb-data-channel] [I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Datagram Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Datagram
Connection", draft-ietf-rtcweb-data-channel-00 (work in Connection", draft-ietf-rtcweb-data-channel-02 (work in
progress), March 2012. progress), October 2012.
[I-D.ietf-rtcweb-jsep] [I-D.ietf-rtcweb-jsep]
Uberti, J. and C. Jennings, "Javascript Session Uberti, J. and C. Jennings, "Javascript Session
Establishment Protocol", draft-ietf-rtcweb-jsep-01 (work Establishment Protocol", draft-ietf-rtcweb-jsep-02 (work
in progress), June 2012. in progress), October 2012.
[I-D.ietf-rtcweb-rtp-usage] [I-D.ietf-rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
Communication (WebRTC): Media Transport and Use of RTP", Communication (WebRTC): Media Transport and Use of RTP",
draft-ietf-rtcweb-rtp-usage-04 (work in progress), draft-ietf-rtcweb-rtp-usage-05 (work in progress),
July 2012. October 2012.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for RTC-Web", Rescorla, E., "Security Considerations for RTC-Web",
draft-ietf-rtcweb-security-03 (work in progress), draft-ietf-rtcweb-security-04 (work in progress),
June 2012. January 2013.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "RTCWEB Security Architecture", Rescorla, E., "RTCWEB Security Architecture",
draft-ietf-rtcweb-security-arch-03 (work in progress), draft-ietf-rtcweb-security-arch-06 (work in progress),
July 2012. January 2013.
[I-D.nandakumar-rtcweb-stun-uri] [I-D.nandakumar-rtcweb-stun-uri]
Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit- Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit-
Huguenin, "URI Scheme for Session Traversal Utilities for Huguenin, "URI Scheme for Session Traversal Utilities for
NAT (STUN) Protocol", draft-nandakumar-rtcweb-stun-uri-01 NAT (STUN) Protocol", draft-nandakumar-rtcweb-stun-uri-03
(work in progress), March 2012. (work in progress), January 2013.
[I-D.tuexen-tsvwg-sctp-dtls-encaps] [I-D.tuexen-tsvwg-sctp-dtls-encaps]
Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS
Encapsulation of SCTP Packets for RTCWEB", Encapsulation of SCTP Packets for RTCWEB",
draft-tuexen-tsvwg-sctp-dtls-encaps-01 (work in progress), draft-tuexen-tsvwg-sctp-dtls-encaps-01 (work in progress),
July 2012. July 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. 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", RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 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.
skipping to change at page 18, line 20 skipping to change at page 17, line 21
[I-D.cbran-rtcweb-codec] [I-D.cbran-rtcweb-codec]
Bran, C., Jennings, C., and J. Valin, "WebRTC Codec and Bran, C., Jennings, C., and J. Valin, "WebRTC Codec and
Media Processing Requirements", Media Processing Requirements",
draft-cbran-rtcweb-codec-02 (work in progress), draft-cbran-rtcweb-codec-02 (work in progress),
March 2012. March 2012.
[I-D.ietf-rtcweb-use-cases-and-requirements] [I-D.ietf-rtcweb-use-cases-and-requirements]
Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use-cases and Requirements", Time Communication Use-cases and Requirements",
draft-ietf-rtcweb-use-cases-and-requirements-09 (work in draft-ietf-rtcweb-use-cases-and-requirements-10 (work in
progress), June 2012. progress), December 2012.
[I-D.jesup-rtcweb-data-protocol] [I-D.jesup-rtcweb-data-protocol]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
Protocol", draft-jesup-rtcweb-data-protocol-02 (work in Protocol", draft-jesup-rtcweb-data-protocol-03 (work in
progress), July 2012. progress), September 2012.
[I-D.rescorla-rtcweb-generic-idp] [I-D.rescorla-rtcweb-generic-idp]
Rescorla, E., "RTCWEB Generic Identity Provider Rescorla, E., "RTCWEB Generic Identity Provider
Interface", draft-rescorla-rtcweb-generic-idp-01 (work in Interface", draft-rescorla-rtcweb-generic-idp-01 (work in
progress), March 2012. progress), March 2012.
[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.
[W3C.WD-html5-20110525] [W3C.WD-html5-20110525]
Hickson, I., "HTML5", World Wide Web Consortium Hickson, I., "HTML5", World Wide Web Consortium
LastCall WD-html5-20110525, May 2011, LastCall WD-html5-20110525, May 2011,
<http://www.w3.org/TR/2011/WD-html5-20110525>. <http://www.w3.org/TR/2011/WD-html5-20110525>.
[W3C.WD-mediacapture-streams-20120628]
Burnett, D. and A. Narayanan, "Media Capture and Streams",
World Wide Web Consortium WD WD-mediacapture-streams-
20120628, June 2012, <http://www.w3.org/TR/2012/
WD-mediacapture-streams-20120628>.
[W3C.WD-webrtc-20120209] [W3C.WD-webrtc-20120209]
Bergkvist, A., Burnett, D., Narayanan, A., and C. Bergkvist, A., Burnett, D., Narayanan, A., and C.
Jennings, "WebRTC 1.0: Real-time Communication Between Jennings, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD WD-webrtc- Browsers", World Wide Web Consortium WD WD-webrtc-
20120209, February 2012, 20120209, February 2012,
<http://www.w3.org/TR/2012/WD-webrtc-20120209>. <http://www.w3.org/TR/2012/WD-webrtc-20120209>.
[getusermedia]
Burnett, D. and A. Narayanan, "getusermedia: Getting
access to local devices that can generate multimedia
streams", December 2011,
<http://dev.w3.org/2011/webrtc/editor/getusermedia.html>.
Appendix A. Transport and Middlebox specification Appendix A. Transport and Middlebox specification
The draft referred to as "transport and middle boxes" in Section 4 The draft referred to as "transport and middle boxes" in Section 4
has not been written yet. This appendix contains some keywords to has not been written yet. This appendix contains some keywords to
what it should say; this also serves the purpose of linking to the what it should say; this also serves the purpose of linking to the
drafts-in-progress that are relevant to this specification. drafts-in-progress that are relevant to this specification.
A.1. System-provided interfaces A.1. System-provided interfaces
The protocol specifications used here assume that the following The protocol specifications used here assume that the following
protocols are available as system-level interfaces: protocols are available as system-level interfaces:
o UDP. This is the protocol assumed by most protocol elements o UDP. This is the protocol assumed by most protocol elements
described. described.
o TCP. This is used for HTTP/WebSockets, as well as for TURN/SSL o TCP. This is used for HTTP/WebSockets, as well as for TURN/SSL
and ICE-TCP. and ICE-TCP.
For both protocols, we assume the ability to set the DSCP code point For both protocols, this specification assumes the ability to set the
of the sockets opened. We do not assume that the DSCP codepoints DSCP code point of the sockets opened. It does not assume that the
will be honored, and we do assume that they may be zeroed or changed, DSCP codepoints will be honored, and does assume that they may be
since this is a local configuration issue. zeroed or changed, since this is a local configuration issue.
We do not assume that the implementation will have access to ICMP or This specification does not assume that the implementation will have
raw IP. access to ICMP or raw IP.
A.2. Middle box related functions A.2. Middle box related functions
The primary mechanism to deal with middle boxes is ICE, which is an The primary mechanism to deal with middle boxes is ICE, which is an
appropriate way to deal with NAT boxes and firewalls that accept appropriate way to deal with NAT boxes and firewalls that accept
traffic from the inside, but only from the outside if it's in traffic from the inside, but only from the outside if it's in
response to inside traffic (simple stateful firewalls). response to inside traffic (simple stateful firewalls).
In order to deal with symmetric NATs, TURN MUST be supported. In order to deal with symmetric NATs, TURN MUST be supported.
In order to deal with firewalls that block all UDP traffic, TURN over In order to deal with firewalls that block all UDP traffic, TURN over
TCP MUST be supported. (QUESTION: What about ICE-TCP?) TCP MUST be supported. (QUESTION: What about ICE-TCP?)
The following specifications MUST be supported: The following specifications MUST be supported:
o ICE [RFC5245] o ICE [RFC5245]
o TURN, including TURN over TCP [[QUESTION: and TURN over TLS]], o TURN, including TURN over TCP [[QUESTION: and TURN over TLS]],
[RFC5766]. [RFC5766].
For referring to ICE servers, we use the STUN URI, For referring to STUN and TURN servers, this specification depends on
[I-D.nandakumar-rtcweb-stun-uri]. the STUN URI, [I-D.nandakumar-rtcweb-stun-uri].
A.3. Transport protocols implemented A.3. Transport protocols implemented
For data transport, we implement SCTP over DTLS over ICE. This is For data transport, RTCWEB implementations support SCTP over DTLS
specified in [I-D.tuexen-tsvwg-sctp-dtls-encaps]. Negotiation of over ICE. This is specified in [I-D.tuexen-tsvwg-sctp-dtls-encaps].
this transport in SCTP is defined in [I-D.ietf-mmusic-sctp-sdp]. Negotiation of this transport in SCTP is defined in
[I-D.ietf-mmusic-sctp-sdp].
Appendix B. Change log Appendix B. 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.
B.1. Changes from draft-alvestrand-dispatch-rtcweb-datagram-00 to -01 B.1. Changes from draft-alvestrand-dispatch-rtcweb-datagram-00 to -01
Added section "On interoperability and innovation" Added section "On interoperability and innovation"
skipping to change at page 22, line 18 skipping to change at page 21, line 21
Several wording changes in response to review comments from EKR Several wording changes in response to review comments from EKR
Added Appendix A to hold references and notes that are not yet in a Added Appendix A to hold references and notes that are not yet in a
separate document. separate document.
B.9. Changes from -04 to -05 of draft-ietf-rtcweb-overview B.9. Changes from -04 to -05 of draft-ietf-rtcweb-overview
Minor grammatical fixes. This is mainly a "keepalive" refresh. Minor grammatical fixes. This is mainly a "keepalive" refresh.
B.10. Changes from -05 to -06
Clarifications in response to Last Call review comments. Inserted
reference to draft-ietf-rtcweb-audio.
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. 32 change blocks. 
95 lines changed or deleted 98 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/