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