idnits 2.17.1 draft-ietf-rtcweb-use-cases-and-requirements-16.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 (January 23, 2015) is 3381 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB Working Group C. Holmberg 3 Internet-Draft S. Hakansson 4 Intended status: Informational G. Eriksson 5 Expires: July 27, 2015 Ericsson 6 January 23, 2015 8 Web Real-Time Communication Use-cases and Requirements 9 draft-ietf-rtcweb-use-cases-and-requirements-16.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 July 27, 2015. 41 Copyright Notice 43 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . 30 96 Appendix A. API requirements . . . . . . . . . . . . . . . . . . 30 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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 the Interactive Connectivity Establishment (ICE) 336 mechanism [RFC5245] will be used, this means that the service 337 provider would like to be able to provide several STUN and TURN 338 servers (via the app) to the browser; selection of which one(s) to 339 use is part of the ICE processing. Other reasons for wanting to 340 provide several STUN and TURN servers include support for IPv4 and 341 IPv6, load balancing and redundancy. 343 Note that ICE support being mandatory does not preclude a WebRTC 344 endpoint from supporting more traversal mechanisms than ICE using 345 STUN and TURN. 347 3.3.4.2. Additional Requirements 349 ---------------------------------------------------------------- 350 REQ-ID DESCRIPTION 351 ---------------------------------------------------------------- 352 F19 The browser must be able to use several STUN 353 and TURN servers 354 ---------------------------------------------------------------- 356 A22 358 3.3.5. Simple Video Communication Service, enterprise aspects 360 3.3.5.1. Description 362 This use-case is similar to the Simple Video Communication Service 363 use-case (Section 3.3.1). 365 What is added is aspects when using the service in enterprises. ICE 366 is assumed in the further description of this use-case. 368 An enterprise that uses a RTCWEB based web application for 369 communication desires to audit all RTCWEB based application sessions 370 used from inside the company towards any external peer. To be able 371 to do this they deploy a TURN server that straddles the boundary 372 between the internal and the external network. 374 The firewall will block all attempts to use STUN with an external 375 destination unless they go to the enterprise auditing TURN server. 376 In cases where employees are using RTCWEB applications provided by an 377 external service provider they still want the traffic to stay inside 378 their internal network and in addition not load the straddling TURN 379 server, thus they deploy a STUN server allowing the RTCWEB client to 380 determine its server reflexive address on the internal side. Thus 381 enabling cases where peers are both on the internal side to connect 382 without the traffic leaving the internal network. It must be 383 possible to configure the browsers used in the enterprise with 384 network specific STUN and TURN servers. This should be possible to 385 achieve by auto-configuration methods. The RTCWEB functionality will 386 need to utilize both network specific STUN and TURN resources and 387 STUN and TURN servers provisioned by the web application. 389 3.3.5.2. Additional Requirements 391 ---------------------------------------------------------------- 392 REQ-ID DESCRIPTION 393 ---------------------------------------------------------------- 394 F20 The browser must support the use of STUN and TURN 395 servers that are supplied by entities other than 396 the web application (i.e. the network provider). 397 ---------------------------------------------------------------- 399 3.3.6. Simple Video Communication Service, access change 401 3.3.6.1. Description 403 This use-case is almost identical to the 404 Simple Video Communication Service use-case (Section 3.3.1). The 405 difference is that the user changes network access during the 406 session. 408 The communication device used by one of the users has several network 409 adapters (Ethernet, WiFi, Cellular). The communication device is 410 accessing the Internet using Ethernet, but the user has to start a 411 trip during the session. The communication device automatically 412 changes to use WiFi when the Ethernet cable is removed and then moves 413 to cellular access to the Internet when moving out of WiFi coverage. 414 The session continues even though the access method changes. 416 3.3.6.2. Additional Requirements 418 ---------------------------------------------------------------- 419 REQ-ID DESCRIPTION 420 ---------------------------------------------------------------- 421 F17 The communication session must survive across a 422 change of the network interface used by the 423 session 424 ---------------------------------------------------------------- 426 3.3.7. Simple Video Communication Service, QoS 428 3.3.7.1. Description 430 This use-case is almost identical to the 431 Simple Video Communication Service, access change use-case 432 (Section 3.3.6). The use of Quality of Service (QoS) capabilities is 433 added: 435 The user in the previous use case that starts a trip is behind a 436 common residential router that supports differentiation of traffic. 437 In addition, the user's provider of cellular access has QoS support 438 enabled. The user is able to take advantage of the QoS support both 439 when accessing via the residential router and when using cellular. 441 3.3.7.2. Additional Requirements 443 ---------------------------------------------------------------- 444 REQ-ID DESCRIPTION 445 ---------------------------------------------------------------- 446 F17 The communication session must survive across a 447 change of the network interface used by the 448 session 449 ---------------------------------------------------------------- 450 F22 The browser should be able to take advantage 451 of available capabilities (supplied by network 452 nodes) to differentiate voice, video and data 453 appropriately. 454 ---------------------------------------------------------------- 456 3.3.8. Simple Video Communication Service with screen sharing 458 3.3.8.1. Description 460 This use-case has the audio and video communication of the 461 Simple Video Communication Service use-case (Section 3.3.1). 463 But in addition to this, one of the users can share what is being 464 displayed on her/his screen with a peer. The user can choose to 465 share the entire screen, part of the screen (part selected by the 466 user) or what a selected application displays with the peer. 468 3.3.8.2. Additional Requirements 469 ---------------------------------------------------------------- 470 REQ-ID DESCRIPTION 471 ---------------------------------------------------------------- 472 F36 The browser must be able to generate streams 473 using the entire user display, a specific area 474 of the user's display or the information being 475 displayed by a specific application. 476 ---------------------------------------------------------------- 478 A21 480 3.3.9. Simple Video Communication Service with file exchange 482 3.3.9.1. Description 484 This use-case has the audio and video communication of the 485 Simple Video Communication Service use-case (Section 3.3.1). 487 But in addition to this, the users can send and receive files stored 488 in the file system of the device used. 490 3.3.9.2. Additional Requirements 492 ---------------------------------------------------------------- 493 REQ-ID DESCRIPTION 494 ---------------------------------------------------------------- 495 F35 The browser must be able to send reliable 496 data traffic to a peer browser. 497 ---------------------------------------------------------------- 499 A21, A24 501 3.3.10. Hockey Game Viewer 503 3.3.10.1. Description 505 An ice-hockey club uses an application that enables talent scouts to, 506 in real-time, show and discuss games and players with the club 507 manager. The talent scouts use a mobile phone with two cameras, one 508 front facing and one rear facing. 510 The club manager uses a desktop, equipped with one camera, for 511 viewing the game and discussing with the talent scout. 513 Before the game starts, and during game breaks, the talent scout and 514 the manager have a 1-1 audiovisual communication session. On the 515 mobile phone, only the camera facing the talent scout is used. On 516 the user display of the mobile phone, the video of the club manager 517 is shown with a picture-in-picture thumbnail of the rear facing 518 camera (self-view). On the display of the desktop, the video of the 519 talent scout is shown with a picture-in-picture thumbnail of the 520 desktop camera (self-view). 522 When the game is on-going, the talent scout activates the use of the 523 front facing camera, and that stream is sent to the desktop (the 524 stream from the rear facing camera continues to be sent all the 525 time). The video stream captured by the front facing camera (that is 526 capturing the game) of the mobile phone is shown in a big window on 527 the desktop screen, with picture-in-picture thumbnails of the rear 528 facing camera and the desktop camera (self-view). On the display of 529 the mobile phone the game is shown (front facing camera) with 530 picture-in-picture thumbnails of the rear facing camera (self-view) 531 and the desktop camera. As the most important stream in this phase 532 is the video showing the game, the application used in the talent 533 scout's mobile sets higher priority for that stream. 535 3.3.10.2. Additional Requirements 537 ---------------------------------------------------------------- 538 REQ-ID DESCRIPTION 539 ---------------------------------------------------------------- 540 F22 The browser should be able to take advantage 541 of available capabilities (supplied by network 542 nodes) to differentiate voice, video and data 543 appropriately. 544 ---------------------------------------------------------------- 545 F25 The browser must be able to render several 546 concurrent audio and video streams. 547 ---------------------------------------------------------------- 549 A17, A23 551 3.3.11. Multiparty video communication 553 3.3.11.1. Description 555 In this use-case, the Simple Video Communication Service use-case 556 (Section 3.3.1) is extended by allowing multiparty sessions. No 557 central server is involved - the browser of each participant sends 558 and receives streams to and from all other session participants. The 559 web application in the browser of each user is responsible for 560 setting up streams to all receivers. 562 In order to enhance the user experience, the web application renders 563 the audio coming from different participants so that it is 564 experienced to come from different spatial locations. This is done 565 automatically, but users can change how the different participants 566 are placed in the (virtual) room. In addition the levels in the 567 audio signals are adjusted before mixing. 569 Another feature intended to enhance the use experience is that the 570 video window that displays the video of the currently speaking peer 571 is highlighted. 573 Each video stream received is by default displayed in a thumbnail 574 frame within the browser, but users can change the display size. 576 Note: What this use-case adds in terms of requirements is 577 capabilities to send streams to and receive streams from several 578 peers concurrently, as well as the capabilities to render the video 579 from all received streams and be able to spatialize, level adjust and 580 mix the audio from all received streams locally in the browser. It 581 also adds the capability to measure the audio level/activity. 583 3.3.11.2. Additional Requirements 585 ---------------------------------------------------------------- 586 REQ-ID DESCRIPTION 587 ---------------------------------------------------------------- 588 F23 The browser must be able to transmit streams and 589 data to several peers concurrently. 590 ---------------------------------------------------------------- 591 F24 The browser must be able to receive streams and 592 data from multiple peers concurrently. 593 ---------------------------------------------------------------- 594 F25 The browser must be able to render several 595 concurrent audio and video streams. 596 ---------------------------------------------------------------- 597 F26 The browser must be able to mix several 598 audio streams. 599 ---------------------------------------------------------------- 600 F27 The browser must be able to apply spatialization 601 effects to audio streams. 602 ---------------------------------------------------------------- 603 F28 The browser must be able to measure the 604 voice activity level in audio streams. 605 ---------------------------------------------------------------- 606 F29 The browser must be able to change the 607 voice activity level in audio streams. 608 ---------------------------------------------------------------- 610 A13, A14, A15, A16 612 3.3.12. Multiparty on-line game with voice communication 614 3.3.12.1. Description 616 This use case is based on the previous one. In this use-case, the 617 voice part of the multiparty video communication use case is used in 618 the context of an on-line game. The received voice audio media is 619 rendered together with game sound objects. For example, the sound of 620 a tank moving from left to right over the screen must be rendered and 621 played to the user together with the voice media. 623 Quick updates of the game state is required, and have higher priority 624 than the voice. 626 Note: the difference regarding local audio processing compared to the 627 "Multiparty video communication" use-case is that other sound objects 628 than the streams must be possible to be included in the 629 spatialization and mixing. "Other sound objects" could for example 630 be a file with the sound of the tank; that file could be stored 631 locally or remotely. 633 3.3.12.2. Additional Requirements 634 ---------------------------------------------------------------- 635 REQ-ID DESCRIPTION 636 ---------------------------------------------------------------- 637 F22 The browser should be able to take advantage 638 of available capabilities (supplied by network 639 nodes) to differentiate voice, video and data 640 appropriately. 641 ---------------------------------------------------------------- 642 F23 The browser must be able to transmit streams and 643 data to several peers concurrently. 644 ---------------------------------------------------------------- 645 F24 The browser must be able to receive streams and 646 data from multiple peers concurrently. 647 ---------------------------------------------------------------- 648 F25 The browser must be able to render several 649 concurrent audio and video streams. 650 ---------------------------------------------------------------- 651 F26 The browser must be able to mix several 652 audio streams. 653 ---------------------------------------------------------------- 654 F27 The browser must be able to apply spatialization 655 effects when playing audio streams. 656 ---------------------------------------------------------------- 657 F28 The browser must be able to measure the 658 voice activity level in audio streams. 659 ---------------------------------------------------------------- 660 F29 The browser must be able to change the 661 voice activity level in audio streams. 662 ---------------------------------------------------------------- 663 F30 The browser must be able to process and mix 664 sound objects (media that is retrieved from 665 another source than the established media 666 stream(s) with the peer(s) with audio streams. 667 ---------------------------------------------------------------- 668 F34 The browser must be able to send short 669 latency unreliable datagram traffic to a 670 peer browser [RFC5405]. 671 ---------------------------------------------------------------- 673 A13, A14, A15, A16, A17, A18, A23 675 3.4. Browser - GW/Server use cases 677 3.4.1. Telephony terminal 678 3.4.1.1. Description 680 A mobile telephony operator allows its customers to use a web browser 681 to access their services. After a simple log in the user can place 682 and receive calls in the same way as when using a normal mobile 683 phone. When a call is received or placed, the identity is shown in 684 the same manner as when a mobile phone is used. 686 Note: With "place and receive calls in the same way as when using a 687 normal mobile phone" it is meant that you can dial a number, and that 688 your mobile telephony operator has made available your phone contacts 689 on line, so they are available and can be clicked to call, and be 690 used to present the identity of an incoming call. If the callee is 691 not in your phone contacts the number is displayed. Furthermore, 692 your call logs are available, and updated with the calls made/ 693 received from the browser. And for people receiving calls made from 694 the web browser the usual identity (i.e. the phone number of the 695 mobile phone) will be presented. 697 3.4.1.2. Additional Requirements 699 ---------------------------------------------------------------- 700 REQ-ID DESCRIPTION 701 ---------------------------------------------------------------- 702 F31 The browser must support an audio media format 703 (codec) that is commonly supported by existing 704 telephony services. 705 ---------------------------------------------------------------- 706 F33 The browser must be able to initiate and 707 accept a media session where the data needed 708 for establishment can be carried in SIP. 709 ---------------------------------------------------------------- 711 3.4.2. Fedex Call 713 3.4.2.1. Description 715 Alice uses her web browser with a service that allows her to call 716 PSTN numbers. Alice calls 1-800-gofedex. Alice should be able to 717 hear the initial prompts from the fedex Interactive Voice Responder 718 (IVR) and when the IVR says press 1, there should be a way for Alice 719 to navigate the IVR. 721 3.4.2.2. Additional Requirements 722 ---------------------------------------------------------------- 723 REQ-ID DESCRIPTION 724 ---------------------------------------------------------------- 725 F31 The browser must support an audio media format 726 (codec) that is commonly supported by existing 727 telephony services. 728 ---------------------------------------------------------------- 729 F32 There should be a way to navigate 730 a Dual-tone multi-frequency signaling (DTMF) 731 based Interactive voice response (IVR) System 732 ---------------------------------------------------------------- 734 3.4.3. Video conferencing system with central server 736 3.4.3.1. Description 738 An organization uses a video communication system that supports the 739 establishment of multiparty video sessions using a central conference 740 server. 742 The browser of each participant sends an audio stream (type in terms 743 of mono, stereo, 5.1, ... depending on the equipment of the 744 participant) to the central server. The central server mixes the 745 audio streams (and can in the mixing process naturally add effects 746 such as spatialization) and sends towards each participant a mixed 747 audio stream which is played to the user. 749 The browser of each participant sends video towards the server. For 750 each participant one high resolution video is displayed in a large 751 window, while a number of low resolution videos are displayed in 752 smaller windows. The server selects what video streams to be 753 forwarded as main- and thumbnail videos respectively, based on speech 754 activity. As the video streams to display can change quite 755 frequently (as the conversation flows) it is important that the delay 756 from when a video stream is selected for display until the video can 757 be displayed is short. 759 All participants are authenticated by the central server, and 760 authorized to connect to the central server. The participants are 761 identified to each other by the central server, and the participants 762 do not have access to each others' credentials such as e-mail 763 addresses or login IDs. 765 Note: This use-case adds requirements on support for fast stream 766 switches F16. There exist several solutions that enable the server 767 to forward one high resolution and several low resolution video 768 streams: a) each browser could send a high resolution, but scalable 769 stream, and the server could send just the base layer for the low 770 resolution streams, b) each browser could in a simulcast fashion send 771 one high resolution and one low resolution stream, and the server 772 just selects or c) each browser sends just a high resolution stream, 773 the server transcodes into low resolution streams as required. 775 3.4.3.2. Additional Requirements 777 ---------------------------------------------------------------- 778 REQ-ID DESCRIPTION 779 ---------------------------------------------------------------- 780 F16 The browser must support insertion of reference frames 781 in outgoing media streams when requested by a peer. 782 ---------------------------------------------------------------- 783 F25 The browser must be able to render several 784 concurrent audio and video streams. 785 ---------------------------------------------------------------- 787 4. Requirements summary 789 4.1. General 791 This section contains the requirements on the browser derived from 792 the use-cases in Section 3. 794 NOTE: It is assumed that the user applications are executed on a 795 browser. Whether the capabilities to implement specific browser 796 requirements are implemented by the browser application, or are 797 provided to the browser application by the underlying operating 798 system, is outside the scope of this document. 800 4.2. Browser requirements 802 ---------------------------------------------------------------- 803 Common, basic requirements 804 ---------------------------------------------------------------- 805 REQ-ID DESCRIPTION 806 ---------------------------------------------------------------- 807 F1 The browser must be able to use microphones and 808 cameras as input devices to generate streams. 809 ---------------------------------------------------------------- 810 F2 The browser must be able to send streams and 811 data to a peer in the presence of NATs. 812 ---------------------------------------------------------------- 813 F3 Transmitted streams and data must be rate 814 controlled (meaning that the browser must, regardless 815 of application behavior, reduce send rate when 816 there is congestion). 818 ---------------------------------------------------------------- 819 F4 The browser must be able to receive, process and 820 render streams and data ("render" does not 821 apply for data) from peers. 822 ---------------------------------------------------------------- 823 F5 The browser should be able to render good quality 824 audio and video even in the presence of 825 reasonable levels of jitter and packet losses. 826 ---------------------------------------------------------------- 827 F6 The browser must detect when a stream from a 828 peer is not received anymore 829 ---------------------------------------------------------------- 830 F7 When there are both incoming and outgoing audio 831 streams, echo cancellation must be made 832 available to avoid disturbing echo during 833 conversation. 834 ---------------------------------------------------------------- 835 F8 The browser must support synchronization of 836 audio and video. 837 ---------------------------------------------------------------- 838 F9 The browser should use encoding of streams 839 suitable for the current rendering (e.g. 840 video display size) and should change parameters 841 if the rendering changes during the session 842 ---------------------------------------------------------------- 843 F10 The browser must support a baseline audio and 844 video codec 845 ---------------------------------------------------------------- 846 F11 It must be possible to protect streams and data 847 from wiretapping [RFC2804][RFC7258]. 848 ---------------------------------------------------------------- 849 F12 The browser must enable verification, given 850 the right circumstances and by use of other 851 trusted communication, that streams and 852 data received have not been manipulated by 853 any party. 854 ---------------------------------------------------------------- 855 F13 The browser must encrypt, authenticate and 856 integrity protect media and data on a 857 per-packet basis, and must drop incoming media 858 and data packets that fail the per-packet 859 integrity check. In addition, the browser 860 must support a mechanism for cryptographically 861 binding media and data security keys to the 862 user identity (see R-ID-BINDING in [RFC5479]). 863 ---------------------------------------------------------------- 864 F14 The browser must make it possible to set up a 865 call between two parties without one party 866 learning the other party's host IP address. 867 ---------------------------------------------------------------- 868 F15 The browser must be able to collect statistics, 869 related to the transport of audio and video 870 between peers, needed to estimate quality of 871 experience. 872 ---------------------------------------------------------------- 873 Requirements related to network and topology 874 ---------------------------------------------------------------- 875 REQ-ID DESCRIPTION 876 ---------------------------------------------------------------- 877 F16 The browser must support insertion of reference frames 878 in outgoing media streams when requested by a peer. 879 ---------------------------------------------------------------- 880 F17 The communication session must survive across a 881 change of the network interface used by the 882 session 883 ---------------------------------------------------------------- 884 F18 The browser must be able to send streams and 885 data to a peer in the presence of NATs and 886 Firewalls that block UDP traffic. 887 ---------------------------------------------------------------- 888 F19 The browser must be able to use several STUN 889 and TURN servers 890 ---------------------------------------------------------------- 891 F20 The browser must support the use of STUN and TURN 892 servers that are supplied by entities other than 893 the web application (i.e. the network provider). 894 ---------------------------------------------------------------- 895 F21 The browser must be able to send streams and 896 data to a peer in the presence of Firewalls that only 897 allows traffic via a HTTP Proxy, when Firewall policy 898 allows WebRTC traffic. 899 ---------------------------------------------------------------- 900 F22 The browser should be able to take advantage 901 of available capabilities (supplied by network 902 nodes) to differentiate voice, video and data 903 appropriately. 904 ---------------------------------------------------------------- 905 Requirements related to multiple peers and streams 906 ---------------------------------------------------------------- 907 REQ-ID DESCRIPTION 908 ---------------------------------------------------------------- 909 F23 The browser must be able to transmit streams and 910 data to several peers concurrently. 911 ---------------------------------------------------------------- 912 F24 The browser must be able to receive streams and 913 data from multiple peers concurrently. 915 ---------------------------------------------------------------- 916 F25 The browser must be able to render several 917 concurrent audio and video streams. 918 ---------------------------------------------------------------- 919 F26 The browser must be able to mix several 920 audio streams. 921 ---------------------------------------------------------------- 922 Requirements related to audio processing 923 ---------------------------------------------------------------- 924 REQ-ID DESCRIPTION 925 ---------------------------------------------------------------- 926 F27 The browser must be able to apply spatialization 927 effects when playing audio streams. 928 ---------------------------------------------------------------- 929 F28 The browser must be able to measure the 930 voice activity level in audio streams. 931 ---------------------------------------------------------------- 932 F29 The browser must be able to change the 933 voice activity level in audio streams. 934 ---------------------------------------------------------------- 935 F30 The browser must be able to process and mix 936 sound objects (media that is retrieved from 937 another source than the established media 938 stream(s) with the peer(s) with audio streams. 939 ---------------------------------------------------------------- 940 Requirements related to legacy interop 941 ---------------------------------------------------------------- 942 REQ-ID DESCRIPTION 943 ---------------------------------------------------------------- 944 F31 The browser must support an audio media format 945 (codec) that is commonly supported by existing 946 telephony services. 947 ---------------------------------------------------------------- 948 F32 There should be a way to navigate 949 a Dual-tone multi-frequency signaling (DTMF) 950 based Interactive voice response (IVR) System 951 ---------------------------------------------------------------- 952 F33 The browser must be able to initiate and 953 accept a media session where the data needed 954 for establishment can be carried in SIP. 955 ---------------------------------------------------------------- 956 Other requirements 957 ---------------------------------------------------------------- 958 REQ-ID DESCRIPTION 959 ---------------------------------------------------------------- 960 F34 The browser must be able to send short 961 latency unreliable datagram traffic to a 962 peer browser [RFC5405]. 964 ---------------------------------------------------------------- 965 F35 The browser must be able to send reliable 966 data traffic to a peer browser. 967 ---------------------------------------------------------------- 968 F36 The browser must be able to generate streams 969 using the entire user display, a specific area 970 of the user's display or the information being 971 displayed by a specific application. 972 ---------------------------------------------------------------- 974 5. IANA Considerations 976 There are no IANA actions in this document. 978 6. Security Considerations 980 6.1. Introduction 982 A malicious web application might use the browser to perform Denial 983 Of Service (DOS) attacks on NAT infrastructure, or on peer devices. 984 Also, a malicious web application might silently establish outgoing, 985 and accept incoming, streams on an already established connection. 987 Based on the identified security risks, this section will describe 988 security considerations for the browser and web application. 990 6.2. Browser Considerations 992 The browser is expected to provide mechanisms for getting user 993 consent to use device resources such as camera and microphone. 995 The browser is expected to provide mechanisms for informing the user 996 that device resources such as camera and microphone are in use 997 ("hot"). 999 The browser must provide mechanisms for users to revise and even 1000 completely revoke consent to use device resources such as camera and 1001 microphone. 1003 The browser is expected to provide mechanisms for getting user 1004 consent to use the screen (or a certain part of it) or what a certain 1005 application displays on the screen as source for streams. 1007 The browser is expected to provide mechanisms for informing the user 1008 that the screen, part thereof or an application is serving as a 1009 stream source ("hot"). 1011 The browser must provide mechanisms for users to revise and even 1012 completely revoke consent to use the screen, part thereof or an 1013 application is serving as a stream source. 1015 The browser is expected to provide mechanisms in order to assure that 1016 streams are the ones the recipient intended to receive. 1018 The browser is expected to provide mechanisms that allows the users 1019 to verify that the streams received have not be manipulated (F12). 1021 The browser needs to ensure that media is not sent, and that received 1022 media is not rendered, until the associated stream establishment and 1023 handshake procedures with the remote peer have been successfully 1024 finished. 1026 The browser needs to ensure that the stream negotiation procedures 1027 are not seen as Denial Of Service (DOS) by other entities. 1029 6.3. Web Application Considerations 1031 The web application is expected to ensure user consent in sending and 1032 receiving media streams. 1034 7. Acknowledgements 1036 The authors wish to thank Bernard Aboba, Gunnar Hellstrom, Martin 1037 Thomson, Lars Eggert, Matthew Kaufman, Emil Ivov, Eric Rescorla, Eric 1038 Burger, John Leslie, Dan Wing, Richard Barnes, Barry Dingle, Dale 1039 Worley, Ted hardie, Mary Barnes, Dan Burnett, Stephan Wenger, Harald 1040 Alvestrand, Cullen Jennings, Andrew Hutton and everyone else in the 1041 RTCWEB community that have provided comments, feedback, text and 1042 improvement proposals on the document. A big thank you to everyone 1043 that provided comments as part of the IESG evaluation, and to 1044 everyone else that provided comments and input in order to improve 1045 the document. 1047 8. Change Log 1049 [RFC EDITOR NOTE: Please remove this section when publishing] 1051 Changes from draft-ietf-rtcweb-use-cases-and-requirements-15 1053 o Changes based on comment from Stephen Farrell: 1055 o - A1 modified, to also cover access to the local file stystem. 1057 o Changes based on comments from Benoit Claise: 1059 o - RFC 5245 added to references. 1061 o - Note added to Annex A, indicating that the API requirements are 1062 not normative. 1064 o Changes based on comments from Brian Carpenter: 1066 o - RFC 7258 added to references. 1068 o - Terminology fixes: 1070 o -- 'prioritize' -> 'differentiate'. 1072 o -- 'prioritization' -> 'differentiation'. 1074 Changes from draft-ietf-rtcweb-use-cases-and-requirements-14 1076 o Changes based on comments from the ops-dir: 1078 o - Editorial fixes. 1080 o - F13: 'per-packet basis' -> 'per IP packet basis'. 1082 o - F22: Text corrected in one occurance. 1084 o - F25: 'audio' added. 1086 o Changes based on comments from IESG 1088 o - Editorial fixes. 1090 o - Disclaimer text suggested by Alissa Cooper added. 1092 o - F11: Reference to RFC 7258 added. 1094 o - F27: 'when playing' removed. 1096 Changes from draft-ietf-rtcweb-use-cases-and-requirements-10 1098 o Described that the API requirements are really from a W3C 1099 perspective and are supplied as an appendix in the introduction. 1100 Moved API requirements to an Appendix. 1102 o Removed the "Conventions" section with the key-words and reference 1103 to RFC2119. Also changed uppercase MUST's/SHOULD's to lowercase. 1105 o Added a note on the proposed use of the document to the 1106 introduction. 1108 o Removed the note talking about WS from the "Firewall that only 1109 allows http" use-case. 1111 o Removed the word "Skype" that was used as example in one of the 1112 use-cases. 1114 o Clarified F3 (the req saying the everything the browser sends must 1115 be rate controlled). 1117 o Removed the TBD saying we need to define reasonable levels from 1118 the requirement saying that quality must be good even in presence 1119 of packet losses (F5), and changed "must" to "should" (Based on a 1120 list discussion involving Bernard). 1122 o Removed F6 ("The browser must be able to handle high loss and 1123 jitter levels in a graceful way."), also after a list discussion. 1125 o Clarified F7 (used to say that the browser must support fast 1126 stream switches, now says that reference frames must be inserted 1127 when requested). 1129 o Removed the questions from F9 (echo cancellation), F10 1130 (synchronization), F21 (telephony codec). 1132 o Exchanged "restrictive firewalls" for "limited middleboxes" in F19 1133 (as proposed by Martin). 1135 o Expanded DTMF and IVR in F22 (proposed by Martin) 1137 o Added ref to RFC5405 in F23 (proposed by Lars Eggert). 1139 o Exchanged "service provided" for "web application" in F32. 1141 o Changed the text in 3.2.1 that motivates F36 (new text "It is 1142 essential that media and data be encrypted, authenticated ... 1143 bound to the user identity."); and rewrote F36, included a ref to 1144 RFC5479. 1146 o Changed "quality of service" to "quality of experience" in F38. 1148 o Added F39. 1150 o Used new formulation of A17 (proposed by Martin). 1152 o Updated A20. 1154 o Updated A25. 1156 Changes from draft-ietf-rtcweb-use-cases-and-requirements-09 1158 o Changed "video communication session" to "audiovisual 1159 communication session. 1161 Changes from draft-ietf-rtcweb-use-cases-and-requirements-08 1163 o Changed "eavesdropping" to "wiretapping" and referenced RFC2804. 1165 o Removed informal ref webrtc_req; that document has been abandoned 1166 by the W3C webrtc WG. 1168 o Added use-case where one user is behind a Firewall that only 1169 allows http; derived req. F37. 1171 o Changed F24 slightly; MUST-> SHOULD, inserted "available". 1173 o Added a clause to "Simple video communication service" saying that 1174 the service provider monitors the quality of service, and derived 1175 reqs F38 and A26. 1177 Changes from draft-ietf-rtcweb-use-cases-and-requirements-07 1179 o Added "and data exchange" to 1. Introduction. 1181 o Removed cone and symmetric NAT from 4.1 Introduction, refers to 1182 RFC4787 instead. 1184 o Added text on enabling verification of that the media has not been 1185 manipulated by anyone to use-case "Simple Video Communication 1186 Service", derived req. F35 1188 o Added text on that the browser should reject media (data) that has 1189 been created/injected/modified by non-trusted party, derived req. 1190 F36 1192 o Added text on enabling the app to refrain from revealing IP 1193 address to use-case "Simple Video Communication Service", derived 1194 req. A25 1196 o Added use-case "Simple Video Communication Service with file 1197 exchange", derived reqs F33 and A24 1199 o Added priority of video streams to "Hockey game viewer" use case, 1200 added priority of data to "on-line game use-case", derived reqs 1201 F34 and A23 1203 o In F22, "the IVR" -> "a DTMF based IVR". 1205 o Updated req F23 to clarify that requirements such as NAT 1206 traversal, protection from eavesdropping, rate control applies 1207 also to datagram. 1209 Changes from draft-ietf-rtcweb-use-cases-and-requirements-06 1211 o Renaming of requirements (FaI1 -> F31), (FaI2 -> F32) and (AaI1 -> 1212 A22) 1214 Changes from draft-ietf-rtcweb-use-cases-and-requirements-05 1216 o Added use-case "global service provider", derived reqs associated 1217 with several STUN/TURN servers 1219 o Added use-case "enterprise aspects", derived req associated with 1220 enabling the network provider to supply STUN and TURN servers 1222 o The requirements from the above are ICE specific and labeled 1223 accordingly 1225 o Separated the requirements phrased like "processing such as pan, 1226 mix and render" for audio to be specific reqs on spatialization, 1227 level measurement, level adjustment and mixing (discussed on the 1228 lists in http://www.ietf.org/mail-archive/web/rtcweb/current/ 1229 msg01648.html and http://lists.w3.org/Archives/Public/public- 1230 webrtc/2011Sep/0102.html) 1232 o Added use-case on sharing as decided in http://www.ietf.org/mail- 1233 archive/web/rtcweb/current/msg01700.html, derived reqs F30 and A21 1235 o Added the list of common considerations proposed in mail 1236 http://www.ietf.org/mail-archive/web/rtcweb/current/msg01562.html 1237 to the Introduction of the use-case section 1239 Changes from draft-ietf-rtcweb-use-cases-and-requirements-04 1241 o Most changes based on the input from Dan Burnett 1242 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00948.html 1244 o Many editorial changes 1246 o 4.2.1.1 Clarified 1247 o Some clarification added to 4.3.1.1 as a note 1249 o F-requirements updated (see reply to Dan's mail). 1251 o Almost all A-requirements updated to start "The Web API MUST 1252 provide ..." 1254 o A8 removed, A9 rephrased to cover A8 and old A9 1256 o A15 rephrased 1258 o For more details, and discussion, look at the response to Dan's 1259 mail http://www.ietf.org/mail-archive/web/rtcweb/current/ 1260 msg01177.html 1262 Changes from draft-ietf-rtcweb-use-cases-and-requirements-03 1264 o Editorials 1266 o Changed when the self-view is displayed in 4.2.1.1, and added 1267 words about allowing users to remove and re-insert it. 1269 o Clarified 4.2.6.1 1271 o Removed the "mono" stuff from 4.2.7.1 1273 o Added that communication should not be possible to eavesdrop to 1274 most use cases - and req. F17 1276 o Re-phrased 4.3.3.1 to not describe the technical solution so much, 1277 and removed "stereo" stuff. Solution possibilities are now in a 1278 note. 1280 o Re-inserted API requirements after discussion in the W3C webrtc 1281 WG. (Re-phrased A15 and added A18 compared to version -02). 1283 Changes from draft-ietf-rtcweb-use-cases-and-requirements-02 1285 o Removed description/list of API requirements, instead 1287 o Reference to W3C webrtc_reqs document for API requirements 1289 Changes from draft-ietf-rtcweb-ucreqs-01 1291 o Changed Intended status to Information 1293 o Changed "Ipr" to "trust200902" 1294 o Added use case "Simple video communication service, NAT/Firewall 1295 that blocks UDP", and derived new req F26 1297 o Added use case "Distributed Music Band" and derived new req A17 1299 o Added F24 as requirement derived from use case "Simple video 1300 communication service with inter-operator calling" 1302 o Added section "Additional use cases" 1304 o Added text about ID handling to multiparty with central server use 1305 case 1307 o Re-phrased A1 slightly 1309 Changes from draft-ietf-rtcweb-ucreqs-00 1311 o - Reshuffled: Just two main groups of use cases (b2b and b2GW/ 1312 Server); removed some specific use cases and added them instead as 1313 flavors to the base use case (Simple video communication) 1315 o - Changed the formulation of F19 1317 o - Removed the requirement on an API for DTMF 1319 o - Removed "FX3: There SHOULD be a mapping of the minimum needed 1320 data for setting up connections into SIP, so that the restriction 1321 to SIP-carriable data can be verified. Not a rew on the browser 1322 but rather on a document" 1324 o - (see http://www.ietf.org/mail-archive/web/rtcweb/current/ 1325 msg00227.html for more details) 1327 o -Added text on informing user of that mic/cam is being used and 1328 that it must be possible to revoce permission to use them in 1329 section 7. 1331 Changes from draft-holmberg-rtcweb-ucreqs-01 1333 o - Draft name changed to draft-ietf-rtcweb-ucreqs 1335 o - Use-case grouping introduced 1337 o - Additional use-cases added 1339 o - Additional reqs added (derived from use cases): F19-F25, A16-A17 1341 Changes from draft-holmberg-rtcweb-ucreqs-00 1342 o - Mapping between use-cases and requirements added (Harald 1343 Alvestrand, 090311) 1345 o - Additional security considerations text (Harald Alvestrand, 1346 090311) 1348 o - Clarification that user applications are assumed to be executed 1349 by a browser (Ted Hardie, 080311) 1351 o - Editorial corrections and clarifications 1353 9. Normative References 1355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1356 Requirement Levels", BCP 14, RFC 2119, March 1997. 1358 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 1359 2000. 1361 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1362 (ICE): A Protocol for Network Address Translator (NAT) 1363 Traversal for Offer/Answer Protocols", RFC 5245, April 1364 2010. 1366 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1367 for Application Designers", BCP 145, RFC 5405, November 1368 2008. 1370 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 1371 "Requirements and Analysis of Media Security Management 1372 Protocols", RFC 5479, April 2009. 1374 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1375 Attack", BCP 188, RFC 7258, May 2014. 1377 Appendix A. API requirements 1379 This section contains the requirements on the API derived from the 1380 use-cases in Section 3. 1382 NOTE: As W3C is responsible for the API, the API requirements in this 1383 specification are not normative. 1385 REQ-ID DESCRIPTION 1386 ---------------------------------------------------------------- 1387 A1 The Web API must provide means for the 1388 application to ask the browser for permission 1389 to use cameras and microphones as input devices, 1390 and to have access to the local file system. 1391 ---------------------------------------------------------------- 1392 A2 The Web API must provide means for the web 1393 application to control how streams generated 1394 by input devices are used. 1395 ---------------------------------------------------------------- 1396 A3 The Web API must provide means for the web 1397 application to control the local rendering of 1398 streams (locally generated streams and streams 1399 received from a peer). 1400 ---------------------------------------------------------------- 1401 A4 The Web API must provide means for the web 1402 application to initiate sending of 1403 stream/stream components to a peer. 1404 ---------------------------------------------------------------- 1405 A5 The Web API must provide means for the web 1406 application to control the media format (codec) 1407 to be used for the streams sent to a peer. 1409 NOTE: The level of control depends on whether 1410 the codec negotiation is handled by the browser 1411 or the web application. 1412 ---------------------------------------------------------------- 1413 A6 The Web API must provide means for the web 1414 application to modify the media format for 1415 streams sent to a peer after a media stream 1416 has been established. 1417 ---------------------------------------------------------------- 1418 A7 The Web API must provide means for 1419 informing the web application of whether the 1420 establishment of a stream with a peer was 1421 successful or not. 1422 ---------------------------------------------------------------- 1423 A8 The Web API must provide means for the web 1424 application to mute/unmute a stream or stream 1425 component(s). When a stream is sent to a peer 1426 mute status must be preserved in the stream 1427 received by the peer. 1428 ---------------------------------------------------------------- 1429 A9 The Web API must provide means for the web 1430 application to cease the sending of a stream 1431 to a peer. 1432 ---------------------------------------------------------------- 1433 A10 The Web API must provide means for the web 1434 application to cease processing and rendering 1435 of a stream received from a peer. 1436 ---------------------------------------------------------------- 1437 A11 The Web API must provide means for 1438 informing the web application when a 1439 stream from a peer is no longer received. 1440 ---------------------------------------------------------------- 1441 A12 The Web API must provide means for 1442 informing the web application when high 1443 loss rates occur. 1444 ---------------------------------------------------------------- 1445 A13 The Web API must provide means for the web 1446 application to apply spatialization effects to 1447 audio streams. 1448 ---------------------------------------------------------------- 1449 A14 The Web API must provide means for the web 1450 application to detect the level in audio 1451 streams. 1452 ---------------------------------------------------------------- 1453 A15 The Web API must provide means for the web 1454 application to adjust the level in audio 1455 streams. 1456 ---------------------------------------------------------------- 1457 A16 The Web API must provide means for the web 1458 application to mix audio streams. 1459 ---------------------------------------------------------------- 1460 A17 The Web API must provide a way to identify 1461 streams such that an application is able to 1462 match streams on a sending peer with the same 1463 stream on all receiving peers. 1464 ---------------------------------------------------------------- 1465 A18 The Web API must provide a mechanism for sending 1466 and receiving isolated discrete chunks of data. 1467 ---------------------------------------------------------------- 1468 A19 The Web API must provide means for the web 1469 application to indicate the type of audio signal 1470 (speech, audio) for audio stream(s)/stream 1471 component(s). 1472 ---------------------------------------------------------------- 1473 A20 It must be possible for an initiator or a 1474 responder web application to indicate the types 1475 of media it is willing to accept incoming 1476 streams for when setting up a connection (audio, 1477 video, other). The types of media to be accepted 1478 can be a subset of the types of media the browser 1479 is able to accept. 1480 ---------------------------------------------------------------- 1481 A21 The Web API must provide means for the 1482 application to ask the browser for permission 1483 to the screen, a certain area on the screen 1484 or what a certain application displays on the 1485 screen as input to streams. 1486 ---------------------------------------------------------------- 1487 A22 The Web API must provide means for the 1488 application to specify several STUN and/or 1489 TURN servers to use. 1490 ---------------------------------------------------------------- 1491 A23 The Web API must provide means for the 1492 application to specify the priority to 1493 apply for outgoing streams and data. 1494 ---------------------------------------------------------------- 1495 A24 The Web API must provide a mechanism for sending 1496 and receiving files. 1497 ---------------------------------------------------------------- 1498 A25 It must be possible for the application to 1499 instruct the browser to refrain from exposing 1500 the host IP address to the application 1501 ---------------------------------------------------------------- 1502 A26 The Web API must provide means for the 1503 application to obtain the statistics (related 1504 to transport, and collected by the browser) 1505 needed to estimate quality of service. 1506 ---------------------------------------------------------------- 1508 Authors' Addresses 1510 Christer Holmberg 1511 Ericsson 1512 Hirsalantie 11 1513 Jorvas 02420 1514 Finland 1516 Email: christer.holmberg@ericsson.com 1518 Stefan Hakansson 1519 Ericsson 1520 Laboratoriegrand 11 1521 Lulea 97128 1522 Sweden 1524 Email: stefan.lk.hakansson@ericsson.com 1525 Goran AP Eriksson 1526 Ericsson 1527 Farogatan 6 1528 Stockholm 16480 1529 Sweden 1531 Email: goran.ap.eriksson@ericsson.com