idnits 2.17.1 draft-ietf-rtcweb-use-cases-and-requirements-02.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 (August 19, 2011) is 4606 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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: Informational G. Eriksson 5 Expires: February 20, 2012 Ericsson 6 August 19, 2011 8 Web Real-Time Communication Use-cases and Requirements 9 draft-ietf-rtcweb-use-cases-and-requirements-02.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 February 20, 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 . . . . . . . . . . . . . . . 3 58 4.2.1. Simple Video Communication Service . . . . . . . . . . 3 59 4.2.2. Simple Video Communication Service, NAT/FW that 60 blocks UDP . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2.3. Simple Video Communication Service, access change . . 4 62 4.2.4. Simple Video Communication Service, QoS . . . . . . . 5 63 4.2.5. Simple video communication service with 64 inter-operator calling . . . . . . . . . . . . . . . . 5 65 4.2.6. Hockey Game Viewer . . . . . . . . . . . . . . . . . . 6 66 4.2.7. Multiparty video communication . . . . . . . . . . . . 6 67 4.2.8. Multiparty on-line game with voice communication . . . 7 68 4.2.9. Distributed Music Band . . . . . . . . . . . . . . . . 7 69 4.3. Browser - GW/Server use cases . . . . . . . . . . . . . . 8 70 4.3.1. Telephony terminal . . . . . . . . . . . . . . . . . . 8 71 4.3.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . . 8 72 4.3.3. Video conferencing system with central server . . . . 9 73 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 5.2. Browser requirements . . . . . . . . . . . . . . . . . . . 10 76 5.3. API requirements . . . . . . . . . . . . . . . . . . . . . 12 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 14 80 7.2. Browser Considerations . . . . . . . . . . . . . . . . . . 14 81 7.3. Web Application Considerations . . . . . . . . . . . . . . 14 82 8. Additional use cases . . . . . . . . . . . . . . . . . . . . . 14 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 84 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 87 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 This document presents a few use-case of web applications that are 93 executed in a browser and use real-time communication capabilities. 94 Based on the use-cases, the document derives requirements related to 95 the browser and the API used by web applications in the browser. 97 The document focuses on requirements related to real-time media 98 streams. Requirements related to privacy, signalling between the 99 browser and web server etc are currently not considered. 101 2. Conventions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in BCP 14, RFC 2119 106 [RFC2119]. 108 3. Definitions 110 TBD 112 4. Use-cases 114 4.1. Introduction 116 This section describes web based real-time communication use-cases, 117 from which requirements are later derived. 119 4.2. Browser-to-browser use-cases 121 4.2.1. Simple Video Communication Service 123 4.2.1.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 sizes of the video displays during the session. The users can 136 also pause sending of media (audio, video, or both), and mute 137 incoming media. 139 Any session participant can end the session at any time. 141 The users are using communication devices of different makes, with 142 different Operating Systems and Browsers from different vendors. 144 One user has an unreliable internet connection. It sometimes has 145 packet losses, and is sometimes goes down completely. 147 One user is located behind a Network Address Translator (NAT). 149 4.2.1.2. Derived Requirements 151 F1, F2, F3, F4, F5, F6, F8, F9, F10, F22, F25 153 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 155 4.2.2. Simple Video Communication Service, NAT/FW that blocks UDP 157 4.2.2.1. Description 159 This use case is almost identical to the previos one. The difference 160 is that one of the users is behind a NAT that blocks UDP traffic. 162 4.2.2.2. Derived Requirements 164 F1, F2, F3, F4, F5, F6, F8, F9, F10, F22, F23, F25, F26 166 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 168 4.2.3. Simple Video Communication Service, access change 170 4.2.3.1. Description 172 This use case is almost identical to "4.2.1 Simple Video 173 Communication Service". The difference is that the user changes 174 network access during the session: 176 The communication device used byt one of the users have several 177 network adapters (Ethernet, WiFi, Cellular). The communication 178 device is access the internet using Ethernet, but the user has to 179 start a trip during the session. The communication device 180 automatically changes to use WiFi when the ethernet cable is removed 181 and then moves to cellular access to the internet when moving out of 182 WiFi coverage. The session continues even though the access method 183 changes. 185 4.2.3.2. Derived Requirements 187 F1, F2, F3, F4, F5, F6, F8, F9, F10, F22, F23, F25 189 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 191 4.2.4. Simple Video Communication Service, QoS 193 4.2.4.1. Description 195 This use case is almost identical to the previos one. The use of QoS 196 capabilities is added: 198 The user in the previous use case that starts a trip is behind a 199 common residential router that supports prioritization of traffic. 200 In addition, the user's provider of cellular access has QoS support 201 enabled. The user is able to take advantage of the QoS support both 202 when accessing via the residential router and when using cellular. 204 4.2.4.2. Derived Requirements 206 F1, F2, F3, F4, F5, F6, F8, F9, F10, F21, F22, F23, F25 208 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 210 4.2.5. Simple video communication service with inter-operator calling 212 4.2.5.1. Description 214 Two users have logged into two different web applications, provided 215 by different service providers. 217 The service providers are interconnected by some means, but exchange 218 no more information about the users than what can be carried using 219 SIP. 221 NOTE: More profiling of what this means may be needed. 223 Each web service publishes information about user login status for 224 users that have a relationship with the other user; how this is 225 established is out of scope. 227 The same functionality as in the "4.2.1 Simple Video Communication 228 Service" is available. 230 The same issues with connectivity apply. 232 4.2.5.2. Derived requirements 234 F1, F2, F3, F4, F5, F6, F8, F9, F10, F22, F24, F25 236 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 238 4.2.6. Hockey Game Viewer 240 4.2.6.1. Description 242 An ice-hockey club uses an application that enables talent scouts to, 243 in real-time, show and discuss games and players with the club 244 manager. The talent scouts use a mobile phone with two cameras, one 245 front-facing and one rear facing. 247 The club manager uses a desktop for viewing the game and discussing 248 with the talent scout. The video stream captured by the front facing 249 camera (that is capturing the game) of the mobile phone is shown in a 250 big window on the desktop screen, while a thumbnail of the rear 251 facing camera is overlaid. 253 Most of the mobile phone screen is covered by a self view of the 254 front facing camera. A thumbnail of the rear facing cameras view is 255 overlaid. 257 4.2.6.2. Derived Requirements 259 F1, F2, F3, F4, F5, F6, F8, F9, F10, F14 261 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A15 263 4.2.7. Multiparty video communication 265 4.2.7.1. Description 267 In this use case the simple video communication service is extended 268 by allowing multiparty sessions. No central server is involved - the 269 browser of each participant sends and receives streams to and from 270 all other session participants. The web application in the browser 271 of each user is responsible for setting up streams to all receivers. 273 The audio sent by each participant is a mono stream. However, in 274 order to enhance intelligibility, the web application pans the audio 275 from different participants differently when rendering the audio. 276 This is done automatically, but users can change how the different 277 participants are placed in the (virtual) room. 279 Each video stream received is by default displayed in a thumbnail 280 frame within the browser, but users can change the display size. 282 Note: What this uses case adds in terms of requirements is 283 capabilities to send streams to and receive streams from several 284 peers concurrently, as well as the capabilities to render the video 285 from all recevied streams and be able to spatialize and mix the audio 286 from all received streams locally in the browser. 288 4.2.7.2. Derived Requirements 290 F1, F2, F3, F4, F5, F6, F8, F9, F10, F11, F12, F13, F14, F22 292 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15 294 4.2.8. Multiparty on-line game with voice communication 296 4.2.8.1. Description 298 In this use-case, the voice part of the multiparty video 299 communication application is used in the context of an on-line game. 300 The received voice audio media is rendered together with game sound 301 objects. For example, the sound of a tank moving from left to right 302 over the screen must be rendered and played to the user together with 303 the voice media. 305 Quick updates of the game state is required. 307 Note: the difference regarding local audio processing compared to the 308 "Multiparty video communication" use case is that other sound objects 309 than the streams must be possible to be included in the 310 spatialization and mixing. "Other sound objects" could for example a 311 file with the sound of the tank, that file could be stored locally or 312 remotely. 314 4.2.8.2. Derived Requirements 316 F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13, F15, F20 318 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16 320 4.2.9. Distributed Music Band 322 4.2.9.1. Description 324 In this use-case, a music band is playing music while the members are 325 at different physical locations. No central server is used, instead 326 all streams are set up in a mesh fashion. 328 Discussion: This use case was briefly discussed at the Quebec webrtc 329 meeting and it got support. So far the only concrete requirement 330 (A17) derived is that the application must be able to ask the browser 331 to treat the audio signal as audio (in contrast to speech). However, 332 the use case should be further analysed to determine other 333 requirements (could be e.g. on delay mic->speaker, level control of 334 audio signals, etc.). 336 4.2.9.2. Derived Requirements 338 F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13 340 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A17 342 4.3. Browser - GW/Server use cases 344 4.3.1. Telephony terminal 346 4.3.1.1. Description 348 A mobile telephony operator allows its customers to use a web browser 349 to access their services. After a simple log in the user can place 350 and receive calls in the same way as when using a normal mobile 351 phone. When a call is received or placed, the identity will be shown 352 in the same manner as when a mobile phone used. 354 4.3.1.2. Derived Requirements 356 F1, F2, F3, F4, F5, F6, F8, F9, F10, F18 358 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A13 360 4.3.2. Fedex Call 362 4.3.2.1. Description 364 Alice uses her web browser with a service something like Skype to be 365 able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should 366 be able to hear the initial prompts from the fedex IVR and when the 367 IVR says press 1, there should be a way for Alice to navigate the 368 IVR. 370 4.3.2.2. Derived Requirements 372 F1, F2, F3, F4, F5, F6, F8, F9, F10, F18, F19 374 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A13 376 4.3.3. Video conferencing system with central server 378 4.3.3.1. Description 380 An organization uses a video communication system that supports the 381 establishment of multiparty video sessions using a central conference 382 server. 384 The browsers of all participants send an audio stream (mono or stereo 385 depending on the equipment of a participant) to the central server. 386 The central server mixes the audio streams and sends towards the 387 participants a mixed stereo audio stream. 389 Each participant sends two video streams in a simulcast fashion 390 towards the server, one low resolution and one high resolution. At 391 each participant one high resolution video is displayed in a large 392 window, while a number of low resolution videos are displayed in 393 smaller windows. The server selects what video streams to be 394 forwarded as main- and thumbnail videos, based on speech activity. 395 As the video streams to display can change quite frequently (as the 396 conversation flows) it is important that the delay from when a video 397 stream is selected for display until the video can be displayed is 398 short. 400 The organization has an internal network set up with an aggressive 401 firewall handling access to the internet. If users can not 402 physically access the internal network, they can establish a Virtual 403 Private Network (VPN). 405 It is essential that the communication can not be eavesdropped. 407 All participant are authenticated by the central server, and 408 authorized to connect to the central server. The participants are 409 identified to each other by the central server, and the participants 410 do not have access to each others' credentials such as e-mail 411 addresses or login IDs. 413 Note: This use case adds requirements on support for fast stream 414 switches F7, on encryption of media and on ability to traverse very 415 restrictive FWs. It also introduces simulcast, but no concrete 416 requirement is put for this. 418 4.3.3.2. Derived Requirements 420 F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F14, F16, F17 422 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A15 424 5. Requirements 426 5.1. General 428 This section contains requirements, derived from the use-cases in 429 section 4. 431 NOTE: It is assumed that the user applications are executed on a 432 browser. Whether the capabilities to implement specific browser 433 requirements are implemented by the browser application, or are 434 provided to the browser application by the underlying Operating 435 System (OS), is outside the scope of this document. 437 5.2. Browser requirements 439 REQ-ID DESCRIPTION 440 --------------------------------------------------------------- 441 F1 The browser MUST be able to use microphones and 442 cameras as input devices to generate streams. 443 ---------------------------------------------------------------- 444 F2 The browser MUST be able to send streams to a 445 peer in presence of NATs. 446 ---------------------------------------------------------------- 447 F3 Transmitted streams MUST be rate controlled. 448 ---------------------------------------------------------------- 449 F4 The browser MUST be able to receive, process and 450 render streams from peers. 451 ---------------------------------------------------------------- 452 F5 The browser MUST be able to render good quality 453 audio and video even in presence of reasonable 454 levels of jitter and packet losses. 456 TBD: What is a reasonable level? 457 ---------------------------------------------------------------- 458 F6 The browser MUST be able to handle high loss and 459 jitter levels in a graceful way. 460 ---------------------------------------------------------------- 461 F7 The browser MUST support fast stream switches. 462 ---------------------------------------------------------------- 463 F8 The browser MUST detect when a stream from a 464 peer is not received any more 465 ---------------------------------------------------------------- 466 F9 When there are both incoming and outgoing audio 467 streams, echo cancellation MUST be made available to 468 avoid disturbing echo during conversation. 470 QUESTION: How much control should be left to the 471 web application? 472 ---------------------------------------------------------------- 473 F10 The browser MUST support synchronization of 474 audio and video. 476 QUESTION: How much control should be left to the 477 web application? 478 ---------------------------------------------------------------- 479 F11 The browser MUST be able to transmit streams to 480 several peers concurrently. 481 ---------------------------------------------------------------- 482 F12 The browser MUST be able to receive streams from 483 multiple peers concurrently. 484 ---------------------------------------------------------------- 485 F13 The browser MUST be able to pan, mix and render 486 several concurrent audio streams. 487 ---------------------------------------------------------------- 488 F14 The browser MUST be able to render several 489 concurrent video streams 490 ---------------------------------------------------------------- 491 F15 The browser MUST be able to process and mix 492 sound objects (media that is retrieved from another 493 source than the established media stream(s) with the 494 peer(s) with audio streams). 495 ---------------------------------------------------------------- 496 F16 Streams MUST be able to pass through restrictive 497 firewalls. 498 ---------------------------------------------------------------- 499 F17 It MUST be possible to protect streams from 500 eavesdropping. 501 ---------------------------------------------------------------- 502 F18 The browser MUST support an audio media format 503 (codec) that is commonly supported by existing 504 telephony services. 506 QUESTION: G.711? 507 ---------------------------------------------------------------- 508 F19 there should be a way to navigate 509 the IVR 510 ---------------------------------------------------------------- 511 F20 The browser must be able to send short 512 latency datagram traffic to a peer browser 513 ---------------------------------------------------------------- 514 F21 The browser MUST be able to take advantage of 515 capabilities to prioritize voice and video 516 appropriately. 517 ---------------------------------------------------------------- 518 F22 The browser SHOULD use encoding of streams 519 suitable for the current rendering (e.g. 520 video display size) and SHOULD change parameters 521 if the rendering changes during the session 522 ---------------------------------------------------------------- 523 F23 It MUST be possible to move from one network 524 interface to another one 525 ---------------------------------------------------------------- 526 F24 The browser MUST be able to initiate and accept a 527 media session where the data needed for establishment 528 can be carried in SIP. 529 ---------------------------------------------------------------- 530 F25 The browser MUST support a baseline audio and 531 video codec 532 ---------------------------------------------------------------- 533 F26 The browser MUST be able to send streams to a 534 peer in presence of NATs that block UDP traffic. 535 ---------------------------------------------------------------- 537 5.3. API requirements 539 REQ-ID DESCRIPTION 540 ---------------------------------------------------------------- 541 A1 The web application MUST be able to ask the 542 browser for permission to use cameras 543 and microphones as input devices. 544 ---------------------------------------------------------------- 545 A2 The web application MUST be able to control how 546 streams generated by input devices are used. 547 ---------------------------------------------------------------- 548 A3 The web application MUST be able to control the 549 local rendering of streams (locally generated streams 550 and streams received from a peer). 551 ---------------------------------------------------------------- 552 A4 The web application MUST be able to initiate 553 sending of stream/stream components to a peer. 554 ---------------------------------------------------------------- 555 A5 The web application MUST be able to control the 556 media format (codec) to be used for the streams 557 sent to a peer. 559 NOTE: The level of control depends on whether 560 the codec negotiation is handled by the browser 561 or the web application. 562 ---------------------------------------------------------------- 563 A6 After a media stream has been established, the 564 web application MUST be able to modify the media 565 format for streams sent to a peer. 566 ---------------------------------------------------------------- 567 A7 The web application MUST be made aware of 568 whether the establishment of a stream with a 569 peer was successful or not. 570 ---------------------------------------------------------------- 571 A8 The web application MUST be able to 572 pause/unpause the sending of a stream to a peer. 573 ---------------------------------------------------------------- 574 A9 The web application MUST be able to mute/unmute 575 a stream received from a peer. 576 ---------------------------------------------------------------- 577 A10 The web application MUST be able to cease the 578 sending of a stream to a peer. 579 ---------------------------------------------------------------- 580 A11 The web application MUST be able to cease 581 processing and rendering of a stream received 582 from a peer. 583 ---------------------------------------------------------------- 584 A12 The web application MUST be informed when a 585 stream from a peer is no longer received. 586 ---------------------------------------------------------------- 587 A13 The web application MUST be informed when high 588 loss rates occur. 589 ---------------------------------------------------------------- 590 A14 It MUST be possible for the web application to 591 control panning, mixing and other processing for 592 individual streams. 593 ---------------------------------------------------------------- 594 A15 The web application MUST be able to identify the 595 context of a stream. 596 ---------------------------------------------------------------- 597 A16 It MUST be possible for the web application to 598 send and receive datagrams to/from peer 599 ---------------------------------------------------------------- 600 A17 It MUST be possible for the web application to 601 indicate the type of audio signal (speech, audio) 602 ---------------------------------------------------------------- 604 6. IANA Considerations 606 TBD 608 7. Security Considerations 609 7.1. Introduction 611 A malicious web application might use the browser to perform Denial 612 Of Service (DOS) attacks on NAT infrastructure, or on peer devices. 613 Also, a malicious web application might silently establish outgoing, 614 and accept incoming, streams on an already established connection. 616 Based on the identified security risks, this section will describe 617 security considerations for the browser and web application. 619 7.2. Browser Considerations 621 The browser is expected to provide mechanisms for getting user 622 consent to use device resources such as camera and microphone. 624 The browser is expected to provide mechanisms for informing the user 625 that device resources such as camera and microphone are in use 626 ("hot"). 628 The browser is expected to provide mechanisms for users to revise 629 consent to use device resources such as camera and microphone. 631 The browser is expected to provide mechanisms in order to assure that 632 streams are the ones the recipient intended to receive. 634 The browser is needs to ensure that media is not sent, and that 635 received media is not rendered, until the associated stream 636 establishment and handshake procedures with the remote peer have been 637 successfully finished. 639 The browser needs to ensure that the stream negotiation procedures 640 are not seen as Denial Of Service (DOS) by other entities. 642 7.3. Web Application Considerations 644 The web application is expected to ensure user consent in sending and 645 receiving media streams. 647 8. Additional use cases 649 Several additional use cases have been discusses. At this point 650 these use cases are not included as requirement deriving use cases 651 for different reasons (lack of documentation, overlap with existing 652 use cases, lack of consensus). For completeness these additional use 653 cases are listed below: 655 1. Use cases regarding different situations when being invited to a 656 "session", e.g. browser open, browser open but another tab 657 active, browser open but active in session, browser closed, .... 658 (Matthew Kaufman); discussed at webrtc meeting 659 2. Different TURN provider scenarios (Cullen Jennings); discussed 660 at the webrtc meeting 661 3. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/ 662 rtcweb/current/msg00525.html 663 4. Local Recording (John Ewell) at webrtc meeting 664 5. Remote recording (John) http://www.ietf.org/mail-archive/web/ 665 rtcweb/current/msg00472.html 666 6. Emergency access for disabled (Bernard Aboba) http:// 667 www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html 668 7. Clue use cases (Roni Even) http://tools.ietf.org/html/ 669 draft-ietf-clue-telepresence-use-cases-01 670 8. Rohan red cross (Cullen Jennings); http://www.ietf.org/ 671 mail-archive/web/rtcweb/current/msg00323.html 672 9. Remote assistance (ala VNC or RDP) - User is helping another 673 user on their computer with either view-only or view-with- 674 control, either of just the browser of the the entire screen. ht 675 tp://www.ietf.org/mail-archive/web/rtcweb/current/msg00543.html 676 10. Security camera/baby monitor usage http://www.ietf.org/ 677 mail-archive/web/rtcweb/current/msg00543.html 678 11. Large multiparty session http://www.ietf.org/mail-archive/web/ 679 rtcweb/current/msg00530.html 681 9. Acknowledgements 683 Harald Alvestrand and Ted Hardie have provided comments and feedback 684 on the draft. 686 Harald Alvestrand and Cullen Jennings have provided additional use- 687 cases. 689 Thank You to everyone in the RTCWEB community that have provided 690 comments, feedback and improvement proposals on the draft content. 692 10. Change Log 694 [RFC EDITOR NOTE: Please remove this section when publishing] 696 Changes from draft-ietf-rtcweb-ucreqs-01 698 o Changed Intended status to Information 699 o Changed "Ipr" to "trust200902" 700 o Added use case "Simple video communication service, NAT/FW that 701 blocks UDP", and derived new req F26 702 o Added use case "Distributed Music Band" and derived new req A17 703 o Added F24 as requirement derived from use case "Simple video 704 communication service with inter-operator calling" 705 o Added section "Additional use cases" 706 o Added text about ID handling to multiparty with central server use 707 case 708 o Re-phrased A1 slightly 710 Changes from draft-ietf-rtcweb-ucreqs-00 712 o - Reshuffled: Just two main groups of use cases (b2b and b2GW/ 713 Server); removed some specific use cases and added them instead as 714 flavors to the base use case (Simple video communciation) 715 o - Changed the fromulation of F19 716 o - Removed the requirement on an API for DTMF 717 o - Removed "FX3: There SHOULD be a mapping of the minimum needed 718 data for setting up connections into SIP, so that the restriction 719 to SIP-carriable data can be verified. Not a rew on the browser 720 but rather on a document" 721 o - (see 722 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00227.html 723 for more details) 724 o -Added text on informing user of that mic/cam is being used and 725 that it must be possible to revoce permission to use them in 726 section 7. 727 Changes from draft-holmberg-rtcweb-ucreqs-01 728 o - Draft name changed to draft-ietf-rtcweb-ucreqs 729 o - Use-case grouping introduced 730 o - Additional use-cases added 731 o - Additional reqs added (derived from use cases): F19-F25, A16-A17 733 Changes from draft-holmberg-rtcweb-ucreqs-00 734 o - Mapping between use-cases and requirements added (Harald 735 Alvestrand, 090311) 736 o - Additional security considerations text (Harald Alvestrand, 737 090311) 738 o - Clarification that user applications are assumed to be executed 739 by a browser (Ted Hardie, 080311) 740 o - Editorial corrections and clarifications 742 11. References 743 11.1. Normative References 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, March 1997. 748 11.2. Informative References 750 Authors' Addresses 752 Christer Holmberg 753 Ericsson 754 Hirsalantie 11 755 Jorvas 02420 756 Finland 758 Email: christer.holmberg@ericsson.com 760 Stefan Hakansson 761 Ericsson 762 Laboratoriegrand 11 763 Lulea 97128 764 Sweden 766 Email: stefan.lk.hakansson@ericsson.com 768 Goran AP Eriksson 769 Ericsson 770 Farogatan 6 771 Stockholm 16480 772 Sweden 774 Email: goran.ap.eriksson@ericsson.com