idnits 2.17.1 draft-ietf-rtcweb-overview-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 12, 2017) is 2355 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-24 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-09 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-13 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-21) exists of draft-ietf-ice-trickle-14 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-39 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Alvestrand 3 Internet-Draft Google 4 Intended status: Standards Track November 12, 2017 5 Expires: May 16, 2018 7 Overview: Real Time Protocols for Browser-based Applications 8 draft-ietf-rtcweb-overview-19 10 Abstract 12 This document gives an overview and context of a protocol suite 13 intended for use with real-time applications that can be deployed in 14 browsers - "real time communication on the Web". 16 It intends to serve as a starting and coordination point to make sure 17 all the parts that are needed to achieve this goal are findable, and 18 that the parts that belong in the Internet protocol suite are fully 19 specified and on the right publication track. 21 This document is an Applicability Statement - it does not itself 22 specify any protocol, but specifies which other specifications WebRTC 23 compliant implementations are supposed to follow. 25 This document is a work item of the RTCWEB working group. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 16, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Principles and Terminology . . . . . . . . . . . . . . . . . 4 63 2.1. Goals of this document . . . . . . . . . . . . . . . . . 4 64 2.2. Relationship between API and protocol . . . . . . . . . . 5 65 2.3. On interoperability and innovation . . . . . . . . . . . 7 66 2.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 67 3. Architecture and Functionality groups . . . . . . . . . . . . 8 68 4. Data transport . . . . . . . . . . . . . . . . . . . . . . . 12 69 5. Data framing and securing . . . . . . . . . . . . . . . . . . 13 70 6. Data formats . . . . . . . . . . . . . . . . . . . . . . . . 13 71 7. Connection management . . . . . . . . . . . . . . . . . . . . 13 72 8. Presentation and control . . . . . . . . . . . . . . . . . . 14 73 9. Local system support functions . . . . . . . . . . . . . . . 14 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 79 13.2. Informative References . . . . . . . . . . . . . . . . . 18 80 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 20 81 A.1. Changes from draft-alvestrand-dispatch-rtcweb-datagram-00 82 to -01 . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 A.2. Changes from draft-alvestrand-dispatch-01 to draft- 84 alvestrand-rtcweb-overview-00 . . . . . . . . . . . . . . 20 85 A.3. Changes from draft-alvestrand-rtcweb-00 to -01 . . . . . 20 86 A.4. Changes from draft-alvestrand-rtcweb-overview-01 to 87 draft-ietf-rtcweb-overview-00 . . . . . . . . . . . . . . 21 88 A.5. Changes from -00 to -01 of draft-ietf-rtcweb-overview . . 21 89 A.6. Changes from -01 to -02 of draft-ietf-rtcweb-overview . . 21 90 A.7. Changes from -02 to -03 of draft-ietf-rtcweb-overview . . 21 91 A.8. Changes from -03 to -04 of draft-ietf-rtcweb-overview . . 22 92 A.9. Changes from -04 to -05 of draft-ietf-rtcweb-overview . . 22 93 A.10. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 22 94 A.11. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 22 95 A.12. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 22 96 A.13. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 22 97 A.14. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 22 98 A.15. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 23 99 A.16. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 23 100 A.17. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 23 101 A.18. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 23 102 A.19. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 23 103 A.20. Changes from -15 to -16 . . . . . . . . . . . . . . . . . 23 104 A.21. Changes from -16 to -17 . . . . . . . . . . . . . . . . . 24 105 A.22. Changes from -17 to -18 . . . . . . . . . . . . . . . . . 24 106 A.23. Changes from -18 to -19 . . . . . . . . . . . . . . . . . 24 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 109 1. Introduction 111 The Internet was, from very early in its lifetime, considered a 112 possible vehicle for the deployment of real-time, interactive 113 applications - with the most easily imaginable being audio 114 conversations (aka "Internet telephony") and video conferencing. 116 The first attempts to build this were dependent on special networks, 117 special hardware and custom-built software, often at very high prices 118 or at low quality, placing great demands on the infrastructure. 120 As the available bandwidth has increased, and as processors and other 121 hardware has become ever faster, the barriers to participation have 122 decreased, and it has become possible to deliver a satisfactory 123 experience on commonly available computing hardware. 125 Still, there are a number of barriers to the ability to communicate 126 universally - one of these is that there is, as of yet, no single set 127 of communication protocols that all agree should be made available 128 for communication; another is the sheer lack of universal 129 identification systems (such as is served by telephone numbers or 130 email addresses in other communications systems). 132 Development of The Universal Solution has, however, proved hard. 134 The last few years have also seen a new platform rise for deployment 135 of services: The browser-embedded application, or "Web application". 136 It turns out that as long as the browser platform has the necessary 137 interfaces, it is possible to deliver almost any kind of service on 138 it. 140 Traditionally, these interfaces have been delivered by plugins, which 141 had to be downloaded and installed separately from the browser; in 142 the development of HTML5, application developers see much promise in 143 the possibility of making those interfaces available in a 144 standardized way within the browser. 146 This memo describes a set of building blocks that can be made 147 accessible and controllable through a Javascript API in a browser, 148 and which together form a sufficient set of functions to allow the 149 use of interactive audio and video in applications that communicate 150 directly between browsers across the Internet. The resulting 151 protocol suite is intended to enable all the applications that are 152 described as required scenarios in the use cases document [RFC7478]. 154 Other efforts, for instance the W3C Web Real-Time Communications, Web 155 Applications Security, and Device and Sensor working groups, focus on 156 making standardized APIs and interfaces available, within or 157 alongside the HTML5 effort, for those functions. This memo 158 concentrates on specifying the protocols and subprotocols that are 159 needed to specify the interactions over the network. 161 Operators should note that deployment of WebRTC will result in a 162 change in the nature of signaling for real time media on the network, 163 and may result in a shift in the kinds of devices used to create and 164 consume such media. In the case of signaling, WebRTC session setup 165 will typically occur over TLS-secured web technologies using 166 application-specific protocols. Operational techniques that involve 167 inserting network elements to interpret SDP -- either through 168 endpoint cooperation [RFC3361] or through the transparent insertion 169 of SIP Application Level Gateways (ALGs) -- will not work with such 170 signaling. In the case of networks using cooperative endpoints, the 171 approaches defined in [RFC8155] may serve as a suitable replacement 172 for [RFC3361]. The increase in browser-based communications may also 173 lead to a shift away from dedicated real-time-communications 174 hardware, such as SIP desk phones. This will diminish the efficacy 175 of operational techniques that place dedicated real-time devices on 176 their own network segment, address range, or VLAN for purposes such 177 as applying traffic filtering and QoS. Applying the markings 178 described in [I-D.ietf-tsvwg-rtcweb-qos] may be appropriate 179 replacements for such techniques. 181 This memo uses the term "WebRTC" (note the case used) to refer to the 182 overall effort consisting of both IETF and W3C efforts. 184 2. Principles and Terminology 186 2.1. Goals of this document 188 The goal of the WebRTC protocol specification is to specify a set of 189 protocols that, if all are implemented, will allow an implementation 190 to communicate with another implementation using audio, video and 191 data sent along the most direct possible path between the 192 participants. 194 This document is intended to serve as the roadmap to the WebRTC 195 specifications. It defines terms used by other parts of the WebRTC 196 protocol specifications, lists references to other specifications 197 that don't need further elaboration in the WebRTC context, and gives 198 pointers to other documents that form part of the WebRTC suite. 200 By reading this document and the documents it refers to, it should be 201 possible to have all information needed to implement a WebRTC 202 compatible implementation. 204 2.2. Relationship between API and protocol 206 The total WebRTC effort consists of two major parts, each consisting 207 of multiple documents: 209 o A protocol specification, done in the IETF 211 o A Javascript API specification, defined in a series of W3C 212 documents 213 [W3C.WD-webrtc-20120209][W3C.WD-mediacapture-streams-20120628] 215 Together, these two specifications aim to provide an environment 216 where Javascript embedded in any page, when suitably authorized by 217 its user, is able to set up communication using audio, video and 218 auxiliary data, as long as the browser supports this specification. 219 The browser environment does not constrain the types of application 220 in which this functionality can be used. 222 The protocol specification does not assume that all implementations 223 implement this API; it is not intended to be necessary for 224 interoperation to know whether the entity one is communicating with 225 is a browser or another device implementing this specification. 227 The goal of cooperation between the protocol specification and the 228 API specification is that for all options and features of the 229 protocol specification, it should be clear which API calls to make to 230 exercise that option or feature; similarly, for any sequence of API 231 calls, it should be clear which protocol options and features will be 232 invoked. Both subject to constraints of the implementation, of 233 course. 235 The following terms are used across the documents specifying the 236 WebRTC suite, in the specific meanings given here. Not all terms are 237 used in this document. Other terms are used in their commonly used 238 meaning. 240 Agent: Undefined term. See "SDP Agent" and "ICE Agent". 242 Application Programming Interface (API): A specification of a set of 243 calls and events, usually tied to a programming language or an 244 abstract formal specification such as WebIDL, with its defined 245 semantics. 247 Browser: Used synonymously with "Interactive User Agent" as defined 248 in the HTML specification [W3C.WD-html5-20110525]. See also 249 "WebRTC User Agent". 251 Data Channel: An abstraction that allows data to be sent between 252 WebRTC endpoints in the form of messages. Two endpoints can have 253 multiple data channels between them. 255 ICE Agent: An implementation of the Interactive Connectivity 256 Establishment (ICE) [RFC5245] protocol. An ICE Agent may also be 257 an SDP Agent, but there exist ICE Agents that do not use SDP (for 258 instance those that use Jingle [XEP-0166]). 260 Interactive: Communication between multiple parties, where the 261 expectation is that an action from one party can cause a reaction 262 by another party, and the reaction can be observed by the first 263 party, with the total time required for the action/reaction/ 264 observation is on the order of no more than hundreds of 265 milliseconds. 267 Media: Audio and video content. Not to be confused with 268 "transmission media" such as wires. 270 Media Path: The path that media data follows from one WebRTC 271 endpoint to another. 273 Protocol: A specification of a set of data units, their 274 representation, and rules for their transmission, with their 275 defined semantics. A protocol is usually thought of as going 276 between systems. 278 Real-time Media: Media where generation of content and display of 279 content are intended to occur closely together in time (on the 280 order of no more than hundreds of milliseconds). Real-time media 281 can be used to support interactive communication. 283 SDP Agent: The protocol implementation involved in the Session 284 Description Protocol (SDP) offer/answer exchange, as defined in 285 [RFC3264] section 3. 287 Signaling: Communication that happens in order to establish, manage 288 and control media paths and data paths. 290 Signaling Path: The communication channels used between entities 291 participating in signaling to transfer signaling. There may be 292 more entities in the signaling path than in the media path. 294 WebRTC Browser: (also called a WebRTC User Agent or WebRTC UA) 295 Something that conforms to both the protocol specification and the 296 Javascript API cited above. 298 WebRTC non-Browser: Something that conforms to the protocol 299 specification, but does not claim to implement the Javascript API. 300 This can also be called a "WebRTC device" or "WebRTC native 301 application". 303 WebRTC Endpoint: Either a WebRTC browser or a WebRTC non-browser. 304 It conforms to the protocol specification. 306 WebRTC-compatible Endpoint: An endpoint that is able to successfully 307 communicate with a WebRTC endpoint, but may fail to meet some 308 requirements of a WebRTC endpoint. This may limit where in the 309 network such an endpoint can be attached, or may limit the 310 security guarantees that it offers to others. It is not 311 constrained by this specification; when it is mentioned at all, it 312 is to note the implications on WebRTC-compatible endpoints of the 313 requirements placed on WebRTC endpoints. 315 WebRTC Gateway: A WebRTC-compatible endpoint that mediates media 316 traffic to non-WebRTC entities. 318 All WebRTC browsers are WebRTC endpoints, so any requirement on a 319 WebRTC endpoint also applies to a WebRTC browser. 321 A WebRTC non-browser may be capable of hosting applications in a 322 similar way to the way in which a browser can host Javascript 323 applications, typically by offering APIs in other languages. For 324 instance it may be implemented as a library that offers a C++ API 325 intended to be loaded into applications. In this case, similar 326 security considerations as for Javascript may be needed; however, 327 since such APIs are not defined or referenced here, this document 328 cannot give any specific rules for those interfaces. 330 WebRTC gateways are described in a separate document, 331 [I-D.ietf-rtcweb-gateways]. 333 2.3. On interoperability and innovation 335 The "Mission statement of the IETF" [RFC3935] states that "The 336 benefit of a standard to the Internet is in interoperability - that 337 multiple products implementing a standard are able to work together 338 in order to deliver valuable functions to the Internet's users." 340 Communication on the Internet frequently occurs in two phases: 342 o Two parties communicate, through some mechanism, what 343 functionality they both are able to support 345 o They use that shared communicative functionality to communicate, 346 or, failing to find anything in common, give up on communication. 348 There are often many choices that can be made for communicative 349 functionality; the history of the Internet is rife with the proposal, 350 standardization, implementation, and success or failure of many types 351 of options, in all sorts of protocols. 353 The goal of having a mandatory to implement function set is to 354 prevent negotiation failure, not to preempt or prevent negotiation. 356 The presence of a mandatory to implement function set serves as a 357 strong changer of the marketplace of deployment - in that it gives a 358 guarantee that, as long as you conform to a specification, and the 359 other party is willing to accept communication at the base level of 360 that specification, you can communicate successfully. 362 The alternative, that is having no mandatory to implement, does not 363 mean that you cannot communicate, it merely means that in order to be 364 part of the communications partnership, you have to implement the 365 standard "and then some". The "and then some" is usually called a 366 profile of some sort; in the version most antithetical to the 367 Internet ethos, that "and then some" consists of having to use a 368 specific vendor's product only. 370 2.4. Terminology 372 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 373 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 374 document are to be interpreted as described in [RFC2119]. 376 3. Architecture and Functionality groups 378 For browser-based applications, the model for real-time support does 379 not assume that the browser will contain all the functions needed for 380 an application such as a telephone or a video conference. The vision 381 is that the browser will have the functions needed for a Web 382 application, working in conjunction with its backend servers, to 383 implement these functions. 385 This means that two vital interfaces need specification: The 386 protocols that browsers use to talk to each other, without any 387 intervening servers, and the APIs that are offered for a Javascript 388 application to take advantage of the browser's functionality. 390 +------------------------+ On-the-wire 391 | | Protocols 392 | Servers |---------> 393 | | 394 | | 395 +------------------------+ 396 ^ 397 | 398 | 399 | HTTPS/ 400 | WebSockets 401 | 402 | 403 +----------------------------+ 404 | Javascript/HTML/CSS | 405 +----------------------------+ 406 Other ^ ^ RTC 407 APIs | | APIs 408 +---|-----------------|------+ 409 | | | | 410 | +---------+| 411 | | Browser || On-the-wire 412 | Browser | RTC || Protocols 413 | | Function|-----------> 414 | | || 415 | | || 416 | +---------+| 417 +---------------------|------+ 418 | 419 V 420 Native OS Services 422 Figure 1: Browser Model 424 Note that HTTPS and WebSockets are also offered to the Javascript 425 application through browser APIs. 427 As for all protocol and API specifications, there is no restriction 428 that the protocols can only be used to talk to another browser; since 429 they are fully specified, any endpoint that implements the protocols 430 faithfully should be able to interoperate with the application 431 running in the browser. 433 A commonly imagined model of deployment is the one depicted below. 434 In the figure below JS is Javascript. 436 +-----------+ +-----------+ 437 | Web | | Web | 438 | | Signaling | | 439 | |-------------| | 440 | Server | path | Server | 441 | | | | 442 +-----------+ +-----------+ 443 / \ 444 / \ Application-defined 445 / \ over 446 / \ HTTPS/WebSockets 447 / Application-defined over \ 448 / HTTPS/WebSockets \ 449 / \ 450 +-----------+ +-----------+ 451 |JS/HTML/CSS| |JS/HTML/CSS| 452 +-----------+ +-----------+ 453 +-----------+ +-----------+ 454 | | | | 455 | | | | 456 | Browser | ------------------------- | Browser | 457 | | Media path | | 458 | | | | 459 +-----------+ +-----------+ 461 Figure 2: Browser RTC Trapezoid 463 On this drawing, the critical part to note is that the media path 464 ("low path") goes directly between the browsers, so it has to be 465 conformant to the specifications of the WebRTC protocol suite; the 466 signaling path ("high path") goes via servers that can modify, 467 translate or manipulate the signals as needed. 469 If the two Web servers are operated by different entities, the inter- 470 server signaling mechanism needs to be agreed upon, either by 471 standardization or by other means of agreement. Existing protocols 472 (e.g. SIP [RFC3261] or XMPP [RFC6120]) could be used between 473 servers, while either a standards-based or proprietary protocol could 474 be used between the browser and the web server. 476 For example, if both operators' servers implement SIP, SIP could be 477 used for communication between servers, along with either a 478 standardized signaling mechanism (e.g. SIP over WebSockets) or a 479 proprietary signaling mechanism used between the application running 480 in the browser and the web server. Similarly, if both operators' 481 servers implement Extensible Messaging and Presence Protocol (XMPP), 482 XMPP could be used for communication between XMPP servers, with 483 either a standardized signaling mechanism (e.g. XMPP over WebSockets 484 or BOSH [XEP-0124] or a proprietary signaling mechanism used between 485 the application running in the browser and the web server. 487 The choice of protocols for client-server and inter-server 488 signalling, and definition of the translation between them, is 489 outside the scope of the WebRTC protocol suite described in the 490 document. 492 The functionality groups that are needed in the browser can be 493 specified, more or less from the bottom up, as: 495 o Data transport: such as TCP, UDP and the means to securely set up 496 connections between entities, as well as the functions for 497 deciding when to send data: congestion management, bandwidth 498 estimation and so on. 500 o Data framing: RTP, SCTP, DTLS, and other data formats that serve 501 as containers, and their functions for data confidentiality and 502 integrity. 504 o Data formats: Codec specifications, format specifications and 505 functionality specifications for the data passed between systems. 506 Audio and video codecs, as well as formats for data and document 507 sharing, belong in this category. In order to make use of data 508 formats, a way to describe them, a session description, is needed. 510 o Connection management: Setting up connections, agreeing on data 511 formats, changing data formats during the duration of a call; SDP, 512 SIP, and Jingle/XMPP belong in this category. 514 o Presentation and control: What needs to happen in order to ensure 515 that interactions behave in a non-surprising manner. This can 516 include floor control, screen layout, voice activated image 517 switching and other such functions - where part of the system 518 require the cooperation between parties. XCON and Cisco/ 519 Tandberg's TIP were some attempts at specifying this kind of 520 functionality; many applications have been built without 521 standardized interfaces to these functions. 523 o Local system support functions: These are things that need not be 524 specified uniformly, because each participant may choose to do 525 these in a way of the participant's choosing, without affecting 526 the bits on the wire in a way that others have to be cognizant of. 527 Examples in this category include echo cancellation (some forms of 528 it), local authentication and authorization mechanisms, OS access 529 control and the ability to do local recording of conversations. 531 Within each functionality group, it is important to preserve both 532 freedom to innovate and the ability for global communication. 533 Freedom to innovate is helped by doing the specification in terms of 534 interfaces, not implementation; any implementation able to 535 communicate according to the interfaces is a valid implementation. 536 Ability to communicate globally is helped both by having core 537 specifications be unencumbered by IPR issues and by having the 538 formats and protocols be fully enough specified to allow for 539 independent implementation. 541 One can think of the three first groups as forming a "media transport 542 infrastructure", and of the three last groups as forming a "media 543 service". In many contexts, it makes sense to use a common 544 specification for the media transport infrastructure, which can be 545 embedded in browsers and accessed using standard interfaces, and "let 546 a thousand flowers bloom" in the "media service" layer; to achieve 547 interoperable services, however, at least the first five of the six 548 groups need to be specified. 550 4. Data transport 552 Data transport refers to the sending and receiving of data over the 553 network interfaces, the choice of network-layer addresses at each end 554 of the communication, and the interaction with any intermediate 555 entities that handle the data, but do not modify it (such as TURN 556 relays). 558 It includes necessary functions for congestion control, 559 retransmission, and in-order delivery. 561 WebRTC endpoints MUST implement the transport protocols described in 562 [I-D.ietf-rtcweb-transports]. 564 5. Data framing and securing 566 The format for media transport is RTP [RFC3550]. Implementation of 567 SRTP [RFC3711] is REQUIRED for all implementations. 569 The detailed considerations for usage of functions from RTP and SRTP 570 are given in [I-D.ietf-rtcweb-rtp-usage]. The security 571 considerations for the WebRTC use case are in 572 [I-D.ietf-rtcweb-security], and the resulting security functions are 573 described in [I-D.ietf-rtcweb-security-arch]. 575 Considerations for the transfer of data that is not in RTP format is 576 described in [I-D.ietf-rtcweb-data-channel], and a supporting 577 protocol for establishing individual data channels is described in 578 [I-D.ietf-rtcweb-data-protocol]. WebRTC endpoints MUST implement 579 these two specifications. 581 WebRTC endpoints MUST implement [I-D.ietf-rtcweb-rtp-usage], 582 [I-D.ietf-rtcweb-security], [I-D.ietf-rtcweb-security-arch], and the 583 requirements they include. 585 6. Data formats 587 The intent of this specification is to allow each communications 588 event to use the data formats that are best suited for that 589 particular instance, where a format is supported by both sides of the 590 connection. However, a minimum standard is greatly helpful in order 591 to ensure that communication can be achieved. This document 592 specifies a minimum baseline that will be supported by all 593 implementations of this specification, and leaves further codecs to 594 be included at the will of the implementor. 596 WebRTC endpoints that support audio and/or video MUST implement the 597 codecs and profiles required in [RFC7874] and [RFC7742]. 599 7. Connection management 601 The methods, mechanisms and requirements for setting up, negotiating 602 and tearing down connections is a large subject, and one where it is 603 desirable to have both interoperability and freedom to innovate. 605 The following principles apply: 607 1. The WebRTC media negotiations will be capable of representing the 608 same SDP offer/answer semantics [RFC3264] that are used in SIP, 609 in such a way that it is possible to build a signaling gateway 610 between SIP and the WebRTC media negotiation. 612 2. It will be possible to gateway between legacy SIP devices that 613 support ICE and appropriate RTP / SDP mechanisms, codecs and 614 security mechanisms without using a media gateway. A signaling 615 gateway to convert between the signaling on the web side to the 616 SIP signaling may be needed. 618 3. When an SDP for a new codec is specified, no other 619 standardization should be required for it to be possible to use 620 that in the web browsers. Adding new codecs which might have new 621 SDP parameters should not change the APIs between the browser and 622 Javascript application. As soon as the browsers support the new 623 codecs, old applications written before the codecs were specified 624 should automatically be able to use the new codecs where 625 appropriate with no changes to the JS applications. 627 The particular choices made for WebRTC, and their implications for 628 the API offered by a browser implementing WebRTC, are described in 629 [I-D.ietf-rtcweb-jsep]. 631 WebRTC browsers MUST implement [I-D.ietf-rtcweb-jsep]. 633 WebRTC endpoints MUST implement the functions described in that 634 document that relate to the network layer (e.g. Bundle 635 [I-D.ietf-mmusic-sdp-bundle-negotiation], RTCP-mux [RFC5761] and 636 Trickle ICE [I-D.ietf-ice-trickle]), but do not need to support the 637 API functionality described there. 639 8. Presentation and control 641 The most important part of control is the user's control over the 642 browser's interaction with input/output devices and communications 643 channels. It is important that the user have some way of figuring 644 out where his audio, video or texting is being sent, for what 645 purported reason, and what guarantees are made by the parties that 646 form part of this control channel. This is largely a local function 647 between the browser, the underlying operating system and the user 648 interface; this is specified in the peer connection API 649 [W3C.WD-webrtc-20120209], and the media capture API 650 [W3C.WD-mediacapture-streams-20120628]. 652 WebRTC browsers MUST implement these two specifications. 654 9. Local system support functions 656 These are characterized by the fact that the quality of these 657 functions strongly influence the user experience, but the exact 658 algorithm does not need coordination. In some cases (for instance 659 echo cancellation, as described below), the overall system definition 660 may need to specify that the overall system needs to have some 661 characteristics for which these facilities are useful, without 662 requiring them to be implemented a certain way. 664 Local functions include echo cancellation, volume control, camera 665 management including focus, zoom, pan/tilt controls (if available), 666 and more. 668 One would want to see certain parts of the system conform to certain 669 properties, for instance: 671 o Echo cancellation should be good enough to achieve the suppression 672 of acoustical feedback loops below a perceptually noticeable 673 level. 675 o Privacy concerns MUST be satisfied; for instance, if remote 676 control of camera is offered, the APIs should be available to let 677 the local participant figure out who's controlling the camera, and 678 possibly decide to revoke the permission for camera usage. 680 o Automatic gain control, if present, should normalize a speaking 681 voice into a reasonable dB range. 683 The requirements on WebRTC systems with regard to audio processing 684 are found in [RFC7874] and includes more guidance about echo 685 cancellation and AGC; the proposed API for control of local devices 686 are found in [W3C.WD-mediacapture-streams-20120628]. 688 WebRTC endpoints MUST implement the processing functions in 689 [RFC7874]. (Together with the requirement in Section 6, this means 690 that WebRTC endpoints MUST implement the whole document.) 692 10. IANA Considerations 694 This document makes no request of IANA. 696 Note to RFC Editor: this section may be removed on publication as an 697 RFC. 699 11. Security Considerations 701 Security of the web-enabled real time communications comes in several 702 pieces: 704 o Security of the components: The browsers, and other servers 705 involved. The most target-rich environment here is probably the 706 browser; the aim here should be that the introduction of these 707 components introduces no additional vulnerability. 709 o Security of the communication channels: It should be easy for a 710 participant to reassure himself of the security of his 711 communication - by verifying the crypto parameters of the links he 712 himself participates in, and to get reassurances from the other 713 parties to the communication that they promise that appropriate 714 measures are taken. 716 o Security of the partners' identity: verifying that the 717 participants are who they say they are (when positive 718 identification is appropriate), or that their identity cannot be 719 uncovered (when anonymity is a goal of the application). 721 The security analysis, and the requirements derived from that 722 analysis, is contained in [I-D.ietf-rtcweb-security]. 724 It is also important to read the security sections of 725 [W3C.WD-mediacapture-streams-20120628] and [W3C.WD-webrtc-20120209]. 727 12. Acknowledgements 729 The number of people who have taken part in the discussions 730 surrounding this draft are too numerous to list, or even to identify. 731 The ones below have made special, identifiable contributions; this 732 does not mean that others' contributions are less important. 734 Thanks to Cary Bran, Cullen Jennings, Colin Perkins, Magnus 735 Westerlund and Joerg Ott, who offered technical contributions on 736 various versions of the draft. 738 Thanks to Jonathan Rosenberg, Matthew Kaufman and others at Skype for 739 the ASCII drawings in section 1. 741 Thanks to Alissa Cooper, Bjoern Hoehrmann, Colin Perkins, Colton 742 Shields, Eric Rescorla, Heath Matlock, Henry Sinnreich, Justin 743 Uberti, Keith Drage, Magnus Westerlund, Olle E. Johansson, Sean 744 Turner and Simon Leinen for document review. 746 13. References 748 13.1. Normative References 750 [I-D.ietf-rtcweb-data-channel] 751 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 752 Channels", draft-ietf-rtcweb-data-channel-13 (work in 753 progress), January 2015. 755 [I-D.ietf-rtcweb-data-protocol] 756 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 757 Establishment Protocol", draft-ietf-rtcweb-data- 758 protocol-09 (work in progress), January 2015. 760 [I-D.ietf-rtcweb-jsep] 761 Uberti, J., Jennings, C., and E. Rescorla, "JavaScript 762 Session Establishment Protocol", draft-ietf-rtcweb-jsep-24 763 (work in progress), October 2017. 765 [I-D.ietf-rtcweb-rtp-usage] 766 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 767 Communication (WebRTC): Media Transport and Use of RTP", 768 draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 769 2016. 771 [I-D.ietf-rtcweb-security] 772 Rescorla, E., "Security Considerations for WebRTC", draft- 773 ietf-rtcweb-security-09 (work in progress), October 2017. 775 [I-D.ietf-rtcweb-security-arch] 776 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 777 rtcweb-security-arch-13 (work in progress), October 2017. 779 [I-D.ietf-rtcweb-transports] 780 Alvestrand, H., "Transports for WebRTC", draft-ietf- 781 rtcweb-transports-17 (work in progress), October 2016. 783 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 784 Requirement Levels", BCP 14, RFC 2119, 785 DOI 10.17487/RFC2119, March 1997, 786 . 788 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 789 with Session Description Protocol (SDP)", RFC 3264, 790 DOI 10.17487/RFC3264, June 2002, 791 . 793 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 794 Jacobson, "RTP: A Transport Protocol for Real-Time 795 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 796 July 2003, . 798 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 799 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 800 RFC 3711, DOI 10.17487/RFC3711, March 2004, 801 . 803 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 804 (ICE): A Protocol for Network Address Translator (NAT) 805 Traversal for Offer/Answer Protocols", RFC 5245, 806 DOI 10.17487/RFC5245, April 2010, 807 . 809 [RFC7742] Roach, A., "WebRTC Video Processing and Codec 810 Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, 811 . 813 [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing 814 Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, 815 . 817 [W3C.WD-mediacapture-streams-20120628] 818 Burnett, D. and A. Narayanan, "Media Capture and Streams", 819 World Wide Web Consortium WD WD-mediacapture-streams- 820 20120628, June 2012, . 823 [W3C.WD-webrtc-20120209] 824 Bergkvist, A., Burnett, D., Jennings, C., and A. 825 Narayanan, "WebRTC 1.0: Real-time Communication Between 826 Browsers", World Wide Web Consortium WD WD-webrtc- 827 20120209, February 2012, 828 . 830 13.2. Informative References 832 [I-D.ietf-ice-trickle] 833 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 834 "Trickle ICE: Incremental Provisioning of Candidates for 835 the Interactive Connectivity Establishment (ICE) 836 Protocol", draft-ietf-ice-trickle-14 (work in progress), 837 September 2017. 839 [I-D.ietf-mmusic-sdp-bundle-negotiation] 840 Holmberg, C., Alvestrand, H., and C. Jennings, 841 "Negotiating Media Multiplexing Using the Session 842 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 843 negotiation-39 (work in progress), August 2017. 845 [I-D.ietf-rtcweb-gateways] 846 Alvestrand, H. and U. Rauschenbach, "WebRTC Gateways", 847 draft-ietf-rtcweb-gateways-02 (work in progress), January 848 2016. 850 [I-D.ietf-tsvwg-rtcweb-qos] 851 Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP 852 Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- 853 qos-18 (work in progress), August 2016. 855 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 856 A., Peterson, J., Sparks, R., Handley, M., and E. 857 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 858 DOI 10.17487/RFC3261, June 2002, 859 . 861 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 862 (DHCP-for-IPv4) Option for Session Initiation Protocol 863 (SIP) Servers", RFC 3361, DOI 10.17487/RFC3361, August 864 2002, . 866 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 867 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 868 . 870 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 871 Control Packets on a Single Port", RFC 5761, 872 DOI 10.17487/RFC5761, April 2010, 873 . 875 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 876 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 877 March 2011, . 879 [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 880 Time Communication Use Cases and Requirements", RFC 7478, 881 DOI 10.17487/RFC7478, March 2015, 882 . 884 [RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays 885 around NAT (TURN) Server Auto Discovery", RFC 8155, 886 DOI 10.17487/RFC8155, April 2017, 887 . 889 [W3C.WD-html5-20110525] 890 Hickson, I., "HTML5", World Wide Web Consortium LastCall 891 WD-html5-20110525, May 2011, 892 . 894 [XEP-0124] 895 Paterson, I., Smith, D., Saint-Andre, P., Moffitt, J., 896 Stout, L., and W. Tilanus, "BOSH", XSF XEP 0124, November 897 2016. 899 [XEP-0166] 900 Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, 901 S., and J. Hildebrand, "Jingle", XSF XEP 0166, June 2007. 903 Appendix A. Change log 905 This section may be deleted by the RFC Editor when preparing for 906 publication. 908 A.1. Changes from draft-alvestrand-dispatch-rtcweb-datagram-00 to -01 910 Added section "On interoperability and innovation" 912 Added data confidentiality and integrity to the "data framing" layer 914 Added congestion management requirements in the "data transport" 915 layer section 917 Changed need for non-media data from "question: do we need this?" to 918 "Open issue: How do we do this?" 920 Strengthened disclaimer that listed codecs are placeholders, not 921 decisions. 923 More details on why the "local system support functions" section is 924 there. 926 A.2. Changes from draft-alvestrand-dispatch-01 to draft-alvestrand- 927 rtcweb-overview-00 929 Added section on "Relationship between API and protocol" 931 Added terminology section 933 Mentioned congestion management as part of the "data transport" layer 934 in the layer list 936 A.3. Changes from draft-alvestrand-rtcweb-00 to -01 938 Removed most technical content, and replaced with pointers to drafts 939 as requested and identified by the RTCWEB WG chairs. 941 Added content to acknowledgments section. 943 Added change log. 945 Spell-checked document. 947 A.4. Changes from draft-alvestrand-rtcweb-overview-01 to draft-ietf- 948 rtcweb-overview-00 950 Changed draft name and document date. 952 Removed unused references 954 A.5. Changes from -00 to -01 of draft-ietf-rtcweb-overview 956 Added architecture figures to section 2. 958 Changed the description of "echo cancellation" under "local system 959 support functions". 961 Added a few more definitions. 963 A.6. Changes from -01 to -02 of draft-ietf-rtcweb-overview 965 Added pointers to use cases, security and rtp-usage drafts (now WG 966 drafts). 968 Changed description of SRTP from mandatory-to-use to mandatory-to- 969 implement. 971 Added the "3 principles of negotiation" to the connection management 972 section. 974 Added an explicit statement that ICE is required for both NAT and 975 consent-to-receive. 977 A.7. Changes from -02 to -03 of draft-ietf-rtcweb-overview 979 Added references to a number of new drafts. 981 Expanded the description text under the "trapezoid" drawing with some 982 more text discussed on the list. 984 Changed the "Connection management" sentence from "will be done using 985 SDP offer/answer" to "will be capable of representing SDP offer/ 986 answer" - this seems more consistent with JSEP. 988 Added "security mechanisms" to the things a non-gatewayed SIP devices 989 must support in order to not need a media gateway. 991 Added a definition for "browser". 993 A.8. Changes from -03 to -04 of draft-ietf-rtcweb-overview 995 Made introduction more normative. 997 Several wording changes in response to review comments from EKR 999 Added an appendix to hold references and notes that are not yet in a 1000 separate document. 1002 A.9. Changes from -04 to -05 of draft-ietf-rtcweb-overview 1004 Minor grammatical fixes. This is mainly a "keepalive" refresh. 1006 A.10. Changes from -05 to -06 1008 Clarifications in response to Last Call review comments. Inserted 1009 reference to draft-ietf-rtcweb-audio. 1011 A.11. Changes from -06 to -07 1013 Added a reference to the "unified plan" draft, and updated some 1014 references. 1016 Otherwise, it's a "keepalive" draft. 1018 A.12. Changes from -07 to -08 1020 Removed the appendix that detailed transports, and replaced it with a 1021 reference to draft-ietf-rtcweb-transports. Removed now-unused 1022 references. 1024 A.13. Changes from -08 to -09 1026 Added text to the Abstract indicating that the intended status is an 1027 Applicability Statement. 1029 A.14. Changes from -09 to -10 1031 Defined "WebRTC Browser" and "WebRTC device" as things that do, or 1032 don't, conform to the API. 1034 Updated reference to data-protocol draft 1036 Updated data formats to reference -rtcweb-audio- and not the expired 1037 -cbran draft. 1039 Deleted references to -unified-plan 1040 Deleted reference to -generic-idp (draft expired) 1042 Added notes on which referenced documents WebRTC browsers or devices 1043 MUST conform to. 1045 Added pointer to the security section of the API drafts. 1047 A.15. Changes from -10 to -11 1049 Added "WebRTC Gateway" as a third class of device, and referenced the 1050 doc describing them. 1052 Made a number of text clarifications in response to document reviews. 1054 A.16. Changes from -11 to -12 1056 Refined entity definitions to define "WebRTC endpoint" and "WebRTC- 1057 compatible endpoint". 1059 Changed remaining usage of the term "RTCWEB" to "WebRTC", including 1060 in the page header. 1062 A.17. Changes from -12 to -13 1064 Changed "WebRTC device" to be "WebRTC non-browser", per decision at 1065 IETF 91. This led to the need for "WebRTC endpoint" as the common 1066 label for both, and the usage of that term in the rest of the 1067 document. 1069 Added words about WebRTC APIs in languages other than Javascript. 1071 Referenced draft-ietf-rtcweb-video for video codecs to support. 1073 A.18. Changes from -13 to -14 1075 None. This is a "keepalive" update. 1077 A.19. Changes from -14 to -15 1079 Changed "gateways" reference to point to the WG document. 1081 A.20. Changes from -15 to -16 1083 None. This is a "keepalive" publication. 1085 A.21. Changes from -16 to -17 1087 Addressed review comments by Olle E. Johansson and Magnus Westerlund 1089 A.22. Changes from -17 to -18 1091 Addressed review comments from Sean Turner and Alissa Cooper 1093 A.23. Changes from -18 to -19 1095 A number of grammatical issues were fixed. 1097 Added note on operational impact of WebRTC. 1099 Unified all definitions into the definitions list. 1101 Added a reference for BOSH. 1103 Changed ICE reference from 5245bis to RFC 5245. 1105 Author's Address 1107 Harald T. Alvestrand 1108 Google 1109 Kungsbron 2 1110 Stockholm 11122 1111 Sweden 1113 Email: harald@alvestrand.no