idnits 2.17.1 draft-ietf-rtcweb-use-cases-and-requirements-04.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 4 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 1, 2011) is 4614 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 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 4, 2012 Ericsson 6 September 1, 2011 8 Web Real-Time Communication Use-cases and Requirements 9 draft-ietf-rtcweb-use-cases-and-requirements-04.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 4, 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 . . . 7 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 . . . . 9 73 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . 15 82 8. Additional use-cases . . . . . . . . . . . . . . . . . . . . . 16 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 84 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 87 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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 In the service the users have loaded, and logged into, a video 132 communication web application into their browsers, provided by the 133 same service provider. The web service publishes information about 134 user login status, by pushing updates to the web application in the 135 browsers. By selecting an online peer user, a 1-1 video 136 communication session between the browsers of the peers is initiated. 137 The invited user might accept or reject the session. 139 During session establishment a self-view is displayed, and once the 140 session has been established the video sent from the remote peer is 141 displayed displayed in addition to the self-view. The users can 142 during the session select to remove, and re-insert the self-view. 143 The users can change the sizes of the video displays during the 144 session. The users can also pause sending of media (audio, video, or 145 both), and mute incoming media. 147 It is essential that the communication can not be eavesdropped. 149 Any session participant can end the session at any time. 151 The users are using communication devices of different makes, with 152 different operating systems and browsers from different vendors. 154 One user has an unreliable Internet connection. It sometimes has 155 packet losses, and is sometimes goes down completely. 157 One user is located behind a Network Address Translator (NAT). 159 4.2.1.2. Derived Requirements 161 F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F22, F25 163 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 165 4.2.2. Simple Video Communication Service, NAT/FW that blocks UDP 167 4.2.2.1. Description 169 This use-case is almost identical to the previos one. The difference 170 is that one of the users is behind a NAT that blocks UDP traffic. 172 4.2.2.2. Derived Requirements 174 F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F22, F23, F25, F26 176 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 178 4.2.3. Simple Video Communication Service, access change 179 4.2.3.1. Description 181 This use-case is almost identical to "4.2.1 Simple Video 182 Communication Service". The difference is that the user changes 183 network access during the session: 185 The communication device used by one of the users have several 186 network adapters (Ethernet, WiFi, Cellular). The communication 187 device is access the Internet using Ethernet, but the user has to 188 start a trip during the session. The communication device 189 automatically changes to use WiFi when the Ethernet cable is removed 190 and then moves to cellular access to the Internet when moving out of 191 WiFi coverage. The session continues even though the access method 192 changes. 194 4.2.3.2. Derived Requirements 196 F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F22, F23, F25 198 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 200 4.2.4. Simple Video Communication Service, QoS 202 4.2.4.1. Description 204 This use-case is almost identical to the previos one. The use of QoS 205 capabilities is added: 207 The user in the previous use case that starts a trip is behind a 208 common residential router that supports prioritization of traffic. 209 In addition, the user's provider of cellular access has QoS support 210 enabled. The user is able to take advantage of the QoS support both 211 when accessing via the residential router and when using cellular. 213 4.2.4.2. Derived Requirements 215 F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F21, F22, F23, F25 217 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 219 4.2.5. Simple video communication service with inter-operator calling 221 4.2.5.1. Description 223 Two users have logged into two different web applications, provided 224 by different service providers. 226 The service providers are interconnected by some means, but exchange 227 no more information about the users than what can be carried using 228 SIP. 230 NOTE: More profiling of what this means may be needed. 232 Each web service publishes information about user login status for 233 users that have a relationship with the other user; how this is 234 established is out of scope. 236 The same functionality as in the "4.2.1 Simple Video Communication 237 Service" is available. 239 The same issues with connectivity apply. 241 4.2.5.2. Derived requirements 243 F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F22, F24, F25 245 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 247 4.2.6. Hockey Game Viewer 249 4.2.6.1. Description 251 An ice-hockey club uses an application that enables talent scouts to, 252 in real-time, show and discuss games and players with the club 253 manager. The talent scouts use a mobile phone with two cameras, one 254 front facing and one rear facing. 256 The club manager uses a desktop, equipped with one camera, for 257 viewing the game and discussing with the talent scout. 259 Before the game starts, and during game breaks, the talent scout and 260 the manager have a 1-1 video communication. Only the rear facing 261 camera of the mobile phone is used. On the display of the mobile 262 phone, the video of the club manager is shown with a picture-in- 263 picture thumbnail of the rear facing camera (self-view). On the 264 display of the desktop, the video of the talent scout is shown with a 265 picture-in-picture thumbnail ot the desktop camera (self-view). 267 When the game is on-going, the talent scout activates the use of the 268 front facing camera, and that stream is sent to the desktop (the 269 stream from the rear facing camera continues to be sent all the 270 time). The video stream captured by the front facing camera (that is 271 capturing the game) of the mobile phone is shown in a big window on 272 the desktop screen, with picture-in-picture thumbnails of the rear 273 facing camera and the desktop camera (self-view). On the display of 274 the mobile phone the game is shown (front facing camera) with 275 picture-in-picture thumbnails of the rear facing camera (self-view) 276 and the desktop camera. 278 It is essential that the communication can not be eavesdropped. 280 4.2.6.2. Derived Requirements 282 F1, F2, F3, F4, F5, F6, F8, F9, F10, F14, F17 284 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A15 286 4.2.7. Multiparty video communication 288 4.2.7.1. Description 290 In this use-case the simple video communication service is extended 291 by allowing multiparty sessions. No central server is involved - the 292 browser of each participant sends and receives streams to and from 293 all other session participants. The web application in the browser 294 of each user is responsible for setting up streams to all receivers. 296 In order to enhance intelligibility, the web application pans the 297 audio from different participants differently when rendering the 298 audio. This is done automatically, but users can change how the 299 different participants are placed in the (virtual) room. 301 Each video stream received is by default displayed in a thumbnail 302 frame within the browser, but users can change the display size. 304 It is essential that the communication can not be eavesdropped. 306 Note: What this use-case adds in terms of requirements is 307 capabilities to send streams to and receive streams from several 308 peers concurrently, as well as the capabilities to render the video 309 from all recevied streams and be able to spatialize and mix the audio 310 from all received streams locally in the browser. 312 4.2.7.2. Derived Requirements 314 F1, F2, F3, F4, F5, F6, F8, F9, F10, F11, F12, F13, F14, F17, F22 316 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15 318 4.2.8. Multiparty on-line game with voice communication 319 4.2.8.1. Description 321 In this use-case, the voice part of the multiparty video 322 communication application is used in the context of an on-line game. 323 The received voice audio media is rendered together with game sound 324 objects. For example, the sound of a tank moving from left to right 325 over the screen must be rendered and played to the user together with 326 the voice media. 328 Quick updates of the game state is required. 330 It is essential that the communication can not be eavesdropped. 332 Note: the difference regarding local audio processing compared to the 333 "Multiparty video communication" use-case is that other sound objects 334 than the streams must be possible to be included in the 335 spatialization and mixing. "Other sound objects" could for example 336 be a file with the sound of the tank, that file could be stored 337 locally or remotely. 339 4.2.8.2. Derived Requirements 341 F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13, F15, F17, F20 343 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16 345 4.2.9. Distributed Music Band 347 4.2.9.1. Description 349 In this use-case, a music band is playing music while the members are 350 at different physical locations. No central server is used, instead 351 all streams are set up in a mesh fashion. 353 Discussion: This use-case was briefly discussed at the Quebec webrtc 354 meeting and it got support. So far the only concrete requirement 355 (A17) derived is that the application must be able to ask the browser 356 to treat the audio signal as audio (in contrast to speech). However, 357 the use case should be further analysed to determine other 358 requirements (could be e.g. on delay mic->speaker, level control of 359 audio signals, etc.). 361 4.2.9.2. Derived Requirements 363 F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13 365 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A17 367 4.3. Browser - GW/Server use cases 369 4.3.1. Telephony terminal 371 4.3.1.1. Description 373 A mobile telephony operator allows its customers to use a web browser 374 to access their services. After a simple log in the user can place 375 and receive calls in the same way as when using a normal mobile 376 phone. When a call is received or placed, the identity is shown in 377 the same manner as when a mobile phone used. 379 It is essential that the communication can not be eavesdropped. 381 4.3.1.2. Derived Requirements 383 F1, F2, F3, F4, F5, F6, F8, F9, F10, F17, F18 385 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A13 387 4.3.2. Fedex Call 389 4.3.2.1. Description 391 Alice uses her web browser with a service something like Skype to be 392 able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should 393 be able to hear the initial prompts from the fedex IVR and when the 394 IVR says press 1, there should be a way for Alice to navigate the 395 IVR. 397 4.3.2.2. Derived Requirements 399 F1, F2, F3, F4, F5, F6, F8, F9, F10, F18, F19 401 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A13 403 4.3.3. Video conferencing system with central server 405 4.3.3.1. Description 407 An organization uses a video communication system that supports the 408 establishment of multiparty video sessions using a central conference 409 server. 411 The browsers of each participant send an audio stream (type in terms 412 of mono, stereo, 5.1, ... depending on the equipment of the 413 participant) to the central server. The central server mixes the 414 audio streams (and can in the mixing process naturally add effects 415 such as spatialization) and sends towards each participant a mixed 416 audio stream which is played to the user. 418 The browser of each participant sends video towards the server. For 419 each participant one high resolution video is displayed in a large 420 window, while a number of low resolution videos are displayed in 421 smaller windows. The server selects what video streams to be 422 forwarded as main- and thumbnail videos respectively, based on speech 423 activity. As the video streams to display can change quite 424 frequently (as the conversation flows) it is important that the delay 425 from when a video stream is selected for display until the video can 426 be displayed is short. 428 The organization has an internal network set up with an aggressive 429 firewall handling access to the Internet. If users can not 430 physically access the internal network, they can establish a Virtual 431 Private Network (VPN). 433 It is essential that the communication can not be eavesdropped. 435 All participant are authenticated by the central server, and 436 authorized to connect to the central server. The participants are 437 identified to each other by the central server, and the participants 438 do not have access to each others' credentials such as e-mail 439 addresses or login IDs. 441 Note: This use-case adds requirements on support for fast stream 442 switches F7, on encryption of media and on ability to traverse very 443 restrictive FWs. There exists several solutions that enable the 444 server to forward one high resolution and several low resolution 445 video streams: a) each browser could send a high resolution, but 446 scalable stream, and the server could send just the base layer for 447 the low resolution streams, b) each browser could in a simulcast 448 fashion send one high resolution and one low resolution stream, the 449 server just selects, c) each browser sends just an high resolution 450 stream, the server trancodes into low reslution streams as required. 452 4.3.3.2. Derived Requirements 454 F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F14, F16, F17 456 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A15 458 5. Requirements 459 5.1. General 461 This section contains the requirements derived from the use-cases in 462 section 4. 464 NOTE: It is assumed that the user applications are executed on a 465 browser. Whether the capabilities to implement specific browser 466 requirements are implemented by the browser application, or are 467 provided to the browser application by the underlying operating 468 system, is outside the scope of this document. 470 5.2. Browser requirements 472 REQ-ID DESCRIPTION 473 --------------------------------------------------------------- 474 F1 The browser MUST be able to use microphones and 475 cameras as input devices to generate streams. 476 ---------------------------------------------------------------- 477 F2 The browser MUST be able to send streams to a 478 peer in presence of NATs. 479 ---------------------------------------------------------------- 480 F3 Transmitted streams MUST be rate controlled. 481 ---------------------------------------------------------------- 482 F4 The browser MUST be able to receive, process and 483 render streams from peers. 484 ---------------------------------------------------------------- 485 F5 The browser MUST be able to render good quality 486 audio and video even in presence of reasonable 487 levels of jitter and packet losses. 489 TBD: What is a reasonable level? 490 ---------------------------------------------------------------- 491 F6 The browser MUST be able to handle high loss and 492 jitter levels in a graceful way. 493 ---------------------------------------------------------------- 494 F7 The browser MUST support fast stream switches. 495 ---------------------------------------------------------------- 496 F8 The browser MUST detect when a stream from a 497 peer is not received any more 498 ---------------------------------------------------------------- 499 F9 When there are both incoming and outgoing audio 500 streams, echo cancellation MUST be made available to 501 avoid disturbing echo during conversation. 503 QUESTION: How much control should be left to the 504 web application? 505 ---------------------------------------------------------------- 506 F10 The browser MUST support synchronization of 507 audio and video. 509 QUESTION: How much control should be left to the 510 web application? 511 ---------------------------------------------------------------- 512 F11 The browser MUST be able to transmit streams to 513 several peers concurrently. 514 ---------------------------------------------------------------- 515 F12 The browser MUST be able to receive streams from 516 multiple peers concurrently. 517 ---------------------------------------------------------------- 518 F13 The browser MUST be able to pan, mix and render 519 several concurrent audio streams. 520 ---------------------------------------------------------------- 521 F14 The browser MUST be able to render several 522 concurrent video streams 523 ---------------------------------------------------------------- 524 F15 The browser MUST be able to process and mix 525 sound objects (media that is retrieved from another 526 source than the established media stream(s) with the 527 peer(s) with audio streams). 528 ---------------------------------------------------------------- 529 F16 Streams MUST be able to pass through restrictive 530 firewalls. 531 ---------------------------------------------------------------- 532 F17 It MUST be possible to protect streams from 533 eavesdropping. 534 ---------------------------------------------------------------- 535 F18 The browser MUST support an audio media format 536 (codec) that is commonly supported by existing 537 telephony services. 539 QUESTION: G.711? 540 ---------------------------------------------------------------- 541 F19 there should be a way to navigate 542 the IVR 543 ---------------------------------------------------------------- 544 F20 The browser must be able to send short 545 latency datagram traffic to a peer browser 546 ---------------------------------------------------------------- 547 F21 The browser MUST be able to take advantage of 548 capabilities to prioritize voice and video 549 appropriately. 550 ---------------------------------------------------------------- 551 F22 The browser SHOULD use encoding of streams 552 suitable for the current rendering (e.g. 554 video display size) and SHOULD change parameters 555 if the rendering changes during the session 556 ---------------------------------------------------------------- 557 F23 It MUST be possible to move from one network 558 interface to another one 559 ---------------------------------------------------------------- 560 F24 The browser MUST be able to initiate and accept a 561 media session where the data needed for establishment 562 can be carried in SIP. 563 ---------------------------------------------------------------- 564 F25 The browser MUST support a baseline audio and 565 video codec 566 ---------------------------------------------------------------- 567 F26 The browser MUST be able to send streams to a 568 peer in presence of NATs that block UDP traffic. 569 ---------------------------------------------------------------- 571 5.3. API requirements 573 REQ-ID DESCRIPTION 574 ---------------------------------------------------------------- 575 A1 The web application MUST be able to ask the 576 browser for permission to use cameras 577 and microphones as input devices. 578 ---------------------------------------------------------------- 579 A2 The web application MUST be able to control how 580 streams generated by input devices are used. 581 ---------------------------------------------------------------- 582 A3 The web application MUST be able to control the 583 local rendering of streams (locally generated streams 584 and streams received from a peer). 585 ---------------------------------------------------------------- 586 A4 The web application MUST be able to initiate 587 sending of stream/stream components to a peer. 588 ---------------------------------------------------------------- 589 A5 The web application MUST be able to control the 590 media format (codec) to be used for the streams 591 sent to a peer. 593 NOTE: The level of control depends on whether 594 the codec negotiation is handled by the browser 595 or the web application. 596 ---------------------------------------------------------------- 597 A6 After a media stream has been established, the 598 web application MUST be able to modify the media 599 format for streams sent to a peer. 600 ---------------------------------------------------------------- 601 A7 The web application MUST be made aware of 602 whether the establishment of a stream with a 603 peer was successful or not. 604 ---------------------------------------------------------------- 605 A8 The web application MUST be able to 606 pause/unpause the sending of a stream to a peer. 607 ---------------------------------------------------------------- 608 A9 The web application MUST be able to mute/unmute 609 a stream received from a peer. 610 ---------------------------------------------------------------- 611 A10 The web application MUST be able to cease the 612 sending of a stream to a peer. 613 ---------------------------------------------------------------- 614 A11 The web application MUST be able to cease 615 processing and rendering of a stream received 616 from a peer. 617 ---------------------------------------------------------------- 618 A12 The web application MUST be informed when a 619 stream from a peer is no longer received. 620 ---------------------------------------------------------------- 621 A13 The web application MUST be informed when high 622 loss rates occur. 623 ---------------------------------------------------------------- 624 A14 It MUST be possible for the web application to 625 control panning, mixing and other processing for 626 individual streams. 627 ---------------------------------------------------------------- 628 A15 The Web application must be provided with an 629 identifier for the stream that can be communicated 630 to the other party of the communication, and which 631 the other party can associate with its end of the 632 same stream. 633 ---------------------------------------------------------------- 634 A16 It MUST be possible for the web application to 635 send and receive datagrams to/from peer 636 ---------------------------------------------------------------- 637 A17 It MUST be possible for the web application to 638 indicate the type of audio signal (speech, audio) 639 ---------------------------------------------------------------- 640 A18 It must be possible for an initiator or a 641 responder Web application to indicate the types 642 of media he's willing to accept incoming streams 643 for when setting up a connection (audio, video, 644 other). The types of media he's willing to accept 645 can be a subset of the types of media the browser 646 is able to accept. 647 ---------------------------------------------------------------- 649 6. IANA Considerations 651 TBD 653 7. Security Considerations 655 7.1. Introduction 657 A malicious web application might use the browser to perform Denial 658 Of Service (DOS) attacks on NAT infrastructure, or on peer devices. 659 Also, a malicious web application might silently establish outgoing, 660 and accept incoming, streams on an already established connection. 662 Based on the identified security risks, this section will describe 663 security considerations for the browser and web application. 665 7.2. Browser Considerations 667 The browser is expected to provide mechanisms for getting user 668 consent to use device resources such as camera and microphone. 670 The browser is expected to provide mechanisms for informing the user 671 that device resources such as camera and microphone are in use 672 ("hot"). 674 The browser is expected to provide mechanisms for users to revise 675 consent to use device resources such as camera and microphone. 677 The browser is expected to provide mechanisms in order to assure that 678 streams are the ones the recipient intended to receive. 680 The browser is needs to ensure that media is not sent, and that 681 received media is not rendered, until the associated stream 682 establishment and handshake procedures with the remote peer have been 683 successfully finished. 685 The browser needs to ensure that the stream negotiation procedures 686 are not seen as Denial Of Service (DOS) by other entities. 688 7.3. Web Application Considerations 690 The web application is expected to ensure user consent in sending and 691 receiving media streams. 693 8. Additional use-cases 695 Several additional use-cases have been discussed. At this point 696 these use-cases are not included as requirement deriving use-cases 697 for different reasons (lack of documentation, overlap with existing 698 use-cases, lack of consensus). For completeness these additional 699 use-cases are listed below: 700 1. Use-cases regarding different situations when being invited to a 701 "session", e.g. browser open, browser open but another tab 702 active, browser open but active in session, browser closed, .... 703 (Matthew Kaufman); discussed at webrtc meeting 704 2. Different TURN provider scenarios (Cullen Jennings); discussed 705 at the webrtc meeting 706 3. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/ 707 rtcweb/current/msg00525.html, followed up by Stephan Wenger 708 4. Local Recording and Remote recording (John): Discussed a _lot_ 709 on the mail lists (rtcweb as well as public-webrtc) late August 710 2011. Not concluded at time of writing. 711 5. Emergency access for disabled (Bernard Aboba) http:// 712 www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html 713 6. Clue use-cases (Roni Even) http://tools.ietf.org/html/ 714 draft-ietf-clue-telepresence-use-cases-01 715 7. Rohan red cross (Cullen Jennings); http://www.ietf.org/ 716 mail-archive/web/rtcweb/current/msg00323.html 717 8. Remote assistance (ala VNC or RDP) - User is helping another 718 user on their computer with either view-only or view-with- 719 control, either of just the browser of the the entire screen. ht 720 tp://www.ietf.org/mail-archive/web/rtcweb/current/msg00543.html 721 9. Security camera/baby monitor usage http://www.ietf.org/ 722 mail-archive/web/rtcweb/current/msg00543.html 723 10. Large multiparty session http://www.ietf.org/mail-archive/web/ 724 rtcweb/current/msg00530.html 726 9. Acknowledgements 728 Stephan Wenger has provided a lot of useful input and feedback, as 729 well as editorial comments. 731 Harald Alvestrand and Ted Hardie have provided comments and feedback 732 on the draft. 734 Harald Alvestrand and Cullen Jennings have provided additional use- 735 cases. 737 Thank You to everyone in the RTCWEB community that have provided 738 comments, feedback and improvement proposals on the draft content. 740 10. Change Log 742 [RFC EDITOR NOTE: Please remove this section when publishing] 744 Changes from draft-ietf-rtcweb-use-cases-and-requirements-03 746 o Editorials 747 o Changed when the self-view is displayed in 4.2.1.1, and added 748 words about allowing users to remove and re-insert it. 749 o Clarified 4.2.6.1 750 o Removed the "mono" stuff from 4.2.7.1 751 o Added that communication should not be possible to eavesdrop to 752 most use cases - and req. F17 753 o Re-phrased 4.3.3.1 to not describe the technical solution so much, 754 and removed "stereo" stuff. Solution possibilities are now in a 755 note. 756 o Re-inserted API requirements after discussion in the W3C webrtc 757 WG. (Re-phrased A15 and added A18 compared to version -02). 759 Changes from draft-ietf-rtcweb-use-cases-and-requirements-02 761 o Removed desrciption/list of API requirements, instead 762 o Reference to W3C webrtc_reqs document for API requirements 764 Changes from draft-ietf-rtcweb-ucreqs-01 766 o Changed Intended status to Information 767 o Changed "Ipr" to "trust200902" 768 o Added use case "Simple video communication service, NAT/FW that 769 blocks UDP", and derived new req F26 770 o Added use case "Distributed Music Band" and derived new req A17 771 o Added F24 as requirement derived from use case "Simple video 772 communication service with inter-operator calling" 773 o Added section "Additional use cases" 774 o Added text about ID handling to multiparty with central server use 775 case 776 o Re-phrased A1 slightly 778 Changes from draft-ietf-rtcweb-ucreqs-00 780 o - Reshuffled: Just two main groups of use cases (b2b and b2GW/ 781 Server); removed some specific use cases and added them instead as 782 flavors to the base use case (Simple video communciation) 783 o - Changed the fromulation of F19 784 o - Removed the requirement on an API for DTMF 785 o - Removed "FX3: There SHOULD be a mapping of the minimum needed 786 data for setting up connections into SIP, so that the restriction 787 to SIP-carriable data can be verified. Not a rew on the browser 788 but rather on a document" 789 o - (see 790 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00227.html 791 for more details) 792 o -Added text on informing user of that mic/cam is being used and 793 that it must be possible to revoce permission to use them in 794 section 7. 795 Changes from draft-holmberg-rtcweb-ucreqs-01 796 o - Draft name changed to draft-ietf-rtcweb-ucreqs 797 o - Use-case grouping introduced 798 o - Additional use-cases added 799 o - Additional reqs added (derived from use cases): F19-F25, A16-A17 801 Changes from draft-holmberg-rtcweb-ucreqs-00 802 o - Mapping between use-cases and requirements added (Harald 803 Alvestrand, 090311) 804 o - Additional security considerations text (Harald Alvestrand, 805 090311) 806 o - Clarification that user applications are assumed to be executed 807 by a browser (Ted Hardie, 080311) 808 o - Editorial corrections and clarifications 810 11. References 812 11.1. Normative References 814 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 815 Requirement Levels", BCP 14, RFC 2119, March 1997. 817 11.2. Informative References 819 [webrtc_reqs] 820 "Webrt requirements, 821 http://dev.w3.org/2011/webrtc/editor/webrtc_reqs.html". 823 Authors' Addresses 825 Christer Holmberg 826 Ericsson 827 Hirsalantie 11 828 Jorvas 02420 829 Finland 831 Email: christer.holmberg@ericsson.com 832 Stefan Hakansson 833 Ericsson 834 Laboratoriegrand 11 835 Lulea 97128 836 Sweden 838 Email: stefan.lk.hakansson@ericsson.com 840 Goran AP Eriksson 841 Ericsson 842 Farogatan 6 843 Stockholm 16480 844 Sweden 846 Email: goran.ap.eriksson@ericsson.com