idnits 2.17.1 draft-ietf-rtcweb-use-cases-and-requirements-05.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 (September 15, 2011) is 4600 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: March 18, 2012 Ericsson 6 September 15, 2011 8 Web Real-Time Communication Use-cases and Requirements 9 draft-ietf-rtcweb-use-cases-and-requirements-05.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 March 18, 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 . . . . . . . . . . . . 7 67 4.2.8. Multiparty on-line game with voice communication . . . 8 68 4.2.9. Distributed Music Band . . . . . . . . . . . . . . . . 8 69 4.3. Browser - GW/Server use cases . . . . . . . . . . . . . . 9 70 4.3.1. Telephony terminal . . . . . . . . . . . . . . . . . . 9 71 4.3.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . . 9 72 4.3.3. Video conferencing system with central server . . . . 10 73 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.2. Browser requirements . . . . . . . . . . . . . . . . . . . 11 76 5.3. API requirements . . . . . . . . . . . . . . . . . . . . . 13 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 15 80 7.2. Browser Considerations . . . . . . . . . . . . . . . . . . 15 81 7.3. Web Application Considerations . . . . . . . . . . . . . . 16 82 8. Additional use-cases . . . . . . . . . . . . . . . . . . . . . 16 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 84 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 87 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 This document presents a few use-cases 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 requirements related to the browser are named "Fn" and are 98 described in Section 5.2 100 The requirements related to the API are named "An" and are described 101 in Section 5.3 103 The document focuses on requirements related to real-time media 104 streams. Requirements related to privacy, signalling between the 105 browser and web server etc. are currently not considered. 107 2. Conventions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in BCP 14, RFC 2119 112 [RFC2119]. 114 3. Definitions 116 TBD 118 4. Use-cases 120 4.1. Introduction 122 This section describes web based real-time communication use-cases, 123 from which requirements are derived. 125 4.2. Browser-to-browser use-cases 127 4.2.1. Simple Video Communication Service 129 4.2.1.1. Description 131 Two or more users have loaded a video communication web application 132 into their browsers, provided by the same service provider, and 133 logged into the service it provides. The web service publishes 134 information about user login status by pushing updates to the web 135 application in the browsers. When one online user selects a peer 136 online user, a 1-1 video communication session between the browsers 137 of the two peers is initiated. The invited user might accept or 138 reject the session. 140 During session establishment a self-view is displayed, and once the 141 session has been established the video sent from the remote peer is 142 displayed in addition to the self-view. During the session, each 143 user can select to remove and re-insert the self-view as often as 144 desired. Each user can also change the sizes of his/her two video 145 displays during the session. Each user can also pause sending of 146 media (audio, video, or both) and mute incoming media 148 It is essential that the communication cannot be eavesdropped. 150 Any session participant can end the session at any time. 152 The two users may be using communication devices of different makes, 153 with different operating systems and browsers from different vendors. 155 One user has an unreliable Internet connection. It sometimes loses 156 packets, and sometimes goes down completely. 158 One user is located behind a Network Address Translator (NAT). 160 4.2.1.2. Derived Requirements 162 F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F22, F25 164 A1, A2, A3, A4, A5, A6, A7, A9, A10, A11, A12, A13 166 4.2.2. Simple Video Communication Service, NAT/FW that blocks UDP 168 4.2.2.1. Description 170 This use-case is almost identical to the previos one. The difference 171 is that one of the users is behind a NAT that blocks UDP traffic. 173 4.2.2.2. Derived Requirements 175 F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F22, F23, F25, F26 177 A1, A2, A3, A4, A5, A6, A7, A9, A10, A11, A12, A13 179 4.2.3. Simple Video Communication Service, access change 180 4.2.3.1. Description 182 This use-case is almost identical to "4.2.1 Simple Video 183 Communication Service". The difference is that the user changes 184 network access during the session: 186 The communication device used by one of the users have several 187 network adapters (Ethernet, WiFi, Cellular). The communication 188 device is accessing the Internet using Ethernet, but the user has to 189 start a trip during the session. The communication device 190 automatically changes to use WiFi when the Ethernet cable is removed 191 and then moves to cellular access to the Internet when moving out of 192 WiFi coverage. The session continues even though the access method 193 changes. 195 4.2.3.2. Derived Requirements 197 F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F22, F23, F25 199 A1, A2, A3, A4, A5, A6, A7, A9, A10, A11, A12, A13 201 4.2.4. Simple Video Communication Service, QoS 203 4.2.4.1. Description 205 This use-case is almost identical to the previous one. The use of 206 Quality of Service (QoS) capabilities is added: 208 The user in the previous use case that starts a trip is behind a 209 common residential router that supports prioritization of traffic. 210 In addition, the user's provider of cellular access has QoS support 211 enabled. The user is able to take advantage of the QoS support both 212 when accessing via the residential router and when using cellular. 214 4.2.4.2. Derived Requirements 216 F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F21, F22, F23, F25 218 A1, A2, A3, A4, A5, A6, A7, A9, A10, A11, A12, A13 220 4.2.5. Simple video communication service with inter-operator calling 222 4.2.5.1. Description 224 Two users have logged into two different web applications, provided 225 by different service providers. 227 The service providers are interconnected by some means, but exchange 228 no more information about the users than what can be carried using 229 SIP. 231 NOTE: More profiling of what this means may be needed. 233 For each user Alice who has authorized another user Bob to receive 234 login status information, Alice's service publishes Alice's login 235 status information to Bob. How this authorization is defined and 236 established is out of scope. 238 The same functionality as in the "4.2.1 Simple Video Communication 239 Service" is available. 241 The same issues with connectivity apply. 243 4.2.5.2. Derived requirements 245 F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F22, F24, F25 247 A1, A2, A3, A4, A5, A6, A7, A9, A10, A11, A12, A13 249 4.2.6. Hockey Game Viewer 251 4.2.6.1. Description 253 An ice-hockey club uses an application that enables talent scouts to, 254 in real-time, show and discuss games and players with the club 255 manager. The talent scouts use a mobile phone with two cameras, one 256 front facing and one rear facing. 258 The club manager uses a desktop, equipped with one camera, for 259 viewing the game and discussing with the talent scout. 261 Before the game starts, and during game breaks, the talent scout and 262 the manager have a 1-1 video communication. Only the rear facing 263 camera of the mobile phone is used. On the display of the mobile 264 phone, the video of the club manager is shown with a picture-in- 265 picture thumbnail of the rear facing camera (self-view). On the 266 display of the desktop, the video of the talent scout is shown with a 267 picture-in-picture thumbnail of the desktop camera (self-view). 269 When the game is on-going, the talent scout activates the use of the 270 front facing camera, and that stream is sent to the desktop (the 271 stream from the rear facing camera continues to be sent all the 272 time). The video stream captured by the front facing camera (that is 273 capturing the game) of the mobile phone is shown in a big window on 274 the desktop screen, with picture-in-picture thumbnails of the rear 275 facing camera and the desktop camera (self-view). On the display of 276 the mobile phone the game is shown (front facing camera) with 277 picture-in-picture thumbnails of the rear facing camera (self-view) 278 and the desktop camera. 280 It is essential that the communication cannot be eavesdropped. 282 4.2.6.2. Derived Requirements 284 F1, F2, F3, F4, F5, F6, F8, F9, F10, F14, F17 286 A1, A2, A3, A4, A5, A7, A9, A10, A11, A12, A13, A15 288 4.2.7. Multiparty video communication 290 4.2.7.1. Description 292 In this use-case the simple video communication service 293 Section 4.2.1is extended by allowing multiparty sessions. No central 294 server is involved - the browser of each participant sends and 295 receives streams to and from all other session participants. The web 296 application in the browser of each user is responsible for setting up 297 streams to all receivers. 299 In order to enhance intelligibility, the web application pans the 300 audio from different participants differently when rendering the 301 audio. This is done automatically, but users can change how the 302 different participants are placed in the (virtual) room. 304 Each video stream received is by default displayed in a thumbnail 305 frame within the browser, but users can change the display size. 307 It is essential that the communication cannot be eavesdropped. 309 Note: What this use-case adds in terms of requirements is 310 capabilities to send streams to and receive streams from several 311 peers concurrently, as well as the capabilities to render the video 312 from all recevied streams and be able to spatialize and mix the audio 313 from all received streams locally in the browser. 315 4.2.7.2. Derived Requirements 317 F1, F2, F3, F4, F5, F6, F8, F9, F10, F11, F12, F13, F14, F17, F22 319 A1, A2, A3, A4, A5, A6, A7, A9, A10, A11, A12, A13, A14, A15 321 4.2.8. Multiparty on-line game with voice communication 323 4.2.8.1. Description 325 This use case is based on the previous one. In this use-case, the 326 voice part of the multiparty video communication use case is used in 327 the context of an on-line game. The received voice audio media is 328 rendered together with game sound objects. For example, the sound of 329 a tank moving from left to right over the screen must be rendered and 330 played to the user together with the voice media. 332 Quick updates of the game state is required. 334 It is essential that the communication cannot be eavesdropped. 336 Note: the difference regarding local audio processing compared to the 337 "Multiparty video communication" use-case is that other sound objects 338 than the streams must be possible to be included in the 339 spatialization and mixing. "Other sound objects" could for example 340 be a file with the sound of the tank; that file could be stored 341 locally or remotely. 343 4.2.8.2. Derived Requirements 345 F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13, F15, F17, F20 347 A1, A2, A3, A4, A5, A7, A9, A10, A11, A12, A13, A14, A15, A16 349 4.2.9. Distributed Music Band 351 4.2.9.1. Description 353 In this use-case, a music band is playing music while the members are 354 at different physical locations. No central server is used, instead 355 all streams are set up in a mesh fashion. 357 Discussion: This use-case was briefly discussed at the Quebec webrtc 358 meeting and it got support. So far the only concrete requirement 359 (A17) derived is that the application must be able to ask the browser 360 to treat the audio signal as audio (in contrast to speech). However, 361 the use case should be further analysed to determine other 362 requirements (could be e.g. on delay mic->speaker, level control of 363 audio signals, etc.). 365 4.2.9.2. Derived Requirements 367 F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13 368 A1, A2, A3, A4, A5, A7, A9, A10, A11, A12, A13, A14, A15, A17 370 4.3. Browser - GW/Server use cases 372 4.3.1. Telephony terminal 374 4.3.1.1. Description 376 A mobile telephony operator allows its customers to use a web browser 377 to access their services. After a simple log in the user can place 378 and receive calls in the same way as when using a normal mobile 379 phone. When a call is received or placed, the identity is shown in 380 the same manner as when a mobile phone is used. 382 It is essential that the communication cannot be eavesdropped. 384 Note: With "place and receive calls in the same way as when using a 385 normal mobile phone" it is meant that you can dial a number, and that 386 your mobile telephony operator has made available your phone contacts 387 on line, so they are available and can be clicked to call, and be 388 used to present the identity of an incoming call. If the callee is 389 not in your phone contacts the number is displayed. Furthermore, 390 your call logs are available, and updated with the calls made/ 391 received from the browser. And for people receiving calls made from 392 the web browser the usual identity (i.e. the phone number of the 393 mobile phone) will be presented. 395 4.3.1.2. Derived Requirements 397 F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F18 399 A1, A2, A3, A4, A7, A9, A10, A11, A12, A13 401 4.3.2. Fedex Call 403 4.3.2.1. Description 405 Alice uses her web browser with a service something like Skype to be 406 able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should 407 be able to hear the initial prompts from the fedex IVR and when the 408 IVR says press 1, there should be a way for Alice to navigate the 409 IVR. 411 4.3.2.2. Derived Requirements 413 F1, F2, F3, F4, F5, F6, F8, F9, F10, F18, F19 415 A1, A2, A3, A4, A7, A9, A10, A11, A12, A13 417 4.3.3. Video conferencing system with central server 419 4.3.3.1. Description 421 An organization uses a video communication system that supports the 422 establishment of multiparty video sessions using a central conference 423 server. 425 The browser of each participant send an audio stream (type in terms 426 of mono, stereo, 5.1, ... depending on the equipment of the 427 participant) to the central server. The central server mixes the 428 audio streams (and can in the mixing process naturally add effects 429 such as spatialization) and sends towards each participant a mixed 430 audio stream which is played to the user. 432 The browser of each participant sends video towards the server. For 433 each participant one high resolution video is displayed in a large 434 window, while a number of low resolution videos are displayed in 435 smaller windows. The server selects what video streams to be 436 forwarded as main- and thumbnail videos respectively, based on speech 437 activity. As the video streams to display can change quite 438 frequently (as the conversation flows) it is important that the delay 439 from when a video stream is selected for display until the video can 440 be displayed is short. 442 The organization has an internal network set up with an aggressive 443 firewall handling access to the Internet. If users cannot physically 444 access the internal network, they can establish a Virtual Private 445 Network (VPN). 447 It is essential that the communication cannot be eavesdropped. 449 All participants are authenticated by the central server, and 450 authorized to connect to the central server. The participants are 451 identified to each other by the central server, and the participants 452 do not have access to each others' credentials such as e-mail 453 addresses or login IDs. 455 Note: This use-case adds requirements on support for fast stream 456 switches F7, on encryption of media and on ability to traverse very 457 restrictive FWs. There exist several solutions that enable the 458 server to forward one high resolution and several low resolution 459 video streams: a) each browser could send a high resolution, but 460 scalable stream, and the server could send just the base layer for 461 the low resolution streams, b) each browser could in a simulcast 462 fashion send one high resolution and one low resolution stream, and 463 the server just selects or c) each browser sends just a high 464 resolution stream, the server transcodes into low resolution streams 465 as required. 467 4.3.3.2. Derived Requirements 469 F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F14, F16, F17 471 A1, A2, A3, A4, A5, A7, A9, A10, A11, A12, A13, A15 473 5. Requirements 475 5.1. General 477 This section contains the requirements derived from the use-cases in 478 section 4. 480 NOTE: It is assumed that the user applications are executed on a 481 browser. Whether the capabilities to implement specific browser 482 requirements are implemented by the browser application, or are 483 provided to the browser application by the underlying operating 484 system, is outside the scope of this document. 486 5.2. Browser requirements 488 REQ-ID DESCRIPTION 489 --------------------------------------------------------------- 490 F1 The browser MUST be able to use microphones and 491 cameras as input devices to generate streams. 492 ---------------------------------------------------------------- 493 F2 The browser MUST be able to send streams to a 494 peer in the presence of NATs. 495 ---------------------------------------------------------------- 496 F3 Transmitted streams MUST be rate controlled. 497 ---------------------------------------------------------------- 498 F4 The browser MUST be able to receive, process and 499 render streams from peers. 500 ---------------------------------------------------------------- 501 F5 The browser MUST be able to render good quality 502 audio and video even in the presence of reasonable 503 levels of jitter and packet losses. 505 TBD: What is a reasonable level? 506 ---------------------------------------------------------------- 507 F6 The browser MUST be able to handle high loss and 508 jitter levels in a graceful way. 509 ---------------------------------------------------------------- 510 F7 The browser MUST support fast stream switches. 512 ---------------------------------------------------------------- 513 F8 The browser MUST detect when a stream from a 514 peer is not received anymore 515 ---------------------------------------------------------------- 516 F9 When there are both incoming and outgoing audio 517 streams, echo cancellation MUST be made available to 518 avoid disturbing echo during conversation. 520 QUESTION: How much control should be left to the 521 web application? 522 ---------------------------------------------------------------- 523 F10 The browser MUST support synchronization of 524 audio and video. 526 QUESTION: How much control should be left to the 527 web application? 528 ---------------------------------------------------------------- 529 F11 The browser MUST be able to transmit streams to 530 several peers concurrently. 531 ---------------------------------------------------------------- 532 F12 The browser MUST be able to receive streams from 533 multiple peers concurrently. 534 ---------------------------------------------------------------- 535 F13 The browser MUST be able to pan, mix and render 536 several concurrent audio streams. 537 ---------------------------------------------------------------- 538 F14 The browser MUST be able to render several 539 concurrent video streams 540 ---------------------------------------------------------------- 541 F15 The browser MUST be able to process and mix 542 sound objects (media that is retrieved from another 543 source than the established media stream(s) with the 544 peer(s) with audio streams). 545 ---------------------------------------------------------------- 546 F16 Streams MUST be able to pass through restrictive 547 firewalls. 548 ---------------------------------------------------------------- 549 F17 It MUST be possible to protect streams from 550 eavesdropping. 551 ---------------------------------------------------------------- 552 F18 The browser MUST support an audio media format 553 (codec) that is commonly supported by existing 554 telephony services. 556 QUESTION: G.711? 557 ---------------------------------------------------------------- 558 F19 There should be a way to navigate 559 the IVR 560 ---------------------------------------------------------------- 561 F20 The browser must be able to send short 562 latency datagram traffic to a peer browser 563 ---------------------------------------------------------------- 564 F21 The browser MUST be able to take advantage of 565 capabilities to prioritize voice and video 566 appropriately. 567 ---------------------------------------------------------------- 568 F22 The browser SHOULD use encoding of streams 569 suitable for the current rendering (e.g. 570 video display size) and SHOULD change parameters 571 if the rendering changes during the session 572 ---------------------------------------------------------------- 573 F23 It MUST be possible to move from one network 574 interface to another one 575 ---------------------------------------------------------------- 576 F24 The browser MUST be able to initiate and accept a 577 media session where the data needed for establishment 578 can be carried in SIP. 579 ---------------------------------------------------------------- 580 F25 The browser MUST support a baseline audio and 581 video codec 582 ---------------------------------------------------------------- 583 F26 The browser MUST be able to send streams to a 584 peer in the presence of NATs that block UDP traffic. 585 ---------------------------------------------------------------- 587 5.3. API requirements 589 REQ-ID DESCRIPTION 590 ---------------------------------------------------------------- 591 A1 The Web API MUST provide means for the 592 application to ask the browser for permission 593 to use cameras and microphones as input devices. 594 ---------------------------------------------------------------- 595 A2 The Web API MUST provide means for the web 596 application to control how streams generated 597 by input devices are used. 598 ---------------------------------------------------------------- 599 A3 The Web API MUST provide means for the web 600 application to control the local rendering of 601 streams (locally generated streams and streams 602 received from a peer). 603 ---------------------------------------------------------------- 604 A4 The Web API MUST provide means for the web 605 application to initiate sending of 606 stream/stream components to a peer. 607 ---------------------------------------------------------------- 608 A5 The Web API MUST provide means for the web 609 application to control the media format (codec) 610 to be used for the streams sent to a peer. 612 NOTE: The level of control depends on whether 613 the codec negotiation is handled by the browser 614 or the web application. 615 ---------------------------------------------------------------- 616 A6 The Web API MUST provide means for the web 617 application to modify the media format for 618 streams sent to a peer after a media stream 619 has been established. 620 ---------------------------------------------------------------- 621 A7 The Web API MUST provide means for 622 informing the web application of whether the 623 establishment of a stream with a peer was 624 successful or not. 625 ---------------------------------------------------------------- 626 A8 Removed. 627 ---------------------------------------------------------------- 628 A9 The Web API MUST provide means for the web 629 application to mute/unmute a stream or stream 630 component(s). When a stream is sent to a peer 631 mute status must be preserved in the stream 632 received by the peer. 633 ---------------------------------------------------------------- 634 A10 The Web API MUST provide means for the web 635 application to cease the sending of a stream 636 to a peer. 637 ---------------------------------------------------------------- 638 A11 The Web API MUST provide means for the web 639 application to cease processing and rendering 640 of a stream received from a peer. 641 ---------------------------------------------------------------- 642 A12 The Web API MUST provide means for 643 informing the web application when a 644 stream from a peer is no longer received. 645 ---------------------------------------------------------------- 646 A13 The Web API MUST provide means for 647 informing the web application when high 648 loss rates occur. 649 ---------------------------------------------------------------- 650 A14 The Web API MUST provide means for the web 651 application to control panning, mixing and 652 other processing for streams. 653 ---------------------------------------------------------------- 654 A15 For each stream generated, the Web API MUST provide 655 an identifier that is accessible by the application. 656 The identifier MUST be accessible also for a peer 657 receiving that stream and MUST be unique relative 658 to all other stream identifiers in use by either party. 659 ---------------------------------------------------------------- 660 A16 In addition to the streams listed elsewhere, 661 the Web API MUST provide a mechanism for sending 662 and receiving isolated discrete chunks of data. 663 ---------------------------------------------------------------- 664 A17 The Web API MUST provide means for the web 665 application indicate the type of audio signal 666 (speech, audio)for audio stream(s)/stream component(s). 667 ---------------------------------------------------------------- 668 A18 It must be possible for an initiator or a 669 responder Web application to indicate the types 670 of media he's willing to accept incoming streams 671 for when setting up a connection (audio, video, 672 other). The types of media he's willing to accept 673 can be a subset of the types of media the browser 674 is able to accept. 675 ---------------------------------------------------------------- 677 6. IANA Considerations 679 TBD 681 7. Security Considerations 683 7.1. Introduction 685 A malicious web application might use the browser to perform Denial 686 Of Service (DOS) attacks on NAT infrastructure, or on peer devices. 687 Also, a malicious web application might silently establish outgoing, 688 and accept incoming, streams on an already established connection. 690 Based on the identified security risks, this section will describe 691 security considerations for the browser and web application. 693 7.2. Browser Considerations 695 The browser is expected to provide mechanisms for getting user 696 consent to use device resources such as camera and microphone. 698 The browser is expected to provide mechanisms for informing the user 699 that device resources such as camera and microphone are in use 700 ("hot"). 702 The browser is expected to provide mechanisms for users to revise and 703 even completely revoke consent to use device resources such as camera 704 and microphone. 706 The browser is expected to provide mechanisms in order to assure that 707 streams are the ones the recipient intended to receive. 709 The browser needs to ensure that media is not sent, and that received 710 media is not rendered, until the associated stream establishment and 711 handshake procedures with the remote peer have been successfully 712 finished. 714 The browser needs to ensure that the stream negotiation procedures 715 are not seen as Denial Of Service (DOS) by other entities. 717 7.3. Web Application Considerations 719 The web application is expected to ensure user consent in sending and 720 receiving media streams. 722 8. Additional use-cases 724 Several additional use-cases have been discussed. At this point 725 these use-cases are not included as requirement deriving use-cases 726 for different reasons (lack of documentation, overlap with existing 727 use-cases, lack of consensus). For completeness these additional 728 use-cases are listed below: 729 1. Use-cases regarding different situations when being invited to a 730 "session", e.g. browser open, browser open but another tab 731 active, browser open but active in session, browser closed, .... 732 (Matthew Kaufman); discussed at webrtc meeting 733 2. Different TURN provider scenarios (Cullen Jennings); discussed 734 at the webrtc meeting. Proposed text in http://lists.w3.org/ 735 Archives/Public/public-webrtc/2011Aug/0133.html 736 3. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/ 737 rtcweb/current/msg00525.html, followed up by Stephan Wenger 738 4. Local Recording and Remote recording (John): Discussed a _lot_ 739 on the mail lists (rtcweb as well as public-webrtc) lAugust and 740 September 2011. Concrete proposal: http://www.ietf.org/ 741 mail-archive/web/rtcweb/current/msg01006.html (remote) and http: 742 //www.ietf.org/mail-archive/web/rtcweb/current/msg00734.html 743 (local) 744 5. Emergency access for disabled (Bernard Aboba) http:// 745 www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html 747 6. Clue use-cases (Roni Even) http://tools.ietf.org/html/ 748 draft-ietf-clue-telepresence-use-cases-01 749 7. Rohan red cross (Cullen Jennings); http://www.ietf.org/ 750 mail-archive/web/rtcweb/current/msg00323.html 751 8. Remote assistance (ala VNC or RDP) - User is helping another 752 user on their computer with either view-only or view-with- 753 control, either of just the browser of the the entire screen. ht 754 tp://www.ietf.org/mail-archive/web/rtcweb/current/msg00543.html 755 9. Security camera/baby monitor usage http://www.ietf.org/ 756 mail-archive/web/rtcweb/current/msg00543.html 757 10. Large multiparty session http://www.ietf.org/mail-archive/web/ 758 rtcweb/current/msg00530.html 760 9. Acknowledgements 762 Dan Burnett has reviewed and proposed a lot of things that enhances 763 the document. Most of this has been incorporated in rev -05. 765 Stephan Wenger has provided a lot of useful input and feedback, as 766 well as editorial comments. 768 Harald Alvestrand and Ted Hardie have provided comments and feedback 769 on the draft. 771 Harald Alvestrand and Cullen Jennings have provided additional use- 772 cases. 774 Thank You to everyone in the RTCWEB community that have provided 775 comments, feedback and improvement proposals on the draft content. 777 10. Change Log 779 [RFC EDITOR NOTE: Please remove this section when publishing] 781 Changes from draft-ietf-rtcweb-use-cases-and-requirements-04 783 o Most changes based on the input from Dan Burnett 784 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00948.html 785 o Many editorial changes 786 o 4.2.1.1 Clarified 787 o Some clarification added to 4.3.1.1 as a note 788 o F-requirements updated (see reply to Dan's mail). 789 o Almost all A-requirements updated to start "The Web API MUST 790 provide ..." 792 o A8 removed, A9 rephrased to cover A8 and old A9 793 o A15 rephrased 794 o For more details, and discussion, look att the response to Dan's 795 mail 796 http://www.ietf.org/mail-archive/web/rtcweb/current/msg01177.html 798 Changes from draft-ietf-rtcweb-use-cases-and-requirements-03 800 o Editorials 801 o Changed when the self-view is displayed in 4.2.1.1, and added 802 words about allowing users to remove and re-insert it. 803 o Clarified 4.2.6.1 804 o Removed the "mono" stuff from 4.2.7.1 805 o Added that communication should not be possible to eavesdrop to 806 most use cases - and req. F17 807 o Re-phrased 4.3.3.1 to not describe the technical solution so much, 808 and removed "stereo" stuff. Solution possibilities are now in a 809 note. 810 o Re-inserted API requirements after discussion in the W3C webrtc 811 WG. (Re-phrased A15 and added A18 compared to version -02). 813 Changes from draft-ietf-rtcweb-use-cases-and-requirements-02 815 o Removed desrciption/list of API requirements, instead 816 o Reference to W3C webrtc_reqs document for API requirements 818 Changes from draft-ietf-rtcweb-ucreqs-01 820 o Changed Intended status to Information 821 o Changed "Ipr" to "trust200902" 822 o Added use case "Simple video communication service, NAT/FW that 823 blocks UDP", and derived new req F26 824 o Added use case "Distributed Music Band" and derived new req A17 825 o Added F24 as requirement derived from use case "Simple video 826 communication service with inter-operator calling" 827 o Added section "Additional use cases" 828 o Added text about ID handling to multiparty with central server use 829 case 830 o Re-phrased A1 slightly 832 Changes from draft-ietf-rtcweb-ucreqs-00 834 o - Reshuffled: Just two main groups of use cases (b2b and b2GW/ 835 Server); removed some specific use cases and added them instead as 836 flavors to the base use case (Simple video communciation) 837 o - Changed the fromulation of F19 838 o - Removed the requirement on an API for DTMF 839 o - Removed "FX3: There SHOULD be a mapping of the minimum needed 840 data for setting up connections into SIP, so that the restriction 841 to SIP-carriable data can be verified. Not a rew on the browser 842 but rather on a document" 843 o - (see 844 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00227.html 845 for more details) 846 o -Added text on informing user of that mic/cam is being used and 847 that it must be possible to revoce permission to use them in 848 section 7. 849 Changes from draft-holmberg-rtcweb-ucreqs-01 850 o - Draft name changed to draft-ietf-rtcweb-ucreqs 851 o - Use-case grouping introduced 852 o - Additional use-cases added 853 o - Additional reqs added (derived from use cases): F19-F25, A16-A17 855 Changes from draft-holmberg-rtcweb-ucreqs-00 856 o - Mapping between use-cases and requirements added (Harald 857 Alvestrand, 090311) 858 o - Additional security considerations text (Harald Alvestrand, 859 090311) 860 o - Clarification that user applications are assumed to be executed 861 by a browser (Ted Hardie, 080311) 862 o - Editorial corrections and clarifications 864 11. References 866 11.1. Normative References 868 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 869 Requirement Levels", BCP 14, RFC 2119, March 1997. 871 11.2. Informative References 873 [webrtc_reqs] 874 "Webrt requirements, 875 http://dev.w3.org/2011/webrtc/editor/webrtc_reqs.html". 877 Authors' Addresses 879 Christer Holmberg 880 Ericsson 881 Hirsalantie 11 882 Jorvas 02420 883 Finland 885 Email: christer.holmberg@ericsson.com 887 Stefan Hakansson 888 Ericsson 889 Laboratoriegrand 11 890 Lulea 97128 891 Sweden 893 Email: stefan.lk.hakansson@ericsson.com 895 Goran AP Eriksson 896 Ericsson 897 Farogatan 6 898 Stockholm 16480 899 Sweden 901 Email: goran.ap.eriksson@ericsson.com