idnits 2.17.1 draft-ietf-rtcweb-use-cases-and-requirements-13.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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 6, 2014) is 3731 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB Working Group C. Holmberg 3 Internet-Draft S. Hakansson 4 Intended status: Informational G. Eriksson 5 Expires: August 10, 2014 Ericsson 6 February 6, 2014 8 Web Real-Time Communication Use-cases and Requirements 9 draft-ietf-rtcweb-use-cases-and-requirements-13.txt 11 Abstract 13 This document describes web based real-time communication use-cases. 14 Requirements on the browser functionality are derived from the use- 15 cases. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 10, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. Common requirements . . . . . . . . . . . . . . . . . . . 4 56 3.3. Browser-to-browser use-cases . . . . . . . . . . . . . . 4 57 3.3.1. Simple Video Communication Service . . . . . . . . . 4 58 3.3.2. Simple Video Communication Service, NAT/Firewall that 59 blocks UDP . . . . . . . . . . . . . . . . . . . . . 5 60 3.3.3. Simple Video Communication Service, Firewall that 61 only allows traffic via a HTTP Proxy . . . . . . . . 5 62 3.3.4. Simple Video Communication Service, global service 63 provider . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3.5. Simple Video Communication Service, enterprise 65 aspects . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.3.6. Simple Video Communication Service, access change . . 7 67 3.3.7. Simple Video Communication Service, QoS . . . . . . . 7 68 3.3.8. Simple Video Communication Service with screen 69 sharing . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.3.9. Simple Video Communication Service with file exchange 8 71 3.3.10. Hockey Game Viewer . . . . . . . . . . . . . . . . . 8 72 3.3.11. Multiparty video communication . . . . . . . . . . . 9 73 3.3.12. Multiparty on-line game with voice communication . . 10 74 3.4. Browser - GW/Server use cases . . . . . . . . . . . . . . 10 75 3.4.1. Telephony terminal . . . . . . . . . . . . . . . . . 11 76 3.4.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . 11 77 3.4.3. Video conferencing system with central server . . . . 11 78 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 79 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.2. Browser requirements . . . . . . . . . . . . . . . . . . 13 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 16 84 6.2. Browser Considerations . . . . . . . . . . . . . . . . . 16 85 6.3. Web Application Considerations . . . . . . . . . . . . . 17 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 87 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 9. Normative References . . . . . . . . . . . . . . . . . . . . 23 89 Appendix A. API requirements . . . . . . . . . . . . . . . . . . 23 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 92 1. Introduction 94 This document presents a few use-cases of web applications that are 95 executed in a browser and use real-time communication capabilities. 96 In most of the use-cases all end-user clients are web applications, 97 but there are some use-cases where at least one of the end-user 98 clients is of another type (e.g. a mobile phone or a SIP UA). 100 Based on the use-cases, the document derives requirements related to 101 browser functionality. These requirements are named "Fn", where n is 102 an integer, and are described in Section 4.2. 104 This document was developed in an initial phase of the work with 105 rather minor updates at later stages. It has not really served as a 106 tool in deciding features or scope for the WGs efforts so far. It is 107 proposed to be used in a later phase to evaluate the protocols and 108 solutions developed by the WG. 110 This document also lists requirements related to the API to be used 111 by web applications as an appendix. The reason is that the W3C 112 WebRTC WG has decided to not develop its own use-case/requirement 113 document, but instead use this document. These requirements are 114 named "An", where n is an integer, and are described in Appendix A- 116 2. Conventions 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in BCP 14, RFC 2119 121 [RFC2119]. 123 3. Use-cases 125 3.1. Introduction 127 This section describes web based real-time communication use-cases, 128 from which requirements are derived. 130 The following considerations are applicable to all use cases: 132 o Clients can be on IPv4-only 134 o Clients can be on IPv6-only 136 o Clients can be on dual-stack 138 o Clients can be connected to networks with different throughput 139 capabilities 141 o Clients can be on variable-media-quality networks (wireless) 143 o Clients can be on congested networks 144 o Clients can be on firewalled networks with no UDP allowed 146 o Clients can be on networks with a NAT using any type of Mapping 147 and Filtering behaviors (as described in RFC4787). 149 3.2. Common requirements 151 The requirements retrived from the Simple Video Communication Service 152 use-case (Section 3.3.1) by default apply to all other use-cases, and 153 are considred common. For each individual use-case, only the 154 additional requirements are listed. The following requirements can 155 be derived from, and apply to, each of the documented use-cases. For 156 each individual use-case, only requirements that are not part of the 157 common requirements are listed. 159 3.3. Browser-to-browser use-cases 161 3.3.1. Simple Video Communication Service 163 3.3.1.1. Description 165 Two or more users have loaded a video communication web application 166 into their browsers, provided by the same service provider, and 167 logged into the service it provides. The web service publishes 168 information about user login status by pushing updates to the web 169 application in the browsers. When one online user selects a peer 170 online user, a 1-1 audiovisual communication session between the 171 browsers of the two peers is initiated. The invited user might 172 accept or reject the session. 174 During session establishment a self-view is displayed, and once the 175 session has been established the video sent from the remote peer is 176 displayed in addition to the self-view. During the session, each 177 user can select to remove and re-insert the self-view as often as 178 desired. Each user can also change the sizes of his/her two video 179 displays during the session. Each user can also pause sending of 180 media (audio, video, or both) and mute incoming media 182 It is essential that media and data be encrypted, authenticated and 183 integrity protected on a per-packet basis and that media and data 184 packets failing the integrity check not be delivered to the 185 application. 187 The application gives the users the opportunity to stop it from 188 exposing the host IP address to the application of the other user. 190 Any session participant can end the session at any time. 192 The two users may be using communication devices with different 193 operating systems and browsers from different vendors. 195 The web service monitors the quality of the service (focus on quality 196 of audio and video) the end-users experience. 198 3.3.1.2. Common Requirements 200 F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F35, F36, F38, F39 202 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A25, A26 204 3.3.2. Simple Video Communication Service, NAT/Firewall that blocks UDP 206 3.3.2.1. Description 208 This use-case is almost identical to the 209 Simple Video Communication Service use-case (Section 3.3.1). The 210 difference is that one of the users is behind a NAT/Firewall that 211 blocks UDP traffic. 213 3.3.2.2. Additional Requirements 215 F29 217 3.3.3. Simple Video Communication Service, Firewall that only allows 218 traffic via a HTTP Proxy 220 3.3.3.1. Description 222 This use-case is almost identical to the 223 Simple Video Communication Service use-case (Section 3.3.1). The 224 difference is that one of the users is behind a Firewall that only 225 allows traffic via a HTTP Proxy. 227 3.3.3.2. Additional Requirements 229 F37 231 3.3.4. Simple Video Communication Service, global service provider 233 3.3.4.1. Description 235 This use-case is almost identical to the 236 Simple Video Communication Service use-case (Section 3.3.1). 238 What is added is that the service provider is operating over large 239 geographical areas (or even globally). 241 Assuming that ICE will be used, this means that the service provider 242 would like to be able to provide several STUN and TURN servers (via 243 the app) to the browser; selection of which one(s) to use is part of 244 the ICE processing. Other reasons for wanting to provide several 245 STUN and TURN servers include support for IPv4 and IPv6, load 246 balancing and redundancy. 248 Note that ICE support being mandatory does not preclude a WebRTC 249 endpoint from supporting additional traversal mechanisms. 251 3.3.4.2. Additional Requirements 253 F31 255 A22 257 3.3.5. Simple Video Communication Service, enterprise aspects 259 3.3.5.1. Description 261 This use-case is similar to the Simple Video Communication Service 262 use-case (Section 3.3.1). 264 What is added is aspects when using the service in enterprises. ICE 265 is assumed in the further description of this use-case. 267 An enterprise that uses a RTCWEB based web application for 268 communication desires to audit all RTCWEB based application sessions 269 used from inside the company towards any external peer. To be able 270 to do this they deploy a TURN server that straddles the boundary 271 between the internal and the external network. 273 The firewall will block all attempts to use STUN with an external 274 destination unless they go to the enterprise auditing TURN server. 275 In cases where employees are using RTCWEB applications provided by an 276 external service provider they still want the traffic to stay inside 277 their internal network and in addition not load the straddling TURN 278 server, thus they deploy a STUN server allowing the RTCWEB client to 279 determine its server reflexive address on the internal side. Thus 280 enabling cases where peers are both on the internal side to connect 281 without the traffic leaving the internal network. It must be 282 possible to configure the browsers used in the enterprise with 283 network specific STUN and TURN servers. This should be possible to 284 achieve by auto-configuration methods. The RTCWEB functionality will 285 need to utilize both network specific STUN and TURN resources and 286 STUN and TURN servers provisioned by the web application. 288 3.3.5.2. Additional Requirements 290 F32 292 3.3.6. Simple Video Communication Service, access change 294 3.3.6.1. Description 296 This use-case is almost identical to the 297 Simple Video Communication Service use-case (Section 3.3.1). The 298 difference is that the user changes network access during the 299 session. 301 The communication device used by one of the users has several network 302 adapters (Ethernet, WiFi, Cellular). The communication device is 303 accessing the Internet using Ethernet, but the user has to start a 304 trip during the session. The communication device automatically 305 changes to use WiFi when the Ethernet cable is removed and then moves 306 to cellular access to the Internet when moving out of WiFi coverage. 307 The session continues even though the access method changes. 309 3.3.6.2. Additional Requirements 311 F26 313 3.3.7. Simple Video Communication Service, QoS 315 3.3.7.1. Description 317 This use-case is almost identical to the 318 Simple Video Communication Service, access change use-case 319 (Section 3.3.6). The use of Quality of Service (QoS) capabilities is 320 added: 322 The user in the previous use case that starts a trip is behind a 323 common residential router that supports prioritization of traffic. 324 In addition, the user's provider of cellular access has QoS support 325 enabled. The user is able to take advantage of the QoS support both 326 when accessing via the residential router and when using cellular. 328 3.3.7.2. Additional Requirements 330 F24, F26 332 3.3.8. Simple Video Communication Service with screen sharing 334 3.3.8.1. Description 336 This use-case has the audio and video communication of the 337 Simple Video Communication Service use-case (Section 3.3.1). 339 But in addition to this, one of the users can share what is being 340 displayed on her/his screen with a peer. The user can choose to 341 share the entire screen, part of the screen (part selected by the 342 user) or what a selected application displays with the peer. 344 3.3.8.2. Additional Requirements 346 F30 348 A21 350 3.3.9. Simple Video Communication Service with file exchange 352 3.3.9.1. Description 354 This use-case has the audio and video communication of the 355 Simple Video Communication Service use-case (Section 3.3.1). 357 But in addition to this, the users can send and receive files stored 358 in the file system of the device used. 360 3.3.9.2. Additional Requirements 362 F30, F33 364 A21, A24 366 3.3.10. Hockey Game Viewer 368 3.3.10.1. Description 370 An ice-hockey club uses an application that enables talent scouts to, 371 in real-time, show and discuss games and players with the club 372 manager. The talent scouts use a mobile phone with two cameras, one 373 front facing and one rear facing. 375 The club manager uses a desktop, equipped with one camera, for 376 viewing the game and discussing with the talent scout. 378 Before the game starts, and during game breaks, the talent scout and 379 the manager have a 1-1 audiovisual communication session. On the 380 mobile phone, only the camera facing the talent scout is used. On 381 the user display of the mobile phone, the video of the club manager 382 is shown with a picture-in-picture thumbnail of the rear facing 383 camera (self-view). On the display of the desktop, the video of the 384 talent scout is shown with a picture-in-picture thumbnail of the 385 desktop camera (self-view). 387 When the game is on-going, the talent scout activates the use of the 388 front facing camera, and that stream is sent to the desktop (the 389 stream from the rear facing camera continues to be sent all the 390 time). The video stream captured by the front facing camera (that is 391 capturing the game) of the mobile phone is shown in a big window on 392 the desktop screen, with picture-in-picture thumbnails of the rear 393 facing camera and the desktop camera (self-view). On the display of 394 the mobile phone the game is shown (front facing camera) with 395 picture-in-picture thumbnails of the rear facing camera (self-view) 396 and the desktop camera. As the most important stream in this phase 397 is the video showing the game, the application used in the talent 398 scout's mobile sets higher priority for that stream. 400 3.3.10.2. Additional Requirements 402 F17, F24 404 A17, A23 406 3.3.11. Multiparty video communication 408 3.3.11.1. Description 410 In this use-case, the Simple Video Communication Service use-case 411 (Section 3.3.1) is extended by allowing multiparty sessions. No 412 central server is involved - the browser of each participant sends 413 and receives streams to and from all other session participants. The 414 web application in the browser of each user is responsible for 415 setting up streams to all receivers. 417 In order to enhance the user experience, the web application renders 418 the audio coming from different particiapants so that it is 419 experienced to come from different spatial locations. This is done 420 automatically, but users can change how the different participants 421 are placed in the (virtual) room. In addition the levels in the 422 audio signals are adjusted before mixing. 424 Another feature intended to enhance the use experience is that the 425 video window that displays the video of the currently speaking peer 426 is highlighted. 428 Each video stream received is by default displayed in a thumbnail 429 frame within the browser, but users can change the display size. 431 Note: What this use-case adds in terms of requirements is 432 capabilities to send streams to and receive streams from several 433 peers concurrently, as well as the capabilities to render the video 434 from all received streams and be able to spatialize, level adjust and 435 mix the audio from all received streams locally in the browser. It 436 also adds the capability to measure the audio level/activity. 438 3.3.11.2. Additional Requirements 440 F11, F12, F13, F14, F15, F16, F17 442 A13, A14, A15, A16, A17 444 3.3.12. Multiparty on-line game with voice communication 446 3.3.12.1. Description 448 This use case is based on the previous one. In this use-case, the 449 voice part of the multiparty video communication use case is used in 450 the context of an on-line game. The received voice audio media is 451 rendered together with game sound objects. For example, the sound of 452 a tank moving from left to right over the screen must be rendered and 453 played to the user together with the voice media. 455 Quick updates of the game state is required, and have higher priority 456 than the voice. 458 Note: the difference regarding local audio processing compared to the 459 "Multiparty video communication" use-case is that other sound objects 460 than the streams must be possible to be included in the 461 spatialization and mixing. "Other sound objects" could for example 462 be a file with the sound of the tank; that file could be stored 463 locally or remotely. 465 3.3.12.2. Additional Requirements 467 F12, F13, F14, F15, F16, F18, F23, F24 469 A13, A14, A15, A16, A17, A18, A23 471 3.4. Browser - GW/Server use cases 472 3.4.1. Telephony terminal 474 3.4.1.1. Description 476 A mobile telephony operator allows its customers to use a web browser 477 to access their services. After a simple log in the user can place 478 and receive calls in the same way as when using a normal mobile 479 phone. When a call is received or placed, the identity is shown in 480 the same manner as when a mobile phone is used. 482 Note: With "place and receive calls in the same way as when using a 483 normal mobile phone" it is meant that you can dial a number, and that 484 your mobile telephony operator has made available your phone contacts 485 on line, so they are available and can be clicked to call, and be 486 used to present the identity of an incoming call. If the callee is 487 not in your phone contacts the number is displayed. Furthermore, 488 your call logs are available, and updated with the calls made/ 489 received from the browser. And for people receiving calls made from 490 the web browser the usual identity (i.e. the phone number of the 491 mobile phone) will be presented. 493 3.4.1.2. Additional Requirements 495 F21, F27 497 3.4.2. Fedex Call 499 3.4.2.1. Description 501 Alice uses her web browser with a service that allows her to call 502 PSTN numbers. Alice calls 1-800-gofedex. Alice should be able to 503 hear the initial prompts from the fedex Interactive Voice Responder 504 (IVR) and when the IVR says press 1, there should be a way for Alice 505 to navigate the IVR. 507 3.4.2.2. Additional Requirements 509 F21, F22 511 3.4.3. Video conferencing system with central server 513 3.4.3.1. Description 515 An organization uses a video communication system that supports the 516 establishment of multiparty video sessions using a central conference 517 server. 519 The browser of each participant sends an audio stream (type in terms 520 of mono, stereo, 5.1, ... depending on the equipment of the 521 participant) to the central server. The central server mixes the 522 audio streams (and can in the mixing process naturally add effects 523 such as spatialization) and sends towards each participant a mixed 524 audio stream which is played to the user. 526 The browser of each participant sends video towards the server. For 527 each participant one high resolution video is displayed in a large 528 window, while a number of low resolution videos are displayed in 529 smaller windows. The server selects what video streams to be 530 forwarded as main- and thumbnail videos respectively, based on speech 531 activity. As the video streams to display can change quite 532 frequently (as the conversation flows) it is important that the delay 533 from when a video stream is selected for display until the video can 534 be displayed is short. 536 All participants are authenticated by the central server, and 537 authorized to connect to the central server. The participants are 538 identified to each other by the central server, and the participants 539 do not have access to each others' credentials such as e-mail 540 addresses or login IDs. 542 Note: This use-case adds requirements on support for fast stream 543 switches F7, on encryption of media and on ability to traverse very 544 restrictive Firewalls. There exist several solutions that enable the 545 server to forward one high resolution and several low resolution 546 video streams: a) each browser could send a high resolution, but 547 scalable stream, and the server could send just the base layer for 548 the low resolution streams, b) each browser could in a simulcast 549 fashion send one high resolution and one low resolution stream, and 550 the server just selects or c) each browser sends just a high 551 resolution stream, the server transcodes into low resolution streams 552 as required. 554 3.4.3.2. Additional Requirements 556 F17 558 A17 560 4. Requirements 562 4.1. General 564 This section contains the requirements on the browser derived from 565 the use-cases in Section 3. 567 NOTE: It is assumed that the user applications are executed on a 568 browser. Whether the capabilities to implement specific browser 569 requirements are implemented by the browser application, or are 570 provided to the browser application by the underlying operating 571 system, is outside the scope of this document. 573 4.2. Browser requirements 575 REQ-ID DESCRIPTION 576 --------------------------------------------------------------- 577 F1 The browser must be able to use microphones and 578 cameras as input devices to generate streams. 579 ---------------------------------------------------------------- 580 F2 The browser must be able to send streams and 581 data to a peer in the presence of NATs. 582 ---------------------------------------------------------------- 583 F3 Transmitted streams and data must be rate 584 controlled (meaning that the browser must, regardless 585 of application behavior, reduce send rate when 586 there is congestion). 587 ---------------------------------------------------------------- 588 F4 The browser must be able to receive, process and 589 render streams and data ("render" does not 590 apply for data) from peers. 591 ---------------------------------------------------------------- 592 F5 The browser should be able to render good quality 593 audio and video even in the presence of 594 reasonable levels of jitter and packet losses. 595 ---------------------------------------------------------------- 596 F7 The browser must support insertion of reference frames 597 in outgoing media streams when requested by a peer. 598 ---------------------------------------------------------------- 599 F8 The browser must detect when a stream from a 600 peer is not received anymore 601 ---------------------------------------------------------------- 602 F9 When there are both incoming and outgoing audio 603 streams, echo cancellation must be made 604 available to avoid disturbing echo during 605 conversation. 606 ---------------------------------------------------------------- 607 F10 The browser must support synchronization of 608 audio and video. 609 ---------------------------------------------------------------- 610 F11 The browser must be able to transmit streams and 611 data to several peers concurrently. 612 ---------------------------------------------------------------- 613 F12 The browser must be able to receive streams and 614 data from multiple peers concurrently. 615 ---------------------------------------------------------------- 616 F13 The browser must be able to apply spatialization 617 effects when playing audio streams. 618 ---------------------------------------------------------------- 619 F14 The browser must be able to measure the 620 voice activity level in audio streams. 621 ---------------------------------------------------------------- 622 F15 The browser must be able to change the 623 voice activity level in audio streams. 624 ---------------------------------------------------------------- 625 F16 The browser must be able to render several 626 concurrent video streams 627 ---------------------------------------------------------------- 628 F17 The browser must be able to mix several 629 audio streams. 630 ---------------------------------------------------------------- 631 F18 The browser must be able to process and mix 632 sound objects (media that is retrieved from 633 another source than the established media 634 stream(s) with the peer(s) with audio streams. 635 ---------------------------------------------------------------- 636 F20 It must be possible to protect streams and data 637 from wiretapping [RFC2804]. 638 ---------------------------------------------------------------- 639 F21 The browser must support an audio media format 640 (codec) that is commonly supported by existing 641 telephony services. 642 ---------------------------------------------------------------- 643 F22 There should be a way to navigate 644 a Dual-tone multi-frequency signaling (DTMF) 645 based Interactive voice response (IVR) System 646 ---------------------------------------------------------------- 647 F23 The browser must be able to send short 648 latency unreliable datagram traffic to a 649 peer browser [RFC5405]. 650 ---------------------------------------------------------------- 651 F24 The browser should be able to take advantage 652 of available capabilities (supplied by network 653 nodes) to prioritize voice, video and data 654 appropriately. 655 ---------------------------------------------------------------- 656 F25 The browser should use encoding of streams 657 suitable for the current rendering (e.g. 658 video display size) and should change parameters 659 if the rendering changes during the session 660 ---------------------------------------------------------------- 661 F26 The communication session must survive across a 662 change of the network interface used by the 663 session 664 ---------------------------------------------------------------- 665 F27 The browser must be able to initiate and 666 accept a media session where the data needed 667 for establishment can be carried in SIP. 668 ---------------------------------------------------------------- 669 F28 The browser must support a baseline audio and 670 video codec 671 ---------------------------------------------------------------- 672 F29 The browser must be able to send streams and 673 data to a peer in the presence of NATs and 674 Firewalls that block UDP traffic. 675 ---------------------------------------------------------------- 676 F30 The browser must be able to generate streams 677 using the entire user display, a specific area 678 of the user's display or the information being 679 displayed by a specific application. 680 ---------------------------------------------------------------- 681 F31 The browser must be able to use several STUN 682 and TURN servers 683 ---------------------------------------------------------------- 684 F32 The browser must support the use of STUN and TURN 685 servers that are supplied by entities other than 686 the web application (i.e. the network provider). 687 ---------------------------------------------------------------- 688 F33 The browser must be able to send reliable 689 data traffic to a peer browser. 690 ---------------------------------------------------------------- 691 F35 The browser must enable verification, given 692 the right circumstances and by use of other 693 trusted communication, that streams and 694 data received have not been manipulated by 695 any party. 696 ---------------------------------------------------------------- 697 F36 The browser must encrypt, authenticate and 698 integrity protect media and data on a 699 per-packet basis, and must drop incoming media 700 and data packets that fail the per-packet 701 integrity check. In addition, the browser 702 must support a mechanism for cryptographically 703 binding media and data security keys to the 704 user identity (see R-ID-BINDING in [RFC5479]). 705 ---------------------------------------------------------------- 706 F37 The browser must be able to send streams and 707 data to a peer in the presence of Firewalls that only 708 allows traffic via a HTTP Proxy, when Firewall policy 709 allows WebRTC traffic. 711 ---------------------------------------------------------------- 712 F38 The browser must be able to collect statistics, 713 related to the transport of audio and video 714 between peers, needed to estimate quality of 715 experience. 716 ---------------------------------------------------------------- 717 F39 The browser must make it possible to set up a 718 call between two parties without one party 719 learning the other party's host IP address. 720 ---------------------------------------------------------------- 722 5. IANA Considerations 724 There are no IANA actions in this document. 726 6. Security Considerations 728 6.1. Introduction 730 A malicious web application might use the browser to perform Denial 731 Of Service (DOS) attacks on NAT infrastructure, or on peer devices. 732 Also, a malicious web application might silently establish outgoing, 733 and accept incoming, streams on an already established connection. 735 Based on the identified security risks, this section will describe 736 security considerations for the browser and web application. 738 6.2. Browser Considerations 740 The browser is expected to provide mechanisms for getting user 741 consent to use device resources such as camera and microphone. 743 The browser is expected to provide mechanisms for informing the user 744 that device resources such as camera and microphone are in use 745 ("hot"). 747 The browser is expected to provide mechanisms for users to revise and 748 even completely revoke consent to use device resources such as camera 749 and microphone. 751 The browser is expected to provide mechanisms for getting user 752 consent to use the screen (or a certain part of it) or what a certain 753 application displays on the screen as source for streams. 755 The browser is expected to provide mechanisms for informing the user 756 that the screen, part thereof or an application is serving as a 757 stream source ("hot"). 759 The browser is expected to provide mechanisms for users to revise and 760 even completely revoke consent to use the screen, part thereof or an 761 application is serving as a stream source. 763 The browser is expected to provide mechanisms in order to assure that 764 streams are the ones the recipient intended to receive. 766 The browser is expected to provide mechanisms that allows the users 767 to verify that the streams received have not be manipulated (F35). 769 The browser needs to ensure that media is not sent, and that received 770 media is not rendered, until the associated stream establishment and 771 handshake procedures with the remote peer have been successfully 772 finished. 774 The browser needs to ensure that the stream negotiation procedures 775 are not seen as Denial Of Service (DOS) by other entities. 777 6.3. Web Application Considerations 779 The web application is expected to ensure user consent in sending and 780 receiving media streams. 782 7. Acknowledgements 784 The authors wish to thank Bernard Aboba, Gunnar Hellstrom, Martin 785 Thomson, Lars Eggert, Matthew Kaufman, Emil Ivov, Eric Rescorla, Eric 786 Burger, John Leslie, Dan Wing, Richard Barnes, Barry Dingle, Dale 787 Worley, Ted hardie, Mary Barnes, Dan Burnett, Stephan Wenger, Harald 788 Alvestrand, Cullen Jennings, Andrew Hutton and everyone else in the 789 RTCWEB community that have provided comments, feedback, text and 790 improvement proposals on the document. 792 8. Change Log 794 [RFC EDITOR NOTE: Please remove this section when publishing] 796 Changes from draft-ietf-rtcweb-use-cases-and-requirements-10 798 o Described that the API requirements are really from a W3C 799 perspective and are supplied as an appendix in the introduction. 800 Moved API requirements to an Appendix. 802 o Removed the "Conventions" section with the key-words and reference 803 to RFC2119. Also changed uppercase MUST's/SHOULD's to lowercase. 805 o Added a note on the proposed use of the document to the 806 introduction. 808 o Removed the note talking about WS from the "Firewall that only 809 allows http" use-case. 811 o Removed the word "Skype" that was used as example in one of the 812 use-cases. 814 o Clarified F3 (the req saying the everything the browser sends must 815 be rate controlled). 817 o Removed the TBD saying we need to define reasonable levels from 818 the requirement saying that quality must be good even in presence 819 of packet losses (F5), and changed "must" to "should" (Based on a 820 list discussion involving Bernard). 822 o Removed F6 ("The browser must be able to handle high loss and 823 jitter levels in a graceful way."), also after a list discussion. 825 o Clarified F7 (used to say that the browser must support fast 826 stream switches, now says that reference frames must be inserted 827 when requested). 829 o Removed the questions from F9 (echo cancellation), F10 830 (synchronization), F21 (telephony codec). 832 o Exchanged "restrictive firewalls" for "limited middleboxes" in F19 833 (as proposed by Martin). 835 o Expanded DTMF and IVR in F22 (proposed by Martin) 837 o Added ref to RFC5405 in F23 (proposed by Lars Eggert). 839 o Exchanged "service provided" for "web application" in F32. 841 o Changed the text in 3.2.1 that motivates F36 (new text "It is 842 essential that media and data be encrypted, authenticated ... 843 bound to the user identity."); and rewrote F36, included a ref to 844 RFC5479. 846 o Changed "quality of service" to "quality of experience" in F38. 848 o Added F39. 850 o Used new formulation of A17 (proposed by Martin). 852 o Updated A20. 854 o Updated A25. 856 Changes from draft-ietf-rtcweb-use-cases-and-requirements-09 858 o Changed "video communication session" to "audiovisual 859 communication session. 861 Changes from draft-ietf-rtcweb-use-cases-and-requirements-08 863 o Changed "eavesdropping" to "wiretapping" and referenced RFC2804. 865 o Removed informal ref webrtc_req; that document has been abandoned 866 by the W3C webrtc WG. 868 o Added use-case where one user is behind a Firewall that only 869 allows http; derived req. F37. 871 o Changed F24 slightly; MUST-> SHOULD, inserted "available". 873 o Added a clause to "Simple video communication service" saying that 874 the service provider monitors the quality of service, and derived 875 reqs F38 and A26. 877 Changes from draft-ietf-rtcweb-use-cases-and-requirements-07 879 o Added "and data exchange" to 1. Introduction. 881 o Removed cone and symmetric NAT from 4.1 Introduction, refers to 882 RFC4787 instead. 884 o Added text on enabling verification of that the media has not been 885 manipulated by anyone to use-case "Simple Video Communication 886 Service", derived req. F35 888 o Added text on that the browser should reject media (data) that has 889 been created/injected/modified by non-trusted party, derived req. 890 F36 892 o Added text on enabling the app to refrain from revealing IP 893 address to use-case "Simple Video Communication Service", derived 894 req. A25 896 o Added use-case "Simple Video Communication Service with file 897 exchange", derived reqs F33 and A24 899 o Added priority of video streams to "Hockey game viewer" use case, 900 added priority of data to "on-line game use-case", derived reqs 901 F34 and A23 903 o In F22, "the IVR" -> "a DTMF based IVR". 905 o Updated req F23 to clarify that requirements such as NAT 906 traversal, protection from eavesdropping, rate control applies 907 also to datagram. 909 Changes from draft-ietf-rtcweb-use-cases-and-requirements-06 911 o Renaming of requirements (FaI1 -> F31), (FaI2 -> F32) and (AaI1 -> 912 A22) 914 Changes from draft-ietf-rtcweb-use-cases-and-requirements-05 916 o Added use-case "global service provider", derived reqs associated 917 with several STUN/TURN servers 919 o Added use-case "enterprise aspects", derived req associated with 920 enabling the network provider to supply STUN and TURN servers 922 o The requirements from the above are ICE specific and labeled 923 accordingly 925 o Separated the requirements phrased like "processing such as pan, 926 mix and render" for audio to be specific reqs on spatialization, 927 level measurement, level adjustment and mixing (discussed on the 928 lists in http://www.ietf.org/mail-archive/web/rtcweb/current/ 929 msg01648.html and http://lists.w3.org/Archives/Public/public- 930 webrtc/2011Sep/0102.html) 932 o Added use-case on sharing as decided in http://www.ietf.org/mail- 933 archive/web/rtcweb/current/msg01700.html, derived reqs F30 and A21 935 o Added the list of common considerations proposed in mail http:// 936 www.ietf.org/mail-archive/web/rtcweb/current/msg01562.html to the 937 Introduction of the use-case section 939 Changes from draft-ietf-rtcweb-use-cases-and-requirements-04 941 o Most changes based on the input from Dan Burnett http:// 942 www.ietf.org/mail-archive/web/rtcweb/current/msg00948.html 944 o Many editorial changes 946 o 4.2.1.1 Clarified 947 o Some clarification added to 4.3.1.1 as a note 949 o F-requirements updated (see reply to Dan's mail). 951 o Almost all A-requirements updated to start "The Web API MUST 952 provide ..." 954 o A8 removed, A9 rephrased to cover A8 and old A9 956 o A15 rephrased 958 o For more details, and discussion, look at the response to Dan's 959 mail http://www.ietf.org/mail-archive/web/rtcweb/current/ 960 msg01177.html 962 Changes from draft-ietf-rtcweb-use-cases-and-requirements-03 964 o Editorials 966 o Changed when the self-view is displayed in 4.2.1.1, and added 967 words about allowing users to remove and re-insert it. 969 o Clarified 4.2.6.1 971 o Removed the "mono" stuff from 4.2.7.1 973 o Added that communication should not be possible to eavesdrop to 974 most use cases - and req. F17 976 o Re-phrased 4.3.3.1 to not describe the technical solution so much, 977 and removed "stereo" stuff. Solution possibilities are now in a 978 note. 980 o Re-inserted API requirements after discussion in the W3C webrtc 981 WG. (Re-phrased A15 and added A18 compared to version -02). 983 Changes from draft-ietf-rtcweb-use-cases-and-requirements-02 985 o Removed description/list of API requirements, instead 987 o Reference to W3C webrtc_reqs document for API requirements 989 Changes from draft-ietf-rtcweb-ucreqs-01 991 o Changed Intended status to Information 993 o Changed "Ipr" to "trust200902" 994 o Added use case "Simple video communication service, NAT/Firewall 995 that blocks UDP", and derived new req F26 997 o Added use case "Distributed Music Band" and derived new req A17 999 o Added F24 as requirement derived from use case "Simple video 1000 communication service with inter-operator calling" 1002 o Added section "Additional use cases" 1004 o Added text about ID handling to multiparty with central server use 1005 case 1007 o Re-phrased A1 slightly 1009 Changes from draft-ietf-rtcweb-ucreqs-00 1011 o - Reshuffled: Just two main groups of use cases (b2b and b2GW/ 1012 Server); removed some specific use cases and added them instead as 1013 flavors to the base use case (Simple video communication) 1015 o - Changed the formulation of F19 1017 o - Removed the requirement on an API for DTMF 1019 o - Removed "FX3: There SHOULD be a mapping of the minimum needed 1020 data for setting up connections into SIP, so that the restriction 1021 to SIP-carriable data can be verified. Not a rew on the browser 1022 but rather on a document" 1024 o - (see http://www.ietf.org/mail-archive/web/rtcweb/current/ 1025 msg00227.html for more details) 1027 o -Added text on informing user of that mic/cam is being used and 1028 that it must be possible to revoce permission to use them in 1029 section 7. 1031 Changes from draft-holmberg-rtcweb-ucreqs-01 1033 o - Draft name changed to draft-ietf-rtcweb-ucreqs 1035 o - Use-case grouping introduced 1037 o - Additional use-cases added 1039 o - Additional reqs added (derived from use cases): F19-F25, A16-A17 1041 Changes from draft-holmberg-rtcweb-ucreqs-00 1042 o - Mapping between use-cases and requirements added (Harald 1043 Alvestrand, 090311) 1045 o - Additional security considerations text (Harald Alvestrand, 1046 090311) 1048 o - Clarification that user applications are assumed to be executed 1049 by a browser (Ted Hardie, 080311) 1051 o - Editorial corrections and clarifications 1053 9. Normative References 1055 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1056 Requirement Levels", BCP 14, RFC 2119, March 1997. 1058 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 1059 2000. 1061 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1062 for Application Designers", BCP 145, RFC 5405, November 1063 2008. 1065 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 1066 "Requirements and Analysis of Media Security Management 1067 Protocols", RFC 5479, April 2009. 1069 Appendix A. API requirements 1071 This section contains the requirements on the API derived from the 1072 use-cases in Section 3. 1074 REQ-ID DESCRIPTION 1075 ---------------------------------------------------------------- 1076 A1 The Web API must provide means for the 1077 application to ask the browser for permission 1078 to use cameras and microphones as input devices. 1079 ---------------------------------------------------------------- 1080 A2 The Web API must provide means for the web 1081 application to control how streams generated 1082 by input devices are used. 1083 ---------------------------------------------------------------- 1084 A3 The Web API must provide means for the web 1085 application to control the local rendering of 1086 streams (locally generated streams and streams 1087 received from a peer). 1088 ---------------------------------------------------------------- 1089 A4 The Web API must provide means for the web 1090 application to initiate sending of 1091 stream/stream components to a peer. 1092 ---------------------------------------------------------------- 1093 A5 The Web API must provide means for the web 1094 application to control the media format (codec) 1095 to be used for the streams sent to a peer. 1097 NOTE: The level of control depends on whether 1098 the codec negotiation is handled by the browser 1099 or the web application. 1100 ---------------------------------------------------------------- 1101 A6 The Web API must provide means for the web 1102 application to modify the media format for 1103 streams sent to a peer after a media stream 1104 has been established. 1105 ---------------------------------------------------------------- 1106 A7 The Web API must provide means for 1107 informing the web application of whether the 1108 establishment of a stream with a peer was 1109 successful or not. 1110 ---------------------------------------------------------------- 1111 A8 The Web API must provide means for the web 1112 application to mute/unmute a stream or stream 1113 component(s). When a stream is sent to a peer 1114 mute status must be preserved in the stream 1115 received by the peer. 1116 ---------------------------------------------------------------- 1117 A9 The Web API must provide means for the web 1118 application to cease the sending of a stream 1119 to a peer. 1120 ---------------------------------------------------------------- 1121 A10 The Web API must provide means for the web 1122 application to cease processing and rendering 1123 of a stream received from a peer. 1124 ---------------------------------------------------------------- 1125 A11 The Web API must provide means for 1126 informing the web application when a 1127 stream from a peer is no longer received. 1128 ---------------------------------------------------------------- 1129 A12 The Web API must provide means for 1130 informing the web application when high 1131 loss rates occur. 1132 ---------------------------------------------------------------- 1133 A13 The Web API must provide means for the web 1134 application to apply spatialization effects to 1135 audio streams. 1136 ---------------------------------------------------------------- 1137 A14 The Web API must provide means for the web 1138 application to detect the level in audio 1139 streams. 1140 ---------------------------------------------------------------- 1141 A15 The Web API must provide means for the web 1142 application to adjust the level in audio 1143 streams. 1144 ---------------------------------------------------------------- 1145 A16 The Web API must provide means for the web 1146 application to mix audio streams. 1147 ---------------------------------------------------------------- 1148 A17 The Web API must provide a way to identify 1149 streams such that an application is able to 1150 match streams on a sending peer with the same 1151 stream on all receiving peers. 1152 ---------------------------------------------------------------- 1153 A18 The Web API must provide a mechanism for sending 1154 and receiving isolated discrete chunks of data. 1155 ---------------------------------------------------------------- 1156 A19 The Web API must provide means for the web 1157 application to indicate the type of audio signal 1158 (speech, audio) for audio stream(s)/stream 1159 component(s). 1160 ---------------------------------------------------------------- 1161 A20 It must be possible for an initiator or a 1162 responder web application to indicate the types 1163 of media it is willing to accept incoming 1164 streams for when setting up a connection (audio, 1165 video, other). The types of media to be accepted 1166 can be a subset of the types of media the browser 1167 is able to accept. 1168 ---------------------------------------------------------------- 1169 A21 The Web API must provide means for the 1170 application to ask the browser for permission 1171 to the screen, a certain area on the screen 1172 or what a certain application displays on the 1173 screen as input to streams. 1174 ---------------------------------------------------------------- 1175 A22 The Web API must provide means for the 1176 application to specify several STUN and/or 1177 TURN servers to use. 1178 ---------------------------------------------------------------- 1179 A23 The Web API must provide means for the 1180 application to specify the priority to 1181 apply for outgoing streams and data. 1182 ---------------------------------------------------------------- 1183 A24 The Web API must provide a mechanism for sending 1184 and receiving files. 1186 ---------------------------------------------------------------- 1187 A25 It must be possible for the application to 1188 instruct the browser to refrain from exposing 1189 the host IP address to the application 1190 ---------------------------------------------------------------- 1191 A26 The Web API must provide means for the 1192 application to obtain the statistics (related 1193 to transport, and collected by the browser) 1194 needed to estimate quality of service. 1195 ---------------------------------------------------------------- 1197 Authors' Addresses 1199 Christer Holmberg 1200 Ericsson 1201 Hirsalantie 11 1202 Jorvas 02420 1203 Finland 1205 Email: christer.holmberg@ericsson.com 1207 Stefan Hakansson 1208 Ericsson 1209 Laboratoriegrand 11 1210 Lulea 97128 1211 Sweden 1213 Email: stefan.lk.hakansson@ericsson.com 1215 Goran AP Eriksson 1216 Ericsson 1217 Farogatan 6 1218 Stockholm 16480 1219 Sweden 1221 Email: goran.ap.eriksson@ericsson.com