idnits 2.17.1 draft-ietf-rtcweb-use-cases-and-requirements-07.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 (April 2, 2012) is 4404 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: October 4, 2012 Ericsson 6 April 2, 2012 8 Web Real-Time Communication Use-cases and Requirements 9 draft-ietf-rtcweb-use-cases-and-requirements-07.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 October 4, 2012. 35 Copyright Notice 37 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . 10 74 4.3. Browser - GW/Server use cases . . . . . . . . . . . . . . 11 75 4.3.1. Telephony terminal . . . . . . . . . . . . . . . . . . 11 76 4.3.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . 18 86 7.3. Web Application Considerations . . . . . . . . . . . . . . 19 87 8. Additional use-cases . . . . . . . . . . . . . . . . . . . . . 19 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 89 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 20 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 4.2.3.2. Derived Requirements 216 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F31 218 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A22 220 4.2.4. Simple Video Communication Service, enterprise aspects 222 4.2.4.1. Description 224 This use-case is similar to the Simple Video Communication Service 225 use-case (Section 4.2.1). 227 What is added is aspects when using the service in enterprises. ICE 228 is assumed in the further description of this use-case. 230 An enterprise that uses a RTCWEB based web application for 231 communication desires to audit all RTCWEB based application session 232 used from inside the company towards any external peer. To be able 233 to do this they deploy a TURN server that straddle the boundary 234 between the internal network and the external. 236 The firewall will block all attempts to use STUN with an external 237 destination unless they go to the enterprise auditing TURN server. 238 In cases where employees are using RTCWEB applications provided by an 239 external service provider they still want to have the traffic to stay 240 inside their internal network and in addition not load the straddling 241 TURN server, thus they deploy a STUN server allowing the RTCWEB 242 client to determine its server reflexive address on the internal 243 side. Thus enabling cases where peers are both on the internal side 244 to connect without the traffic leaving the internal network. It must 245 be possibele to configure the browsers used in the enterprise with 246 network specific STUN and TURN servers. This should be possible to 247 achieve by autoconfiguration methods. The RTCWEB functionality will 248 need to utilize both network specific STUN and TURN resources and 249 STUN and TURN servers provisioned by the web application. 251 4.2.4.2. Derived Requirements 253 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F32 255 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 257 4.2.5. Simple Video Communication Service, access change 259 4.2.5.1. Description 261 This use-case is almost identical to the Simple Video Communication 262 Service use-case (Section 4.2.1).The difference is that the user 263 changes network access during the session: 265 The communication device used by one of the users have several 266 network adapters (Ethernet, WiFi, Cellular). The communication 267 device is accessing the Internet using Ethernet, but the user has to 268 start a trip during the session. The communication device 269 automatically changes to use WiFi when the Ethernet cable is removed 270 and then moves to cellular access to the Internet when moving out of 271 WiFi coverage. The session continues even though the access method 272 changes. 274 4.2.5.2. Derived Requirements 276 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F26, F28 278 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 280 4.2.6. Simple Video Communication Service, QoS 282 4.2.6.1. Description 284 This use-case is almost identical to the Simple Video Communication 285 Service, access change use-case (Section 4.2.5). The use of Quality 286 of Service (QoS) capabilities is added: 288 The user in the previous use case that starts a trip is behind a 289 common residential router that supports prioritization of traffic. 290 In addition, the user's provider of cellular access has QoS support 291 enabled. The user is able to take advantage of the QoS support both 292 when accessing via the residential router and when using cellular. 294 4.2.6.2. Derived Requirements 296 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F24, F25, F26, F28 298 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 300 4.2.7. Simple Video Communication Service with sharing 302 4.2.7.1. Description 304 This use-case has the audio and video communication of the Simple 305 Video Communication Service use-case (Section 4.2.1). 307 But in addition to this, one of the users can share what is being 308 displayed on her/his screen with a peer. The user can choose to 309 share the entire screen, part of the screen (part selected by the 310 user) or what a selected applicaton displays with the peer. 312 4.2.7.2. Derived Requirements 314 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F30 316 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A21 318 4.2.8. Simple video communication service with inter-operator calling 320 4.2.8.1. Description 322 Two users have logged into two different web applications, provided 323 by different service providers. 325 The service providers are interconnected by some means, but exchange 326 no more information about the users than what can be carried using 327 SIP. 329 NOTE: More profiling of what this means may be needed. 331 For each user Alice who has authorized another user Bob to receive 332 login status information, Alice's service publishes Alice's login 333 status information to Bob. How this authorization is defined and 334 established is out of scope. 336 The same functionality as in the the Simple Video Communication 337 Service use-case (Section 4.2.1) is available. 339 The same issues with connectivity apply. 341 4.2.8.2. Derived requirements 343 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F27, F28 345 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A20 347 4.2.9. Hockey Game Viewer 349 4.2.9.1. Description 351 An ice-hockey club uses an application that enables talent scouts to, 352 in real-time, show and discuss games and players with the club 353 manager. The talent scouts use a mobile phone with two cameras, one 354 front facing and one rear facing. 356 The club manager uses a desktop, equipped with one camera, for 357 viewing the game and discussing with the talent scout. 359 Before the game starts, and during game breaks, the talent scout and 360 the manager have a 1-1 video communication. Only the rear facing 361 camera of the mobile phone is used. On the display of the mobile 362 phone, the video of the club manager is shown with a picture-in- 363 picture thumbnail of the rear facing camera (self-view). On the 364 display of the desktop, the video of the talent scout is shown with a 365 picture-in-picture thumbnail of the desktop camera (self-view). 367 When the game is on-going, the talent scout activates the use of the 368 front facing camera, and that stream is sent to the desktop (the 369 stream from the rear facing camera continues to be sent all the 370 time). The video stream captured by the front facing camera (that is 371 capturing the game) of the mobile phone is shown in a big window on 372 the desktop screen, with picture-in-picture thumbnails of the rear 373 facing camera and the desktop camera (self-view). On the display of 374 the mobile phone the game is shown (front facing camera) with 375 picture-in-picture thumbnails of the rear facing camera (self-view) 376 and the desktop camera. 378 It is essential that the communication cannot be eavesdropped. 380 4.2.9.2. Derived Requirements 382 F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F20 384 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A17 386 4.2.10. Multiparty video communication 388 4.2.10.1. Description 390 In this use-case is the Simple Video Communication Service use-case 391 (Section 4.2.1) is extended by allowing multiparty sessions. No 392 central server is involved - the browser of each participant sends 393 and receives streams to and from all other session participants. The 394 web application in the browser of each user is responsible for 395 setting up streams to all receivers. 397 In order to enhance intelligibility, the web application pans the 398 audio from different participants differently when rendering the 399 audio. This is done automatically, but users can change how the 400 different participants are placed in the (virtual) room. In addition 401 the levels in the audio signals are adjusted before mixing. 403 Another feature intended to enhance the use experience is that the 404 video window that displays the video of the currently speaking peer 405 is highlighted. 407 Each video stream received is by default displayed in a thumbnail 408 frame within the browser, but users can change the display size. 410 It is essential that the communication cannot be eavesdropped. 412 Note: What this use-case adds in terms of requirements is 413 capabilities to send streams to and receive streams from several 414 peers concurrently, as well as the capabilities to render the video 415 from all recevied streams and be able to spatialize, level adjust and 416 mix the audio from all received streams locally in the browser. It 417 also adds the capability to measure the audio level/activity. 419 4.2.10.2. Derived Requirements 421 F1, F2, F3, F4, F5, F6, F8, F9, F10, F11, F12, F13, F14, F15, F16, 422 F17, F20, F25 424 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, 425 A16, A17 427 4.2.11. Multiparty on-line game with voice communication 429 4.2.11.1. Description 431 This use case is based on the previous one. In this use-case, the 432 voice part of the multiparty video communication use case is used in 433 the context of an on-line game. The received voice audio media is 434 rendered together with game sound objects. For example, the sound of 435 a tank moving from left to right over the screen must be rendered and 436 played to the user together with the voice media. 438 Quick updates of the game state is required. 440 It is essential that the communication cannot be eavesdropped. 442 Note: the difference regarding local audio processing compared to the 443 "Multiparty video communication" use-case is that other sound objects 444 than the streams must be possible to be included in the 445 spatialization and mixing. "Other sound objects" could for example 446 be a file with the sound of the tank; that file could be stored 447 locally or remotely. 449 4.2.11.2. Derived Requirements 451 F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13, F14, F15, F16, F18, 452 F20, F23 454 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, 455 A17, A18 457 4.2.12. Distributed Music Band 459 4.2.12.1. Description 461 In this use-case, a music band is playing music while the members are 462 at different physical locations. No central server is used, instead 463 all streams are set up in a mesh fashion. 465 Discussion: This use-case was briefly discussed at the Quebec webrtc 466 meeting and it got support. So far the only concrete requirement 467 (A17) derived is that the application must be able to ask the browser 468 to treat the audio signal as audio (in contrast to speech). However, 469 the use case should be further analysed to determine other 470 requirements (could be e.g. on delay mic->speaker, level control of 471 audio signals, etc.). 473 4.2.12.2. Derived Requirements 475 F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13, F14, F15, F16 477 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, 478 A19 480 4.3. Browser - GW/Server use cases 482 4.3.1. Telephony terminal 484 4.3.1.1. Description 486 A mobile telephony operator allows its customers to use a web browser 487 to access their services. After a simple log in the user can place 488 and receive calls in the same way as when using a normal mobile 489 phone. When a call is received or placed, the identity is shown in 490 the same manner as when a mobile phone is used. 492 It is essential that the communication cannot be eavesdropped. 494 Note: With "place and receive calls in the same way as when using a 495 normal mobile phone" it is meant that you can dial a number, and that 496 your mobile telephony operator has made available your phone contacts 497 on line, so they are available and can be clicked to call, and be 498 used to present the identity of an incoming call. If the callee is 499 not in your phone contacts the number is displayed. Furthermore, 500 your call logs are available, and updated with the calls made/ 501 received from the browser. And for people receiving calls made from 502 the web browser the usual identity (i.e. the phone number of the 503 mobile phone) will be presented. 505 4.3.1.2. Derived Requirements 507 F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21 509 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12 511 4.3.2. Fedex Call 513 4.3.2.1. Description 515 Alice uses her web browser with a service something like Skype to be 516 able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should 517 be able to hear the initial prompts from the fedex IVR and when the 518 IVR says press 1, there should be a way for Alice to navigate the 519 IVR. 521 4.3.2.2. Derived Requirements 523 F1, F2, F3, F4, F5, F6, F8, F9, F10, F21, F22 525 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12 527 4.3.3. Video conferencing system with central server 529 4.3.3.1. Description 531 An organization uses a video communication system that supports the 532 establishment of multiparty video sessions using a central conference 533 server. 535 The browser of each participant send an audio stream (type in terms 536 of mono, stereo, 5.1, ... depending on the equipment of the 537 participant) to the central server. The central server mixes the 538 audio streams (and can in the mixing process naturally add effects 539 such as spatialization) and sends towards each participant a mixed 540 audio stream which is played to the user. 542 The browser of each participant sends video towards the server. For 543 each participant one high resolution video is displayed in a large 544 window, while a number of low resolution videos are displayed in 545 smaller windows. The server selects what video streams to be 546 forwarded as main- and thumbnail videos respectively, based on speech 547 activity. As the video streams to display can change quite 548 frequently (as the conversation flows) it is important that the delay 549 from when a video stream is selected for display until the video can 550 be displayed is short. 552 The organization has an internal network set up with an aggressive 553 firewall handling access to the Internet. If users cannot physically 554 access the internal network, they can establish a Virtual Private 555 Network (VPN). 557 It is essential that the communication cannot be eavesdropped. 559 All participants are authenticated by the central server, and 560 authorized to connect to the central server. The participants are 561 identified to each other by the central server, and the participants 562 do not have access to each others' credentials such as e-mail 563 addresses or login IDs. 565 Note: This use-case adds requirements on support for fast stream 566 switches F7, on encryption of media and on ability to traverse very 567 restrictive FWs. There exist several solutions that enable the 568 server to forward one high resolution and several low resolution 569 video streams: a) each browser could send a high resolution, but 570 scalable stream, and the server could send just the base layer for 571 the low resolution streams, b) each browser could in a simulcast 572 fashion send one high resolution and one low resolution stream, and 573 the server just selects or c) each browser sends just a high 574 resolution stream, the server transcodes into low resolution streams 575 as required. 577 4.3.3.2. Derived Requirements 579 F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F17, F19, F20 581 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A17 583 5. Requirements 585 5.1. General 587 This section contains the requirements derived from the use-cases in 588 section 4. 590 NOTE: It is assumed that the user applications are executed on a 591 browser. Whether the capabilities to implement specific browser 592 requirements are implemented by the browser application, or are 593 provided to the browser application by the underlying operating 594 system, is outside the scope of this document. 596 5.2. Browser requirements 598 REQ-ID DESCRIPTION 599 --------------------------------------------------------------- 600 F1 The browser MUST be able to use microphones and 601 cameras as input devices to generate streams. 602 ---------------------------------------------------------------- 603 F2 The browser MUST be able to send streams to a 604 peer in the presence of NATs. 605 ---------------------------------------------------------------- 606 F3 Transmitted streams MUST be rate controlled. 607 ---------------------------------------------------------------- 608 F4 The browser MUST be able to receive, process and 609 render streams from peers. 610 ---------------------------------------------------------------- 611 F5 The browser MUST be able to render good quality 612 audio and video even in the presence of reasonable 613 levels of jitter and packet losses. 615 TBD: What is a reasonable level? 616 ---------------------------------------------------------------- 617 F6 The browser MUST be able to handle high loss and 618 jitter levels in a graceful way. 619 ---------------------------------------------------------------- 620 F7 The browser MUST support fast stream switches. 621 ---------------------------------------------------------------- 622 F8 The browser MUST detect when a stream from a 623 peer is not received anymore 624 ---------------------------------------------------------------- 625 F9 When there are both incoming and outgoing audio 626 streams, echo cancellation MUST be made available to 627 avoid disturbing echo during conversation. 629 QUESTION: How much control should be left to the 630 web application? 631 ---------------------------------------------------------------- 632 F10 The browser MUST support synchronization of 633 audio and video. 635 QUESTION: How much control should be left to the 636 web application? 637 ---------------------------------------------------------------- 638 F11 The browser MUST be able to transmit streams to 639 several peers concurrently. 640 ---------------------------------------------------------------- 641 F12 The browser MUST be able to receive streams from 642 multiple peers concurrently. 643 ---------------------------------------------------------------- 644 F13 The browser MUST be able to apply spatialization 645 effects to audio streams. 646 ---------------------------------------------------------------- 647 F14 The browser MUST be able to measure the level 648 in audio streams. 649 ---------------------------------------------------------------- 650 F15 The browser MUST be able to change the level 651 in audio streams. 652 ---------------------------------------------------------------- 653 F16 The browser MUST be able to render several 654 concurrent video streams 655 ---------------------------------------------------------------- 656 F17 The browser MUST be able to mix several 657 audio streams. 658 ---------------------------------------------------------------- 659 F18 The browser MUST be able to process and mix 660 sound objects (media that is retrieved from another 661 source than the established media stream(s) with the 662 peer(s) with audio streams. 663 ---------------------------------------------------------------- 664 F19 Streams MUST be able to pass through restrictive 665 firewalls. 666 ---------------------------------------------------------------- 667 F20 It MUST be possible to protect streams from 668 eavesdropping. 669 ---------------------------------------------------------------- 670 F21 The browser MUST support an audio media format 671 (codec) that is commonly supported by existing 672 telephony services. 674 QUESTION: G.711? 675 ---------------------------------------------------------------- 676 F22 There should be a way to navigate 677 the IVR 678 ---------------------------------------------------------------- 679 F23 The browser must be able to send short 680 latency datagram traffic to a peer browser 681 ---------------------------------------------------------------- 682 F24 The browser MUST be able to take advantage of 683 capabilities to prioritize voice and video 684 appropriately. 685 ---------------------------------------------------------------- 686 F25 The browser SHOULD use encoding of streams 687 suitable for the current rendering (e.g. 688 video display size) and SHOULD change parameters 689 if the rendering changes during the session 690 ---------------------------------------------------------------- 691 F26 It MUST be possible to move from one network 692 interface to another one 693 ---------------------------------------------------------------- 694 F27 The browser MUST be able to initiate and accept a 695 media session where the data needed for establishment 696 can be carried in SIP. 697 ---------------------------------------------------------------- 698 F28 The browser MUST support a baseline audio and 699 video codec 700 ---------------------------------------------------------------- 701 F29 The browser MUST be able to send streams to a 702 peer in the presence of NATs that block UDP traffic. 703 ---------------------------------------------------------------- 704 F30 The browser MUST be able to use the screen (or 705 a specific area of the screen) or what a certain 706 application displays on the screen to generate 707 streams. 708 ---------------------------------------------------------------- 709 F31 The browser MUST be able to use several STUN 710 and TURN servers 711 ---------------------------------------------------------------- 712 F32 There browser MUST support that STUN and TURN 713 servers to use are supplied by other entities than 714 the service provided (i.e. the network provider) 715 ---------------------------------------------------------------- 717 5.3. API requirements 719 REQ-ID DESCRIPTION 720 ---------------------------------------------------------------- 721 A1 The Web API MUST provide means for the 722 application to ask the browser for permission 723 to use cameras and microphones as input devices. 724 ---------------------------------------------------------------- 725 A2 The Web API MUST provide means for the web 726 application to control how streams generated 727 by input devices are used. 728 ---------------------------------------------------------------- 729 A3 The Web API MUST provide means for the web 730 application to control the local rendering of 731 streams (locally generated streams and streams 732 received from a peer). 733 ---------------------------------------------------------------- 734 A4 The Web API MUST provide means for the web 735 application to initiate sending of 736 stream/stream components to a peer. 737 ---------------------------------------------------------------- 738 A5 The Web API MUST provide means for the web 739 application to control the media format (codec) 740 to be used for the streams sent to a peer. 742 NOTE: The level of control depends on whether 743 the codec negotiation is handled by the browser 744 or the web application. 745 ---------------------------------------------------------------- 746 A6 The Web API MUST provide means for the web 747 application to modify the media format for 748 streams sent to a peer after a media stream 749 has been established. 750 ---------------------------------------------------------------- 751 A7 The Web API MUST provide means for 752 informing the web application of whether the 753 establishment of a stream with a peer was 754 successful or not. 755 ---------------------------------------------------------------- 756 A8 The Web API MUST provide means for the web 757 application to mute/unmute a stream or stream 758 component(s). When a stream is sent to a peer 759 mute status must be preserved in the stream 760 received by the peer. 761 ---------------------------------------------------------------- 762 A9 The Web API MUST provide means for the web 763 application to cease the sending of a stream 764 to a peer. 765 ---------------------------------------------------------------- 766 A10 The Web API MUST provide means for the web 767 application to cease processing and rendering 768 of a stream received from a peer. 769 ---------------------------------------------------------------- 770 A11 The Web API MUST provide means for 771 informing the web application when a 772 stream from a peer is no longer received. 773 ---------------------------------------------------------------- 774 A12 The Web API MUST provide means for 775 informing the web application when high 776 loss rates occur. 777 ---------------------------------------------------------------- 778 A13 The Web API MUST provide means for the web 779 application to apply spatialization effects to 780 audio streams. 781 ---------------------------------------------------------------- 782 A14 The Web API MUST provide means for the web 783 application to detect the level in audio 784 streams. 785 ---------------------------------------------------------------- 786 A15 The Web API MUST provide means for the web 787 application to adjust the level in audio 788 streams. 789 ---------------------------------------------------------------- 790 A16 The Web API MUST provide means for the web 791 application to mix audio streams. 792 ---------------------------------------------------------------- 793 A17 For each stream generated, the Web API MUST provide 794 an identifier that is accessible by the application. 795 The identifier MUST be accessible also for a peer 796 receiving that stream and MUST be unique relative 797 to all other stream identifiers in use by either party. 798 ---------------------------------------------------------------- 799 A18 In addition to the streams listed elsewhere, 800 the Web API MUST provide a mechanism for sending 801 and receiving isolated discrete chunks of data. 802 ---------------------------------------------------------------- 803 A19 The Web API MUST provide means for the web 804 application indicate the type of audio signal 805 (speech, audio)for audio stream(s)/stream component(s). 806 ---------------------------------------------------------------- 807 A20 It must be possible for an initiator or a 808 responder Web application to indicate the types 809 of media he's willing to accept incoming streams 810 for when setting up a connection (audio, video, 811 other). The types of media he's willing to accept 812 can be a subset of the types of media the browser 813 is able to accept. 814 ---------------------------------------------------------------- 815 A21 The Web API MUST provide means for the 816 application to ask the browser for permission 817 to the screen, a certain area on the screen 818 or what a certain application displays on the 819 screen as input to streams. 820 ---------------------------------------------------------------- 821 A22 The Web API MUST provide means for the 822 application to specify several STUN and/or 823 TURN servers to use. 824 ---------------------------------------------------------------- 826 6. IANA Considerations 828 TBD 830 7. Security Considerations 832 7.1. Introduction 834 A malicious web application might use the browser to perform Denial 835 Of Service (DOS) attacks on NAT infrastructure, or on peer devices. 836 Also, a malicious web application might silently establish outgoing, 837 and accept incoming, streams on an already established connection. 839 Based on the identified security risks, this section will describe 840 security considerations for the browser and web application. 842 7.2. Browser Considerations 844 The browser is expected to provide mechanisms for getting user 845 consent to use device resources such as camera and microphone. 847 The browser is expected to provide mechanisms for informing the user 848 that device resources such as camera and microphone are in use 849 ("hot"). 851 The browser is expected to provide mechanisms for users to revise and 852 even completely revoke consent to use device resources such as camera 853 and microphone. 855 The browser is expected to provide mechanisms for getting user 856 consent to use the screen (or a certain part of it) or what a certain 857 application displays on the screen as source for streams. 859 The browser is expected to provide mechanisms for informing the user 860 that the screen, part thereof or an application is serving as a 861 stream source ("hot"). 863 The browser is expected to provide mechanisms for users to revise and 864 even completely revoke consent to use the screen, part thereof or an 865 application is serving as a stream source. 867 The browser is expected to provide mechanisms in order to assure that 868 streams are the ones the recipient intended to receive. 870 The browser needs to ensure that media is not sent, and that received 871 media is not rendered, until the associated stream establishment and 872 handshake procedures with the remote peer have been successfully 873 finished. 875 The browser needs to ensure that the stream negotiation procedures 876 are not seen as Denial Of Service (DOS) by other entities. 878 7.3. Web Application Considerations 880 The web application is expected to ensure user consent in sending and 881 receiving media streams. 883 8. Additional use-cases 885 Several additional use-cases have been discussed. At this point 886 these use-cases are not included as requirement deriving use-cases 887 for different reasons (lack of documentation, overlap with existing 888 use-cases, lack of consensus). For completeness these additional 889 use-cases are listed below: 890 1. Use-cases regarding different situations when being invited to a 891 "session", e.g. browser open, browser open but another tab 892 active, browser open but active in session, browser closed, .... 893 (Matthew Kaufman); discussed at webrtc meeting 894 2. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/rtcweb/ 895 current/msg00525.html, followed up by Stephan Wenger 897 3. Local Recording and Remote recording (John): Discussed a _lot_ on 898 the mail lists (rtcweb as well as public-webrtc) lAugust and 899 September 2011. Concrete proposal: 900 http://www.ietf.org/mail-archive/web/rtcweb/current/msg01006.html 901 (remote) and 902 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00734.html 903 (local) 904 4. Emergency access for disabled (Bernard Aboba) 905 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html 906 5. Clue use-cases (Roni Even) http://tools.ietf.org/html/ 907 draft-ietf-clue-telepresence-use-cases-01 908 6. Rohan red cross (Cullen Jennings); 909 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00323.html 910 7. Security camera/baby monitor usage 911 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00543.html 912 8. Large multiparty session 913 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00530.html 915 9. Acknowledgements 917 Dan Burnett has reviewed and proposed a lot of things that enhances 918 the document. Most of this has been incorporated in rev -05. 920 Stephan Wenger has provided a lot of useful input and feedback, as 921 well as editorial comments. 923 Harald Alvestrand and Ted Hardie have provided comments and feedback 924 on the draft. 926 Harald Alvestrand and Cullen Jennings have provided additional use- 927 cases. 929 Thank You to everyone in the RTCWEB community that have provided 930 comments, feedback and improvement proposals on the draft content. 932 10. Change Log 934 [RFC EDITOR NOTE: Please remove this section when publishing] 936 Changes from draft-ietf-rtcweb-use-cases-and-requirements-06 938 o Renaming of requirements (FaI1 -> F31), (FaI2 -> F32) and (AaI1 -> 939 A22) 941 Changes from draft-ietf-rtcweb-use-cases-and-requirements-05 942 o Added use-case "global service provider", derived reqs associated 943 with several STUN/TURN servers 944 o Added use-case "enterprise aspects", derived req associated with 945 enabling the network provider to supply STUN and TURN servers 946 o The requirements from the above are ICE specific and labeled 947 accordingly 948 o Separated the requirements phrased like "processing such as pan, 949 mix and render" for audio to be specific reqs on spatialization, 950 level measurement, level adjustment and mixing (discussed on the 951 lists in 952 http://www.ietf.org/mail-archive/web/rtcweb/current/msg01648.html 953 and http://lists.w3.org/Archives/Public/public-webrtc/2011Sep/ 954 0102.html) 955 o Added use-case on sharing as decided in 956 http://www.ietf.org/mail-archive/web/rtcweb/current/msg01700.html, 957 derived reqs F30 and A21 958 o Added the list of common considerations proposed in mail 959 http://www.ietf.org/mail-archive/web/rtcweb/current/msg01562.html 960 to the Introduction of the use-case section 962 Changes from draft-ietf-rtcweb-use-cases-and-requirements-04 964 o Most changes based on the input from Dan Burnett 965 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00948.html 966 o Many editorial changes 967 o 4.2.1.1 Clarified 968 o Some clarification added to 4.3.1.1 as a note 969 o F-requirements updated (see reply to Dan's mail). 970 o Almost all A-requirements updated to start "The Web API MUST 971 provide ..." 972 o A8 removed, A9 rephrased to cover A8 and old A9 973 o A15 rephrased 974 o For more details, and discussion, look att the response to Dan's 975 mail 976 http://www.ietf.org/mail-archive/web/rtcweb/current/msg01177.html 978 Changes from draft-ietf-rtcweb-use-cases-and-requirements-03 980 o Editorials 981 o Changed when the self-view is displayed in 4.2.1.1, and added 982 words about allowing users to remove and re-insert it. 983 o Clarified 4.2.6.1 984 o Removed the "mono" stuff from 4.2.7.1 985 o Added that communication should not be possible to eavesdrop to 986 most use cases - and req. F17 987 o Re-phrased 4.3.3.1 to not describe the technical solution so much, 988 and removed "stereo" stuff. Solution possibilities are now in a 989 note. 991 o Re-inserted API requirements after discussion in the W3C webrtc 992 WG. (Re-phrased A15 and added A18 compared to version -02). 994 Changes from draft-ietf-rtcweb-use-cases-and-requirements-02 996 o Removed desrciption/list of API requirements, instead 997 o Reference to W3C webrtc_reqs document for API requirements 999 Changes from draft-ietf-rtcweb-ucreqs-01 1001 o Changed Intended status to Information 1002 o Changed "Ipr" to "trust200902" 1003 o Added use case "Simple video communication service, NAT/FW that 1004 blocks UDP", and derived new req F26 1005 o Added use case "Distributed Music Band" and derived new req A17 1006 o Added F24 as requirement derived from use case "Simple video 1007 communication service with inter-operator calling" 1008 o Added section "Additional use cases" 1009 o Added text about ID handling to multiparty with central server use 1010 case 1011 o Re-phrased A1 slightly 1013 Changes from draft-ietf-rtcweb-ucreqs-00 1015 o - Reshuffled: Just two main groups of use cases (b2b and b2GW/ 1016 Server); removed some specific use cases and added them instead as 1017 flavors to the base use case (Simple video communciation) 1018 o - Changed the fromulation of F19 1019 o - Removed the requirement on an API for DTMF 1020 o - Removed "FX3: There SHOULD be a mapping of the minimum needed 1021 data for setting up connections into SIP, so that the restriction 1022 to SIP-carriable data can be verified. Not a rew on the browser 1023 but rather on a document" 1024 o - (see 1025 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00227.html 1026 for more details) 1027 o -Added text on informing user of that mic/cam is being used and 1028 that it must be possible to revoce permission to use them in 1029 section 7. 1030 Changes from draft-holmberg-rtcweb-ucreqs-01 1031 o - Draft name changed to draft-ietf-rtcweb-ucreqs 1032 o - Use-case grouping introduced 1033 o - Additional use-cases added 1034 o - Additional reqs added (derived from use cases): F19-F25, A16-A17 1036 Changes from draft-holmberg-rtcweb-ucreqs-00 1037 o - Mapping between use-cases and requirements added (Harald 1038 Alvestrand, 090311) 1039 o - Additional security considerations text (Harald Alvestrand, 1040 090311) 1041 o - Clarification that user applications are assumed to be executed 1042 by a browser (Ted Hardie, 080311) 1043 o - Editorial corrections and clarifications 1045 11. References 1047 11.1. Normative References 1049 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1050 Requirement Levels", BCP 14, RFC 2119, March 1997. 1052 11.2. Informative References 1054 [webrtc_reqs] 1055 "Webrt requirements, 1056 http://dev.w3.org/2011/webrtc/editor/webrtc_reqs.html". 1058 Authors' Addresses 1060 Christer Holmberg 1061 Ericsson 1062 Hirsalantie 11 1063 Jorvas 02420 1064 Finland 1066 Email: christer.holmberg@ericsson.com 1068 Stefan Hakansson 1069 Ericsson 1070 Laboratoriegrand 11 1071 Lulea 97128 1072 Sweden 1074 Email: stefan.lk.hakansson@ericsson.com 1075 Goran AP Eriksson 1076 Ericsson 1077 Farogatan 6 1078 Stockholm 16480 1079 Sweden 1081 Email: goran.ap.eriksson@ericsson.com