idnits 2.17.1 draft-ietf-rtcweb-use-cases-and-requirements-15.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 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 (December 17, 2014) is 3417 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7258' is mentioned on line 846, but not defined ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) Summary: 1 error (**), 0 flaws (~~), 3 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: June 20, 2015 Ericsson 6 December 17, 2014 8 Web Real-Time Communication Use-cases and Requirements 9 draft-ietf-rtcweb-use-cases-and-requirements-15.txt 11 Abstract 13 This document describes web based real-time communication use-cases. 14 Requirements on the browser functionality are derived from the use- 15 cases. 17 This document was developed in an initial phase of the work with 18 rather minor updates at later stages. It has not really served as a 19 tool in deciding features or scope for the WGs efforts so far. It is 20 being published to record the early conclusions of the working group. 21 It will not be used as a set of rigid guidelines that specifications 22 and implementations will be held to in the future. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 20, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Common requirements . . . . . . . . . . . . . . . . . . . 4 63 3.3. Browser-to-browser use-cases . . . . . . . . . . . . . . 4 64 3.3.1. Simple Video Communication Service . . . . . . . . . 4 65 3.3.2. Simple Video Communication Service, NAT/Firewall that 66 blocks UDP . . . . . . . . . . . . . . . . . . . . . 7 67 3.3.3. Simple Video Communication Service, Firewall that 68 only allows traffic via a HTTP Proxy . . . . . . . . 7 69 3.3.4. Simple Video Communication Service, global service 70 provider . . . . . . . . . . . . . . . . . . . . . . 7 71 3.3.5. Simple Video Communication Service, enterprise 72 aspects . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.3.6. Simple Video Communication Service, access change . . 9 74 3.3.7. Simple Video Communication Service, QoS . . . . . . . 10 75 3.3.8. Simple Video Communication Service with screen 76 sharing . . . . . . . . . . . . . . . . . . . . . . . 10 77 3.3.9. Simple Video Communication Service with file exchange 11 78 3.3.10. Hockey Game Viewer . . . . . . . . . . . . . . . . . 11 79 3.3.11. Multiparty video communication . . . . . . . . . . . 12 80 3.3.12. Multiparty on-line game with voice communication . . 14 81 3.4. Browser - GW/Server use cases . . . . . . . . . . . . . . 15 82 3.4.1. Telephony terminal . . . . . . . . . . . . . . . . . 15 83 3.4.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . 16 84 3.4.3. Video conferencing system with central server . . . . 17 85 4. Requirements summary . . . . . . . . . . . . . . . . . . . . 18 86 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 4.2. Browser requirements . . . . . . . . . . . . . . . . . . 18 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 22 91 6.2. Browser Considerations . . . . . . . . . . . . . . . . . 22 92 6.3. Web Application Considerations . . . . . . . . . . . . . 23 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 94 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 9. Normative References . . . . . . . . . . . . . . . . . . . . 29 96 Appendix A. API requirements . . . . . . . . . . . . . . . . . . 30 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 99 1. Introduction 101 This document presents a few use-cases of web applications that are 102 executed in a browser and use real-time communication capabilities. 103 In most of the use-cases all end-user clients are web applications, 104 but there are some use-cases where at least one of the end-user 105 clients is of another type (e.g. a mobile phone or a SIP User Agent 106 (UA)). 108 Based on the use-cases, the document derives requirements related to 109 browser functionality. These requirements are named "Fn", where n is 110 an integer, and are listed in conjunction with the use-cases. A 111 summary is provided in Section 4.2. 113 This document was developed in an initial phase of the work with 114 rather minor updates at later stages. It has not really served as a 115 tool in deciding features or scope for the WGs efforts so far. It is 116 proposed to be used in a later phase to evaluate the protocols and 117 solutions developed by the WG. 119 This document also lists requirements related to the API to be used 120 by web applications as an appendix. The reason is that the W3C 121 WebRTC WG has decided to not develop its own use-case/requirement 122 document, but instead use this document. These requirements are 123 named "An", where n is an integer, and are described in Appendix A. 125 This document was developed in an initial phase of the work with 126 rather minor updates at later stages. It has not really served as a 127 tool in deciding features or scope for the WGs efforts so far. It is 128 being published to record the early conclusions of the working group. 129 It will not be used as a set of rigid guidelines that specifications 130 and implementations will be held to in the future. 132 2. Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in BCP 14, RFC 2119 137 [RFC2119]. 139 3. Use-cases 140 3.1. Introduction 142 This section describes web based real-time communication use-cases, 143 from which requirements are derived. 145 The following considerations are applicable to all use cases: 147 o Clients can be on IPv4-only 149 o Clients can be on IPv6-only 151 o Clients can be on dual-stack 153 o Clients can be connected to networks with different throughput 154 capabilities 156 o Clients can be on variable-media-quality networks (wireless) 158 o Clients can be on congested networks 160 o Clients can be on firewalled networks with no UDP allowed 162 o Clients can be on networks with a NAT or IPv4-IPv6 translation 163 devices using any type of Mapping and Filtering behaviors (as 164 described in RFC4787). 166 3.2. Common requirements 168 The requirements retrived from the Simple Video Communication Service 169 use-case (Section 3.3.1) by default apply to all other use-cases, and 170 are considred common. For each individual use-case, only the 171 additional requirements are listed. 173 3.3. Browser-to-browser use-cases 175 3.3.1. Simple Video Communication Service 177 3.3.1.1. Description 179 Two or more users have loaded a video communication web application 180 into their browsers, provided by the same service provider, and 181 logged into the service it provides. The web service publishes 182 information about user login status by pushing updates to the web 183 application in the browsers. When one online user selects a peer 184 online user, a 1-1 audiovisual communication session between the 185 browsers of the two peers is initiated. The invited user might 186 accept or reject the session. 188 During session establishment a self-view is displayed, and once the 189 session has been established the video sent from the remote peer is 190 displayed in addition to the self-view. During the session, each 191 user can select to remove and re-insert the self-view as often as 192 desired. Each user can also change the sizes of his/her two video 193 displays during the session. Each user can also pause sending of 194 media (audio, video, or both) and mute incoming media. 196 It is essential that media and data be encrypted, authenticated and 197 integrity protected on a per IP packet basis and that media and data 198 packets failing the integrity check not be delivered to the 199 application. 201 The application gives the users the opportunity to stop it from 202 exposing the host IP address to the application of the other user. 204 Any session participant can end the session at any time. 206 The two users may be using communication devices with different 207 operating systems and browsers from different vendors. 209 The web service monitors the quality of the service (focus on quality 210 of audio and video) the end-users experience. 212 3.3.1.2. Common Requirements 214 ---------------------------------------------------------------- 215 REQ-ID DESCRIPTION 216 ---------------------------------------------------------------- 217 F1 The browser must be able to use microphones and 218 cameras as input devices to generate streams. 219 ---------------------------------------------------------------- 220 F2 The browser must be able to send streams and 221 data to a peer in the presence of NATs. 222 ---------------------------------------------------------------- 223 F3 Transmitted streams and data must be rate 224 controlled (meaning that the browser must, regardless 225 of application behavior, reduce send rate when 226 there is congestion). 227 ---------------------------------------------------------------- 228 F4 The browser must be able to receive, process and 229 render streams and data ("render" does not 230 apply for data) from peers. 231 ---------------------------------------------------------------- 232 F5 The browser should be able to render good quality 233 audio and video even in the presence of 234 reasonable levels of jitter and packet losses. 235 ---------------------------------------------------------------- 236 F6 The browser must detect when a stream from a 237 peer is not received anymore. 238 ---------------------------------------------------------------- 239 F7 When there are both incoming and outgoing audio 240 streams, echo cancellation must be made 241 available to avoid disturbing echo during 242 conversation. 243 ---------------------------------------------------------------- 244 F8 The browser must support synchronization of 245 audio and video. 246 ---------------------------------------------------------------- 247 F9 The browser should use encoding of streams 248 suitable for the current rendering (e.g. 249 video display size) and should change parameters 250 if the rendering changes during the session. 251 ---------------------------------------------------------------- 252 F10 The browser must support a baseline audio and 253 video codec. 254 ---------------------------------------------------------------- 255 F11 It must be possible to protect streams and data 256 from wiretapping [RFC2804][RFC7258]. 257 ---------------------------------------------------------------- 258 F12 The browser must enable verification, given 259 the right circumstances and by use of other 260 trusted communication, that streams and 261 data received have not been manipulated by 262 any party. 263 ---------------------------------------------------------------- 264 F13 The browser must encrypt, authenticate and 265 integrity protect media and data on a 266 per IP packet basis, and must drop incoming media 267 and data packets that fail the per IP packet 268 integrity check. In addition, the browser 269 must support a mechanism for cryptographically 270 binding media and data security keys to the 271 user identity (see R-ID-BINDING in [RFC5479]). 272 ---------------------------------------------------------------- 273 F14 The browser must make it possible to set up a 274 call between two parties without one party 275 learning the other party's host IP address. 276 ---------------------------------------------------------------- 277 F15 The browser must be able to collect statistics, 278 related to the transport of audio and video 279 between peers, needed to estimate quality of 280 experience. 281 ---------------------------------------------------------------- 283 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A25, A26 285 3.3.2. Simple Video Communication Service, NAT/Firewall that blocks UDP 287 3.3.2.1. Description 289 This use-case is almost identical to the 290 Simple Video Communication Service use-case (Section 3.3.1). The 291 difference is that one of the users is behind a NAT/Firewall that 292 blocks UDP traffic. 294 3.3.2.2. Additional Requirements 296 ---------------------------------------------------------------- 297 REQ-ID DESCRIPTION 298 ---------------------------------------------------------------- 299 F18 The browser must be able to send streams and 300 data to a peer in the presence of NATs and 301 Firewalls that block UDP traffic. 302 ---------------------------------------------------------------- 304 3.3.3. Simple Video Communication Service, Firewall that only allows 305 traffic via a HTTP Proxy 307 3.3.3.1. Description 309 This use-case is almost identical to the 310 Simple Video Communication Service use-case (Section 3.3.1). The 311 difference is that one of the users is behind a Firewall that only 312 allows traffic via a HTTP Proxy. 314 3.3.3.2. Additional Requirements 316 ---------------------------------------------------------------- 317 REQ-ID DESCRIPTION 318 ---------------------------------------------------------------- 319 F21 The browser must be able to send streams and 320 data to a peer in the presence of Firewalls that only 321 allows traffic via a HTTP Proxy, when Firewall policy 322 allows WebRTC traffic. 323 ---------------------------------------------------------------- 325 3.3.4. Simple Video Communication Service, global service provider 327 3.3.4.1. Description 329 This use-case is almost identical to the 330 Simple Video Communication Service use-case (Section 3.3.1). 332 What is added is that the service provider is operating over large 333 geographical areas (or even globally). 335 Assuming that ICE will be used, this means that the service provider 336 would like to be able to provide several STUN and TURN servers (via 337 the app) to the browser; selection of which one(s) to use is part of 338 the ICE processing. Other reasons for wanting to provide several 339 STUN and TURN servers include support for IPv4 and IPv6, load 340 balancing and redundancy. 342 Note that ICE support being mandatory does not preclude a WebRTC 343 endpoint from supporting more traversal mechanisms than ICE using 344 STUN and TURN. 346 3.3.4.2. Additional Requirements 348 ---------------------------------------------------------------- 349 REQ-ID DESCRIPTION 350 ---------------------------------------------------------------- 351 F19 The browser must be able to use several STUN 352 and TURN servers 353 ---------------------------------------------------------------- 355 A22 357 3.3.5. Simple Video Communication Service, enterprise aspects 359 3.3.5.1. Description 361 This use-case is similar to the Simple Video Communication Service 362 use-case (Section 3.3.1). 364 What is added is aspects when using the service in enterprises. ICE 365 is assumed in the further description of this use-case. 367 An enterprise that uses a RTCWEB based web application for 368 communication desires to audit all RTCWEB based application sessions 369 used from inside the company towards any external peer. To be able 370 to do this they deploy a TURN server that straddles the boundary 371 between the internal and the external network. 373 The firewall will block all attempts to use STUN with an external 374 destination unless they go to the enterprise auditing TURN server. 375 In cases where employees are using RTCWEB applications provided by an 376 external service provider they still want the traffic to stay inside 377 their internal network and in addition not load the straddling TURN 378 server, thus they deploy a STUN server allowing the RTCWEB client to 379 determine its server reflexive address on the internal side. Thus 380 enabling cases where peers are both on the internal side to connect 381 without the traffic leaving the internal network. It must be 382 possible to configure the browsers used in the enterprise with 383 network specific STUN and TURN servers. This should be possible to 384 achieve by auto-configuration methods. The RTCWEB functionality will 385 need to utilize both network specific STUN and TURN resources and 386 STUN and TURN servers provisioned by the web application. 388 3.3.5.2. Additional Requirements 390 ---------------------------------------------------------------- 391 REQ-ID DESCRIPTION 392 ---------------------------------------------------------------- 393 F20 The browser must support the use of STUN and TURN 394 servers that are supplied by entities other than 395 the web application (i.e. the network provider). 396 ---------------------------------------------------------------- 398 3.3.6. Simple Video Communication Service, access change 400 3.3.6.1. Description 402 This use-case is almost identical to the 403 Simple Video Communication Service use-case (Section 3.3.1). The 404 difference is that the user changes network access during the 405 session. 407 The communication device used by one of the users has several network 408 adapters (Ethernet, WiFi, Cellular). The communication device is 409 accessing the Internet using Ethernet, but the user has to start a 410 trip during the session. The communication device automatically 411 changes to use WiFi when the Ethernet cable is removed and then moves 412 to cellular access to the Internet when moving out of WiFi coverage. 413 The session continues even though the access method changes. 415 3.3.6.2. Additional Requirements 417 ---------------------------------------------------------------- 418 REQ-ID DESCRIPTION 419 ---------------------------------------------------------------- 420 F17 The communication session must survive across a 421 change of the network interface used by the 422 session 423 ---------------------------------------------------------------- 425 3.3.7. Simple Video Communication Service, QoS 427 3.3.7.1. Description 429 This use-case is almost identical to the 430 Simple Video Communication Service, access change use-case 431 (Section 3.3.6). The use of Quality of Service (QoS) capabilities is 432 added: 434 The user in the previous use case that starts a trip is behind a 435 common residential router that supports prioritization of traffic. 436 In addition, the user's provider of cellular access has QoS support 437 enabled. The user is able to take advantage of the QoS support both 438 when accessing via the residential router and when using cellular. 440 3.3.7.2. Additional Requirements 442 ---------------------------------------------------------------- 443 REQ-ID DESCRIPTION 444 ---------------------------------------------------------------- 445 F17 The communication session must survive across a 446 change of the network interface used by the 447 session 448 ---------------------------------------------------------------- 449 F22 The browser should be able to take advantage 450 of available capabilities (supplied by network 451 nodes) to prioritize voice, video and data 452 appropriately. 453 ---------------------------------------------------------------- 455 3.3.8. Simple Video Communication Service with screen sharing 457 3.3.8.1. Description 459 This use-case has the audio and video communication of the 460 Simple Video Communication Service use-case (Section 3.3.1). 462 But in addition to this, one of the users can share what is being 463 displayed on her/his screen with a peer. The user can choose to 464 share the entire screen, part of the screen (part selected by the 465 user) or what a selected application displays with the peer. 467 3.3.8.2. Additional Requirements 468 ---------------------------------------------------------------- 469 REQ-ID DESCRIPTION 470 ---------------------------------------------------------------- 471 F36 The browser must be able to generate streams 472 using the entire user display, a specific area 473 of the user's display or the information being 474 displayed by a specific application. 475 ---------------------------------------------------------------- 477 A21 479 3.3.9. Simple Video Communication Service with file exchange 481 3.3.9.1. Description 483 This use-case has the audio and video communication of the 484 Simple Video Communication Service use-case (Section 3.3.1). 486 But in addition to this, the users can send and receive files stored 487 in the file system of the device used. 489 3.3.9.2. Additional Requirements 491 ---------------------------------------------------------------- 492 REQ-ID DESCRIPTION 493 ---------------------------------------------------------------- 494 F35 The browser must be able to send reliable 495 data traffic to a peer browser. 496 ---------------------------------------------------------------- 498 A21, A24 500 3.3.10. Hockey Game Viewer 502 3.3.10.1. Description 504 An ice-hockey club uses an application that enables talent scouts to, 505 in real-time, show and discuss games and players with the club 506 manager. The talent scouts use a mobile phone with two cameras, one 507 front facing and one rear facing. 509 The club manager uses a desktop, equipped with one camera, for 510 viewing the game and discussing with the talent scout. 512 Before the game starts, and during game breaks, the talent scout and 513 the manager have a 1-1 audiovisual communication session. On the 514 mobile phone, only the camera facing the talent scout is used. On 515 the user display of the mobile phone, the video of the club manager 516 is shown with a picture-in-picture thumbnail of the rear facing 517 camera (self-view). On the display of the desktop, the video of the 518 talent scout is shown with a picture-in-picture thumbnail of the 519 desktop camera (self-view). 521 When the game is on-going, the talent scout activates the use of the 522 front facing camera, and that stream is sent to the desktop (the 523 stream from the rear facing camera continues to be sent all the 524 time). The video stream captured by the front facing camera (that is 525 capturing the game) of the mobile phone is shown in a big window on 526 the desktop screen, with picture-in-picture thumbnails of the rear 527 facing camera and the desktop camera (self-view). On the display of 528 the mobile phone the game is shown (front facing camera) with 529 picture-in-picture thumbnails of the rear facing camera (self-view) 530 and the desktop camera. As the most important stream in this phase 531 is the video showing the game, the application used in the talent 532 scout's mobile sets higher priority for that stream. 534 3.3.10.2. Additional Requirements 536 ---------------------------------------------------------------- 537 REQ-ID DESCRIPTION 538 ---------------------------------------------------------------- 539 F22 The browser should be able to take advantage 540 of available capabilities (supplied by network 541 nodes) to prioritize voice, video and data 542 appropriately. 543 ---------------------------------------------------------------- 544 F25 The browser must be able to render several 545 concurrent audio and video streams. 546 ---------------------------------------------------------------- 548 A17, A23 550 3.3.11. Multiparty video communication 552 3.3.11.1. Description 554 In this use-case, the Simple Video Communication Service use-case 555 (Section 3.3.1) is extended by allowing multiparty sessions. No 556 central server is involved - the browser of each participant sends 557 and receives streams to and from all other session participants. The 558 web application in the browser of each user is responsible for 559 setting up streams to all receivers. 561 In order to enhance the user experience, the web application renders 562 the audio coming from different particiapants so that it is 563 experienced to come from different spatial locations. This is done 564 automatically, but users can change how the different participants 565 are placed in the (virtual) room. In addition the levels in the 566 audio signals are adjusted before mixing. 568 Another feature intended to enhance the use experience is that the 569 video window that displays the video of the currently speaking peer 570 is highlighted. 572 Each video stream received is by default displayed in a thumbnail 573 frame within the browser, but users can change the display size. 575 Note: What this use-case adds in terms of requirements is 576 capabilities to send streams to and receive streams from several 577 peers concurrently, as well as the capabilities to render the video 578 from all received streams and be able to spatialize, level adjust and 579 mix the audio from all received streams locally in the browser. It 580 also adds the capability to measure the audio level/activity. 582 3.3.11.2. Additional Requirements 584 ---------------------------------------------------------------- 585 REQ-ID DESCRIPTION 586 ---------------------------------------------------------------- 587 F23 The browser must be able to transmit streams and 588 data to several peers concurrently. 589 ---------------------------------------------------------------- 590 F24 The browser must be able to receive streams and 591 data from multiple peers concurrently. 592 ---------------------------------------------------------------- 593 F25 The browser must be able to render several 594 concurrent audio and video streams. 595 ---------------------------------------------------------------- 596 F26 The browser must be able to mix several 597 audio streams. 598 ---------------------------------------------------------------- 599 F27 The browser must be able to apply spatialization 600 effects to audio streams. 601 ---------------------------------------------------------------- 602 F28 The browser must be able to measure the 603 voice activity level in audio streams. 604 ---------------------------------------------------------------- 605 F29 The browser must be able to change the 606 voice activity level in audio streams. 607 ---------------------------------------------------------------- 609 A13, A14, A15, A16 611 3.3.12. Multiparty on-line game with voice communication 613 3.3.12.1. Description 615 This use case is based on the previous one. In this use-case, the 616 voice part of the multiparty video communication use case is used in 617 the context of an on-line game. The received voice audio media is 618 rendered together with game sound objects. For example, the sound of 619 a tank moving from left to right over the screen must be rendered and 620 played to the user together with the voice media. 622 Quick updates of the game state is required, and have higher priority 623 than the voice. 625 Note: the difference regarding local audio processing compared to the 626 "Multiparty video communication" use-case is that other sound objects 627 than the streams must be possible to be included in the 628 spatialization and mixing. "Other sound objects" could for example 629 be a file with the sound of the tank; that file could be stored 630 locally or remotely. 632 3.3.12.2. Additional Requirements 633 ---------------------------------------------------------------- 634 REQ-ID DESCRIPTION 635 ---------------------------------------------------------------- 636 F22 The browser should be able to take advantage 637 of available capabilities (supplied by network 638 nodes) to prioritize voice, video and data 639 appropriately. 640 ---------------------------------------------------------------- 641 F23 The browser must be able to transmit streams and 642 data to several peers concurrently. 643 ---------------------------------------------------------------- 644 F24 The browser must be able to receive streams and 645 data from multiple peers concurrently. 646 ---------------------------------------------------------------- 647 F25 The browser must be able to render several 648 concurrent audio and video streams. 649 ---------------------------------------------------------------- 650 F26 The browser must be able to mix several 651 audio streams. 652 ---------------------------------------------------------------- 653 F27 The browser must be able to apply spatialization 654 effects when playing audio streams. 655 ---------------------------------------------------------------- 656 F28 The browser must be able to measure the 657 voice activity level in audio streams. 658 ---------------------------------------------------------------- 659 F29 The browser must be able to change the 660 voice activity level in audio streams. 661 ---------------------------------------------------------------- 662 F30 The browser must be able to process and mix 663 sound objects (media that is retrieved from 664 another source than the established media 665 stream(s) with the peer(s) with audio streams. 666 ---------------------------------------------------------------- 667 F34 The browser must be able to send short 668 latency unreliable datagram traffic to a 669 peer browser [RFC5405]. 670 ---------------------------------------------------------------- 672 A13, A14, A15, A16, A17, A18, A23 674 3.4. Browser - GW/Server use cases 676 3.4.1. Telephony terminal 677 3.4.1.1. Description 679 A mobile telephony operator allows its customers to use a web browser 680 to access their services. After a simple log in the user can place 681 and receive calls in the same way as when using a normal mobile 682 phone. When a call is received or placed, the identity is shown in 683 the same manner as when a mobile phone is used. 685 Note: With "place and receive calls in the same way as when using a 686 normal mobile phone" it is meant that you can dial a number, and that 687 your mobile telephony operator has made available your phone contacts 688 on line, so they are available and can be clicked to call, and be 689 used to present the identity of an incoming call. If the callee is 690 not in your phone contacts the number is displayed. Furthermore, 691 your call logs are available, and updated with the calls made/ 692 received from the browser. And for people receiving calls made from 693 the web browser the usual identity (i.e. the phone number of the 694 mobile phone) will be presented. 696 3.4.1.2. Additional Requirements 698 ---------------------------------------------------------------- 699 REQ-ID DESCRIPTION 700 ---------------------------------------------------------------- 701 F31 The browser must support an audio media format 702 (codec) that is commonly supported by existing 703 telephony services. 704 ---------------------------------------------------------------- 705 F33 The browser must be able to initiate and 706 accept a media session where the data needed 707 for establishment can be carried in SIP. 708 ---------------------------------------------------------------- 710 3.4.2. Fedex Call 712 3.4.2.1. Description 714 Alice uses her web browser with a service that allows her to call 715 PSTN numbers. Alice calls 1-800-gofedex. Alice should be able to 716 hear the initial prompts from the fedex Interactive Voice Responder 717 (IVR) and when the IVR says press 1, there should be a way for Alice 718 to navigate the IVR. 720 3.4.2.2. Additional Requirements 721 ---------------------------------------------------------------- 722 REQ-ID DESCRIPTION 723 ---------------------------------------------------------------- 724 F31 The browser must support an audio media format 725 (codec) that is commonly supported by existing 726 telephony services. 727 ---------------------------------------------------------------- 728 F32 There should be a way to navigate 729 a Dual-tone multi-frequency signaling (DTMF) 730 based Interactive voice response (IVR) System 731 ---------------------------------------------------------------- 733 3.4.3. Video conferencing system with central server 735 3.4.3.1. Description 737 An organization uses a video communication system that supports the 738 establishment of multiparty video sessions using a central conference 739 server. 741 The browser of each participant sends an audio stream (type in terms 742 of mono, stereo, 5.1, ... depending on the equipment of the 743 participant) to the central server. The central server mixes the 744 audio streams (and can in the mixing process naturally add effects 745 such as spatialization) and sends towards each participant a mixed 746 audio stream which is played to the user. 748 The browser of each participant sends video towards the server. For 749 each participant one high resolution video is displayed in a large 750 window, while a number of low resolution videos are displayed in 751 smaller windows. The server selects what video streams to be 752 forwarded as main- and thumbnail videos respectively, based on speech 753 activity. As the video streams to display can change quite 754 frequently (as the conversation flows) it is important that the delay 755 from when a video stream is selected for display until the video can 756 be displayed is short. 758 All participants are authenticated by the central server, and 759 authorized to connect to the central server. The participants are 760 identified to each other by the central server, and the participants 761 do not have access to each others' credentials such as e-mail 762 addresses or login IDs. 764 Note: This use-case adds requirements on support for fast stream 765 switches F16. There exist several solutions that enable the server 766 to forward one high resolution and several low resolution video 767 streams: a) each browser could send a high resolution, but scalable 768 stream, and the server could send just the base layer for the low 769 resolution streams, b) each browser could in a simulcast fashion send 770 one high resolution and one low resolution stream, and the server 771 just selects or c) each browser sends just a high resolution stream, 772 the server transcodes into low resolution streams as required. 774 3.4.3.2. Additional Requirements 776 ---------------------------------------------------------------- 777 REQ-ID DESCRIPTION 778 ---------------------------------------------------------------- 779 F16 The browser must support insertion of reference frames 780 in outgoing media streams when requested by a peer. 781 ---------------------------------------------------------------- 782 F25 The browser must be able to render several 783 concurrent audio and video streams. 784 ---------------------------------------------------------------- 786 4. Requirements summary 788 4.1. General 790 This section contains the requirements on the browser derived from 791 the use-cases in Section 3. 793 NOTE: It is assumed that the user applications are executed on a 794 browser. Whether the capabilities to implement specific browser 795 requirements are implemented by the browser application, or are 796 provided to the browser application by the underlying operating 797 system, is outside the scope of this document. 799 4.2. Browser requirements 801 ---------------------------------------------------------------- 802 Common, basic requirements 803 ---------------------------------------------------------------- 804 REQ-ID DESCRIPTION 805 ---------------------------------------------------------------- 806 F1 The browser must be able to use microphones and 807 cameras as input devices to generate streams. 808 ---------------------------------------------------------------- 809 F2 The browser must be able to send streams and 810 data to a peer in the presence of NATs. 811 ---------------------------------------------------------------- 812 F3 Transmitted streams and data must be rate 813 controlled (meaning that the browser must, regardless 814 of application behavior, reduce send rate when 815 there is congestion). 817 ---------------------------------------------------------------- 818 F4 The browser must be able to receive, process and 819 render streams and data ("render" does not 820 apply for data) from peers. 821 ---------------------------------------------------------------- 822 F5 The browser should be able to render good quality 823 audio and video even in the presence of 824 reasonable levels of jitter and packet losses. 825 ---------------------------------------------------------------- 826 F6 The browser must detect when a stream from a 827 peer is not received anymore 828 ---------------------------------------------------------------- 829 F7 When there are both incoming and outgoing audio 830 streams, echo cancellation must be made 831 available to avoid disturbing echo during 832 conversation. 833 ---------------------------------------------------------------- 834 F8 The browser must support synchronization of 835 audio and video. 836 ---------------------------------------------------------------- 837 F9 The browser should use encoding of streams 838 suitable for the current rendering (e.g. 839 video display size) and should change parameters 840 if the rendering changes during the session 841 ---------------------------------------------------------------- 842 F10 The browser must support a baseline audio and 843 video codec 844 ---------------------------------------------------------------- 845 F11 It must be possible to protect streams and data 846 from wiretapping [RFC2804][RFC7258]. 847 ---------------------------------------------------------------- 848 F12 The browser must enable verification, given 849 the right circumstances and by use of other 850 trusted communication, that streams and 851 data received have not been manipulated by 852 any party. 853 ---------------------------------------------------------------- 854 F13 The browser must encrypt, authenticate and 855 integrity protect media and data on a 856 per-packet basis, and must drop incoming media 857 and data packets that fail the per-packet 858 integrity check. In addition, the browser 859 must support a mechanism for cryptographically 860 binding media and data security keys to the 861 user identity (see R-ID-BINDING in [RFC5479]). 862 ---------------------------------------------------------------- 863 F14 The browser must make it possible to set up a 864 call between two parties without one party 865 learning the other party's host IP address. 866 ---------------------------------------------------------------- 867 F15 The browser must be able to collect statistics, 868 related to the transport of audio and video 869 between peers, needed to estimate quality of 870 experience. 871 ---------------------------------------------------------------- 872 Requirements related to network and topology 873 ---------------------------------------------------------------- 874 REQ-ID DESCRIPTION 875 ---------------------------------------------------------------- 876 F16 The browser must support insertion of reference frames 877 in outgoing media streams when requested by a peer. 878 ---------------------------------------------------------------- 879 F17 The communication session must survive across a 880 change of the network interface used by the 881 session 882 ---------------------------------------------------------------- 883 F18 The browser must be able to send streams and 884 data to a peer in the presence of NATs and 885 Firewalls that block UDP traffic. 886 ---------------------------------------------------------------- 887 F19 The browser must be able to use several STUN 888 and TURN servers 889 ---------------------------------------------------------------- 890 F20 The browser must support the use of STUN and TURN 891 servers that are supplied by entities other than 892 the web application (i.e. the network provider). 893 ---------------------------------------------------------------- 894 F21 The browser must be able to send streams and 895 data to a peer in the presence of Firewalls that only 896 allows traffic via a HTTP Proxy, when Firewall policy 897 allows WebRTC traffic. 898 ---------------------------------------------------------------- 899 F22 The browser should be able to take advantage 900 of available capabilities (supplied by network 901 nodes) to prioritize voice, video and data 902 appropriately. 903 ---------------------------------------------------------------- 904 Requirements related to multiple peers and streams 905 ---------------------------------------------------------------- 906 REQ-ID DESCRIPTION 907 ---------------------------------------------------------------- 908 F23 The browser must be able to transmit streams and 909 data to several peers concurrently. 910 ---------------------------------------------------------------- 911 F24 The browser must be able to receive streams and 912 data from multiple peers concurrently. 914 ---------------------------------------------------------------- 915 F25 The browser must be able to render several 916 concurrent audio and video streams. 917 ---------------------------------------------------------------- 918 F26 The browser must be able to mix several 919 audio streams. 920 ---------------------------------------------------------------- 921 Requirements related to audio processing 922 ---------------------------------------------------------------- 923 REQ-ID DESCRIPTION 924 ---------------------------------------------------------------- 925 F27 The browser must be able to apply spatialization 926 effects when playing audio streams. 927 ---------------------------------------------------------------- 928 F28 The browser must be able to measure the 929 voice activity level in audio streams. 930 ---------------------------------------------------------------- 931 F29 The browser must be able to change the 932 voice activity level in audio streams. 933 ---------------------------------------------------------------- 934 F30 The browser must be able to process and mix 935 sound objects (media that is retrieved from 936 another source than the established media 937 stream(s) with the peer(s) with audio streams. 938 ---------------------------------------------------------------- 939 Requirements related to legacy interop 940 ---------------------------------------------------------------- 941 REQ-ID DESCRIPTION 942 ---------------------------------------------------------------- 943 F31 The browser must support an audio media format 944 (codec) that is commonly supported by existing 945 telephony services. 946 ---------------------------------------------------------------- 947 F32 There should be a way to navigate 948 a Dual-tone multi-frequency signaling (DTMF) 949 based Interactive voice response (IVR) System 950 ---------------------------------------------------------------- 951 F33 The browser must be able to initiate and 952 accept a media session where the data needed 953 for establishment can be carried in SIP. 954 ---------------------------------------------------------------- 955 Other requirements 956 ---------------------------------------------------------------- 957 REQ-ID DESCRIPTION 958 ---------------------------------------------------------------- 959 F34 The browser must be able to send short 960 latency unreliable datagram traffic to a 961 peer browser [RFC5405]. 963 ---------------------------------------------------------------- 964 F35 The browser must be able to send reliable 965 data traffic to a peer browser. 966 ---------------------------------------------------------------- 967 F36 The browser must be able to generate streams 968 using the entire user display, a specific area 969 of the user's display or the information being 970 displayed by a specific application. 971 ---------------------------------------------------------------- 973 5. IANA Considerations 975 There are no IANA actions in this document. 977 6. Security Considerations 979 6.1. Introduction 981 A malicious web application might use the browser to perform Denial 982 Of Service (DOS) attacks on NAT infrastructure, or on peer devices. 983 Also, a malicious web application might silently establish outgoing, 984 and accept incoming, streams on an already established connection. 986 Based on the identified security risks, this section will describe 987 security considerations for the browser and web application. 989 6.2. Browser Considerations 991 The browser is expected to provide mechanisms for getting user 992 consent to use device resources such as camera and microphone. 994 The browser is expected to provide mechanisms for informing the user 995 that device resources such as camera and microphone are in use 996 ("hot"). 998 The browser is expected to provide mechanisms for users to revise and 999 even completely revoke consent to use device resources such as camera 1000 and microphone. 1002 The browser is expected to provide mechanisms for getting user 1003 consent to use the screen (or a certain part of it) or what a certain 1004 application displays on the screen as source for streams. 1006 The browser is expected to provide mechanisms for informing the user 1007 that the screen, part thereof or an application is serving as a 1008 stream source ("hot"). 1010 The browser is expected to provide mechanisms for users to revise and 1011 even completely revoke consent to use the screen, part thereof or an 1012 application is serving as a stream source. 1014 The browser is expected to provide mechanisms in order to assure that 1015 streams are the ones the recipient intended to receive. 1017 The browser is expected to provide mechanisms that allows the users 1018 to verify that the streams received have not be manipulated (F12). 1020 The browser needs to ensure that media is not sent, and that received 1021 media is not rendered, until the associated stream establishment and 1022 handshake procedures with the remote peer have been successfully 1023 finished. 1025 The browser needs to ensure that the stream negotiation procedures 1026 are not seen as Denial Of Service (DOS) by other entities. 1028 6.3. Web Application Considerations 1030 The web application is expected to ensure user consent in sending and 1031 receiving media streams. 1033 7. Acknowledgements 1035 The authors wish to thank Bernard Aboba, Gunnar Hellstrom, Martin 1036 Thomson, Lars Eggert, Matthew Kaufman, Emil Ivov, Eric Rescorla, Eric 1037 Burger, John Leslie, Dan Wing, Richard Barnes, Barry Dingle, Dale 1038 Worley, Ted hardie, Mary Barnes, Dan Burnett, Stephan Wenger, Harald 1039 Alvestrand, Cullen Jennings, Andrew Hutton and everyone else in the 1040 RTCWEB community that have provided comments, feedback, text and 1041 improvement proposals on the document. 1043 8. Change Log 1045 [RFC EDITOR NOTE: Please remove this section when publishing] 1047 Changes from draft-ietf-rtcweb-use-cases-and-requirements-14 1049 o Changes based on comments from the ops-dir: 1051 o - Editorial fixes. 1053 o - F13: 'per-packet basis' -> 'per IP packet basis'. 1055 o - F22: Text corrected in one occurance. 1057 o - F25: 'audio' added. 1059 o Changes based on comments from IESG 1061 o - Editorial fixes. 1063 o - Disclaimer text suggested by Alissa Cooper added. 1065 o - F11: Reference to RFC 7258 added. 1067 o - F27: 'when playing' removed. 1069 Changes from draft-ietf-rtcweb-use-cases-and-requirements-10 1071 o Described that the API requirements are really from a W3C 1072 perspective and are supplied as an appendix in the introduction. 1073 Moved API requirements to an Appendix. 1075 o Removed the "Conventions" section with the key-words and reference 1076 to RFC2119. Also changed uppercase MUST's/SHOULD's to lowercase. 1078 o Added a note on the proposed use of the document to the 1079 introduction. 1081 o Removed the note talking about WS from the "Firewall that only 1082 allows http" use-case. 1084 o Removed the word "Skype" that was used as example in one of the 1085 use-cases. 1087 o Clarified F3 (the req saying the everything the browser sends must 1088 be rate controlled). 1090 o Removed the TBD saying we need to define reasonable levels from 1091 the requirement saying that quality must be good even in presence 1092 of packet losses (F5), and changed "must" to "should" (Based on a 1093 list discussion involving Bernard). 1095 o Removed F6 ("The browser must be able to handle high loss and 1096 jitter levels in a graceful way."), also after a list discussion. 1098 o Clarified F7 (used to say that the browser must support fast 1099 stream switches, now says that reference frames must be inserted 1100 when requested). 1102 o Removed the questions from F9 (echo cancellation), F10 1103 (synchronization), F21 (telephony codec). 1105 o Exchanged "restrictive firewalls" for "limited middleboxes" in F19 1106 (as proposed by Martin). 1108 o Expanded DTMF and IVR in F22 (proposed by Martin) 1110 o Added ref to RFC5405 in F23 (proposed by Lars Eggert). 1112 o Exchanged "service provided" for "web application" in F32. 1114 o Changed the text in 3.2.1 that motivates F36 (new text "It is 1115 essential that media and data be encrypted, authenticated ... 1116 bound to the user identity."); and rewrote F36, included a ref to 1117 RFC5479. 1119 o Changed "quality of service" to "quality of experience" in F38. 1121 o Added F39. 1123 o Used new formulation of A17 (proposed by Martin). 1125 o Updated A20. 1127 o Updated A25. 1129 Changes from draft-ietf-rtcweb-use-cases-and-requirements-09 1131 o Changed "video communication session" to "audiovisual 1132 communication session. 1134 Changes from draft-ietf-rtcweb-use-cases-and-requirements-08 1136 o Changed "eavesdropping" to "wiretapping" and referenced RFC2804. 1138 o Removed informal ref webrtc_req; that document has been abandoned 1139 by the W3C webrtc WG. 1141 o Added use-case where one user is behind a Firewall that only 1142 allows http; derived req. F37. 1144 o Changed F24 slightly; MUST-> SHOULD, inserted "available". 1146 o Added a clause to "Simple video communication service" saying that 1147 the service provider monitors the quality of service, and derived 1148 reqs F38 and A26. 1150 Changes from draft-ietf-rtcweb-use-cases-and-requirements-07 1152 o Added "and data exchange" to 1. Introduction. 1154 o Removed cone and symmetric NAT from 4.1 Introduction, refers to 1155 RFC4787 instead. 1157 o Added text on enabling verification of that the media has not been 1158 manipulated by anyone to use-case "Simple Video Communication 1159 Service", derived req. F35 1161 o Added text on that the browser should reject media (data) that has 1162 been created/injected/modified by non-trusted party, derived req. 1163 F36 1165 o Added text on enabling the app to refrain from revealing IP 1166 address to use-case "Simple Video Communication Service", derived 1167 req. A25 1169 o Added use-case "Simple Video Communication Service with file 1170 exchange", derived reqs F33 and A24 1172 o Added priority of video streams to "Hockey game viewer" use case, 1173 added priority of data to "on-line game use-case", derived reqs 1174 F34 and A23 1176 o In F22, "the IVR" -> "a DTMF based IVR". 1178 o Updated req F23 to clarify that requirements such as NAT 1179 traversal, protection from eavesdropping, rate control applies 1180 also to datagram. 1182 Changes from draft-ietf-rtcweb-use-cases-and-requirements-06 1184 o Renaming of requirements (FaI1 -> F31), (FaI2 -> F32) and (AaI1 -> 1185 A22) 1187 Changes from draft-ietf-rtcweb-use-cases-and-requirements-05 1189 o Added use-case "global service provider", derived reqs associated 1190 with several STUN/TURN servers 1192 o Added use-case "enterprise aspects", derived req associated with 1193 enabling the network provider to supply STUN and TURN servers 1195 o The requirements from the above are ICE specific and labeled 1196 accordingly 1198 o Separated the requirements phrased like "processing such as pan, 1199 mix and render" for audio to be specific reqs on spatialization, 1200 level measurement, level adjustment and mixing (discussed on the 1201 lists in http://www.ietf.org/mail-archive/web/rtcweb/current/ 1202 msg01648.html and http://lists.w3.org/Archives/Public/public- 1203 webrtc/2011Sep/0102.html) 1205 o Added use-case on sharing as decided in http://www.ietf.org/mail- 1206 archive/web/rtcweb/current/msg01700.html, derived reqs F30 and A21 1208 o Added the list of common considerations proposed in mail 1209 http://www.ietf.org/mail-archive/web/rtcweb/current/msg01562.html 1210 to the Introduction of the use-case section 1212 Changes from draft-ietf-rtcweb-use-cases-and-requirements-04 1214 o Most changes based on the input from Dan Burnett 1215 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00948.html 1217 o Many editorial changes 1219 o 4.2.1.1 Clarified 1221 o Some clarification added to 4.3.1.1 as a note 1223 o F-requirements updated (see reply to Dan's mail). 1225 o Almost all A-requirements updated to start "The Web API MUST 1226 provide ..." 1228 o A8 removed, A9 rephrased to cover A8 and old A9 1230 o A15 rephrased 1232 o For more details, and discussion, look at the response to Dan's 1233 mail http://www.ietf.org/mail-archive/web/rtcweb/current/ 1234 msg01177.html 1236 Changes from draft-ietf-rtcweb-use-cases-and-requirements-03 1238 o Editorials 1240 o Changed when the self-view is displayed in 4.2.1.1, and added 1241 words about allowing users to remove and re-insert it. 1243 o Clarified 4.2.6.1 1245 o Removed the "mono" stuff from 4.2.7.1 1246 o Added that communication should not be possible to eavesdrop to 1247 most use cases - and req. F17 1249 o Re-phrased 4.3.3.1 to not describe the technical solution so much, 1250 and removed "stereo" stuff. Solution possibilities are now in a 1251 note. 1253 o Re-inserted API requirements after discussion in the W3C webrtc 1254 WG. (Re-phrased A15 and added A18 compared to version -02). 1256 Changes from draft-ietf-rtcweb-use-cases-and-requirements-02 1258 o Removed description/list of API requirements, instead 1260 o Reference to W3C webrtc_reqs document for API requirements 1262 Changes from draft-ietf-rtcweb-ucreqs-01 1264 o Changed Intended status to Information 1266 o Changed "Ipr" to "trust200902" 1268 o Added use case "Simple video communication service, NAT/Firewall 1269 that blocks UDP", and derived new req F26 1271 o Added use case "Distributed Music Band" and derived new req A17 1273 o Added F24 as requirement derived from use case "Simple video 1274 communication service with inter-operator calling" 1276 o Added section "Additional use cases" 1278 o Added text about ID handling to multiparty with central server use 1279 case 1281 o Re-phrased A1 slightly 1283 Changes from draft-ietf-rtcweb-ucreqs-00 1285 o - Reshuffled: Just two main groups of use cases (b2b and b2GW/ 1286 Server); removed some specific use cases and added them instead as 1287 flavors to the base use case (Simple video communication) 1289 o - Changed the formulation of F19 1291 o - Removed the requirement on an API for DTMF 1292 o - Removed "FX3: There SHOULD be a mapping of the minimum needed 1293 data for setting up connections into SIP, so that the restriction 1294 to SIP-carriable data can be verified. Not a rew on the browser 1295 but rather on a document" 1297 o - (see http://www.ietf.org/mail-archive/web/rtcweb/current/ 1298 msg00227.html for more details) 1300 o -Added text on informing user of that mic/cam is being used and 1301 that it must be possible to revoce permission to use them in 1302 section 7. 1304 Changes from draft-holmberg-rtcweb-ucreqs-01 1306 o - Draft name changed to draft-ietf-rtcweb-ucreqs 1308 o - Use-case grouping introduced 1310 o - Additional use-cases added 1312 o - Additional reqs added (derived from use cases): F19-F25, A16-A17 1314 Changes from draft-holmberg-rtcweb-ucreqs-00 1316 o - Mapping between use-cases and requirements added (Harald 1317 Alvestrand, 090311) 1319 o - Additional security considerations text (Harald Alvestrand, 1320 090311) 1322 o - Clarification that user applications are assumed to be executed 1323 by a browser (Ted Hardie, 080311) 1325 o - Editorial corrections and clarifications 1327 9. Normative References 1329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1330 Requirement Levels", BCP 14, RFC 2119, March 1997. 1332 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 1333 2000. 1335 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1336 for Application Designers", BCP 145, RFC 5405, November 1337 2008. 1339 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 1340 "Requirements and Analysis of Media Security Management 1341 Protocols", RFC 5479, April 2009. 1343 Appendix A. API requirements 1345 This section contains the requirements on the API derived from the 1346 use-cases in Section 3. 1348 REQ-ID DESCRIPTION 1349 ---------------------------------------------------------------- 1350 A1 The Web API must provide means for the 1351 application to ask the browser for permission 1352 to use cameras and microphones as input devices. 1353 ---------------------------------------------------------------- 1354 A2 The Web API must provide means for the web 1355 application to control how streams generated 1356 by input devices are used. 1357 ---------------------------------------------------------------- 1358 A3 The Web API must provide means for the web 1359 application to control the local rendering of 1360 streams (locally generated streams and streams 1361 received from a peer). 1362 ---------------------------------------------------------------- 1363 A4 The Web API must provide means for the web 1364 application to initiate sending of 1365 stream/stream components to a peer. 1366 ---------------------------------------------------------------- 1367 A5 The Web API must provide means for the web 1368 application to control the media format (codec) 1369 to be used for the streams sent to a peer. 1371 NOTE: The level of control depends on whether 1372 the codec negotiation is handled by the browser 1373 or the web application. 1374 ---------------------------------------------------------------- 1375 A6 The Web API must provide means for the web 1376 application to modify the media format for 1377 streams sent to a peer after a media stream 1378 has been established. 1379 ---------------------------------------------------------------- 1380 A7 The Web API must provide means for 1381 informing the web application of whether the 1382 establishment of a stream with a peer was 1383 successful or not. 1384 ---------------------------------------------------------------- 1385 A8 The Web API must provide means for the web 1386 application to mute/unmute a stream or stream 1387 component(s). When a stream is sent to a peer 1388 mute status must be preserved in the stream 1389 received by the peer. 1390 ---------------------------------------------------------------- 1391 A9 The Web API must provide means for the web 1392 application to cease the sending of a stream 1393 to a peer. 1394 ---------------------------------------------------------------- 1395 A10 The Web API must provide means for the web 1396 application to cease processing and rendering 1397 of a stream received from a peer. 1398 ---------------------------------------------------------------- 1399 A11 The Web API must provide means for 1400 informing the web application when a 1401 stream from a peer is no longer received. 1402 ---------------------------------------------------------------- 1403 A12 The Web API must provide means for 1404 informing the web application when high 1405 loss rates occur. 1406 ---------------------------------------------------------------- 1407 A13 The Web API must provide means for the web 1408 application to apply spatialization effects to 1409 audio streams. 1410 ---------------------------------------------------------------- 1411 A14 The Web API must provide means for the web 1412 application to detect the level in audio 1413 streams. 1414 ---------------------------------------------------------------- 1415 A15 The Web API must provide means for the web 1416 application to adjust the level in audio 1417 streams. 1418 ---------------------------------------------------------------- 1419 A16 The Web API must provide means for the web 1420 application to mix audio streams. 1421 ---------------------------------------------------------------- 1422 A17 The Web API must provide a way to identify 1423 streams such that an application is able to 1424 match streams on a sending peer with the same 1425 stream on all receiving peers. 1426 ---------------------------------------------------------------- 1427 A18 The Web API must provide a mechanism for sending 1428 and receiving isolated discrete chunks of data. 1429 ---------------------------------------------------------------- 1430 A19 The Web API must provide means for the web 1431 application to indicate the type of audio signal 1432 (speech, audio) for audio stream(s)/stream 1433 component(s). 1435 ---------------------------------------------------------------- 1436 A20 It must be possible for an initiator or a 1437 responder web application to indicate the types 1438 of media it is willing to accept incoming 1439 streams for when setting up a connection (audio, 1440 video, other). The types of media to be accepted 1441 can be a subset of the types of media the browser 1442 is able to accept. 1443 ---------------------------------------------------------------- 1444 A21 The Web API must provide means for the 1445 application to ask the browser for permission 1446 to the screen, a certain area on the screen 1447 or what a certain application displays on the 1448 screen as input to streams. 1449 ---------------------------------------------------------------- 1450 A22 The Web API must provide means for the 1451 application to specify several STUN and/or 1452 TURN servers to use. 1453 ---------------------------------------------------------------- 1454 A23 The Web API must provide means for the 1455 application to specify the priority to 1456 apply for outgoing streams and data. 1457 ---------------------------------------------------------------- 1458 A24 The Web API must provide a mechanism for sending 1459 and receiving files. 1460 ---------------------------------------------------------------- 1461 A25 It must be possible for the application to 1462 instruct the browser to refrain from exposing 1463 the host IP address to the application 1464 ---------------------------------------------------------------- 1465 A26 The Web API must provide means for the 1466 application to obtain the statistics (related 1467 to transport, and collected by the browser) 1468 needed to estimate quality of service. 1469 ---------------------------------------------------------------- 1471 Authors' Addresses 1473 Christer Holmberg 1474 Ericsson 1475 Hirsalantie 11 1476 Jorvas 02420 1477 Finland 1479 Email: christer.holmberg@ericsson.com 1480 Stefan Hakansson 1481 Ericsson 1482 Laboratoriegrand 11 1483 Lulea 97128 1484 Sweden 1486 Email: stefan.lk.hakansson@ericsson.com 1488 Goran AP Eriksson 1489 Ericsson 1490 Farogatan 6 1491 Stockholm 16480 1492 Sweden 1494 Email: goran.ap.eriksson@ericsson.com