idnits 2.17.1 draft-holmberg-rtcweb-ucreqs-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 14, 2011) is 4764 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: Standards Track G. Eriksson 5 Expires: September 15, 2011 Ericsson 6 March 14, 2011 8 Web Real-Time Communication Use-cases and Requirements 9 draft-holmberg-rtcweb-ucreqs-01.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 to IETF 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 September 15, 2011. 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. Use-case: Simple Video Communication Service . . . . . . . 3 58 4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 3 59 4.2.2. Derived Requirements . . . . . . . . . . . . . . . . . 4 60 4.3. Use-case: Multiparty video communication . . . . . . . . . 4 61 4.3.1. Description . . . . . . . . . . . . . . . . . . . . . 4 62 4.3.2. Derived Requirements . . . . . . . . . . . . . . . . . 4 63 4.4. Use-case: Multiparty on-line game with voice 64 communication . . . . . . . . . . . . . . . . . . . . . . 4 65 4.4.1. Description . . . . . . . . . . . . . . . . . . . . . 4 66 4.4.2. Derived Requirements . . . . . . . . . . . . . . . . . 5 67 4.5. Use-case: Video conferencing system with central server . 5 68 4.5.1. Description . . . . . . . . . . . . . . . . . . . . . 5 69 4.5.2. Derived Requirements . . . . . . . . . . . . . . . . . 5 70 4.6. Use-case: Hockey game viewer . . . . . . . . . . . . . . . 5 71 4.6.1. Description . . . . . . . . . . . . . . . . . . . . . 5 72 4.6.2. Derived Requirements . . . . . . . . . . . . . . . . . 6 73 4.7. Use-case: Telephony terminal . . . . . . . . . . . . . . . 6 74 4.7.1. Description . . . . . . . . . . . . . . . . . . . . . 6 75 4.7.2. Derived Requirements . . . . . . . . . . . . . . . . . 6 76 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 5.2. Browser requirements . . . . . . . . . . . . . . . . . . . 6 79 5.3. API requirements . . . . . . . . . . . . . . . . . . . . . 8 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 83 7.2. Browser Considerations . . . . . . . . . . . . . . . . . . 10 84 7.3. Web Application Considerations . . . . . . . . . . . . . . 10 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 86 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 89 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Introduction 94 This document presents a few use-case of web applications that are 95 executed in a browser and use real-time communication capabilities. 96 Based on the use-cases, the document derives requirements related to 97 the browser and the API used by web applications in the browser. 99 The document focuses on requirements related to real-time media 100 streams. Requirements related to privacy, signalling between the 101 browser and web server etc are currently not considered. 103 2. Conventions 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in BCP 14, RFC 2119 108 [RFC2119]. 110 3. Definitions 112 TBD 114 4. Use-cases 116 4.1. Introduction 118 This section describes web based real-time communication use-cases, 119 from which requirements are later derived. 121 4.2. Use-case: Simple Video Communication Service 123 4.2.1. Description 125 In the service the users have loaded, and logged into, a video 126 communication web application into their browsers, provided by the 127 same service provider. The web service publishes information about 128 user login status, by pushing updates to the web application in the 129 browsers. By selecting an online peer user, a 1-1 video 130 communication session between the browsers of the peers is initiated. 131 The invited user might accept or reject the session. 133 When the session has been established, a self-view, as well as the 134 video sent from the remote peer, are displayed. The users can change 135 the display sizes during the session. The users can also pause 136 sending of media (audio, video, or both), and mute incoming media. 138 Any session participant can end the session at any time. 140 One participant has an unreliable internet connection. It sometimes 141 has packet losses, and is sometimes goes down completely. 143 One participant is located behind a Network Address Translator (NAT). 145 4.2.2. Derived Requirements 147 F1, F2, F3, F4, F5, F6, F8, F9, F10 149 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 151 4.3. Use-case: Multiparty video communication 153 4.3.1. Description 155 In this use case the simple video communication service is extended 156 by allowing multiparty sessions. No central server is involved - the 157 browser of each participant sends and receives streams to and from 158 all other session participants. 160 The audio sent by each participant is a mono stream. However, in 161 order to enhance intelligibility, the web application pans the audio 162 from different participants differently when rendering the audio. 163 This is done automatically, but users can change how the different 164 participants are placed in the (virtual) room. 166 Each video stream received is by default displayed in a thumbnail 167 frame within the browser, but users can change the display size. 169 4.3.2. Derived Requirements 171 F1, F2, F3, F4, F5, F6, F8, F9, F10, F11, F12, F13, F14 173 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15 175 4.4. Use-case: Multiparty on-line game with voice communication 177 4.4.1. Description 179 In this use-case, the voice part of the multiparty video 180 communication application is used in the context of an on-line game. 181 The received voice audio media is rendered together with game sound 182 objects. For example, the sound of a tank moving from left to right 183 over the screen must be rendered and played to the user together with 184 the voice media. 186 4.4.2. Derived Requirements 188 F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13, F15, F21 190 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A17 192 4.5. Use-case: Video conferencing system with central server 194 4.5.1. Description 196 An organization uses a video communication system that supports the 197 establishment of multiparty video sessions using a central conference 198 server. 200 The browsers of all participants send an audio stream (mono or stereo 201 depending on the equipment of a participant) to the central server. 202 The central server mixes the audio streams and sends towards the 203 participants a mixed stereo stream. 205 All participants send two video streams towards the server, one low 206 resolution and one high resolution. At each participant one high 207 resolution video is displayed in a large window, while a number of 208 low resolution videos are displayed in smaller windows. The server 209 selects what video streams to be forwarded as main- and thumbnail 210 videos, based on speech activity. 212 The organization has an internal network set up with an aggressive 213 firewall handling access to the internet. If users can not 214 physically access the internal network, they can establish a Virtual 215 Private Network (VPN). 217 It is essential that the communication can not be eavesdropped. 219 4.5.2. Derived Requirements 221 F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F14, F16, F17 223 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A15 225 4.6. Use-case: Hockey game viewer 227 4.6.1. Description 229 An ice-hockey club uses an application that enables talent scouts to, 230 in real-time, show and discuss games and players with the club 231 manager. The talent scouts use a mobile phone with two cameras, one 232 front-facing and one rear facing. 234 The club manager uses a desktop for viewing the game and discussing 235 with the talent scout. The video stream captured by the front facing 236 camera (that is capturing the game) of the mobile phone is shown in a 237 big window on the desktop screen, while a thumbnail of the rear 238 facing camera is overlaid. 240 Most of the mobile phone screen is covered by a self view of the 241 front facing camera. A thumbnail of the rear facing cameras view is 242 overlaid. 244 4.6.2. Derived Requirements 246 F1, F2, F3, F4, F5, F6, F8, F9, F10, F14 248 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A15 250 4.7. Use-case: Telephony terminal 252 4.7.1. Description 254 A mobile telephony operator allows its customers to use a web browser 255 to access their services. After a simple log in the user can place 256 and receive calls in the same way as when using a normal mobile 257 phone. When a call is received or placed, the identity will be shown 258 in the same manner as when a mobile phone used. 260 4.7.2. Derived Requirements 262 F1, F2, F3, F4, F5, F6, F8, F9, F10, F18, F20 264 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A13, A16 266 5. Requirements 268 5.1. General 270 This section contains requirements, derived from the use-cases in 271 section 4. 273 NOTE: It is assumed that the user applications are executed on a 274 browser. Whether the capabilities to implement specific browser 275 requirements are implemented by the browser application, or are 276 provided to the browser application by the underlying Operating 277 System (OS), is outside the scope of this document. 279 5.2. Browser requirements 280 REQ-ID DESCRIPTION 281 --------------------------------------------------------------- 282 F1 The browser MUST be able to use microphones and 283 cameras as input devices to generate streams. 284 ---------------------------------------------------------------- 285 F2 The browser MUST be able to send streams to a 286 peer in presence of NATs. 287 ---------------------------------------------------------------- 288 F3 Transmitted streams MUST be rate controlled. 289 ---------------------------------------------------------------- 290 F4 The browser MUST be able to receive, process and 291 render streams from peers. 292 ---------------------------------------------------------------- 293 F5 The browser MUST be able to render good quality 294 audio and video even in presence of reasonable 295 levels of jitter and packet losses. 297 TBD: What is a reasonable level? 298 ---------------------------------------------------------------- 299 F6 The browser MUST be able to handle high loss and 300 jitter levels in a graceful way. 301 ---------------------------------------------------------------- 302 F7 The browser MUST support fast stream switches. 303 ---------------------------------------------------------------- 304 F8 The browser MUST detect when a stream from a 305 peer is not received any more 306 ---------------------------------------------------------------- 307 F9 When there are both incoming and outgoing audio 308 streams, echo cancellation MUST be made available to 309 avoid disturbing echo during conversation. 311 QUESTION: How much control should be left to the 312 web application? 313 ---------------------------------------------------------------- 314 F10 The browser MUST support synchronization of 315 audio and video. 317 QUESTION: How much control should be left to the 318 web application? 319 ---------------------------------------------------------------- 320 F11 The browser MUST be able to transmit streams to 321 several peers concurrently. 322 ---------------------------------------------------------------- 323 F12 The browser MUST be able to receive streams from 324 multiple peers concurrently. 325 ---------------------------------------------------------------- 326 F13 The browser MUST be able to pan, mix and render 327 several concurrent audio streams. 328 ---------------------------------------------------------------- 329 F14 The browser MUST be able to render several 330 concurrent video streams 331 ---------------------------------------------------------------- 332 F15 The browser MUST be able to process and mix 333 sound objects (media that is retrieved from another 334 source than the established media stream(s) with the 335 peer(s) with audio streams). 336 ---------------------------------------------------------------- 337 F16 Streams MUST be able to pass through restrictive 338 firewalls. 339 ---------------------------------------------------------------- 340 F17 It MUST be possible to protect streams from 341 eavesdropping. 342 ---------------------------------------------------------------- 343 F18 The browser MUST support an audio media format 344 (codec) that is commonly supported by existing 345 telephony services. 347 QUESTION: G.711? 348 ---------------------------------------------------------------- 350 5.3. API requirements 352 REQ-ID DESCRIPTION 353 ---------------------------------------------------------------- 354 A1 The web application MUST be able to query the 355 user about the usage of cameras and microphones 356 as input devices. 357 ---------------------------------------------------------------- 358 A2 The web application MUST be able to control how 359 streams generated by input devices are used. 360 ---------------------------------------------------------------- 361 A3 The web application MUST be able to control the 362 local layout streams (locally generated streams 363 and streams received from a peer). 364 ---------------------------------------------------------------- 365 A4 The web application MUST be able to initiate 366 sending of stream/stream components to a peer. 367 ---------------------------------------------------------------- 368 A5 The web application MUST be able to control the 369 media format (codec) to be used for the streams 370 sent to a peer. 372 NOTE: The level of control depends on whether 373 the codec negotiation is handled by the browser 374 or the web application. 375 ---------------------------------------------------------------- 376 A6 After a media stream has been established, the 377 web application MUST be able to modify the media 378 format for streams sent to a peer. 379 ---------------------------------------------------------------- 380 A7 The web application MUST be made aware of 381 whether the establishment of a stream with a 382 peer was successful or not. 383 ---------------------------------------------------------------- 384 A8 The web application MUST be able to 385 pause/unpause the sending of a stream to a peer. 386 ---------------------------------------------------------------- 387 A9 The web application MUST be able to mute/unmute 388 a stream received from a peer. 389 ---------------------------------------------------------------- 390 A10 The web application MUST be able to cease the 391 sending of a stream to a peer. 392 ---------------------------------------------------------------- 393 A11 The web application MUST be able to cease 394 processing and rendering of a stream received 395 from a peer. 396 ---------------------------------------------------------------- 397 A12 The web application MUST be informed when a 398 stream from a peer is no longer received. 399 ---------------------------------------------------------------- 400 A13 The web application MUST be informed when high 401 loss rates occur. 402 ---------------------------------------------------------------- 403 A14 It MUST be possible for the web application to 404 control panning, mixing and other processing for 405 individual streams. 406 ---------------------------------------------------------------- 407 A15 The web application MUST be able to identity the 408 context of a stream. 409 ---------------------------------------------------------------- 411 6. IANA Considerations 413 TBD 415 7. Security Considerations 417 7.1. Introduction 419 A malicious web application might use the browser to perform Denial 420 Of Service (DOS) attacks on NAT infrastructure, or on peer devices. 421 Also, a malicious web application might silently establish outgoing, 422 and accept incoming, streams on an already established connection. 424 Based on the identified security risks, this section will describe 425 security considerations for the browser and web application. 427 7.2. Browser Considerations 429 The browser is expected to provide mechanisms for getting user 430 consent to use device resources such as camera and microphone. 432 The browser is expected to provide mechanisms in order to assure that 433 streams are the ones the recipient intended to receive. 435 The browser is needs to ensure that media is not sent, and that 436 received media is not rendered, until the associated stream 437 establishment and handshake procedures with the remote peer have been 438 successfully finished. 440 The browser needs to ensure that the stream negotiation procedures 441 are not seen as Denial Of Service (DOS) by other entities. 443 7.3. Web Application Considerations 445 The web application is expected to ensure user consent in sending and 446 receiving media streams. 448 8. Acknowledgements 450 Harald Alvestrand and Ted Hardie have provided comments and feedback 451 on the draft. 453 9. Change Log 455 [RFC EDITOR NOTE: Please remove this section when publishing] 457 Changes from draft-holmberg-rtcweb-ucreqs-00 458 o - Mapping between use-cases and requirements added (Harald 459 Alvestrand, 090311) 461 o - Additional security considerations text (Harald Alvestrand, 462 090311) 463 o - Clarification that user applications are assumed to be executed 464 by a browser (Ted Hardie, 080311) 465 o - Editorial corrections and clarifications 467 10. References 469 10.1. Normative References 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, March 1997. 474 10.2. Informative References 476 Authors' Addresses 478 Christer Holmberg 479 Ericsson 480 Hirsalantie 11 481 Jorvas 02420 482 Finland 484 Email: christer.holmberg@ericsson.com 486 Stefan Hakansson 487 Ericsson 488 Laboratoriegrand 11 489 Lulea 97128 490 Sweden 492 Email: stefan.lk.hakansson@ericsson.com 494 Goran AP Eriksson 495 Ericsson 496 Farogatan 6 497 Stockholm 16480 498 Sweden 500 Email: goran.ap.eriksson@ericsson.com