idnits 2.17.1 draft-ietf-rtcweb-overview-11.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 513: '... WebRTC devices MUST implement the tr...' RFC 2119 keyword, line 519: '... SRTP [RFC3711] is REQUIRED for all implementations....' RFC 2119 keyword, line 530: '... [I-D.ietf-rtcweb-data-protocol]. Webrtc devices MUST implement these...' RFC 2119 keyword, line 533: '... WebRTC devices MUST implement [I-D.ietf-rtcweb-rtp-usage],...' RFC 2119 keyword, line 548: '... WebRTC devices MUST implement the co...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 18, 2014) is 3538 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 (-11) exists of draft-ietf-rtcweb-audio-05 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-11 == Outdated reference: A later version (-09) exists of draft-ietf-rtcweb-data-protocol-07 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-07 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-16 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-07 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-10 == Outdated reference: A later version (-17) exists of draft-ietf-rtcweb-transports-06 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-02) exists of draft-alvestrand-rtcweb-gateways-00 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-14 Summary: 2 errors (**), 0 flaws (~~), 11 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 August 18, 2014 5 Expires: February 19, 2015 7 Overview: Real Time Protocols for Browser-based Applications 8 draft-ietf-rtcweb-overview-11 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 RTCWEB 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 http://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 February 19, 2015. 44 Copyright Notice 46 Copyright (c) 2014 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 (http://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 . . . . . . . . . . 4 65 2.3. On interoperability and innovation . . . . . . . . . . . 5 66 2.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Architecture and Functionality groups . . . . . . . . . . . . 7 68 4. Data transport . . . . . . . . . . . . . . . . . . . . . . . 12 69 5. Data framing and securing . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . 18 81 A.1. Changes from draft-alvestrand-dispatch-rtcweb-datagram-00 82 to -01 . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 A.2. Changes from draft-alvestrand-dispatch-01 to draft- 84 alvestrand-rtcweb-overview-00 . . . . . . . . . . . . . . 19 85 A.3. Changes from draft-alvestrand-rtcweb-00 to -01 . . . . . 19 86 A.4. Changes from draft-alvestrand-rtcweb-overview-01 to 87 draft-ietf-rtcweb-overview-00 . . . . . . . . . . . . . . 19 88 A.5. Changes from -00 to -01 of draft-ietf-rtcweb-overview . . 19 89 A.6. Changes from -01 to -02 of draft-ietf-rtcweb-overview . . 20 90 A.7. Changes from -02 to -03 of draft-ietf-rtcweb-overview . . 20 91 A.8. Changes from -03 to -04 of draft-ietf-rtcweb-overview . . 20 92 A.9. Changes from -04 to -05 of draft-ietf-rtcweb-overview . . 20 93 A.10. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 20 94 A.11. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 21 95 A.12. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 21 96 A.13. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 21 97 A.14. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 21 98 A.15. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 21 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 101 1. Introduction 103 The Internet was, from very early in its lifetime, considered a 104 possible vehicle for the deployment of real-time, interactive 105 applications - with the most easily imaginable being audio 106 conversations (aka "Internet telephony") and video conferencing. 108 The first attempts to build this were dependent on special networks, 109 special hardware and custom-built software, often at very high prices 110 or at low quality, placing great demands on the infrastructure. 112 As the available bandwidth has increased, and as processors an other 113 hardware has become ever faster, the barriers to participation have 114 decreased, and it has become possible to deliver a satisfactory 115 experience on commonly available computing hardware. 117 Still, there are a number of barriers to the ability to communicate 118 universally - one of these is that there is, as of yet, no single set 119 of communication protocols that all agree should be made available 120 for communication; another is the sheer lack of universal 121 identification systems (such as is served by telephone numbers or 122 email addresses in other communications systems). 124 Development of The Universal Solution has proved hard, however, for 125 all the usual reasons. 127 The last few years have also seen a new platform rise for deployment 128 of services: The browser-embedded application, or "Web application". 129 It turns out that as long as the browser platform has the necessary 130 interfaces, it is possible to deliver almost any kind of service on 131 it. 133 Traditionally, these interfaces have been delivered by plugins, which 134 had to be downloaded and installed separately from the browser; in 135 the development of HTML5, application developers see much promise in 136 the possibility of making those interfaces available in a 137 standardized way within the browser. 139 This memo describes a set of building blocks that can be made 140 accessible and controllable through a Javascript API in a browser, 141 and which together form a sufficient set of functions to allow the 142 use of interactive audio and video in applications that communicate 143 directly between browsers across the Internet. The resulting 144 protocol suite is intended to enable all the applications that are 145 described as required scenarios in the RTCWEB use cases document 146 [I-D.ietf-rtcweb-use-cases-and-requirements]. 148 Other efforts, for instance the W3C WEBRTC, Web Applications and 149 Device API working groups, focus on making standardized APIs and 150 interfaces available, within or alongside the HTML5 effort, for those 151 functions; this memo concentrates on specifying the protocols and 152 subprotocols that are needed to specify the interactions that happen 153 across the network. 155 This memo uses the term "WebRTC" (note the case used) to refer to the 156 overall effort consisting of both IETF and W3C efforts. 158 2. Principles and Terminology 160 2.1. Goals of this document 162 The goal of the RTCWEB protocol specification is to specify a set of 163 protocols that, if all are implemented, will allow an implementation 164 to communicate with another implementation using audio, video and 165 data sent along the most direct possible path between the 166 participants. 168 This document is intended to serve as the roadmap to the RTCWEB 169 specifications. It defines terms used by other pieces of 170 specification, lists references to other specifications that don't 171 need further elaboration in the RTCWEB context, and gives pointers to 172 other documents that form part of the RTCWEB suite. 174 By reading this document and the documents it refers to, it should be 175 possible to have all information needed to implement an RTCWEB 176 compatible implementation. 178 2.2. Relationship between API and protocol 180 The total WebRTC effort consists of two pieces: 182 o A protocol specification, done in the IETF 184 o A Javascript API specification, done in the W3C 185 [W3C.WD-webrtc-20120209][W3C.WD-mediacapture-streams-20120628] 187 Together, these two specifications aim to provide an environment 188 where Javascript embedded in any page, viewed in any compatible 189 browser, when suitably authorized by its user, is able to set up 190 communication using audio, video and auxiliary data, where the 191 browser environment does not constrain the types of application in 192 which this functionality can be used. 194 The protocol specification does not assume that all implementations 195 implement this API; it is not intended to be necessary for 196 interoperation to know whether the entity one is communicating with 197 is a browser or another device implementing this specification. 199 The goal of cooperation between the protocol specification and the 200 API specification is that for all options and features of the 201 protocol specification, it should be clear which API calls to make to 202 exercise that option or feature; similarly, for any sequence of API 203 calls, it should be clear which protocol options and features will be 204 invoked. Both subject to constraints of the implementation, of 205 course. 207 For the purpose of this document, three classes of things that can 208 claim conformance are defined: 210 o A WebRTC browser is something that conforms to both the protocol 211 specification and the Javascript API defined above. 213 o A WebRTC device is something that conforms to the protocol 214 specification, but does not claim to implement the Javascript API. 216 o A WebRTC gateway is something that mediates media traffic to non- 217 WebRTC entities. It is like a device, but has certain 218 restrictiions on where it can operate, which means that some of 219 the requirements can be relaxed. 221 All WebRTC browsers are WebRTC devices, so any requirement on a 222 WebRTC device also applies to a WebRTC browser. 224 WebRTC gateways are described in a separate document, 225 [I-D.alvestrand-rtcweb-gateways]. 227 2.3. On interoperability and innovation 229 The "Mission statement of the IETF" [RFC3935] states that "The 230 benefit of a standard to the Internet is in interoperability - that 231 multiple products implementing a standard are able to work together 232 in order to deliver valuable functions to the Internet's users." 234 Communication on the Internet frequently occurs in two phases: 236 o Two parties communicate, through some mechanism, what 237 functionality they both are able to support 239 o They use that shared communicative functionality to communicate, 240 or, failing to find anything in common, give up on communication. 242 There are often many choices that can be made for communicative 243 functionality; the history of the Internet is rife with the proposal, 244 standardization, implementation, and success or failure of many types 245 of options, in all sorts of protocols. 247 The goal of having a mandatory to implement function set is to 248 prevent negotiation failure, not to preempt or prevent negotiation. 250 The presence of a mandatory to implement function set serves as a 251 strong changer of the marketplace of deployment - in that it gives a 252 guarantee that, as long as you conform to a specification, and the 253 other party is willing to accept communication at the base level of 254 that specification, you can communicate successfully. 256 The alternative - that of having no mandatory to implement - does not 257 mean that you cannot communicate, it merely means that in order to be 258 part of the communications partnership, you have to implement the 259 standard "and then some" - that "and then some" usually being called 260 a profile of some sort; in the version most antithetical to the 261 Internet ethos, that "and then some" consists of having to use a 262 specific vendor's product only. 264 2.4. Terminology 266 The following terms are used in this document, and as far as possible 267 across the documents specifying the RTCWEB suite, in the specific 268 meanings given here. Not all terms are used in this document. Other 269 terms are used in their commonly used meaning. 271 The list is in alphabetical order. 273 Agent: Undefined term. See "SDP Agent" and "ICE Agent". 275 API: Application Programming Interface - a specification of a set of 276 calls and events, usually tied to a programming language or an 277 abstract formal specification such as WebIDL, with its defined 278 semantics. 280 Browser: Used synonymously with "Interactive User Agent" as defined 281 in the HTML specification [W3C.WD-html5-20110525]. 283 ICE Agent: An implementation of the Interactive Connectivty 284 Establishment (ICE) [RFC5245] protocol. An ICE Agent may also be 285 an SDP Agent, but there exist ICE Agents that do not use SDP (for 286 instance those that use Jingle). 288 Interactive: Communication between multiple parties, where the 289 expectation is that an action from one party can cause a reaction 290 by another party, and the reaction can be observed by the first 291 party, with the total time required for the action/reaction/ 292 observation is on the order of no more than hundreds of 293 milliseconds. 295 Media: Audio and video content. Not to be confused with 296 "transmission media" such as wires. 298 Media path: The path that media data follows from one WebRTC device 299 to another. 301 Protocol: A specification of a set of data units, their 302 representation, and rules for their transmission, with their 303 defined semantics. A protocol is usually thought of as going 304 between systems. 306 Real-time media: Media where generation of content and display of 307 content are intended to occur closely together in time (on the 308 order of no more than hundreds of milliseconds). Real-time media 309 can be used to support interactive communication. 311 SDP Agent: The protocol implementation involved in the SDP offer/ 312 answer exchange, as defined in [RFC3264] section 3. 314 Signaling: Communication that happens in order to establish, manage 315 and control media paths. 317 Signaling Path: The communication channels used between entities 318 participating in signaling to transfer signaling. There may be 319 more entities in the signaling path than in the media path. 321 WebRTC Browser: Browser that conforms to the WebRTC protocol 322 specifications and offer the WebRTC Javascript APIs. 324 WebRTC Device: An unit (software, hardware or combinations) that 325 conforms to the WebRTC protocol specifications, but does not offer 326 the WebRTC Javascript APIs. 328 NOTE: Where common definitions exist for these terms, those 329 definitions should be used to the greatest extent possible. 331 3. Architecture and Functionality groups 333 The model of real-time support for browser-based applications does 334 not assume that the browser will contain all the functions that need 335 to be performed in order to have a function such as a telephone or a 336 video conferencing unit; the vision is that the browser will have the 337 functions that are needed for a Web application, working in 338 conjunction with its backend servers, to implement these functions. 340 This means that two vital interfaces need specification: The 341 protocols that browsers talk to each other, without any intervening 342 servers, and the APIs that are offered for a Javascript application 343 to take advantage of the browser's functionality. 345 +------------------------+ On-the-wire 346 | | Protocols 347 | Servers |---------> 348 | | 349 | | 350 +------------------------+ 351 ^ 352 | 353 | 354 | HTTP/ 355 | Websockets 356 | 357 | 358 +----------------------------+ 359 | Javascript/HTML/CSS | 360 +----------------------------+ 361 Other ^ ^RTC 362 APIs | |APIs 363 +---|-----------------|------+ 364 | | | | 365 | +---------+| 366 | | Browser || On-the-wire 367 | Browser | RTC || Protocols 368 | | Function|-----------> 369 | | || 370 | | || 371 | +---------+| 372 +---------------------|------+ 373 | 374 V 375 Native OS Services 377 Figure 1: Browser Model 379 Note that HTTP and Websockets are also offered to the Javascript 380 application through browser APIs. 382 As for all protocol and API specifications, there is no restriction 383 that the protocols can only be used to talk to another browser; since 384 they are fully specified, any device that implements the protocols 385 faithfully should be able to interoperate with the application 386 running in the browser. 388 A commonly imagined model of deployment is the one depicted below. 390 +-----------+ +-----------+ 391 | Web | | Web | 392 | | Signaling | | 393 | |-------------| | 394 | Server | path | Server | 395 | | | | 396 +-----------+ +-----------+ 397 / \ 398 / \ Application-defined 399 / \ over 400 / \ HTTP/Websockets 401 / Application-defined over \ 402 / HTTP/Websockets \ 403 / \ 404 +-----------+ +-----------+ 405 |JS/HTML/CSS| |JS/HTML/CSS| 406 +-----------+ +-----------+ 407 +-----------+ +-----------+ 408 | | | | 409 | | | | 410 | Browser | ------------------------- | Browser | 411 | | Media path | | 412 | | | | 413 +-----------+ +-----------+ 415 Figure 2: Browser RTC Trapezoid 417 On this drawing, the critical part to note is that the media path 418 ("low path") goes directly between the browsers, so it has to be 419 conformant to the specifications of the RTCWEB protocol suite; the 420 signaling path ("high path") goes via servers that can modify, 421 translate or massage the signals as needed. 423 If the two Web servers are operated by different entities, the inter- 424 server signaling mechanism needs to be agreed upon, either by 425 standardization or by other means of agreement. Existing protocols 426 (for example SIP [RFC3261] or XMPP [RFC6120]) could be used between 427 servers, while either a standards-based or proprietary protocol could 428 be used between the browser and the web server. 430 For example, if both operators' servers implement SIP, SIP could be 431 used for communication between servers, along with either a 432 standardized signaling mechanism (e.g. SIP over Websockets) or a 433 proprietary signaling mechanism used between the application running 434 in the browser and the web server. Similarly, if both operators' 435 servers implement XMPP, XMPP could be used for communication between 436 XMPP servers, with either a standardized signaling mechanism (e.g. 437 XMPP over Websockets or BOSH) or a proprietary signaling mechanism 438 used between the application running in the browser and the web 439 server. 441 The choice of protocols, and definition of the translation between 442 them, is outside the scope of the RTCWEB standards suite described in 443 the document. 445 The functionality groups that are needed in the browser can be 446 specified, more or less from the bottom up, as: 448 o Data transport: TCP, UDP and the means to securely set up 449 connections between entities, as well as the functions for 450 deciding when to send data: Congestion management, bandwidth 451 estimation and so on. 453 o Data framing: RTP and other data formats that serve as containers, 454 and their functions for data confidentiality and integrity. 456 o Data formats: Codec specifications, format specifications and 457 functionality specifications for the data passed between systems. 458 Audio and video codecs, as well as formats for data and document 459 sharing, belong in this category. In order to make use of data 460 formats, a way to describe them, a session description, is needed. 462 o Connection management: Setting up connections, agreeing on data 463 formats, changing data formats during the duration of a call; SIP 464 and Jingle/XMPP belong in this category. 466 o Presentation and control: What needs to happen in order to ensure 467 that interactions behave in a non-surprising manner. This can 468 include floor control, screen layout, voice activated image 469 switching and other such functions - where part of the system 470 require the cooperation between parties. XCON and Cisco/ 471 Tandberg's TIP were some attempts at specifying this kind of 472 functionality; many applications have been built without 473 standardized interfaces to these functions. 475 o Local system support functions: These are things that need not be 476 specified uniformly, because each participant may choose to do 477 these in a way of the participant's choosing, without affecting 478 the bits on the wire in a way that others have to be cognizant of. 479 Examples in this category include echo cancellation (some forms of 480 it), local authentication and authorization mechanisms, OS access 481 control and the ability to do local recording of conversations. 483 Within each functionality group, it is important to preserve both 484 freedom to innovate and the ability for global communication. 485 Freedom to innovate is helped by doing the specification in terms of 486 interfaces, not implementation; any implementation able to 487 communicate according to the interfaces is a valid implementation. 488 Ability to communicate globally is helped both by having core 489 specifications be unencumbered by IPR issues and by having the 490 formats and protocols be fully enough specified to allow for 491 independent implementation. 493 One can think of the three first groups as forming a "media transport 494 infrastructure", and of the three last groups as forming a "media 495 service". In many contexts, it makes sense to use a common 496 specification for the media transport infrastructure, which can be 497 embedded in browsers and accessed using standard interfaces, and "let 498 a thousand flowers bloom" in the "media service" layer; to achieve 499 interoperable services, however, at least the first five of the six 500 groups need to be specified. 502 4. Data transport 504 Data transport refers to the sending and receiving of data over the 505 network interfaces, the choice of network-layer addresses at each end 506 of the communication, and the interaction with any intermediate 507 entities that handle the data, but do not modify it (such as TURN 508 relays). 510 It includes necessary functions for congestion control: When not to 511 send data. 513 WebRTC devices MUST implement the transport protocols described in 514 [I-D.ietf-rtcweb-transports]. 516 5. Data framing and securing 518 The format for media transport is RTP [RFC3550]. Implementation of 519 SRTP [RFC3711] is REQUIRED for all implementations. 521 The detailed considerations for usage of functions from RTP and SRTP 522 are given in [I-D.ietf-rtcweb-rtp-usage]. The security 523 considerations for the RTCWEB use case are in 524 [I-D.ietf-rtcweb-security], and the resulting security functions are 525 described in [I-D.ietf-rtcweb-security-arch]. 527 Considerations for the transfer of data that is not in RTP format is 528 described in [I-D.ietf-rtcweb-data-channel], and a supporting 529 protocol for establishing individual data channels is described in 530 [I-D.ietf-rtcweb-data-protocol]. Webrtc devices MUST implement these 531 two specifications. 533 WebRTC devices MUST implement [I-D.ietf-rtcweb-rtp-usage], 534 [I-D.ietf-rtcweb-security], [I-D.ietf-rtcweb-security-arch], and the 535 requirements they include. 537 6. Data formats 539 The intent of this specification is to allow each communications 540 event to use the data formats that are best suited for that 541 particular instance, where a format is supported by both sides of the 542 connection. However, a minimum standard is greatly helpful in order 543 to ensure that communication can be achieved. This document 544 specifies a minimum baseline that will be supported by all 545 implementations of this specification, and leaves further codecs to 546 be included at the will of the implementor. 548 WebRTC devices MUST implement the codecs and profiles required in 549 [I-D.ietf-rtcweb-audio] 551 NOTE IN DRAFT: At this time (June 2014) there is no consensus on what 552 to say about video codecs in this section. 554 7. Connection management 556 The methods, mechanisms and requirements for setting up, negotiating 557 and tearing down connections is a large subject, and one where it is 558 desirable to have both interoperability and freedom to innovate. 560 The following principles apply: 562 1. The RTCWEB media negotiations will be capable of representing the 563 same SDP offer/answer semantics that are used in SIP [RFC3264], 564 in such a way that it is possible to build a signaling gateway 565 between SIP and the RTCWEB media negotiation. 567 2. It will be possible to gateway between legacy SIP devices that 568 support ICE and appropriate RTP / SDP mechanisms, codecs and 569 security mechanisms without using a media gateway. A signaling 570 gateway to convert between the signaling on the web side to the 571 SIP signaling may be needed. 573 3. When a new codec is specified, and the SDP for the new codec is 574 specified in the MMUSIC WG, no other standardization should be 575 required for it to be possible to use that in the web browsers. 576 Adding new codecs which might have new SDP parameters should not 577 change the APIs between the browser and Javascript application. 578 As soon as the browsers support the new codecs, old applications 579 written before the codecs were specified should automatically be 580 able to use the new codecs where appropriate with no changes to 581 the JS applications. 583 The particular choices made for RTCWEB, and their implications for 584 the API offered by a browser implementing RTCWEB, are described in 585 [I-D.ietf-rtcweb-jsep]. 587 WebRTC browsers MUST implement [I-D.ietf-rtcweb-jsep]. 589 WebRTC devices MUST implement the functions described in that 590 document that relate to the network layer (for example Bundle, RTCP- 591 mux and Trickle ICE), but do not need to support the API 592 functionality described there. 594 8. Presentation and control 596 The most important part of control is the user's control over the 597 browser's interaction with input/output devices and communications 598 channels. It is important that the user have some way of figuring 599 out where his audio, video or texting is being sent, for what 600 purported reason, and what guarantees are made by the parties that 601 form part of this control channel. This is largely a local function 602 between the browser, the underlying operating system and the user 603 interface; this is specified in the peer connection API 604 [W3C.WD-webrtc-20120209], and the media capture API 605 [W3C.WD-mediacapture-streams-20120628]. 607 WebRTC browsers MUST implement these two specifications. 609 9. Local system support functions 611 These are characterized by the fact that the quality of these 612 functions strongly influence the user experience, but the exact 613 algorithm does not need coordination. In some cases (for instance 614 echo cancellation, as described below), the overall system definition 615 may need to specify that the overall system needs to have some 616 characteristics for which these facilities are useful, without 617 requiring them to be implemented a certain way. 619 Local functions include echo cancellation, volume control, camera 620 management including focus, zoom, pan/tilt controls (if available), 621 and more. 623 Certain parts of the system SHOULD conform to certain properties, for 624 instance: 626 o Echo cancellation should be good enough to achieve the suppression 627 of acoustical feedback loops below a perceptually noticeable 628 level. 630 o Privacy concerns MUST be satisfied; for instance, if remote 631 control of camera is offered, the APIs should be available to let 632 the local participant figure out who's controlling the camera, and 633 possibly decide to revoke the permission for camera usage. 635 o Automatic gain control, if present, should normalize a speaking 636 voice into a reasonable dB range. 638 The requirements on RTCWEB systems with regard to audio processing 639 are found in [I-D.ietf-rtcweb-audio]; the proposed API for control of 640 local devices are found in [W3C.WD-mediacapture-streams-20120628]. 642 WebRTC browsers MUST implement the processing functions in 643 [I-D.ietf-rtcweb-audio]. (Together with the requirement inSection 6, 644 this means that browsers MUST implement the whole document.) 646 10. IANA Considerations 648 This document makes no request of IANA. 650 Note to RFC Editor: this section may be removed on publication as an 651 RFC. 653 11. Security Considerations 655 Security of the web-enabled real time communications comes in several 656 pieces: 658 o Security of the components: The browsers, and other servers 659 involved. The most target-rich environment here is probably the 660 browser; the aim here should be that the introduction of these 661 components introduces no additional vulnerability. 663 o Security of the communication channels: It should be easy for a 664 participant to reassure himself of the security of his 665 communication - by verifying the crypto parameters of the links he 666 himself participates in, and to get reassurances from the other 667 parties to the communication that they promise that appropriate 668 measures are taken. 670 o Security of the partners' identity: verifying that the 671 participants are who they say they are (when positive 672 identification is appropriate), or that their identity cannot be 673 uncovered (when anonymity is a goal of the application). 675 The security analysis, and the requirements derived from that 676 analysis, is contained in [I-D.ietf-rtcweb-security]. 678 It is also important to read the security sections of 679 [W3C.WD-mediacapture-streams-20120628] and [W3C.WD-webrtc-20120209]. 681 12. Acknowledgements 683 The number of people who have taken part in the discussions 684 surrounding this draft are too numerous to list, or even to identify. 685 The ones below have made special, identifiable contributions; this 686 does not mean that others' contributions are less important. 688 Thanks to Cary Bran, Cullen Jennings, Colin Perkins, Magnus 689 Westerlund and Joerg Ott, who offered technical contributions on 690 various versions of the draft. 692 Thanks to Jonathan Rosenberg, Matthew Kaufman and others at Skype for 693 the ASCII drawings in section 1. 695 Thanks to Bjoern Hoehrmann, Colin Perkins, Colton Shields, Eric 696 Rescorla, Heath Matlock, Henry Sinnreich, Justin Uberti, Keith Drage 697 and Simon Leinen for document review. 699 13. References 701 13.1. Normative References 703 [I-D.ietf-rtcweb-audio] 704 Valin, J. and C. Bran, "WebRTC Audio Codec and Processing 705 Requirements", draft-ietf-rtcweb-audio-05 (work in 706 progress), February 2014. 708 [I-D.ietf-rtcweb-data-channel] 709 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 710 Channels", draft-ietf-rtcweb-data-channel-11 (work in 711 progress), July 2014. 713 [I-D.ietf-rtcweb-data-protocol] 714 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 715 Establishment Protocol", draft-ietf-rtcweb-data- 716 protocol-07 (work in progress), July 2014. 718 [I-D.ietf-rtcweb-jsep] 719 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 720 Session Establishment Protocol", draft-ietf-rtcweb-jsep-07 721 (work in progress), July 2014. 723 [I-D.ietf-rtcweb-rtp-usage] 724 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 725 Communication (WebRTC): Media Transport and Use of RTP", 726 draft-ietf-rtcweb-rtp-usage-16 (work in progress), July 727 2014. 729 [I-D.ietf-rtcweb-security] 730 Rescorla, E., "Security Considerations for WebRTC", draft- 731 ietf-rtcweb-security-07 (work in progress), July 2014. 733 [I-D.ietf-rtcweb-security-arch] 734 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 735 rtcweb-security-arch-10 (work in progress), July 2014. 737 [I-D.ietf-rtcweb-transports] 738 Alvestrand, H., "Transports for WebRTC", draft-ietf- 739 rtcweb-transports-06 (work in progress), August 2014. 741 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 742 with Session Description Protocol (SDP)", RFC 3264, June 743 2002. 745 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 746 Jacobson, "RTP: A Transport Protocol for Real-Time 747 Applications", STD 64, RFC 3550, July 2003. 749 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 750 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 751 RFC 3711, March 2004. 753 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 754 (ICE): A Protocol for Network Address Translator (NAT) 755 Traversal for Offer/Answer Protocols", RFC 5245, April 756 2010. 758 [W3C.WD-mediacapture-streams-20120628] 759 Burnett, D. and A. Narayanan, "Media Capture and Streams", 760 World Wide Web Consortium WD WD-mediacapture-streams- 761 20120628, June 2012, . 764 [W3C.WD-webrtc-20120209] 765 Bergkvist, A., Burnett, D., Jennings, C., and A. 766 Narayanan, "WebRTC 1.0: Real-time Communication Between 767 Browsers", World Wide Web Consortium WD WD-webrtc- 768 20120209, February 2012, 769 . 771 13.2. Informative References 773 [I-D.alvestrand-rtcweb-gateways] 774 Alvestrand, H., "WebRTC Gateways", draft-alvestrand- 775 rtcweb-gateways-00 (work in progress), August 2014. 777 [I-D.ietf-rtcweb-use-cases-and-requirements] 778 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 779 Time Communication Use-cases and Requirements", draft- 780 ietf-rtcweb-use-cases-and-requirements-14 (work in 781 progress), February 2014. 783 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 784 A., Peterson, J., Sparks, R., Handley, M., and E. 785 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 786 June 2002. 788 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 789 95, RFC 3935, October 2004. 791 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 792 Protocol (XMPP): Core", RFC 6120, March 2011. 794 [W3C.WD-html5-20110525] 795 Hickson, I., "HTML5", World Wide Web Consortium LastCall 796 WD-html5-20110525, May 2011, 797 . 799 Appendix A. Change log 801 This section may be deleted by the RFC Editor when preparing for 802 publication. 804 A.1. Changes from draft-alvestrand-dispatch-rtcweb-datagram-00 to -01 806 Added section "On interoperability and innovation" 808 Added data confidentiality and integrity to the "data framing" layer 810 Added congestion management requirements in the "data transport" 811 layer section 812 Changed need for non-media data from "question: do we need this?" to 813 "Open issue: How do we do this?" 815 Strengthened disclaimer that listed codecs are placeholders, not 816 decisions. 818 More details on why the "local system support functions" section is 819 there. 821 A.2. Changes from draft-alvestrand-dispatch-01 to draft-alvestrand- 822 rtcweb-overview-00 824 Added section on "Relationship between API and protocol" 826 Added terminology section 828 Mentioned congestion management as part of the "data transport" layer 829 in the layer list 831 A.3. Changes from draft-alvestrand-rtcweb-00 to -01 833 Removed most technical content, and replaced with pointers to drafts 834 as requested and identified by the RTCWEB WG chairs. 836 Added content to acknowledgments section. 838 Added change log. 840 Spell-checked document. 842 A.4. Changes from draft-alvestrand-rtcweb-overview-01 to draft-ietf- 843 rtcweb-overview-00 845 Changed draft name and document date. 847 Removed unused references 849 A.5. Changes from -00 to -01 of draft-ietf-rtcweb-overview 851 Added architecture figures to section 2. 853 Changed the description of "echo cancellation" under "local system 854 support functions". 856 Added a few more definitions. 858 A.6. Changes from -01 to -02 of draft-ietf-rtcweb-overview 860 Added pointers to use cases, security and rtp-usage drafts (now WG 861 drafts). 863 Changed description of SRTP from mandatory-to-use to mandatory-to- 864 implement. 866 Added the "3 principles of negotiation" to the connection management 867 section. 869 Added an explicit statement that ICE is required for both NAT and 870 consent-to-receive. 872 A.7. Changes from -02 to -03 of draft-ietf-rtcweb-overview 874 Added references to a number of new drafts. 876 Expanded the description text under the "trapezoid" drawing with some 877 more text discussed on the list. 879 Changed the "Connection management" sentence from "will be done using 880 SDP offer/answer" to "will be capable of representing SDP offer/ 881 answer" - this seems more consistent with JSEP. 883 Added "security mechanisms" to the things a non-gatewayed SIP devices 884 must support in order to not need a media gateway. 886 Added a definition for "browser". 888 A.8. Changes from -03 to -04 of draft-ietf-rtcweb-overview 890 Made introduction more normative. 892 Several wording changes in response to review comments from EKR 894 Added an appendix to hold references and notes that are not yet in a 895 separate document. 897 A.9. Changes from -04 to -05 of draft-ietf-rtcweb-overview 899 Minor grammatical fixes. This is mainly a "keepalive" refresh. 901 A.10. Changes from -05 to -06 903 Clarifications in response to Last Call review comments. Inserted 904 reference to draft-ietf-rtcweb-audio. 906 A.11. Changes from -06 to -07 908 Added a reference to the "unified plan" draft, and updated some 909 references. 911 Otherwise, it's a "keepalive" draft. 913 A.12. Changes from -07 to -08 915 Removed the appendix that detailed transports, and replaced it with a 916 reference to draft-ietf-rtcweb-transports. Removed now-unused 917 references. 919 A.13. Changes from -08 to -09 921 Added text to the Abstract indicating that the intended status is an 922 Applicability Statement. 924 A.14. Changes from -09 to -10 926 Defined "WebRTC Browser" and "WebRTC device" as things that do, or 927 don't, conform to the API. 929 Updated reference to data-protocol draft 931 Updated data formats to reference -rtcweb-audio- and not the expired 932 -cbran draft. 934 Deleted references to -unified-plan 936 Deleted reference to -generic-idp (draft expired) 938 Added notes on which referenced documents WebRTC browsers or devices 939 MUST conform to. 941 Added pointer to the security section of the API drafts. 943 A.15. Changes from -10 to -11 945 Added "WebRTC Gateway" as a third class of device, and referenced the 946 doc describing them. 948 Made a number of text clarifications in response to document reviews. 950 Author's Address 952 Harald T. Alvestrand 953 Google 954 Kungsbron 2 955 Stockholm 11122 956 Sweden 958 Email: harald@alvestrand.no