--- 1/draft-ietf-rtcweb-overview-16.txt 2017-02-17 03:13:08.850740012 -0800 +++ 2/draft-ietf-rtcweb-overview-17.txt 2017-02-17 03:13:08.898741145 -0800 @@ -1,18 +1,18 @@ Network Working Group H. Alvestrand Internet-Draft Google -Intended status: Standards Track November 14, 2016 -Expires: May 18, 2017 +Intended status: Standards Track February 17, 2017 +Expires: August 21, 2017 Overview: Real Time Protocols for Browser-based Applications - draft-ietf-rtcweb-overview-16 + draft-ietf-rtcweb-overview-17 Abstract This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". 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 that the parts that belong in the Internet protocol suite are fully @@ -32,25 +32,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 18, 2017. + This Internet-Draft will expire on August 21, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -94,20 +94,21 @@ A.11. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 21 A.12. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 21 A.13. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 21 A.14. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 21 A.15. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 22 A.16. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 22 A.17. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 22 A.18. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 22 A.19. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 22 A.20. Changes from -15 to -16 . . . . . . . . . . . . . . . . . 22 + A.21. Changes from -16 to -17 . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction The Internet was, from very early in its lifetime, considered a possible vehicle for the deployment of real-time, interactive applications - with the most easily imaginable being audio conversations (aka "Internet telephony") and video conferencing. The first attempts to build this were dependent on special networks, @@ -164,44 +165,45 @@ 2.1. Goals of this document The goal of the WebRTC protocol specification is to specify a set of protocols that, if all are implemented, will allow an implementation to communicate with another implementation using audio, video and data sent along the most direct possible path between the participants. This document is intended to serve as the roadmap to the WebRTC - specifications. It defines terms used by other pieces of - specification, lists references to other specifications that don't - need further elaboration in the WebRTC context, and gives pointers to - other documents that form part of the WebRTC suite. + specifications. It defines terms used by other parts of the WebRTC + protocol specifications, lists references to other specifications + that don't need further elaboration in the WebRTC context, and gives + pointers to other documents that form part of the WebRTC suite. By reading this document and the documents it refers to, it should be possible to have all information needed to implement an WebRTC compatible implementation. 2.2. Relationship between API and protocol - The total WebRTC effort consists of two pieces: + The total WebRTC effort consists of two major parts, each consisting + of multiple documents: o A protocol specification, done in the IETF - - o A Javascript API specification, done in the W3C + o A Javascript API specification, defined in a series of W3C + documents [W3C.WD-webrtc-20120209][W3C.WD-mediacapture-streams-20120628] Together, these two specifications aim to provide an environment - where Javascript embedded in any page, viewed in any compatible - browser, when suitably authorized by its user, is able to set up - communication using audio, video and auxiliary data, where the - browser environment does not constrain the types of application in - which this functionality can be used. + where Javascript embedded in any page, when suitably authorized by + its user, is able to set up communication using audio, video and + auxiliary data, as long as the browser supports this specification. + The browser environment does not constrain the types of application + in which this functionality can be used. The protocol specification does not assume that all implementations implement this API; it is not intended to be necessary for interoperation to know whether the entity one is communicating with is a browser or another device implementing this specification. The goal of cooperation between the protocol specification and the API specification is that for all options and features of the protocol specification, it should be clear which API calls to make to exercise that option or feature; similarly, for any sequence of API @@ -301,24 +303,28 @@ API: Application Programming Interface - a specification of a set of calls and events, usually tied to a programming language or an abstract formal specification such as WebIDL, with its defined semantics. Browser: Used synonymously with "Interactive User Agent" as defined in the HTML specification [W3C.WD-html5-20110525]. See also "WebRTC User Agent". + Data channel: An abstraction that allows data to be sent between + WebRTC endpoints in the form of messages. Two endpoints can have + multiple data channels between them. + ICE Agent: An implementation of the Interactive Connectivty - Establishment (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). + Establishment (ICE) [I-D.ietf-ice-rfc5245bis] 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 expectation is that an action from one party can cause a reaction by another party, and the reaction can be observed by the first party, with the total time required for the action/reaction/ observation is on the order of no more than hundreds of milliseconds. Media: Audio and video content. Not to be confused with "transmission media" such as wires. @@ -333,54 +339,54 @@ Real-time media: Media where generation of content and display of content are intended to occur closely together in time (on the order of no more than hundreds of milliseconds). Real-time media can be used to support interactive communication. 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. + and control media paths and data paths. Signaling Path: The communication channels used between entities participating in signaling 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 definitions should be used to the greatest extent possible. 3. Architecture and Functionality groups The model of real-time support for browser-based applications does not assume 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 video conferencing 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. + protocols that browsers use to 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 + | WebSockets | | +----------------------------+ | Javascript/HTML/CSS | +----------------------------+ Other ^ ^RTC APIs | |APIs +---|-----------------|------+ | | | | | +---------+| @@ -390,44 +396,44 @@ | | || | | || | +---------+| +---------------------|------+ | V Native OS Services Figure 1: Browser Model - Note that HTTP and Websockets are also offered to the Javascript + Note that HTTP and WebSockets are also offered to the Javascript application through browser APIs. 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 endpoint 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 | | | Signaling | | | |-------------| | | Server | path | Server | | | | | +-----------+ +-----------+ / \ / \ Application-defined / \ over - / \ HTTP/Websockets + / \ HTTP/WebSockets / Application-defined over \ - / HTTP/Websockets \ + / HTTP/WebSockets \ / \ +-----------+ +-----------+ |JS/HTML/CSS| |JS/HTML/CSS| +-----------+ +-----------+ +-----------+ +-----------+ | | | | | | | | | Browser | ------------------------- | Browser | | | Media path | | | | | | @@ -443,43 +449,45 @@ If the two Web servers are operated by different entities, the inter- server signaling mechanism needs to be agreed upon, either by standardization or by other means of agreement. Existing protocols (for example SIP [RFC3261] or XMPP [RFC6120]) could be used between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server. For example, if both operators' servers implement SIP, SIP could be used for communication between servers, along with either a - standardized signaling mechanism (e.g. SIP over Websockets) or a + standardized signaling mechanism (e.g. SIP over WebSockets) or a proprietary signaling mechanism used between the application running in the browser and the web server. Similarly, if both operators' servers implement XMPP, XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g. - XMPP over Websockets or BOSH) or a proprietary signaling mechanism + XMPP over WebSockets or BOSH) or a proprietary signaling mechanism used between the application running in the browser and the web server. - The choice of protocols, and definition of the translation between - them, is outside the scope of the WebRTC protocol suite described in - the document. + The choice of protocols for client-server and inter-server + signalling, and definition of the translation between them, is + outside the scope of the WebRTC protocol suite described in the + document. 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 connections between entities, as well as the functions for deciding when to send data: Congestion management, bandwidth estimation and so on. - o Data framing: RTP and other data formats that serve as containers, - and their functions for data confidentiality and integrity. + o Data framing: RTP, SCTP and other data formats that serve as + containers, and their functions for data confidentiality and + integrity. o Data formats: Codec specifications, format specifications and functionality specifications for the data passed between systems. Audio and video codecs, as well as formats for data and document sharing, belong in this category. In order to make use of data formats, a way to describe them, a session description, is needed. o Connection management: Setting up connections, agreeing on data formats, changing data formats during the duration of a call; SIP and Jingle/XMPP belong in this category. @@ -652,22 +660,23 @@ possibly decide to revoke the permission for camera usage. o Automatic gain control, if present, should normalize a speaking voice into a reasonable dB range. The requirements on WebRTC systems with regard to audio processing are found in [I-D.ietf-rtcweb-audio]; the proposed API for control of local devices are found in [W3C.WD-mediacapture-streams-20120628]. WebRTC endpoints MUST implement the processing functions in - [I-D.ietf-rtcweb-audio]. (Together with the requirement inSection 6, - this means that WebRTC endpoints MUST implement the whole document.) + [I-D.ietf-rtcweb-audio]. (Together with the requirement in + Section 6, this means that WebRTC endpoints MUST implement the whole + document.) 10. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 11. Security Considerations @@ -705,46 +714,53 @@ does not mean that others' contributions are less important. Thanks to Cary Bran, Cullen Jennings, Colin Perkins, Magnus Westerlund and Joerg Ott, who offered technical contributions on various versions of the draft. Thanks to Jonathan Rosenberg, Matthew Kaufman and others at Skype for the ASCII drawings in section 1. Thanks to Bjoern Hoehrmann, Colin Perkins, Colton Shields, Eric - Rescorla, Heath Matlock, Henry Sinnreich, Justin Uberti, Keith Drage - and Simon Leinen for document review. + Rescorla, Heath Matlock, Henry Sinnreich, Justin Uberti, Keith Drage, + Magnus Westerlund, Olle E. Johansson and Simon Leinen for document + review. 13. References 13.1. Normative References + [I-D.ietf-ice-rfc5245bis] + Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive + Connectivity Establishment (ICE): A Protocol for Network + Address Translator (NAT) Traversal", draft-ietf-ice- + rfc5245bis-08 (work in progress), December 2016. + [I-D.ietf-rtcweb-audio] Valin, J. and C. Bran, "WebRTC Audio Codec and Processing Requirements", draft-ietf-rtcweb-audio-11 (work in progress), April 2016. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Establishment Protocol", draft-ietf-rtcweb-data- protocol-09 (work in progress), January 2015. [I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C., and E. Rescorla, "Javascript - Session Establishment Protocol", draft-ietf-rtcweb-jsep-17 - (work in progress), October 2016. + Session Establishment Protocol", draft-ietf-rtcweb-jsep-18 + (work in progress), January 2017. [I-D.ietf-rtcweb-rtp-usage] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 2016. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-08 (work in progress), February 2015. @@ -770,26 +786,20 @@ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . - [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment - (ICE): A Protocol for Network Address Translator (NAT) - Traversal for Offer/Answer Protocols", RFC 5245, - DOI 10.17487/RFC5245, April 2010, - . - [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, . [W3C.WD-webrtc-20120209] Bergkvist, A., Burnett, D., Jennings, C., and A. Narayanan, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc- @@ -1003,19 +1013,23 @@ None. This is a "keepalive" update. A.19. Changes from -14 to -15 Changed "gateways" reference to point to the WG document. A.20. Changes from -15 to -16 None. This is a "keepalive" publication. +A.21. Changes from -16 to -17 + + Addressed review comments by Olle E. Johansson and Magnus Westerlund + Author's Address Harald T. Alvestrand Google Kungsbron 2 Stockholm 11122 Sweden Email: harald@alvestrand.no