idnits 2.17.1 draft-ietf-rtcweb-use-cases-and-requirements-06.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 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == 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 (October 4, 2011) is 4588 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. 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: April 6, 2012 Ericsson 6 October 4, 2011 8 Web Real-Time Communication Use-cases and Requirements 9 draft-ietf-rtcweb-use-cases-and-requirements-06.txt 11 Abstract 13 This document describes web based real-time communication use-cases. 14 Based on the use-cases, the document also derives requirements 15 related to the browser, and the API used by web applications to 16 request and control media stream services provided by the browser. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 6, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 57 4.2. Browser-to-browser use-cases . . . . . . . . . . . . . . . 4 58 4.2.1. Simple Video Communication Service . . . . . . . . . . 4 59 4.2.2. Simple Video Communication Service, NAT/FW that 60 blocks UDP . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2.3. Simple Video Communication Service, global service 62 provider . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2.4. Simple Video Communication Service, enterprise 64 aspects . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2.5. Simple Video Communication Service, access change . . 6 66 4.2.6. Simple Video Communication Service, QoS . . . . . . . 7 67 4.2.7. Simple Video Communication Service with sharing . . . 7 68 4.2.8. Simple video communication service with 69 inter-operator calling . . . . . . . . . . . . . . . . 8 70 4.2.9. Hockey Game Viewer . . . . . . . . . . . . . . . . . . 8 71 4.2.10. Multiparty video communication . . . . . . . . . . . . 9 72 4.2.11. Multiparty on-line game with voice communication . . . 10 73 4.2.12. Distributed Music Band . . . . . . . . . . . . . . . . 11 74 4.3. Browser - GW/Server use cases . . . . . . . . . . . . . . 11 75 4.3.1. Telephony terminal . . . . . . . . . . . . . . . . . . 11 76 4.3.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . . 12 77 4.3.3. Video conferencing system with central server . . . . 12 78 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.2. Browser requirements . . . . . . . . . . . . . . . . . . . 13 81 5.3. API requirements . . . . . . . . . . . . . . . . . . . . . 16 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 18 85 7.2. Browser Considerations . . . . . . . . . . . . . . . . . . 19 86 7.3. Web Application Considerations . . . . . . . . . . . . . . 19 87 8. Additional use-cases . . . . . . . . . . . . . . . . . . . . . 20 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 89 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 92 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 95 1. Introduction 97 This document presents a few use-cases of web applications that are 98 executed in a browser and use real-time communication capabilities. 99 Based on the use-cases, the document derives requirements related to 100 the browser and the API used by web applications in the browser. 102 The requirements related to the browser are named "Fn" and are 103 described in Section 5.2 105 The requirements related to the API are named "An" and are described 106 in Section 5.3 108 The document focuses on requirements related to real-time media 109 streams. Requirements related to privacy, signalling between the 110 browser and web server etc. are currently not considered. 112 2. Conventions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14, RFC 2119 117 [RFC2119]. 119 3. Definitions 121 TBD 123 4. Use-cases 125 4.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: 131 o Clients can be on IPv4-only 132 o Clients can be on IPv6-only 133 o Clients can be on dual-stack 134 o Clients can be on wideband (10s of Mbits/sec) 135 o Clients can be on narrowband (10s to 100s of Kbits/sec) 136 o Clients can be on variable-media-quality networks (wireless) 137 o Clients can be on congested networks 138 o Clients can be on firewalled networks with no UDP allowed 139 o Clients can be on networks with cone NAT 140 o Clients can be on networks with symmetric NAT 142 4.2. Browser-to-browser use-cases 144 4.2.1. Simple Video Communication Service 146 4.2.1.1. Description 148 Two or more users have loaded a video communication web application 149 into their browsers, provided by the same service provider, and 150 logged into the service it provides. The web service publishes 151 information about user login status by pushing updates to the web 152 application in the browsers. When one online user selects a peer 153 online user, a 1-1 video communication session between the browsers 154 of the two peers is initiated. The invited user might accept or 155 reject the session. 157 During session establishment a self-view is displayed, and once the 158 session has been established the video sent from the remote peer is 159 displayed in addition to the self-view. During the session, each 160 user can select to remove and re-insert the self-view as often as 161 desired. Each user can also change the sizes of his/her two video 162 displays during the session. Each user can also pause sending of 163 media (audio, video, or both) and mute incoming media 165 It is essential that the communication cannot be eavesdropped. 167 Any session participant can end the session at any time. 169 The two users may be using communication devices of different makes, 170 with different operating systems and browsers from different vendors. 172 One user has an unreliable Internet connection. It sometimes loses 173 packets, and sometimes goes down completely. 175 One user is located behind a Network Address Translator (NAT). 177 4.2.1.2. Derived Requirements 179 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28 181 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 183 4.2.2. Simple Video Communication Service, NAT/FW that blocks UDP 185 4.2.2.1. Description 187 This use-case is almost identical to the Simple Video Communication 188 Service use-case (Section 4.2.1). The difference is that one of the 189 users is behind a NAT that blocks UDP traffic. 191 4.2.2.2. Derived Requirements 193 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F29 195 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 197 4.2.3. Simple Video Communication Service, global service provider 199 4.2.3.1. Description 201 This use-case is almost identical to the Simple Video Communication 202 Service use-case (Section 4.2.1). 204 What is added is that the service provider is operating over large 205 geographical areas (or even globally). 207 Assuming that ICE will be used, this means that the service provider 208 would like to be able to provide several STUN and TURN servers (via 209 the app) to the browser; selection of which one(s) to use is part of 210 the ICE processing. Other reasons for wanting to provide several 211 STUN and TURN servers include support for IPv4 and IPv6, load 212 balancing and redundancy. 214 Note that the additional requirements derived are termed FaI/AaI 215 where aI means "assuming ICE". 217 4.2.3.2. Derived Requirements 219 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28 221 FaI1 223 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 225 AaI1 227 4.2.4. Simple Video Communication Service, enterprise aspects 228 4.2.4.1. Description 230 This use-case is similar to the Simple Video Communication Service 231 use-case (Section 4.2.1). 233 What is added is aspects when using the service in enterprises. ICE 234 is assumed in the further description of this use-case. 236 An enterprise that uses a RTCWEB based web application for 237 communication desires to audit all RTCWEB based application session 238 used from inside the company towards any external peer. To be able 239 to do this they deploy a TURN server that straddle the boundary 240 between the internal network and the external. 242 The firewall will block all attempts to use STUN with an external 243 destination unless they go to the enterprise auditing TURN server. 244 In cases where employees are using RTCWEB applications provided by an 245 external service provider they still want to have the traffic to stay 246 inside their internal network and in addition not load the straddling 247 TURN server, thus they deploy a STUN server allowing the RTCWEB 248 client to determine its server reflexive address on the internal 249 side. Thus enabling cases where peers are both on the internal side 250 to connect without the traffic leaving the internal network. It must 251 be possibele to configure the browsers used in the enterprise with 252 network specific STUN and TURN servers. This should be possible to 253 achieve by autoconfiguration methods. The RTCWEB functionality will 254 need to utilize both network specific STUN and TURN resources and 255 STUN and TURN servers provisioned by the web application. 257 Note that the additional requirements derived are termed FaI/AaI 258 where aI means "assuming ICE". 260 4.2.4.2. Derived Requirements 262 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28 264 FaI2 266 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 268 4.2.5. Simple Video Communication Service, access change 270 4.2.5.1. Description 272 This use-case is almost identical to the Simple Video Communication 273 Service use-case (Section 4.2.1).The difference is that the user 274 changes network access during the session: 276 The communication device used by one of the users have several 277 network adapters (Ethernet, WiFi, Cellular). The communication 278 device is accessing the Internet using Ethernet, but the user has to 279 start a trip during the session. The communication device 280 automatically changes to use WiFi when the Ethernet cable is removed 281 and then moves to cellular access to the Internet when moving out of 282 WiFi coverage. The session continues even though the access method 283 changes. 285 4.2.5.2. Derived Requirements 287 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F26, F28 289 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 291 4.2.6. Simple Video Communication Service, QoS 293 4.2.6.1. Description 295 This use-case is almost identical to the Simple Video Communication 296 Service, access change use-case (Section 4.2.5). The use of Quality 297 of Service (QoS) capabilities is added: 299 The user in the previous use case that starts a trip is behind a 300 common residential router that supports prioritization of traffic. 301 In addition, the user's provider of cellular access has QoS support 302 enabled. The user is able to take advantage of the QoS support both 303 when accessing via the residential router and when using cellular. 305 4.2.6.2. Derived Requirements 307 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F24, F25, F26, F28 309 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 311 4.2.7. Simple Video Communication Service with sharing 313 4.2.7.1. Description 315 This use-case has the audio and video communication of the Simple 316 Video Communication Service use-case (Section 4.2.1). 318 But in addition to this, one of the users can share what is being 319 displayed on her/his screen with a peer. The user can choose to 320 share the entire screen, part of the screen (part selected by the 321 user) or what a selected applicaton displays with the peer. 323 4.2.7.2. Derived Requirements 325 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F30 327 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A21 329 4.2.8. Simple video communication service with inter-operator calling 331 4.2.8.1. Description 333 Two users have logged into two different web applications, provided 334 by different service providers. 336 The service providers are interconnected by some means, but exchange 337 no more information about the users than what can be carried using 338 SIP. 340 NOTE: More profiling of what this means may be needed. 342 For each user Alice who has authorized another user Bob to receive 343 login status information, Alice's service publishes Alice's login 344 status information to Bob. How this authorization is defined and 345 established is out of scope. 347 The same functionality as in the the Simple Video Communication 348 Service use-case (Section 4.2.1) is available. 350 The same issues with connectivity apply. 352 4.2.8.2. Derived requirements 354 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F27, F28 356 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A20 358 4.2.9. Hockey Game Viewer 360 4.2.9.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 video communication. Only the rear facing 372 camera of the mobile phone is used. On the display of the mobile 373 phone, the video of the club manager is shown with a picture-in- 374 picture thumbnail of the rear facing camera (self-view). On the 375 display of the desktop, the video of the talent scout is shown with a 376 picture-in-picture thumbnail of the desktop camera (self-view). 378 When the game is on-going, the talent scout activates the use of the 379 front facing camera, and that stream is sent to the desktop (the 380 stream from the rear facing camera continues to be sent all the 381 time). The video stream captured by the front facing camera (that is 382 capturing the game) of the mobile phone is shown in a big window on 383 the desktop screen, with picture-in-picture thumbnails of the rear 384 facing camera and the desktop camera (self-view). On the display of 385 the mobile phone the game is shown (front facing camera) with 386 picture-in-picture thumbnails of the rear facing camera (self-view) 387 and the desktop camera. 389 It is essential that the communication cannot be eavesdropped. 391 4.2.9.2. Derived Requirements 393 F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F20 395 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A17 397 4.2.10. Multiparty video communication 399 4.2.10.1. Description 401 In this use-case is the Simple Video Communication Service use-case 402 (Section 4.2.1) is extended by allowing multiparty sessions. No 403 central server is involved - the browser of each participant sends 404 and receives streams to and from all other session participants. The 405 web application in the browser of each user is responsible for 406 setting up streams to all receivers. 408 In order to enhance intelligibility, the web application pans the 409 audio from different participants differently when rendering the 410 audio. This is done automatically, but users can change how the 411 different participants are placed in the (virtual) room. In addition 412 the levels in the audio signals are adjusted before mixing. 414 Another feature intended to enhance the use experience is that the 415 video window that displays the video of the currently speaking peer 416 is highlighted. 418 Each video stream received is by default displayed in a thumbnail 419 frame within the browser, but users can change the display size. 421 It is essential that the communication cannot be eavesdropped. 423 Note: What this use-case adds in terms of requirements is 424 capabilities to send streams to and receive streams from several 425 peers concurrently, as well as the capabilities to render the video 426 from all recevied streams and be able to spatialize, level adjust and 427 mix the audio from all received streams locally in the browser. It 428 also adds the capability to measure the audio level/activity. 430 4.2.10.2. Derived Requirements 432 F1, F2, F3, F4, F5, F6, F8, F9, F10, F11, F12, F13, F14, F15, F16, 433 F17, F20, F25 435 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, 436 A16, A17 438 4.2.11. Multiparty on-line game with voice communication 440 4.2.11.1. Description 442 This use case is based on the previous one. In this use-case, the 443 voice part of the multiparty video communication use case is used in 444 the context of an on-line game. The received voice audio media is 445 rendered together with game sound objects. For example, the sound of 446 a tank moving from left to right over the screen must be rendered and 447 played to the user together with the voice media. 449 Quick updates of the game state is required. 451 It is essential that the communication cannot be eavesdropped. 453 Note: the difference regarding local audio processing compared to the 454 "Multiparty video communication" use-case is that other sound objects 455 than the streams must be possible to be included in the 456 spatialization and mixing. "Other sound objects" could for example 457 be a file with the sound of the tank; that file could be stored 458 locally or remotely. 460 4.2.11.2. Derived Requirements 462 F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13, F14, F15, F16, F18, 463 F20, F23 465 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, 466 A17, A18 468 4.2.12. Distributed Music Band 470 4.2.12.1. Description 472 In this use-case, a music band is playing music while the members are 473 at different physical locations. No central server is used, instead 474 all streams are set up in a mesh fashion. 476 Discussion: This use-case was briefly discussed at the Quebec webrtc 477 meeting and it got support. So far the only concrete requirement 478 (A17) derived is that the application must be able to ask the browser 479 to treat the audio signal as audio (in contrast to speech). However, 480 the use case should be further analysed to determine other 481 requirements (could be e.g. on delay mic->speaker, level control of 482 audio signals, etc.). 484 4.2.12.2. Derived Requirements 486 F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13, F14, F15, F16 488 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, 489 A19 491 4.3. Browser - GW/Server use cases 493 4.3.1. Telephony terminal 495 4.3.1.1. Description 497 A mobile telephony operator allows its customers to use a web browser 498 to access their services. After a simple log in the user can place 499 and receive calls in the same way as when using a normal mobile 500 phone. When a call is received or placed, the identity is shown in 501 the same manner as when a mobile phone is used. 503 It is essential that the communication cannot be eavesdropped. 505 Note: With "place and receive calls in the same way as when using a 506 normal mobile phone" it is meant that you can dial a number, and that 507 your mobile telephony operator has made available your phone contacts 508 on line, so they are available and can be clicked to call, and be 509 used to present the identity of an incoming call. If the callee is 510 not in your phone contacts the number is displayed. Furthermore, 511 your call logs are available, and updated with the calls made/ 512 received from the browser. And for people receiving calls made from 513 the web browser the usual identity (i.e. the phone number of the 514 mobile phone) will be presented. 516 4.3.1.2. Derived Requirements 518 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21 520 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12 522 4.3.2. Fedex Call 524 4.3.2.1. Description 526 Alice uses her web browser with a service something like Skype to be 527 able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should 528 be able to hear the initial prompts from the fedex IVR and when the 529 IVR says press 1, there should be a way for Alice to navigate the 530 IVR. 532 4.3.2.2. Derived Requirements 534 F1, F2, F3, F4, F5, F6, F8, F9, F10, F21, F22 536 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12 538 4.3.3. Video conferencing system with central server 540 4.3.3.1. Description 542 An organization uses a video communication system that supports the 543 establishment of multiparty video sessions using a central conference 544 server. 546 The browser of each participant send an audio stream (type in terms 547 of mono, stereo, 5.1, ... depending on the equipment of the 548 participant) to the central server. The central server mixes the 549 audio streams (and can in the mixing process naturally add effects 550 such as spatialization) and sends towards each participant a mixed 551 audio stream which is played to the user. 553 The browser of each participant sends video towards the server. For 554 each participant one high resolution video is displayed in a large 555 window, while a number of low resolution videos are displayed in 556 smaller windows. The server selects what video streams to be 557 forwarded as main- and thumbnail videos respectively, based on speech 558 activity. As the video streams to display can change quite 559 frequently (as the conversation flows) it is important that the delay 560 from when a video stream is selected for display until the video can 561 be displayed is short. 563 The organization has an internal network set up with an aggressive 564 firewall handling access to the Internet. If users cannot physically 565 access the internal network, they can establish a Virtual Private 566 Network (VPN). 568 It is essential that the communication cannot be eavesdropped. 570 All participants are authenticated by the central server, and 571 authorized to connect to the central server. The participants are 572 identified to each other by the central server, and the participants 573 do not have access to each others' credentials such as e-mail 574 addresses or login IDs. 576 Note: This use-case adds requirements on support for fast stream 577 switches F7, on encryption of media and on ability to traverse very 578 restrictive FWs. There exist several solutions that enable the 579 server to forward one high resolution and several low resolution 580 video streams: a) each browser could send a high resolution, but 581 scalable stream, and the server could send just the base layer for 582 the low resolution streams, b) each browser could in a simulcast 583 fashion send one high resolution and one low resolution stream, and 584 the server just selects or c) each browser sends just a high 585 resolution stream, the server transcodes into low resolution streams 586 as required. 588 4.3.3.2. Derived Requirements 590 F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F17, F19, F20 592 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A17 594 5. Requirements 596 5.1. General 598 This section contains the requirements derived from the use-cases in 599 section 4. 601 NOTE: It is assumed that the user applications are executed on a 602 browser. Whether the capabilities to implement specific browser 603 requirements are implemented by the browser application, or are 604 provided to the browser application by the underlying operating 605 system, is outside the scope of this document. 607 5.2. Browser requirements 609 REQ-ID DESCRIPTION 610 --------------------------------------------------------------- 611 F1 The browser MUST be able to use microphones and 612 cameras as input devices to generate streams. 613 ---------------------------------------------------------------- 614 F2 The browser MUST be able to send streams to a 615 peer in the presence of NATs. 616 ---------------------------------------------------------------- 617 F3 Transmitted streams MUST be rate controlled. 618 ---------------------------------------------------------------- 619 F4 The browser MUST be able to receive, process and 620 render streams from peers. 621 ---------------------------------------------------------------- 622 F5 The browser MUST be able to render good quality 623 audio and video even in the presence of reasonable 624 levels of jitter and packet losses. 626 TBD: What is a reasonable level? 627 ---------------------------------------------------------------- 628 F6 The browser MUST be able to handle high loss and 629 jitter levels in a graceful way. 630 ---------------------------------------------------------------- 631 F7 The browser MUST support fast stream switches. 632 ---------------------------------------------------------------- 633 F8 The browser MUST detect when a stream from a 634 peer is not received anymore 635 ---------------------------------------------------------------- 636 F9 When there are both incoming and outgoing audio 637 streams, echo cancellation MUST be made available to 638 avoid disturbing echo during conversation. 640 QUESTION: How much control should be left to the 641 web application? 642 ---------------------------------------------------------------- 643 F10 The browser MUST support synchronization of 644 audio and video. 646 QUESTION: How much control should be left to the 647 web application? 648 ---------------------------------------------------------------- 649 F11 The browser MUST be able to transmit streams to 650 several peers concurrently. 651 ---------------------------------------------------------------- 652 F12 The browser MUST be able to receive streams from 653 multiple peers concurrently. 654 ---------------------------------------------------------------- 655 F13 The browser MUST be able to apply spatialization 656 effects to audio streams. 658 ---------------------------------------------------------------- 659 F14 The browser MUST be able to measure the level 660 in audio streams. 661 ---------------------------------------------------------------- 662 F15 The browser MUST be able to change the level 663 in audio streams. 664 ---------------------------------------------------------------- 665 F16 The browser MUST be able to render several 666 concurrent video streams 667 ---------------------------------------------------------------- 668 F17 The browser MUST be able to mix several 669 audio streams. 670 ---------------------------------------------------------------- 671 F18 The browser MUST be able to process and mix 672 sound objects (media that is retrieved from another 673 source than the established media stream(s) with the 674 peer(s) with audio streams. 675 ---------------------------------------------------------------- 676 F19 Streams MUST be able to pass through restrictive 677 firewalls. 678 ---------------------------------------------------------------- 679 F20 It MUST be possible to protect streams from 680 eavesdropping. 681 ---------------------------------------------------------------- 682 F21 The browser MUST support an audio media format 683 (codec) that is commonly supported by existing 684 telephony services. 686 QUESTION: G.711? 687 ---------------------------------------------------------------- 688 F22 There should be a way to navigate 689 the IVR 690 ---------------------------------------------------------------- 691 F23 The browser must be able to send short 692 latency datagram traffic to a peer browser 693 ---------------------------------------------------------------- 694 F24 The browser MUST be able to take advantage of 695 capabilities to prioritize voice and video 696 appropriately. 697 ---------------------------------------------------------------- 698 F25 The browser SHOULD use encoding of streams 699 suitable for the current rendering (e.g. 700 video display size) and SHOULD change parameters 701 if the rendering changes during the session 702 ---------------------------------------------------------------- 703 F26 It MUST be possible to move from one network 704 interface to another one 705 ---------------------------------------------------------------- 706 F27 The browser MUST be able to initiate and accept a 707 media session where the data needed for establishment 708 can be carried in SIP. 709 ---------------------------------------------------------------- 710 F28 The browser MUST support a baseline audio and 711 video codec 712 ---------------------------------------------------------------- 713 F29 The browser MUST be able to send streams to a 714 peer in the presence of NATs that block UDP traffic. 715 ---------------------------------------------------------------- 716 F30 The browser MUST be able to use the screen (or 717 a specific area of the screen) or what a certain 718 application displays on the screen to generate 719 streams. 720 ---------------------------------------------------------------- 721 FaI1 The browser MUST be able to use several STUN 722 and TURN servers 723 ---------------------------------------------------------------- 724 FaI2 There browser MUST support that STUN and TURN 725 servers to use are supplied by other entities than 726 the service provided (i.e. the network provider) 727 ---------------------------------------------------------------- 729 5.3. API requirements 731 REQ-ID DESCRIPTION 732 ---------------------------------------------------------------- 733 A1 The Web API MUST provide means for the 734 application to ask the browser for permission 735 to use cameras and microphones as input devices. 736 ---------------------------------------------------------------- 737 A2 The Web API MUST provide means for the web 738 application to control how streams generated 739 by input devices are used. 740 ---------------------------------------------------------------- 741 A3 The Web API MUST provide means for the web 742 application to control the local rendering of 743 streams (locally generated streams and streams 744 received from a peer). 745 ---------------------------------------------------------------- 746 A4 The Web API MUST provide means for the web 747 application to initiate sending of 748 stream/stream components to a peer. 749 ---------------------------------------------------------------- 750 A5 The Web API MUST provide means for the web 751 application to control the media format (codec) 752 to be used for the streams sent to a peer. 754 NOTE: The level of control depends on whether 755 the codec negotiation is handled by the browser 756 or the web application. 757 ---------------------------------------------------------------- 758 A6 The Web API MUST provide means for the web 759 application to modify the media format for 760 streams sent to a peer after a media stream 761 has been established. 762 ---------------------------------------------------------------- 763 A7 The Web API MUST provide means for 764 informing the web application of whether the 765 establishment of a stream with a peer was 766 successful or not. 767 ---------------------------------------------------------------- 768 A8 The Web API MUST provide means for the web 769 application to mute/unmute a stream or stream 770 component(s). When a stream is sent to a peer 771 mute status must be preserved in the stream 772 received by the peer. 773 ---------------------------------------------------------------- 774 A9 The Web API MUST provide means for the web 775 application to cease the sending of a stream 776 to a peer. 777 ---------------------------------------------------------------- 778 A10 The Web API MUST provide means for the web 779 application to cease processing and rendering 780 of a stream received from a peer. 781 ---------------------------------------------------------------- 782 A11 The Web API MUST provide means for 783 informing the web application when a 784 stream from a peer is no longer received. 785 ---------------------------------------------------------------- 786 A12 The Web API MUST provide means for 787 informing the web application when high 788 loss rates occur. 789 ---------------------------------------------------------------- 790 A13 The Web API MUST provide means for the web 791 application to apply spatialization effects to 792 audio streams. 793 ---------------------------------------------------------------- 794 A14 The Web API MUST provide means for the web 795 application to detect the level in audio 796 streams. 797 ---------------------------------------------------------------- 798 A15 The Web API MUST provide means for the web 799 application to adjust the level in audio 800 streams. 801 ---------------------------------------------------------------- 802 A16 The Web API MUST provide means for the web 803 application to mix audio streams. 804 ---------------------------------------------------------------- 805 A17 For each stream generated, the Web API MUST provide 806 an identifier that is accessible by the application. 807 The identifier MUST be accessible also for a peer 808 receiving that stream and MUST be unique relative 809 to all other stream identifiers in use by either party. 810 ---------------------------------------------------------------- 811 A18 In addition to the streams listed elsewhere, 812 the Web API MUST provide a mechanism for sending 813 and receiving isolated discrete chunks of data. 814 ---------------------------------------------------------------- 815 A19 The Web API MUST provide means for the web 816 application indicate the type of audio signal 817 (speech, audio)for audio stream(s)/stream component(s). 818 ---------------------------------------------------------------- 819 A20 It must be possible for an initiator or a 820 responder Web application to indicate the types 821 of media he's willing to accept incoming streams 822 for when setting up a connection (audio, video, 823 other). The types of media he's willing to accept 824 can be a subset of the types of media the browser 825 is able to accept. 826 ---------------------------------------------------------------- 827 A21 The Web API MUST provide means for the 828 application to ask the browser for permission 829 to the screen, a certain area on the screen 830 or what a certain application displays on the 831 screen as input to streams. 832 ---------------------------------------------------------------- 833 AaI1 The Web API MUST provide means for the 834 application to specify several STUN and/or 835 TURN servers to use. 836 ---------------------------------------------------------------- 838 6. IANA Considerations 840 TBD 842 7. Security Considerations 844 7.1. Introduction 846 A malicious web application might use the browser to perform Denial 847 Of Service (DOS) attacks on NAT infrastructure, or on peer devices. 849 Also, a malicious web application might silently establish outgoing, 850 and accept incoming, streams on an already established connection. 852 Based on the identified security risks, this section will describe 853 security considerations for the browser and web application. 855 7.2. Browser Considerations 857 The browser is expected to provide mechanisms for getting user 858 consent to use device resources such as camera and microphone. 860 The browser is expected to provide mechanisms for informing the user 861 that device resources such as camera and microphone are in use 862 ("hot"). 864 The browser is expected to provide mechanisms for users to revise and 865 even completely revoke consent to use device resources such as camera 866 and microphone. 868 The browser is expected to provide mechanisms for getting user 869 consent to use the screen (or a certain part of it) or what a certain 870 application displays on the screen as source for streams. 872 The browser is expected to provide mechanisms for informing the user 873 that the screen, part thereof or an application is serving as a 874 stream source ("hot"). 876 The browser is expected to provide mechanisms for users to revise and 877 even completely revoke consent to use the screen, part thereof or an 878 application is serving as a stream source. 880 The browser is expected to provide mechanisms in order to assure that 881 streams are the ones the recipient intended to receive. 883 The browser needs to ensure that media is not sent, and that received 884 media is not rendered, until the associated stream establishment and 885 handshake procedures with the remote peer have been successfully 886 finished. 888 The browser needs to ensure that the stream negotiation procedures 889 are not seen as Denial Of Service (DOS) by other entities. 891 7.3. Web Application Considerations 893 The web application is expected to ensure user consent in sending and 894 receiving media streams. 896 8. Additional use-cases 898 Several additional use-cases have been discussed. At this point 899 these use-cases are not included as requirement deriving use-cases 900 for different reasons (lack of documentation, overlap with existing 901 use-cases, lack of consensus). For completeness these additional 902 use-cases are listed below: 903 1. Use-cases regarding different situations when being invited to a 904 "session", e.g. browser open, browser open but another tab 905 active, browser open but active in session, browser closed, .... 906 (Matthew Kaufman); discussed at webrtc meeting 907 2. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/rtcweb/ 908 current/msg00525.html, followed up by Stephan Wenger 909 3. Local Recording and Remote recording (John): Discussed a _lot_ on 910 the mail lists (rtcweb as well as public-webrtc) lAugust and 911 September 2011. Concrete proposal: 912 http://www.ietf.org/mail-archive/web/rtcweb/current/msg01006.html 913 (remote) and 914 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00734.html 915 (local) 916 4. Emergency access for disabled (Bernard Aboba) 917 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html 918 5. Clue use-cases (Roni Even) http://tools.ietf.org/html/ 919 draft-ietf-clue-telepresence-use-cases-01 920 6. Rohan red cross (Cullen Jennings); 921 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00323.html 922 7. Security camera/baby monitor usage 923 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00543.html 924 8. Large multiparty session 925 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00530.html 927 9. Acknowledgements 929 Dan Burnett has reviewed and proposed a lot of things that enhances 930 the document. Most of this has been incorporated in rev -05. 932 Stephan Wenger has provided a lot of useful input and feedback, as 933 well as editorial comments. 935 Harald Alvestrand and Ted Hardie have provided comments and feedback 936 on the draft. 938 Harald Alvestrand and Cullen Jennings have provided additional use- 939 cases. 941 Thank You to everyone in the RTCWEB community that have provided 942 comments, feedback and improvement proposals on the draft content. 944 10. Change Log 946 [RFC EDITOR NOTE: Please remove this section when publishing] 948 Changes from draft-ietf-rtcweb-use-cases-and-requirements-05 950 o Added use-case "global service provider", derived reqs associated 951 with several STUN/TURN servers 952 o Added use-case "enterprise aspects", derived req associated with 953 enabling the network provider to supply STUN and TURN servers 954 o The requirements from the above are ICE specific and labeled 955 accordingly 956 o Separated the requirements phrased like "processing such as pan, 957 mix and render" for audio to be specific reqs on spatialization, 958 level measurement, level adjustment and mixing (discussed on the 959 lists in 960 http://www.ietf.org/mail-archive/web/rtcweb/current/msg01648.html 961 and http://lists.w3.org/Archives/Public/public-webrtc/2011Sep/ 962 0102.html) 963 o Added use-case on sharing as decided in 964 http://www.ietf.org/mail-archive/web/rtcweb/current/msg01700.html, 965 derived reqs F30 and A21 966 o Added the list of common considerations proposed in mail 967 http://www.ietf.org/mail-archive/web/rtcweb/current/msg01562.html 968 to the Introduction of the use-case section 970 Changes from draft-ietf-rtcweb-use-cases-and-requirements-04 972 o Most changes based on the input from Dan Burnett 973 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00948.html 974 o Many editorial changes 975 o 4.2.1.1 Clarified 976 o Some clarification added to 4.3.1.1 as a note 977 o F-requirements updated (see reply to Dan's mail). 978 o Almost all A-requirements updated to start "The Web API MUST 979 provide ..." 980 o A8 removed, A9 rephrased to cover A8 and old A9 981 o A15 rephrased 982 o For more details, and discussion, look att the response to Dan's 983 mail 984 http://www.ietf.org/mail-archive/web/rtcweb/current/msg01177.html 986 Changes from draft-ietf-rtcweb-use-cases-and-requirements-03 988 o Editorials 989 o Changed when the self-view is displayed in 4.2.1.1, and added 990 words about allowing users to remove and re-insert it. 992 o Clarified 4.2.6.1 993 o Removed the "mono" stuff from 4.2.7.1 994 o Added that communication should not be possible to eavesdrop to 995 most use cases - and req. F17 996 o Re-phrased 4.3.3.1 to not describe the technical solution so much, 997 and removed "stereo" stuff. Solution possibilities are now in a 998 note. 999 o Re-inserted API requirements after discussion in the W3C webrtc 1000 WG. (Re-phrased A15 and added A18 compared to version -02). 1002 Changes from draft-ietf-rtcweb-use-cases-and-requirements-02 1004 o Removed desrciption/list of API requirements, instead 1005 o Reference to W3C webrtc_reqs document for API requirements 1007 Changes from draft-ietf-rtcweb-ucreqs-01 1009 o Changed Intended status to Information 1010 o Changed "Ipr" to "trust200902" 1011 o Added use case "Simple video communication service, NAT/FW that 1012 blocks UDP", and derived new req F26 1013 o Added use case "Distributed Music Band" and derived new req A17 1014 o Added F24 as requirement derived from use case "Simple video 1015 communication service with inter-operator calling" 1016 o Added section "Additional use cases" 1017 o Added text about ID handling to multiparty with central server use 1018 case 1019 o Re-phrased A1 slightly 1021 Changes from draft-ietf-rtcweb-ucreqs-00 1023 o - Reshuffled: Just two main groups of use cases (b2b and b2GW/ 1024 Server); removed some specific use cases and added them instead as 1025 flavors to the base use case (Simple video communciation) 1026 o - Changed the fromulation of F19 1027 o - Removed the requirement on an API for DTMF 1028 o - Removed "FX3: There SHOULD be a mapping of the minimum needed 1029 data for setting up connections into SIP, so that the restriction 1030 to SIP-carriable data can be verified. Not a rew on the browser 1031 but rather on a document" 1032 o - (see 1033 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00227.html 1034 for more details) 1035 o -Added text on informing user of that mic/cam is being used and 1036 that it must be possible to revoce permission to use them in 1037 section 7. 1038 Changes from draft-holmberg-rtcweb-ucreqs-01 1039 o - Draft name changed to draft-ietf-rtcweb-ucreqs 1040 o - Use-case grouping introduced 1041 o - Additional use-cases added 1042 o - Additional reqs added (derived from use cases): F19-F25, A16-A17 1044 Changes from draft-holmberg-rtcweb-ucreqs-00 1045 o - Mapping between use-cases and requirements added (Harald 1046 Alvestrand, 090311) 1047 o - Additional security considerations text (Harald Alvestrand, 1048 090311) 1049 o - Clarification that user applications are assumed to be executed 1050 by a browser (Ted Hardie, 080311) 1051 o - Editorial corrections and clarifications 1053 11. References 1055 11.1. Normative References 1057 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1058 Requirement Levels", BCP 14, RFC 2119, March 1997. 1060 11.2. Informative References 1062 [webrtc_reqs] 1063 "Webrt requirements, 1064 http://dev.w3.org/2011/webrtc/editor/webrtc_reqs.html". 1066 Authors' Addresses 1068 Christer Holmberg 1069 Ericsson 1070 Hirsalantie 11 1071 Jorvas 02420 1072 Finland 1074 Email: christer.holmberg@ericsson.com 1076 Stefan Hakansson 1077 Ericsson 1078 Laboratoriegrand 11 1079 Lulea 97128 1080 Sweden 1082 Email: stefan.lk.hakansson@ericsson.com 1083 Goran AP Eriksson 1084 Ericsson 1085 Farogatan 6 1086 Stockholm 16480 1087 Sweden 1089 Email: goran.ap.eriksson@ericsson.com