idnits 2.17.1 draft-ietf-rtcweb-use-cases-and-requirements-12.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 == Line 572 has weird spacing: '...resence of NA...' == Line 688 has weird spacing: '...of that strea...' -- The document date (October 14, 2013) is 3847 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 (~~), 4 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: April 17, 2014 Ericsson 6 October 14, 2013 8 Web Real-Time Communication Use-cases and Requirements 9 draft-ietf-rtcweb-use-cases-and-requirements-12.txt 11 Abstract 13 This document describes web based real-time communication use-cases. 14 Requirements on the browser functionality are derived from use-cases. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 17, 2014. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 54 3.2. Common requirements . . . . . . . . . . . . . . . . . . . 4 55 3.3. Browser-to-browser use-cases . . . . . . . . . . . . . . 4 56 3.3.1. Simple Video Communication Service . . . . . . . . . 4 57 3.3.2. Simple Video Communication Service, NAT/FW that 58 blocks UDP . . . . . . . . . . . . . . . . . . . . . 5 59 3.3.3. Simple Video Communication Service, FW that only 60 allows http . . . . . . . . . . . . . . . . . . . . . 5 61 3.3.4. Simple Video Communication Service, global service 62 provider . . . . . . . . . . . . . . . . . . . . . . 5 63 3.3.5. Simple Video Communication Service, enterprise 64 aspects . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3.6. Simple Video Communication Service, access change . . 7 66 3.3.7. Simple Video Communication Service, QoS . . . . . . . 7 67 3.3.8. Simple Video Communication Service with sharing . . . 8 68 3.3.9. Simple Video Communication Service with file exchange 8 69 3.3.10. Hockey Game Viewer . . . . . . . . . . . . . . . . . 8 70 3.3.11. Multiparty video communication . . . . . . . . . . . 9 71 3.3.12. Multiparty on-line game with voice communication . . 10 72 3.4. Browser - GW/Server use cases . . . . . . . . . . . . . . 11 73 3.4.1. Telephony terminal . . . . . . . . . . . . . . . . . 11 74 3.4.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . 11 75 3.4.3. Video conferencing system with central server . . . . 11 76 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 13 77 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 4.2. Browser requirements . . . . . . . . . . . . . . . . . . 13 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 16 82 6.2. Browser Considerations . . . . . . . . . . . . . . . . . 16 83 6.3. Web Application Considerations . . . . . . . . . . . . . 17 84 7. Additional use-cases . . . . . . . . . . . . . . . . . . . . 17 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 86 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 10. Normative References . . . . . . . . . . . . . . . . . . . . 24 88 Appendix A. API requirements . . . . . . . . . . . . . . . . . . 24 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 91 1. Introduction 93 This document presents a few use-cases of web applications that are 94 executed in a browser and use real-time communication capabilities. 95 In most of the use-cases all end-user clients are web applications, 96 but there are some use-cases where at least one of the end-user 97 client is of another type (e.g. a telephone). 99 Based on the use-cases, the document derives requirements related to 100 browser functionality. These requirements are named "Fn", where n is 101 an integer, and are described in Section 4.2. 103 This document was developed in an initial phase of the work with 104 rather minor updates at later stages. It has not really served as a 105 tool in deciding features or scope for the WGs efforts so far. It is 106 proposed to be used in a later phase to evaluate the protocols and 107 solutions developed by the WG. 109 This document also lists requirements related to the API to be used 110 by web applications as an appendix. The reason is that the W3C 111 WebRTC WG has decided to not develop its own use-case/requirement 112 document, but instead use this document. These requirements are 113 named "An", where n is an integer, and are described in Appendix A- 115 2. Conventions 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in BCP 14, RFC 2119 120 [RFC2119]. 122 3. Use-cases 124 3.1. Introduction 126 This section describes web based real-time communication use-cases, 127 from which requirements are derived. 129 The following considerations are applicable to all use cases: 131 o Clients can be on IPv4-only 133 o Clients can be on IPv6-only 135 o Clients can be on dual-stack 137 o Clients can be connected to networks with different throughput 138 capabilities 140 o Clients can be on variable-media-quality networks (wireless) 142 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 152 Service" by default apply to all other use-cases, and are considred 153 common. For each individual use-case, only the additional 154 requirements are listed. The following requirements can be retrieved 155 from, and apply to, each of the documented use-cases. For each 156 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 of different makes, 193 with different 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/FW that blocks UDP 206 3.3.2.1. Description 208 This use-case is almost identical to the Simple Video Communication 209 Service use-case (Section 3.3.1). The difference is that one of the 210 users is behind a NAT that blocks UDP traffic. 212 3.3.2.2. Additional Requirements 214 F29 216 3.3.3. Simple Video Communication Service, FW that only allows http 218 3.3.3.1. Description 220 This use-case is almost identical to the Simple Video Communication 221 Service use-case (Section 3.3.1). The difference is that one of the 222 users is behind a FW that only allows traffic via a HTTP Proxy. 224 3.3.3.2. Additional Requirements 226 F37 228 3.3.4. Simple Video Communication Service, global service provider 229 3.3.4.1. Description 231 This use-case is almost identical to the Simple Video Communication 232 Service use-case (Section 3.3.1). 234 What is added is that the service provider is operating over large 235 geographical areas (or even globally). 237 Assuming that ICE will be used, this means that the service provider 238 would like to be able to provide several STUN and TURN servers (via 239 the app) to the browser; selection of which one(s) to use is part of 240 the ICE processing. Other reasons for wanting to provide several 241 STUN and TURN servers include support for IPv4 and IPv6, load 242 balancing and redundancy. 244 3.3.4.2. Additional Requirements 246 F31 248 A22 250 3.3.5. Simple Video Communication Service, enterprise aspects 252 3.3.5.1. Description 254 This use-case is similar to the Simple Video Communication Service 255 use-case (Section 3.3.1). 257 What is added is aspects when using the service in enterprises. ICE 258 is assumed in the further description of this use-case. 260 An enterprise that uses a RTCWEB based web application for 261 communication desires to audit all RTCWEB based application session 262 used from inside the company towards any external peer. To be able 263 to do this they deploy a TURN server that straddle the boundary 264 between the internal network and the external. 266 The firewall will block all attempts to use STUN with an external 267 destination unless they go to the enterprise auditing TURN server. 268 In cases where employees are using RTCWEB applications provided by an 269 external service provider they still want to have the traffic to stay 270 inside their internal network and in addition not load the straddling 271 TURN server, thus they deploy a STUN server allowing the RTCWEB 272 client to determine its server reflexive address on the internal 273 side. Thus enabling cases where peers are both on the internal side 274 to connect without the traffic leaving the internal network. It must 275 be possible to configure the browsers used in the enterprise with 276 network specific STUN and TURN servers. This should be possible to 277 achieve by auto-configuration methods. The RTCWEB functionality will 278 need to utilize both network specific STUN and TURN resources and 279 STUN and TURN servers provisioned by the web application. 281 3.3.5.2. Additional Requirements 283 F32 285 3.3.6. Simple Video Communication Service, access change 287 3.3.6.1. Description 289 This use-case is almost identical to the Simple Video Communication 290 Service use-case (Section 3.3.1). The difference is that the user 291 changes network access during the session: 293 The communication device used by one of the users have several 294 network adapters (Ethernet, WiFi, Cellular). The communication 295 device is accessing the Internet using Ethernet, but the user has to 296 start a trip during the session. The communication device 297 automatically changes to use WiFi when the Ethernet cable is removed 298 and then moves to cellular access to the Internet when moving out of 299 WiFi coverage. The session continues even though the access method 300 changes. 302 3.3.6.2. Additional Requirements 304 F26 306 3.3.7. Simple Video Communication Service, QoS 308 3.3.7.1. Description 310 This use-case is almost identical to the Simple Video Communication 311 Service, access change use-case (Section 3.3.6). The use of Quality 312 of Service (QoS) capabilities is added: 314 The user in the previous use case that starts a trip is behind a 315 common residential router that supports prioritization of traffic. 316 In addition, the user's provider of cellular access has QoS support 317 enabled. The user is able to take advantage of the QoS support both 318 when accessing via the residential router and when using cellular. 320 3.3.7.2. Additional Requirements 322 F24, F26 324 3.3.8. Simple Video Communication Service with sharing 326 3.3.8.1. Description 328 This use-case has the audio and video communication of the Simple 329 Video Communication Service use-case (Section 3.3.1). 331 But in addition to this, one of the users can share what is being 332 displayed on her/his screen with a peer. The user can choose to 333 share the entire screen, part of the screen (part selected by the 334 user) or what a selected application displays with the peer. 336 3.3.8.2. Additional Requirements 338 F30 340 A21 342 3.3.9. Simple Video Communication Service with file exchange 344 3.3.9.1. Description 346 This use-case has the audio and video communication of the Simple 347 Video Communication Service use-case (Section 3.3.1). 349 But in addition to this, the users can send and receive files stored 350 in the file system of the device used. 352 3.3.9.2. Additional Requirements 354 F30, F33 356 A21, A24 358 3.3.10. Hockey Game Viewer 360 3.3.10.1. Description 362 An ice-hockey club uses an application that enables talent scouts to, 363 in real-time, show and discuss games and players with the club 364 manager. The talent scouts use a mobile phone with two cameras, one 365 front facing and one rear facing. 367 The club manager uses a desktop, equipped with one camera, for 368 viewing the game and discussing with the talent scout. 370 Before the game starts, and during game breaks, the talent scout and 371 the manager have a 1-1 audiovisual communication session. On the 372 mobile phone, only the camera facing the talent scout is used. On 373 the user display of the mobile phone, the video of the club manager 374 is shown with a picture-in-picture thumbnail of the rear facing 375 camera (self-view). On the display of the desktop, the video of the 376 talent scout is shown with a picture-in-picture thumbnail of the 377 desktop camera (self-view). 379 When the game is on-going, the talent scout activates the use of the 380 front facing camera, and that stream is sent to the desktop (the 381 stream from the rear facing camera continues to be sent all the 382 time). The video stream captured by the front facing camera (that is 383 capturing the game) of the mobile phone is shown in a big window on 384 the desktop screen, with picture-in-picture thumbnails of the rear 385 facing camera and the desktop camera (self-view). On the display of 386 the mobile phone the game is shown (front facing camera) with 387 picture-in-picture thumbnails of the rear facing camera (self-view) 388 and the desktop camera. As the most important stream in this phase 389 is the video showing the game, the application used in the talent 390 scout's mobile sets higher priority for that stream. 392 3.3.10.2. Additional Requirements 394 F17, F34 396 A17, A23 398 3.3.11. Multiparty video communication 400 3.3.11.1. Description 402 In this use-case is the Simple Video Communication Service use-case 403 (Section 3.3.1) is extended by allowing multiparty sessions. No 404 central server is involved - the browser of each participant sends 405 and receives streams to and from all other session participants. The 406 web application in the browser of each user is responsible for 407 setting up streams to all receivers. 409 In order to enhance intelligibility, the web application pans the 410 audio from different participants differently when rendering the 411 audio. This is done automatically, but users can change how the 412 different participants are placed in the (virtual) room. In addition 413 the levels in the audio signals are adjusted before mixing. 415 Another feature intended to enhance the use experience is that the 416 video window that displays the video of the currently speaking peer 417 is highlighted. 419 Each video stream received is by default displayed in a thumbnail 420 frame within the browser, but users can change the display size. 422 Note: What this use-case adds in terms of requirements is 423 capabilities to send streams to and receive streams from several 424 peers concurrently, as well as the capabilities to render the video 425 from all received streams and be able to spatialize, level adjust and 426 mix the audio from all received streams locally in the browser. It 427 also adds the capability to measure the audio level/activity. 429 3.3.11.2. Additional Requirements 431 F11, F12, F13, F14, F15, F16, F17 433 A13, A14, A15, A16, A17 435 3.3.12. Multiparty on-line game with voice communication 437 3.3.12.1. Description 439 This use case is based on the previous one. In this use-case, the 440 voice part of the multiparty video communication use case is used in 441 the context of an on-line game. The received voice audio media is 442 rendered together with game sound objects. For example, the sound of 443 a tank moving from left to right over the screen must be rendered and 444 played to the user together with the voice media. 446 Quick updates of the game state is required, and have higher priority 447 than the voice. 449 Note: the difference regarding local audio processing compared to the 450 "Multiparty video communication" use-case is that other sound objects 451 than the streams must be possible to be included in the 452 spatialization and mixing. "Other sound objects" could for example 453 be a file with the sound of the tank; that file could be stored 454 locally or remotely. 456 3.3.12.2. Additional Requirements 458 F12, F13, F14, F15, F16, F18 460 A13, A14, A15, A16, A17, A18, A23 462 3.4. Browser - GW/Server use cases 464 3.4.1. Telephony terminal 466 3.4.1.1. Description 468 A mobile telephony operator allows its customers to use a web browser 469 to access their services. After a simple log in the user can place 470 and receive calls in the same way as when using a normal mobile 471 phone. When a call is received or placed, the identity is shown in 472 the same manner as when a mobile phone is used. 474 Note: With "place and receive calls in the same way as when using a 475 normal mobile phone" it is meant that you can dial a number, and that 476 your mobile telephony operator has made available your phone contacts 477 on line, so they are available and can be clicked to call, and be 478 used to present the identity of an incoming call. If the callee is 479 not in your phone contacts the number is displayed. Furthermore, 480 your call logs are available, and updated with the calls made/ 481 received from the browser. And for people receiving calls made from 482 the web browser the usual identity (i.e. the phone number of the 483 mobile phone) will be presented. 485 3.4.1.2. Additional Requirements 487 F21 489 3.4.2. Fedex Call 491 3.4.2.1. Description 493 Alice uses her web browser with a service that allows her to call 494 PSTN numbers. Alice calls 1-800-gofedex. Alice should be able to 495 hear the initial prompts from the fedex Interactive Voice Responder 496 (IVR) and when the IVR says press 1, there should be a way for Alice 497 to navigate the IVR. 499 3.4.2.2. Additional Requirements 501 F21, F22 503 3.4.3. Video conferencing system with central server 504 3.4.3.1. Description 506 An organization uses a video communication system that supports the 507 establishment of multiparty video sessions using a central conference 508 server. 510 The browser of each participant send an audio stream (type in terms 511 of mono, stereo, 5.1, ... depending on the equipment of the 512 participant) to the central server. The central server mixes the 513 audio streams (and can in the mixing process naturally add effects 514 such as spatialization) and sends towards each participant a mixed 515 audio stream which is played to the user. 517 The browser of each participant sends video towards the server. For 518 each participant one high resolution video is displayed in a large 519 window, while a number of low resolution videos are displayed in 520 smaller windows. The server selects what video streams to be 521 forwarded as main- and thumbnail videos respectively, based on speech 522 activity. As the video streams to display can change quite 523 frequently (as the conversation flows) it is important that the delay 524 from when a video stream is selected for display until the video can 525 be displayed is short. 527 All participants are authenticated by the central server, and 528 authorized to connect to the central server. The participants are 529 identified to each other by the central server, and the participants 530 do not have access to each others' credentials such as e-mail 531 addresses or login IDs. 533 Note: This use-case adds requirements on support for fast stream 534 switches F7, on encryption of media and on ability to traverse very 535 restrictive FWs. There exist several solutions that enable the 536 server to forward one high resolution and several low resolution 537 video streams: a) each browser could send a high resolution, but 538 scalable stream, and the server could send just the base layer for 539 the low resolution streams, b) each browser could in a simulcast 540 fashion send one high resolution and one low resolution stream, and 541 the server just selects or c) each browser sends just a high 542 resolution stream, the server transcodes into low resolution streams 543 as required. 545 3.4.3.2. Additional Requirements 547 F17 549 A17 551 4. Requirements 553 4.1. General 555 This section contains the requirements on the browser derived from 556 the use-cases in Section 3. 558 NOTE: It is assumed that the user applications are executed on a 559 browser. Whether the capabilities to implement specific browser 560 requirements are implemented by the browser application, or are 561 provided to the browser application by the underlying operating 562 system, is outside the scope of this document. 564 4.2. Browser requirements 566 REQ-ID DESCRIPTION 567 --------------------------------------------------------------- 568 F1 The browser must be able to use microphones and 569 cameras as input devices to generate streams. 570 ---------------------------------------------------------------- 571 F2 The browser must be able to send streams and 572 data to a peer in the presence of NATs. 573 ---------------------------------------------------------------- 574 F3 Transmitted streams and data must be rate 575 controlled (meaning that the browser must, regardless 576 of application behavior, reduce send rate when 577 there is congestion). 578 ---------------------------------------------------------------- 579 F4 The browser must be able to receive, process and 580 render streams and data ("render" does not 581 apply for data) from peers. 582 ---------------------------------------------------------------- 583 F5 The browser should be able to render good quality 584 audio and video even in the presence of 585 reasonable levels of jitter and packet losses. 586 ---------------------------------------------------------------- 587 F7 The browser must support insertion of reference frames 588 in outgoing media streams when requested by a peer. 589 ---------------------------------------------------------------- 590 F8 The browser must detect when a stream from a 591 peer is not received anymore 592 ---------------------------------------------------------------- 593 F9 When there are both incoming and outgoing audio 594 streams, echo cancellation must be made 595 available to avoid disturbing echo during 596 conversation. 597 ---------------------------------------------------------------- 598 F10 The browser must support synchronization of 599 audio and video. 600 ---------------------------------------------------------------- 601 F11 The browser must be able to transmit streams and 602 data to several peers concurrently. 603 ---------------------------------------------------------------- 604 F12 The browser must be able to receive streams and 605 data from multiple peers concurrently. 606 ---------------------------------------------------------------- 607 F13 The browser must be able to apply spatialization 608 effects when playing audio streams. 609 ---------------------------------------------------------------- 610 F14 The browser must be able to measure the 611 voice activity level in audio streams. 612 ---------------------------------------------------------------- 613 F15 The browser must be able to change the 614 voice activity level in audio streams. 615 ---------------------------------------------------------------- 616 F16 The browser must be able to render several 617 concurrent video streams 618 ---------------------------------------------------------------- 619 F17 The browser must be able to mix several 620 audio streams. 621 ---------------------------------------------------------------- 622 F18 The browser must be able to process and mix 623 sound objects (media that is retrieved from 624 another source than the established media 625 stream(s) with the peer(s) with audio streams. 626 ---------------------------------------------------------------- 627 F20 It must be possible to protect streams and data 628 from wiretapping [RFC2804]. 629 ---------------------------------------------------------------- 630 F21 The browser must support an audio media format 631 (codec) that is commonly supported by existing 632 telephony services. 633 ---------------------------------------------------------------- 634 F22 There should be a way to navigate 635 a Dual-tone multi-frequency signaling (DTMF) 636 based Interactive voice response (IVR) System 637 ---------------------------------------------------------------- 638 F23 The browser must be able to send short 639 latency unreliable datagram traffic to a 640 peer browser [RFC5405]. 641 ---------------------------------------------------------------- 642 F24 The browser should be able to take advantage 643 of available capabilities (supplied by network 644 nodes) to prioritize voice, video and data 645 appropriately. 647 ---------------------------------------------------------------- 648 F25 The browser should use encoding of streams 649 suitable for the current rendering (e.g. 650 video display size) and should change parameters 651 if the rendering changes during the session 652 ---------------------------------------------------------------- 653 F26 It must be possible to move from one network 654 interface to another one 655 ---------------------------------------------------------------- 656 F27 The browser must be able to initiate and 657 accept a media session where the data needed 658 for establishment can be carried in SIP. 659 ---------------------------------------------------------------- 660 F28 The browser must support a baseline audio and 661 video codec 662 ---------------------------------------------------------------- 663 F29 The browser must be able to send streams and 664 data to a peer in the presence of NATs that 665 block UDP traffic. 666 ---------------------------------------------------------------- 667 F30 The browser must be able to use the screen (or 668 a specific area of the screen) or what a certain 669 application displays on the screen to generate 670 streams. 671 ---------------------------------------------------------------- 672 F31 The browser must be able to use several STUN 673 and TURN servers 674 ---------------------------------------------------------------- 675 F32 There browser must support that STUN and TURN 676 servers to use are supplied by other entities 677 than via the web application (i.e. the network 678 provider). 679 ---------------------------------------------------------------- 680 F33 The browser must be able to send reliable 681 data traffic to a peer browser. 682 ---------------------------------------------------------------- 683 F34 The browser must support prioritization of 684 streams and data. 685 ---------------------------------------------------------------- 686 F35 The browser must enable verification, given 687 the right circumstances and by use of other 688 trusted communication, of that streams and 689 data received have not been manipulated by 690 any party. 691 ---------------------------------------------------------------- 692 F36 The browser must encrypt, authenticate and 693 integrity protect media and data on a 694 per-packet basis, and must drop incoming media 695 and data packets that fail the per-packet 696 integrity check. In addition, the browser 697 must support a mechanism for cryptographically 698 binding media and data security keys to the 699 user identity (see R-ID-BINDING in [RFC5479]). 700 ---------------------------------------------------------------- 701 F37 The browser must be able to send streams and 702 data to a peer in the presence of FWs that only 703 allows traffic via a HTTP Proxy, when FW policy 704 allows WebRTC traffic. 705 ---------------------------------------------------------------- 706 F38 The browser must be able to collect statistics, 707 related to the transport of audio and video 708 between peers, needed to estimate quality of 709 experience. 710 ---------------------------------------------------------------- 711 F39 The browser must make it possible to set up a 712 call between two parties without one party 713 learning the other party's host IP address. 714 ---------------------------------------------------------------- 716 5. IANA Considerations 718 There are no IANA actions in this document. 720 6. Security Considerations 722 6.1. Introduction 724 A malicious web application might use the browser to perform Denial 725 Of Service (DOS) attacks on NAT infrastructure, or on peer devices. 726 Also, a malicious web application might silently establish outgoing, 727 and accept incoming, streams on an already established connection. 729 Based on the identified security risks, this section will describe 730 security considerations for the browser and web application. 732 6.2. Browser Considerations 734 The browser is expected to provide mechanisms for getting user 735 consent to use device resources such as camera and microphone. 737 The browser is expected to provide mechanisms for informing the user 738 that device resources such as camera and microphone are in use 739 ("hot"). 741 The browser is expected to provide mechanisms for users to revise and 742 even completely revoke consent to use device resources such as camera 743 and microphone. 745 The browser is expected to provide mechanisms for getting user 746 consent to use the screen (or a certain part of it) or what a certain 747 application displays on the screen as source for streams. 749 The browser is expected to provide mechanisms for informing the user 750 that the screen, part thereof or an application is serving as a 751 stream source ("hot"). 753 The browser is expected to provide mechanisms for users to revise and 754 even completely revoke consent to use the screen, part thereof or an 755 application is serving as a stream source. 757 The browser is expected to provide mechanisms in order to assure that 758 streams are the ones the recipient intended to receive. 760 The browser is expected to provide mechanisms that allows the users 761 to verify that the streams received have not be manipulated (F35). 763 The browser needs to ensure that media is not sent, and that received 764 media is not rendered, until the associated stream establishment and 765 handshake procedures with the remote peer have been successfully 766 finished. 768 The browser needs to ensure that the stream negotiation procedures 769 are not seen as Denial Of Service (DOS) by other entities. 771 6.3. Web Application Considerations 773 The web application is expected to ensure user consent in sending and 774 receiving media streams. 776 7. Additional use-cases 778 Several additional use-cases have been discussed. At this point 779 these use-cases are not included as requirement deriving use-cases 780 for different reasons (lack of documentation, overlap with existing 781 use-cases, lack of consensus). For completeness these additional 782 use-cases are listed below: 784 1. Use-cases regarding different situations when being invited to a 785 "session", e.g. browser open, browser open but another tab 786 active, browser open but active in session, browser closed, .... 787 (Matthew Kaufman); discussed at webrtc meeting 789 2. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/rtcweb 790 /current/msg00525.html, followed up by Stephan Wenger 792 3. Local Recording and Remote recording (John): Discussed a _lot_ 793 on the mail lists (rtcweb as well as public-webrtc) August and 794 September 2011. Concrete proposal: http://www.ietf.org/mail- 795 archive/web/rtcweb/current/msg01006.html (remote) and http:// 796 www.ietf.org/mail-archive/web/rtcweb/current/msg00734.html 797 (local) 799 4. Emergency access for disabled (Bernard Aboba) http:// 800 www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html 802 5. Clue use-cases (Roni Even) http://tools.ietf.org/html/draft- 803 ietf-clue-telepresence-use-cases-01 805 6. Rohan red cross (Cullen Jennings); http://www.ietf.org/mail- 806 archive/web/rtcweb/current/msg00323.html 808 7. Security camera/baby monitor usage http://www.ietf.org/mail- 809 archive/web/rtcweb/current/msg00543.html 811 8. Large multiparty session http://www.ietf.org/mail-archive/web/ 812 rtcweb/current/msg00530.html 814 9. Call center http://www.ietf.org/mail-archive/web/rtcweb/current/ 815 msg04203.html 817 10. Enterprise policies http://www.ietf.org/mail-archive/web/rtcweb/ 818 current/msg04271.html 820 11. Low-complex multiparty central node http://www.ietf.org/mail- 821 archive/web/rtcweb/current/msg04430.html 823 12. Multiparty central node that is not allowed to decipher http:// 824 www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html 826 8. Acknowledgements 828 The authors wish to thank Bernard Aboba, Gunnar Hellstrom, Martin 829 Thomson, Lars Eggert, Matthew Kaufman, Emil Ivov, Eric Rescorla, Eric 830 Burger, John Leslie, Dan Wing, Richard Barnes, Barry Dingle, Dale 831 Worley, Ted hardie, Mary Barnes, Dan Burnett, Stephan Wenger, Harald 832 Alvestrand, Cullen Jennings, Andrew Hutton and everyone else in the 833 RTCWEB community that have provided comments, feedback, text and 834 improvement proposals on the document. 836 9. Change Log 838 [RFC EDITOR NOTE: Please remove this section when publishing] 840 Changes from draft-ietf-rtcweb-use-cases-and-requirements-10 842 o Described that the API requirements are really from a W3C 843 perspective and are supplied as an appendix in the introduction. 844 Moved API requirements to an Appendix. 846 o Removed the "Conventions" section with the key-words and reference 847 to RFC2119. Also changed uppercase MUST's/SHOULD's to lowercase. 849 o Added a note on the proposed use of the document to the 850 introduction. 852 o Removed the note talking about WS from the "FW that only allows 853 http" use-case. 855 o Removed the word "Skype" that was used as example in one of the 856 use-cases. 858 o Clarified F3 (the req saying the everything the browser sends must 859 be rate controlled). 861 o Removed the TBD saying we need to define reasonable levels from 862 the requirement saying that quality must be good even in presence 863 of packet losses (F5), and changed "must" to "should" (Based on a 864 list discussion involving Bernard). 866 o Removed F6 ("The browser must be able to handle high loss and 867 jitter levels in a graceful way."), also after a list discussion. 869 o Clarified F7 (used to say that the browser must support fast 870 stream switches, now says that reference frames must be inserted 871 when requested). 873 o Removed the questions from F9 (echo cancellation), F10 874 (synchronization), F21 (telephony codec). 876 o Exchanged "restrictive firewalls" for "limited middleboxes" in F19 877 (as proposed by Martin). 879 o Expanded DTMF and IVR in F22 (proposed by Martin) 881 o Added ref to RFC5405 in F23 (proposed by Lars Eggert). 883 o Exchanged "service provided" for "web application" in F32. 885 o Changed the text in 3.2.1 that motivates F36 (new text "It is 886 essential that media and data be encrypted, authenticated ... 887 bound to the user identity."); and rewrote F36, included a ref to 888 RFC5479. 890 o Changed "quality of service" to "quality of experience" in F38. 892 o Added F39. 894 o Used new formulation of A17 (proposed by Martin). 896 o Updated A20. 898 o Updated A25. 900 Changes from draft-ietf-rtcweb-use-cases-and-requirements-09 902 o Changed "video communication session" to "audiovisual 903 communication session. 905 Changes from draft-ietf-rtcweb-use-cases-and-requirements-08 907 o Changed "eavesdropping" to "wiretapping" and referenced RFC2804. 909 o Removed informal ref webrtc_req; that document has been abandoned 910 by the W3C webrtc WG. 912 o Added use-case where one user is behind a FW that only allows 913 http; derived req. F37. 915 o Changed F24 slightly; MUST-> SHOULD, inserted "available". 917 o Added a clause to "Simple video communication service" saying that 918 the service provider monitors the quality of service, and derived 919 reqs F38 and A26. 921 Changes from draft-ietf-rtcweb-use-cases-and-requirements-07 923 o Added "and data exchange" to 1. Introduction. 925 o Removed cone and symmetric NAT from 4.1 Introduction, refers to 926 RFC4787 instead. 928 o Added text on enabling verification of that the media has not been 929 manipulated by anyone to use-case "Simple Video Communication 930 Service", derived req. F35 932 o Added text on that the browser should reject media (data) that has 933 been created/injected/modified by non-trusted party, derived req. 934 F36 936 o Added text on enabling the app to refrain from revealing IP 937 address to use-case "Simple Video Communication Service", derived 938 req. A25 940 o Added use-case "Simple Video Communication Service with file 941 exchange", derived reqs F33 and A24 943 o Added priority of video streams to "Hockey game viewer" use case, 944 added priority of data to "on-line game use-case", derived reqs 945 F34 and A23 947 o In F22, "the IVR" -> "a DTMF based IVR". 949 o Updated req F23 to clarify that requirements such as NAT 950 traversal, protection from eavesdropping, rate control applies 951 also to datagram. 953 Changes from draft-ietf-rtcweb-use-cases-and-requirements-06 955 o Renaming of requirements (FaI1 -> F31), (FaI2 -> F32) and (AaI1 -> 956 A22) 958 Changes from draft-ietf-rtcweb-use-cases-and-requirements-05 960 o Added use-case "global service provider", derived reqs associated 961 with several STUN/TURN servers 963 o Added use-case "enterprise aspects", derived req associated with 964 enabling the network provider to supply STUN and TURN servers 966 o The requirements from the above are ICE specific and labeled 967 accordingly 969 o Separated the requirements phrased like "processing such as pan, 970 mix and render" for audio to be specific reqs on spatialization, 971 level measurement, level adjustment and mixing (discussed on the 972 lists in http://www.ietf.org/mail-archive/web/rtcweb/current/ 973 msg01648.html and http://lists.w3.org/Archives/Public/public- 974 webrtc/2011Sep/0102.html) 976 o Added use-case on sharing as decided in http://www.ietf.org/mail- 977 archive/web/rtcweb/current/msg01700.html, derived reqs F30 and A21 979 o Added the list of common considerations proposed in mail http:// 980 www.ietf.org/mail-archive/web/rtcweb/current/msg01562.html to the 981 Introduction of the use-case section 983 Changes from draft-ietf-rtcweb-use-cases-and-requirements-04 985 o Most changes based on the input from Dan Burnett http:// 986 www.ietf.org/mail-archive/web/rtcweb/current/msg00948.html 988 o Many editorial changes 990 o 4.2.1.1 Clarified 992 o Some clarification added to 4.3.1.1 as a note 994 o F-requirements updated (see reply to Dan's mail). 996 o Almost all A-requirements updated to start "The Web API MUST 997 provide ..." 999 o A8 removed, A9 rephrased to cover A8 and old A9 1001 o A15 rephrased 1003 o For more details, and discussion, look at the response to Dan's 1004 mail http://www.ietf.org/mail-archive/web/rtcweb/current/ 1005 msg01177.html 1007 Changes from draft-ietf-rtcweb-use-cases-and-requirements-03 1009 o Editorials 1011 o Changed when the self-view is displayed in 4.2.1.1, and added 1012 words about allowing users to remove and re-insert it. 1014 o Clarified 4.2.6.1 1016 o Removed the "mono" stuff from 4.2.7.1 1018 o Added that communication should not be possible to eavesdrop to 1019 most use cases - and req. F17 1021 o Re-phrased 4.3.3.1 to not describe the technical solution so much, 1022 and removed "stereo" stuff. Solution possibilities are now in a 1023 note. 1025 o Re-inserted API requirements after discussion in the W3C webrtc 1026 WG. (Re-phrased A15 and added A18 compared to version -02). 1028 Changes from draft-ietf-rtcweb-use-cases-and-requirements-02 1030 o Removed description/list of API requirements, instead 1032 o Reference to W3C webrtc_reqs document for API requirements 1034 Changes from draft-ietf-rtcweb-ucreqs-01 1036 o Changed Intended status to Information 1038 o Changed "Ipr" to "trust200902" 1040 o Added use case "Simple video communication service, NAT/FW that 1041 blocks UDP", and derived new req F26 1043 o Added use case "Distributed Music Band" and derived new req A17 1045 o Added F24 as requirement derived from use case "Simple video 1046 communication service with inter-operator calling" 1048 o Added section "Additional use cases" 1050 o Added text about ID handling to multiparty with central server use 1051 case 1053 o Re-phrased A1 slightly 1055 Changes from draft-ietf-rtcweb-ucreqs-00 1057 o - Reshuffled: Just two main groups of use cases (b2b and b2GW/ 1058 Server); removed some specific use cases and added them instead as 1059 flavors to the base use case (Simple video communication) 1061 o - Changed the formulation of F19 1063 o - Removed the requirement on an API for DTMF 1065 o - Removed "FX3: There SHOULD be a mapping of the minimum needed 1066 data for setting up connections into SIP, so that the restriction 1067 to SIP-carriable data can be verified. Not a rew on the browser 1068 but rather on a document" 1070 o - (see http://www.ietf.org/mail-archive/web/rtcweb/current/ 1071 msg00227.html for more details) 1073 o -Added text on informing user of that mic/cam is being used and 1074 that it must be possible to revoce permission to use them in 1075 section 7. 1077 Changes from draft-holmberg-rtcweb-ucreqs-01 1079 o - Draft name changed to draft-ietf-rtcweb-ucreqs 1081 o - Use-case grouping introduced 1083 o - Additional use-cases added 1085 o - Additional reqs added (derived from use cases): F19-F25, A16-A17 1087 Changes from draft-holmberg-rtcweb-ucreqs-00 1089 o - Mapping between use-cases and requirements added (Harald 1090 Alvestrand, 090311) 1092 o - Additional security considerations text (Harald Alvestrand, 1093 090311) 1095 o - Clarification that user applications are assumed to be executed 1096 by a browser (Ted Hardie, 080311) 1098 o - Editorial corrections and clarifications 1100 10. Normative References 1102 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1103 Requirement Levels", BCP 14, RFC 2119, March 1997. 1105 [RFC2804] IAB IESG, "IETF Policy on Wiretapping", RFC 2804, May 1106 2000. 1108 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1109 for Application Designers", BCP 145, RFC 5405, November 1110 2008. 1112 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 1113 "Requirements and Analysis of Media Security Management 1114 Protocols", RFC 5479, April 2009. 1116 Appendix A. API requirements 1118 This section contains the requirements on the API derived from the 1119 use-cases in Section 3. 1121 REQ-ID DESCRIPTION 1122 ---------------------------------------------------------------- 1123 A1 The Web API must provide means for the 1124 application to ask the browser for permission 1125 to use cameras and microphones as input devices. 1126 ---------------------------------------------------------------- 1127 A2 The Web API must provide means for the web 1128 application to control how streams generated 1129 by input devices are used. 1130 ---------------------------------------------------------------- 1131 A3 The Web API must provide means for the web 1132 application to control the local rendering of 1133 streams (locally generated streams and streams 1134 received from a peer). 1135 ---------------------------------------------------------------- 1136 A4 The Web API must provide means for the web 1137 application to initiate sending of 1138 stream/stream components to a peer. 1139 ---------------------------------------------------------------- 1140 A5 The Web API must provide means for the web 1141 application to control the media format (codec) 1142 to be used for the streams sent to a peer. 1144 NOTE: The level of control depends on whether 1145 the codec negotiation is handled by the browser 1146 or the web application. 1147 ---------------------------------------------------------------- 1148 A6 The Web API must provide means for the web 1149 application to modify the media format for 1150 streams sent to a peer after a media stream 1151 has been established. 1152 ---------------------------------------------------------------- 1153 A7 The Web API must provide means for 1154 informing the web application of whether the 1155 establishment of a stream with a peer was 1156 successful or not. 1157 ---------------------------------------------------------------- 1158 A8 The Web API must provide means for the web 1159 application to mute/unmute a stream or stream 1160 component(s). When a stream is sent to a peer 1161 mute status must be preserved in the stream 1162 received by the peer. 1163 ---------------------------------------------------------------- 1164 A9 The Web API must provide means for the web 1165 application to cease the sending of a stream 1166 to a peer. 1167 ---------------------------------------------------------------- 1168 A10 The Web API must provide means for the web 1169 application to cease processing and rendering 1170 of a stream received from a peer. 1171 ---------------------------------------------------------------- 1172 A11 The Web API must provide means for 1173 informing the web application when a 1174 stream from a peer is no longer received. 1175 ---------------------------------------------------------------- 1176 A12 The Web API must provide means for 1177 informing the web application when high 1178 loss rates occur. 1179 ---------------------------------------------------------------- 1180 A13 The Web API must provide means for the web 1181 application to apply spatialization effects to 1182 audio streams. 1183 ---------------------------------------------------------------- 1184 A14 The Web API must provide means for the web 1185 application to detect the level in audio 1186 streams. 1187 ---------------------------------------------------------------- 1188 A15 The Web API must provide means for the web 1189 application to adjust the level in audio 1190 streams. 1191 ---------------------------------------------------------------- 1192 A16 The Web API must provide means for the web 1193 application to mix audio streams. 1194 ---------------------------------------------------------------- 1195 A17 The Web API must provide a way to identify 1196 streams such that an application is able to 1197 match streams on a sending peer with the same 1198 stream on all receiving peers. 1199 ---------------------------------------------------------------- 1200 A18 The Web API must provide a mechanism for sending 1201 and receiving isolated discrete chunks of data. 1202 ---------------------------------------------------------------- 1203 A19 The Web API must provide means for the web 1204 application to indicate the type of audio signal 1205 (speech, audio) for audio stream(s)/stream 1206 component(s). 1207 ---------------------------------------------------------------- 1208 A20 It must be possible for an initiator or a 1209 responder web application to indicate the types 1210 of media it is willing to accept incoming 1211 streams for when setting up a connection (audio, 1212 video, other). The types of media to be accepted 1213 can be a subset of the types of media the browser 1214 is able to accept. 1215 ---------------------------------------------------------------- 1216 A21 The Web API must provide means for the 1217 application to ask the browser for permission 1218 to the screen, a certain area on the screen 1219 or what a certain application displays on the 1220 screen as input to streams. 1221 ---------------------------------------------------------------- 1222 A22 The Web API must provide means for the 1223 application to specify several STUN and/or 1224 TURN servers to use. 1225 ---------------------------------------------------------------- 1226 A23 The Web API must provide means for the 1227 application to specify the priority to 1228 apply for outgoing streams and data. 1229 ---------------------------------------------------------------- 1230 A24 The Web API must provide a mechanism for sending 1231 and receiving files. 1232 ---------------------------------------------------------------- 1233 A25 It must be possible for the application to 1234 instruct the browser to refrain from exposing 1235 the host IP address to the application 1236 ---------------------------------------------------------------- 1237 A26 The Web API must provide means for the 1238 application to obtain the statistics (related 1239 to transport, and collected by the browser) 1240 needed to estimate quality of service. 1241 ---------------------------------------------------------------- 1243 Authors' Addresses 1245 Christer Holmberg 1246 Ericsson 1247 Hirsalantie 11 1248 Jorvas 02420 1249 Finland 1251 Email: christer.holmberg@ericsson.com 1253 Stefan Hakansson 1254 Ericsson 1255 Laboratoriegrand 11 1256 Lulea 97128 1257 Sweden 1259 Email: stefan.lk.hakansson@ericsson.com 1260 Goran AP Eriksson 1261 Ericsson 1262 Farogatan 6 1263 Stockholm 16480 1264 Sweden 1266 Email: goran.ap.eriksson@ericsson.com