idnits 2.17.1 draft-ietf-rtcweb-use-cases-and-requirements-11.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1026: '...slightly; MUST-> SHOULD, inserted "ava...' RFC 2119 keyword, line 1107: '...nts updated to start "The Web API MUST...' RFC 2119 keyword, line 1174: '...oved "FX3: There SHOULD be a mapping o...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 667 has weird spacing: '...resence of NA...' == Line 785 has weird spacing: '...of that strea...' -- The document date (June 27, 2013) is 3955 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) Summary: 2 errors (**), 0 flaws (~~), 4 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: December 29, 2013 Ericsson 6 June 27, 2013 8 Web Real-Time Communication Use-cases and Requirements 9 draft-ietf-rtcweb-use-cases-and-requirements-11.txt 11 Abstract 13 This document describes web based real-time communication use-cases. 14 Requirements on the browser functionality are derived from use-cases. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 29, 2013. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 54 3.2. Browser-to-browser use-cases . . . . . . . . . . . . . . 4 55 3.2.1. Simple Video Communication Service . . . . . . . . . 4 56 3.2.2. Simple Video Communication Service, NAT/FW that 57 blocks UDP . . . . . . . . . . . . . . . . . . . . . 5 58 3.2.3. Simple Video Communication Service, FW that only 59 allows http . . . . . . . . . . . . . . . . . . . . . 5 60 3.2.4. Simple Video Communication Service, global service 61 provider . . . . . . . . . . . . . . . . . . . . . . 6 62 3.2.5. Simple Video Communication Service, enterprise 63 aspects . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2.6. Simple Video Communication Service, access change . . 7 65 3.2.7. Simple Video Communication Service, QoS . . . . . . . 7 66 3.2.8. Simple Video Communication Service with sharing . . . 8 67 3.2.9. Simple Video Communication Service with file exchange 8 68 3.2.10. Simple video communication service with inter- 69 operator calling . . . . . . . . . . . . . . . . . . 8 70 3.2.11. Hockey Game Viewer . . . . . . . . . . . . . . . . . 9 71 3.2.12. Multiparty video communication . . . . . . . . . . . 10 72 3.2.13. Multiparty on-line game with voice communication . . 11 73 3.2.14. Distributed Music Band . . . . . . . . . . . . . . . 12 74 3.3. Browser - GW/Server use cases . . . . . . . . . . . . . . 12 75 3.3.1. Telephony terminal . . . . . . . . . . . . . . . . . 12 76 3.3.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . 13 77 3.3.3. Video conferencing system with central server . . . . 13 78 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 14 79 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 4.2. Browser requirements . . . . . . . . . . . . . . . . . . 15 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 18 84 6.2. Browser Considerations . . . . . . . . . . . . . . . . . 18 85 6.3. Web Application Considerations . . . . . . . . . . . . . 19 86 7. Additional use-cases . . . . . . . . . . . . . . . . . . . . 19 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 88 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 10. Normative References . . . . . . . . . . . . . . . . . . . . 26 90 Appendix A. API requirements . . . . . . . . . . . . . . . . . . 27 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 93 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 client is of another type (e.g. a telephone). 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 described in Section 4.2. 104 This document was developed in an initial phase of the work with 105 rather minor updates at later stages. It has not really served as a 106 tool in deciding features or scope for the WGs efforts so far. It is 107 proposed to be used in a later phase to evaluate the protocols and 108 solutions developed by the WG. 110 This document also lists requirements related to the API to be used 111 by web applications as an appendix. The reason is that the W3C 112 WebRTC WG has decided to not develop its own use-case/requirement 113 document, but instead use this document. These requirements are 114 named "An", where n is an integer, and are described in Appendix A- 116 The document focuses on requirements related to real-time media 117 streams and data exchange. Requirements related to privacy, 118 signalling between the browser and web server etc. are currently not 119 considered. 121 2. Definitions 123 TBD 125 3. Use-cases 127 3.1. Introduction 129 This section describes web based real-time communication use-cases, 130 from which requirements are derived. 132 The following considerations are applicable to all use cases: 134 o Clients can be on IPv4-only 136 o Clients can be on IPv6-only 138 o Clients can be on dual-stack 140 o Clients can be on wideband (10s of Mbits/sec) 141 o Clients can be on narrowband (10s to 100s of Kbits/sec) 143 o Clients can be on variable-media-quality networks (wireless) 145 o Clients can be on congested networks 147 o Clients can be on firewalled networks with no UDP allowed 149 o Clients can be on networks with any type (as described in RFC4787) 150 of NAT. 152 3.2. Browser-to-browser use-cases 154 3.2.1. Simple Video Communication Service 156 3.2.1.1. Description 158 Two or more users have loaded a video communication web application 159 into their browsers, provided by the same service provider, and 160 logged into the service it provides. The web service publishes 161 information about user login status by pushing updates to the web 162 application in the browsers. When one online user selects a peer 163 online user, a 1-1 audiovisual communication session between the 164 browsers of the two peers is initiated. The invited user might 165 accept or reject the session. 167 During session establishment a self-view is displayed, and once the 168 session has been established the video sent from the remote peer is 169 displayed in addition to the self-view. During the session, each 170 user can select to remove and re-insert the self-view as often as 171 desired. Each user can also change the sizes of his/her two video 172 displays during the session. Each user can also pause sending of 173 media (audio, video, or both) and mute incoming media 175 It is essential that the communication cannot be wiretapped 176 [RFC2804]. 178 It is essential that media and data be encrypted, authenticated and 179 integrity protected on a per-packet basis and that media and data 180 packets failing the integrity check not be delivered to the 181 application. 183 In addition, it is required that browsers enable the media and data 184 security keys to be cryptographically bound to the user identity. 186 The application gives the users the opportunity to stop it from 187 exposing the host IP address to the application of the other user. 189 Any session participant can end the session at any time. 191 The two users may be using communication devices of different makes, 192 with different operating systems and browsers from different vendors. 194 One user has an unreliable Internet connection. It sometimes loses 195 packets, and sometimes goes down completely. 197 One user is located behind a Network Address Translator (NAT). 199 The web service monitors the quality of the service (focus on quality 200 of audio and video) the end-users experience. 202 3.2.1.2. Derived Requirements 204 F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F35, F36, F38, F39 206 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A25, A26 208 3.2.2. Simple Video Communication Service, NAT/FW that blocks UDP 210 3.2.2.1. Description 212 This use-case is almost identical to the Simple Video Communication 213 Service use-case (Section 3.2.1). The difference is that one of the 214 users is behind a NAT that blocks UDP traffic. 216 3.2.2.2. Derived Requirements 218 F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F29 220 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 222 3.2.3. Simple Video Communication Service, FW that only allows http 224 3.2.3.1. Description 226 This use-case is almost identical to the Simple Video Communication 227 Service use-case (Section 3.2.1). The difference is that one of the 228 users is behind a FW that only allows http traffic. 230 3.2.3.2. Derived Requirements 232 F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F37 234 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 236 3.2.4. Simple Video Communication Service, global service provider 238 3.2.4.1. Description 240 This use-case is almost identical to the Simple Video Communication 241 Service use-case (Section 3.2.1). 243 What is added is that the service provider is operating over large 244 geographical areas (or even globally). 246 Assuming that ICE will be used, this means that the service provider 247 would like to be able to provide several STUN and TURN servers (via 248 the app) to the browser; selection of which one(s) to use is part of 249 the ICE processing. Other reasons for wanting to provide several 250 STUN and TURN servers include support for IPv4 and IPv6, load 251 balancing and redundancy. 253 3.2.4.2. Derived Requirements 255 F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F31 257 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A22 259 3.2.5. Simple Video Communication Service, enterprise aspects 261 3.2.5.1. Description 263 This use-case is similar to the Simple Video Communication Service 264 use-case (Section 3.2.1). 266 What is added is aspects when using the service in enterprises. ICE 267 is assumed in the further description of this use-case. 269 An enterprise that uses a RTCWEB based web application for 270 communication desires to audit all RTCWEB based application session 271 used from inside the company towards any external peer. To be able 272 to do this they deploy a TURN server that straddle the boundary 273 between the internal network and the external. 275 The firewall will block all attempts to use STUN with an external 276 destination unless they go to the enterprise auditing TURN server. 277 In cases where employees are using RTCWEB applications provided by an 278 external service provider they still want to have the traffic to stay 279 inside their internal network and in addition not load the straddling 280 TURN server, thus they deploy a STUN server allowing the RTCWEB 281 client to determine its server reflexive address on the internal 282 side. Thus enabling cases where peers are both on the internal side 283 to connect without the traffic leaving the internal network. It must 284 be possibele to configure the browsers used in the enterprise with 285 network specific STUN and TURN servers. This should be possible to 286 achieve by autoconfiguration methods. The RTCWEB functionality will 287 need to utilize both network specific STUN and TURN resources and 288 STUN and TURN servers provisioned by the web application. 290 3.2.5.2. Derived Requirements 292 F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F32 294 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 296 3.2.6. Simple Video Communication Service, access change 298 3.2.6.1. Description 300 This use-case is almost identical to the Simple Video Communication 301 Service use-case (Section 3.2.1). The difference is that the user 302 changes network access during the session: 304 The communication device used by one of the users have several 305 network adapters (Ethernet, WiFi, Cellular). The communication 306 device is accessing the Internet using Ethernet, but the user has to 307 start a trip during the session. The communication device 308 automatically changes to use WiFi when the Ethernet cable is removed 309 and then moves to cellular access to the Internet when moving out of 310 WiFi coverage. The session continues even though the access method 311 changes. 313 3.2.6.2. Derived Requirements 315 F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F26, F28 317 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 319 3.2.7. Simple Video Communication Service, QoS 321 3.2.7.1. Description 323 This use-case is almost identical to the Simple Video Communication 324 Service, access change use-case (Section 3.2.6). The use of Quality 325 of Service (QoS) capabilities is added: 327 The user in the previous use case that starts a trip is behind a 328 common residential router that supports prioritization of traffic. 329 In addition, the user's provider of cellular access has QoS support 330 enabled. The user is able to take advantage of the QoS support both 331 when accessing via the residential router and when using cellular. 333 3.2.7.2. Derived Requirements 335 F1, F2, F3, F4, F5, F8, F9, F10, F20, F24, F25, F26, F28 337 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 339 3.2.8. Simple Video Communication Service with sharing 341 3.2.8.1. Description 343 This use-case has the audio and video communication of the Simple 344 Video Communication Service use-case (Section 3.2.1). 346 But in addition to this, one of the users can share what is being 347 displayed on her/his screen with a peer. The user can choose to 348 share the entire screen, part of the screen (part selected by the 349 user) or what a selected applicaton displays with the peer. 351 3.2.8.2. Derived Requirements 353 F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F30 355 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A21 357 3.2.9. Simple Video Communication Service with file exchange 359 3.2.9.1. Description 361 This use-case has the audio and video communication of the Simple 362 Video Communication Service use-case (Section 3.2.1). 364 But in addition to this, the users can send and receive files stored 365 in the file system of the device used. 367 3.2.9.2. Derived Requirements 369 F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F30, F33 371 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A21, A24 373 3.2.10. Simple video communication service with inter-operator calling 375 3.2.10.1. Description 377 Two users have logged into two different web applications, provided 378 by different service providers. 380 The service providers are interconnected by some means, but exchange 381 no more information about the users than what can be carried using 382 SIP. 384 NOTE: More profiling of what this means may be needed. 386 For each user Alice who has authorized another user Bob to receive 387 login status information, Alice's service publishes Alice's login 388 status information to Bob. How this authorization is defined and 389 established is out of scope. 391 The same functionality as in the the Simple Video Communication 392 Service use-case (Section 3.2.1) is available. 394 The same issues with connectivity apply. 396 3.2.10.2. Derived requirements 398 F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F27, F28 400 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A20 402 3.2.11. Hockey Game Viewer 404 3.2.11.1. Description 406 An ice-hockey club uses an application that enables talent scouts to, 407 in real-time, show and discuss games and players with the club 408 manager. The talent scouts use a mobile phone with two cameras, one 409 front facing and one rear facing. 411 The club manager uses a desktop, equipped with one camera, for 412 viewing the game and discussing with the talent scout. 414 Before the game starts, and during game breaks, the talent scout and 415 the manager have a 1-1 audiovisual communication session. Only the 416 rear facing camera of the mobile phone is used. On the display of 417 the mobile phone, the video of the club manager is shown with a 418 picture-in-picture thumbnail of the rear facing camera (self-view). 419 On the display of the desktop, the video of the talent scout is shown 420 with a picture-in-picture thumbnail of the desktop camera (self- 421 view). 423 When the game is on-going, the talent scout activates the use of the 424 front facing camera, and that stream is sent to the desktop (the 425 stream from the rear facing camera continues to be sent all the 426 time). The video stream captured by the front facing camera (that is 427 capturing the game) of the mobile phone is shown in a big window on 428 the desktop screen, with picture-in-picture thumbnails of the rear 429 facing camera and the desktop camera (self-view). On the display of 430 the mobile phone the game is shown (front facing camera) with 431 picture-in-picture thumbnails of the rear facing camera (self-view) 432 and the desktop camera. As the most important stream in this phase 433 is the video showing the game, the application used in the talent 434 scout's mobile sets higher priority for that stream. 436 It is essential that the communication cannot be wiretapped 437 [RFC2804]. 439 3.2.11.2. Derived Requirements 441 F1, F2, F3, F4, F5, F8, F9, F10, F17, F20, F34 443 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A17, A23 445 3.2.12. Multiparty video communication 447 3.2.12.1. Description 449 In this use-case is the Simple Video Communication Service use-case 450 (Section 3.2.1) is extended by allowing multiparty sessions. No 451 central server is involved - the browser of each participant sends 452 and receives streams to and from all other session participants. The 453 web application in the browser of each user is responsible for 454 setting up streams to all receivers. 456 In order to enhance intelligibility, the web application pans the 457 audio from different participants differently when rendering the 458 audio. This is done automatically, but users can change how the 459 different participants are placed in the (virtual) room. In addition 460 the levels in the audio signals are adjusted before mixing. 462 Another feature intended to enhance the use experience is that the 463 video window that displays the video of the currently speaking peer 464 is highlighted. 466 Each video stream received is by default displayed in a thumbnail 467 frame within the browser, but users can change the display size. 469 It is essential that the communication cannot be wiretapped 470 [RFC2804]. 472 Note: What this use-case adds in terms of requirements is 473 capabilities to send streams to and receive streams from several 474 peers concurrently, as well as the capabilities to render the video 475 from all recevied streams and be able to spatialize, level adjust and 476 mix the audio from all received streams locally in the browser. It 477 also adds the capability to measure the audio level/activity. 479 3.2.12.2. Derived Requirements 481 F1, F2, F3, F4, F5, F8, F9, F10, F11, F12, F13, F14, F15, F16, F17, 482 F20, F25 484 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, 485 A16, A17 487 3.2.13. Multiparty on-line game with voice communication 489 3.2.13.1. Description 491 This use case is based on the previous one. In this use-case, the 492 voice part of the multiparty video communication use case is used in 493 the context of an on-line game. The received voice audio media is 494 rendered together with game sound objects. For example, the sound of 495 a tank moving from left to right over the screen must be rendered and 496 played to the user together with the voice media. 498 Quick updates of the game state is required, and have higher priority 499 than the voice. 501 It is essential that the communication cannot be wiretapped 502 [RFC2804]. 504 Note: the difference regarding local audio processing compared to the 505 "Multiparty video communication" use-case is that other sound objects 506 than the streams must be possible to be included in the 507 spatialization and mixing. "Other sound objects" could for example 508 be a file with the sound of the tank; that file could be stored 509 locally or remotely. 511 3.2.13.2. Derived Requirements 513 F1, F2, F3, F4, F5, F8, F9, F11, F12, F13, F14, F15, F16, F18, F20, 514 F23, F34 516 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, 517 A17, A18, A23 519 3.2.14. Distributed Music Band 521 3.2.14.1. Description 523 In this use-case, a music band is playing music while the members are 524 at different physical locations. No central server is used, instead 525 all streams are set up in a mesh fashion. 527 Discussion: This use-case was briefly discussed at the Quebec webrtc 528 meeting and it got support. So far the only concrete requirement 529 (A17) derived is that the application must be able to ask the browser 530 to treat the audio signal as audio (in contrast to speech). However, 531 the use case should be further analysed to determine other 532 requirements (could be e.g. on delay mic->speaker, level control of 533 audio signals, etc.). 535 3.2.14.2. Derived Requirements 537 F1, F2, F3, F4, F5, F8, F9, F11, F12, F13, F14, F15, F16 539 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, 540 A19 542 3.3. Browser - GW/Server use cases 544 3.3.1. Telephony terminal 546 3.3.1.1. Description 548 A mobile telephony operator allows its customers to use a web browser 549 to access their services. After a simple log in the user can place 550 and receive calls in the same way as when using a normal mobile 551 phone. When a call is received or placed, the identity is shown in 552 the same manner as when a mobile phone is used. 554 It is essential that the communication cannot be wiretapped 555 [RFC2804]. 557 Note: With "place and receive calls in the same way as when using a 558 normal mobile phone" it is meant that you can dial a number, and that 559 your mobile telephony operator has made available your phone contacts 560 on line, so they are available and can be clicked to call, and be 561 used to present the identity of an incoming call. If the callee is 562 not in your phone contacts the number is displayed. Furthermore, 563 your call logs are available, and updated with the calls made/ 564 received from the browser. And for people receiving calls made from 565 the web browser the usual identity (i.e. the phone number of the 566 mobile phone) will be presented. 568 3.3.1.2. Derived Requirements 570 F1, F2, F3, F4, F5, F8, F9, F10, F20, F21 572 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12 574 3.3.2. Fedex Call 576 3.3.2.1. Description 578 Alice uses her web browser with a service that allows her to call 579 PSTN numbers. Alice calls 1-800-gofedex. Alice should be able to 580 hear the initial prompts from the fedex IVR and when the IVR says 581 press 1, there should be a way for Alice to navigate the IVR. 583 3.3.2.2. Derived Requirements 585 F1, F2, F3, F4, F5, F8, F9, F10, F21, F22 587 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12 589 3.3.3. Video conferencing system with central server 591 3.3.3.1. Description 593 An organization uses a video communication system that supports the 594 establishment of multiparty video sessions using a central conference 595 server. 597 The browser of each participant send an audio stream (type in terms 598 of mono, stereo, 5.1, ... depending on the equipment of the 599 participant) to the central server. The central server mixes the 600 audio streams (and can in the mixing process naturally add effects 601 such as spatialization) and sends towards each participant a mixed 602 audio stream which is played to the user. 604 The browser of each participant sends video towards the server. For 605 each participant one high resolution video is displayed in a large 606 window, while a number of low resolution videos are displayed in 607 smaller windows. The server selects what video streams to be 608 forwarded as main- and thumbnail videos respectively, based on speech 609 activity. As the video streams to display can change quite 610 frequently (as the conversation flows) it is important that the delay 611 from when a video stream is selected for display until the video can 612 be displayed is short. 614 The organization has an internal network set up with an aggressive 615 firewall handling access to the Internet. If users cannot physically 616 access the internal network, they can establish a Virtual Private 617 Network (VPN). 619 It is essential that the communication cannot be wiretapped 620 [RFC2804]. 622 All participants are authenticated by the central server, and 623 authorized to connect to the central server. The participants are 624 identified to each other by the central server, and the participants 625 do not have access to each others' credentials such as e-mail 626 addresses or login IDs. 628 Note: This use-case adds requirements on support for fast stream 629 switches F7, on encryption of media and on ability to traverse very 630 restrictive FWs. There exist several solutions that enable the 631 server to forward one high resolution and several low resolution 632 video streams: a) each browser could send a high resolution, but 633 scalable stream, and the server could send just the base layer for 634 the low resolution streams, b) each browser could in a simulcast 635 fashion send one high resolution and one low resolution stream, and 636 the server just selects or c) each browser sends just a high 637 resolution stream, the server transcodes into low resolution streams 638 as required. 640 3.3.3.2. Derived Requirements 642 F1, F2, F3, F4, F5, F7, F8, F9, F10, F17, F19, F20 644 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A17 646 4. Requirements 648 4.1. General 650 This section contains the requirements on the browser derived from 651 the use-cases in Section 3. 653 NOTE: It is assumed that the user applications are executed on a 654 browser. Whether the capabilities to implement specific browser 655 requirements are implemented by the browser application, or are 656 provided to the browser application by the underlying operating 657 system, is outside the scope of this document. 659 4.2. Browser requirements 661 REQ-ID DESCRIPTION 662 --------------------------------------------------------------- 663 F1 The browser must be able to use microphones and 664 cameras as input devices to generate streams. 665 ---------------------------------------------------------------- 666 F2 The browser must be able to send streams and 667 data to a peer in the presence of NATs. 668 ---------------------------------------------------------------- 669 F3 Transmitted streams and data must be rate 670 controlled (meaning that the browser must, regardless 671 of application behavior, reduce send rate when 672 there is congestion). 673 ---------------------------------------------------------------- 674 F4 The browser must be able to receive, process and 675 render streams and data ("render" does not 676 apply for data) from peers. 677 ---------------------------------------------------------------- 678 F5 The browser should be able to render good quality 679 audio and video even in the presence of 680 reasonable levels of jitter and packet losses. 681 ---------------------------------------------------------------- 682 F7 The browser must support insertion of reference frames 683 in ougoing media streams when requested by a peer. 684 ---------------------------------------------------------------- 685 F8 The browser must detect when a stream from a 686 peer is not received anymore 687 ---------------------------------------------------------------- 688 F9 When there are both incoming and outgoing audio 689 streams, echo cancellation must be made 690 available to avoid disturbing echo during 691 conversation. 692 ---------------------------------------------------------------- 693 F10 The browser must support synchronization of 694 audio and video. 695 ---------------------------------------------------------------- 696 F11 The browser must be able to transmit streams and 697 data to several peers concurrently. 698 ---------------------------------------------------------------- 699 F12 The browser must be able to receive streams and 700 data from multiple peers concurrently. 701 ---------------------------------------------------------------- 702 F13 The browser must be able to apply spatialization 703 effects when playing audio streams. 704 ---------------------------------------------------------------- 705 F14 The browser must be able to measure the level 706 in audio streams. 707 ---------------------------------------------------------------- 708 F15 The browser must be able to change the level 709 in audio streams. 710 ---------------------------------------------------------------- 711 F16 The browser must be able to render several 712 concurrent video streams 713 ---------------------------------------------------------------- 714 F17 The browser must be able to mix several 715 audio streams. 716 ---------------------------------------------------------------- 717 F18 The browser must be able to process and mix 718 sound objects (media that is retrieved from 719 another source than the established media 720 stream(s) with the peer(s) with audio streams. 721 ---------------------------------------------------------------- 722 F19 Streams and data must be able to pass through 723 limited middleboxes. 724 ---------------------------------------------------------------- 725 F20 It must be possible to protect streams and data 726 from wiretapping [RFC2804]. 727 ---------------------------------------------------------------- 728 F21 The browser must support an audio media format 729 (codec) that is commonly supported by existing 730 telephony services. 731 ---------------------------------------------------------------- 732 F22 There should be a way to navigate 733 a Dual-tone multi-frequency signaling (DTMF) 734 based Interactive voice response (IVR) System 735 ---------------------------------------------------------------- 736 F23 The browser must be able to send short 737 latency unreliable datagram traffic to a 738 peer browser [RFC5405]. 739 ---------------------------------------------------------------- 740 F24 The browser should be able to take advantage 741 of available capabilities (supplied by network 742 nodes) to prioritize voice, video and data 743 appropriately. 744 ---------------------------------------------------------------- 745 F25 The browser should use encoding of streams 746 suitable for the current rendering (e.g. 747 video display size) and should change parameters 748 if the rendering changes during the session 749 ---------------------------------------------------------------- 750 F26 It must be possible to move from one network 751 interface to another one 752 ---------------------------------------------------------------- 753 F27 The browser must be able to initiate and 754 accept a media session where the data needed 755 for establishment can be carried in SIP. 756 ---------------------------------------------------------------- 757 F28 The browser must support a baseline audio and 758 video codec 759 ---------------------------------------------------------------- 760 F29 The browser must be able to send streams and 761 data to a peer in the presence of NATs that 762 block UDP traffic. 763 ---------------------------------------------------------------- 764 F30 The browser must be able to use the screen (or 765 a specific area of the screen) or what a certain 766 application displays on the screen to generate 767 streams. 768 ---------------------------------------------------------------- 769 F31 The browser must be able to use several STUN 770 and TURN servers 771 ---------------------------------------------------------------- 772 F32 There browser must support that STUN and TURN 773 servers to use are supplied by other entities 774 than via the web application (i.e. the network 775 provider). 776 ---------------------------------------------------------------- 777 F33 The browser must be able to send reliable 778 data traffic to a peer browser. 779 ---------------------------------------------------------------- 780 F34 The browser must support priortization of 781 streams and data. 782 ---------------------------------------------------------------- 783 F35 The browser must enable verification, given 784 the right circumstances and by use of other 785 trusted communication, of that streams and 786 data received have not been manipulated by 787 any party. 788 ---------------------------------------------------------------- 789 F36 The browser must encrypt, authenticate and 790 integrity protect media and data on a 791 per-packet asis, and must drop incoming media 792 and data packets that fail the per-packet 793 integrity check. In addition, the browser 794 must support a mechanism for cryptographically 795 binding media and data security keys to the 796 user identity (see R-ID-BINDING in [RFC5479]). 797 ---------------------------------------------------------------- 798 F37 The browser must be able to send streams and 799 data to a peer in the presence of FWs that only 800 allows http(s) traffic. 801 ---------------------------------------------------------------- 802 F38 The browser must be able to collect statistics, 803 related to the transport of audio and video 804 between peers, needed to estimate quality of 805 experience. 806 ---------------------------------------------------------------- 807 F39 The browser must make it possible to set up a 808 call between two parties without one party 809 learning the other party's host IP address. 810 ---------------------------------------------------------------- 812 5. IANA Considerations 814 TBD 816 6. Security Considerations 818 6.1. Introduction 820 A malicious web application might use the browser to perform Denial 821 Of Service (DOS) attacks on NAT infrastructure, or on peer devices. 822 Also, a malicious web application might silently establish outgoing, 823 and accept incoming, streams on an already established connection. 825 Based on the identified security risks, this section will describe 826 security considerations for the browser and web application. 828 6.2. Browser Considerations 830 The browser is expected to provide mechanisms for getting user 831 consent to use device resources such as camera and microphone. 833 The browser is expected to provide mechanisms for informing the user 834 that device resources such as camera and microphone are in use 835 ("hot"). 837 The browser is expected to provide mechanisms for users to revise and 838 even completely revoke consent to use device resources such as camera 839 and microphone. 841 The browser is expected to provide mechanisms for getting user 842 consent to use the screen (or a certain part of it) or what a certain 843 application displays on the screen as source for streams. 845 The browser is expected to provide mechanisms for informing the user 846 that the screen, part thereof or an application is serving as a 847 stream source ("hot"). 849 The browser is expected to provide mechanisms for users to revise and 850 even completely revoke consent to use the screen, part thereof or an 851 application is serving as a stream source. 853 The browser is expected to provide mechanisms in order to assure that 854 streams are the ones the recipient intended to receive. 856 The browser is expected to provide mechanisms that allows the users 857 to verify that the streams received have not be manipulated (F35). 859 The browser needs to ensure that media is not sent, and that received 860 media is not rendered, until the associated stream establishment and 861 handshake procedures with the remote peer have been successfully 862 finished. 864 The browser needs to ensure that the stream negotiation procedures 865 are not seen as Denial Of Service (DOS) by other entities. 867 6.3. Web Application Considerations 869 The web application is expected to ensure user consent in sending and 870 receiving media streams. 872 7. Additional use-cases 874 Several additional use-cases have been discussed. At this point 875 these use-cases are not included as requirement deriving use-cases 876 for different reasons (lack of documentation, overlap with existing 877 use-cases, lack of consensus). For completeness these additional 878 use-cases are listed below: 880 1. Use-cases regarding different situations when being invited to a 881 "session", e.g. browser open, browser open but another tab 882 active, browser open but active in session, browser closed, .... 883 (Matthew Kaufman); discussed at webrtc meeting 885 2. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/rtcweb 886 /current/msg00525.html, followed up by Stephan Wenger 888 3. Local Recording and Remote recording (John): Discussed a _lot_ 889 on the mail lists (rtcweb as well as public-webrtc) lAugust and 890 September 2011. Concrete proposal: http://www.ietf.org/mail- 891 archive/web/rtcweb/current/msg01006.html (remote) and http:// 892 www.ietf.org/mail-archive/web/rtcweb/current/msg00734.html 893 (local) 895 4. Emergency access for disabled (Bernard Aboba) http:// 896 www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html 898 5. Clue use-cases (Roni Even) http://tools.ietf.org/html/draft- 899 ietf-clue-telepresence-use-cases-01 901 6. Rohan red cross (Cullen Jennings); http://www.ietf.org/mail- 902 archive/web/rtcweb/current/msg00323.html 904 7. Security camera/baby monitor usage http://www.ietf.org/mail- 905 archive/web/rtcweb/current/msg00543.html 907 8. Large multiparty session http://www.ietf.org/mail-archive/web/ 908 rtcweb/current/msg00530.html 910 9. Call center http://www.ietf.org/mail-archive/web/rtcweb/current/ 911 msg04203.html 913 10. Enterprise policies http://www.ietf.org/mail-archive/web/rtcweb/ 914 current/msg04271.html 916 11. Low-complex multiparty central node http://www.ietf.org/mail- 917 archive/web/rtcweb/current/msg04430.html 919 12. Multiparty central node that is not allowed to decipher http:// 920 www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html 922 13. Enable company coop without being able to decipher http:// 923 www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html 925 8. Acknowledgements 927 Bernard Aboba, Gunnar Hellstrom, Martin Thomson, Lars Eggert, Matthew 928 Kaufman, Emil Ivov, Eric Rescorla, Eric Burger, John Leslie, Dan 929 Wing, Richard Barnes, Barry Dingle, Dale Worley, Ted hardie, Mary 930 Barnes, 932 Dan Burnett has reviewed and proposed a lot of things that enhances 933 the document. Most of this has been incorporated in rev -05. 935 Stephan Wenger has provided a lot of useful input and feedback, as 936 well as editorial comments. 938 Harald Alvestrand and Ted Hardie have provided comments and feedback 939 on the draft. 941 Harald Alvestrand and Cullen Jennings have provided additional use- 942 cases. 944 Thank You to everyone in the RTCWEB community that have provided 945 comments, feedback and improvement proposals on the draft content. 947 9. Change Log 949 [RFC EDITOR NOTE: Please remove this section when publishing] 951 Changes from draft-ietf-rtcweb-use-cases-and-requirements-10 953 o Described that the API requirements are really from a W3C 954 perspective and are supplied as an appendix in the introduction. 955 Moved API requirements to an Appendix. 957 o Removed the "Conventions" section with the key-words and reference 958 to RFC2119. Also changed uppercase MUST's/SHOULD's to lowercase. 960 o Added a note on the proposed use of the document to the 961 introduction. 963 o Removed the note talking about WS from the "FW that only allows 964 http" use-case. 966 o Removed the word "Skype" that was used as example in one of the 967 use-cases. 969 o Clarified F3 (the req saying the everything the browser sends must 970 be rate controlled). 972 o Removed the TBD saying we need to define reasonable levels from 973 the requirement saying that quality must be good even in presence 974 of packet losses (F5), and changed "must" to "should" (Based on a 975 list discussion involving Bernard). 977 o Removed F6 ("The browser must be able to handle high loss and 978 jitter levels in a graceful way."), also after a list discussion. 980 o Clarified F7 (used to say that the browser must support fast 981 stream switches, now says that reference frames must be inserted 982 when requested). 984 o Removed the questions from F9 (echo cancellation), F10 985 (syncronization), F21 (telephony codec). 987 o Exchanged "restrictive firewalls" for "limited middleboxes" in F19 988 (as proposed by Martin). 990 o Expanded DTMF and IVR in F22 (proposed by Martin) 992 o Added ref to RFC5405 in F23 (proposed by Lars Eggert). 994 o Exchanged "service provided" for "web application" in F32. 996 o Changed the text in 3.2.1 that motivates F36 (new text "It is 997 essential that media and data be encrypted, authenticated ... 998 bound to the user identity."); and rewrote F36, included a ref to 999 RFC5479. 1001 o Changed "quality of service" to "quality of experience" in F38. 1003 o Added F39. 1005 o Used new formulation of A17 (proposed by Martin). 1007 o Updated A20. 1009 o Updated A25. 1011 Changes from draft-ietf-rtcweb-use-cases-and-requirements-09 1013 o Changed "video communication session" to "audiovisual 1014 communication session. 1016 Changes from draft-ietf-rtcweb-use-cases-and-requirements-08 1018 o Changed "eavesdropping" to "wiretapping" and referenced RFC2804. 1020 o Removed informal ref webrtc_req; that document has been abandoned 1021 by the W3C webrtc WG. 1023 o Added use-case where one user is behind a FW that only allows 1024 http; derived req. F37. 1026 o Changed F24 slightly; MUST-> SHOULD, inserted "available". 1028 o Added a clause to "Simple video communication service" saying that 1029 the service provider monitors the quality of service, and derived 1030 reqs F38 and A26. 1032 Changes from draft-ietf-rtcweb-use-cases-and-requirements-07 1034 o Added "and data exchange" to 1. Introduction. 1036 o Removed cone and symmetric NAT from 4.1 Introduction, refers to 1037 RFC4787 instead. 1039 o Added text on enabling verifyication of that the media has not 1040 been manipulated by anyone to use-case "Simple Video Communication 1041 Service", derived req. F35 1043 o Added text on that the browser should reject media (data) that has 1044 been created/injected/modified by non-trusted party, derived req. 1045 F36 1047 o Added text on enabling the app to refrain from revealing IP 1048 address to use-case "Simple Video Communication Service", derived 1049 req. A25 1051 o Added use-case "Simple Video Communication Service with file 1052 exchange", derived reqs F33 and A24 1054 o Added priority of video streams to "Hockey game viewer" use case, 1055 added priority of data to "on-line game use-case", derived reqs 1056 F34 and A23 1058 o In F22, "the IVR" -> "a DTMF based IVR". 1060 o Updated req F23 to clarify that requirements such as NAT 1061 traversal, prtoection from eavesdropping, rate control applies 1062 also to datagram. 1064 Changes from draft-ietf-rtcweb-use-cases-and-requirements-06 1066 o Renaming of requirements (FaI1 -> F31), (FaI2 -> F32) and (AaI1 -> 1067 A22) 1069 Changes from draft-ietf-rtcweb-use-cases-and-requirements-05 1071 o Added use-case "global service provider", derived reqs associated 1072 with several STUN/TURN servers 1074 o Added use-case "enterprise aspects", derived req associated with 1075 enabling the network provider to supply STUN and TURN servers 1077 o The requirements from the above are ICE specific and labeled 1078 accordingly 1080 o Separated the requirements phrased like "processing such as pan, 1081 mix and render" for audio to be specific reqs on spatialization, 1082 level measurement, level adjustment and mixing (discussed on the 1083 lists in http://www.ietf.org/mail-archive/web/rtcweb/current/ 1084 msg01648.html and http://lists.w3.org/Archives/Public/public- 1085 webrtc/2011Sep/0102.html) 1087 o Added use-case on sharing as decided in http://www.ietf.org/mail- 1088 archive/web/rtcweb/current/msg01700.html, derived reqs F30 and A21 1090 o Added the list of common considerations proposed in mail http:// 1091 www.ietf.org/mail-archive/web/rtcweb/current/msg01562.html to the 1092 Introduction of the use-case section 1094 Changes from draft-ietf-rtcweb-use-cases-and-requirements-04 1096 o Most changes based on the input from Dan Burnett http:// 1097 www.ietf.org/mail-archive/web/rtcweb/current/msg00948.html 1099 o Many editorial changes 1101 o 4.2.1.1 Clarified 1103 o Some clarification added to 4.3.1.1 as a note 1105 o F-requirements updated (see reply to Dan's mail). 1107 o Almost all A-requirements updated to start "The Web API MUST 1108 provide ..." 1110 o A8 removed, A9 rephrased to cover A8 and old A9 1112 o A15 rephrased 1114 o For more details, and discussion, look att the response to Dan's 1115 mail http://www.ietf.org/mail-archive/web/rtcweb/current/ 1116 msg01177.html 1118 Changes from draft-ietf-rtcweb-use-cases-and-requirements-03 1120 o Editorials 1122 o Changed when the self-view is displayed in 4.2.1.1, and added 1123 words about allowing users to remove and re-insert it. 1125 o Clarified 4.2.6.1 1127 o Removed the "mono" stuff from 4.2.7.1 1128 o Added that communication should not be possible to eavesdrop to 1129 most use cases - and req. F17 1131 o Re-phrased 4.3.3.1 to not describe the technical solution so much, 1132 and removed "stereo" stuff. Solution possibilities are now in a 1133 note. 1135 o Re-inserted API requirements after discussion in the W3C webrtc 1136 WG. (Re-phrased A15 and added A18 compared to version -02). 1138 Changes from draft-ietf-rtcweb-use-cases-and-requirements-02 1140 o Removed desrciption/list of API requirements, instead 1142 o Reference to W3C webrtc_reqs document for API requirements 1144 Changes from draft-ietf-rtcweb-ucreqs-01 1146 o Changed Intended status to Information 1148 o Changed "Ipr" to "trust200902" 1150 o Added use case "Simple video communication service, NAT/FW that 1151 blocks UDP", and derived new req F26 1153 o Added use case "Distributed Music Band" and derived new req A17 1155 o Added F24 as requirement derived from use case "Simple video 1156 communication service with inter-operator calling" 1158 o Added section "Additional use cases" 1160 o Added text about ID handling to multiparty with central server use 1161 case 1163 o Re-phrased A1 slightly 1165 Changes from draft-ietf-rtcweb-ucreqs-00 1167 o - Reshuffled: Just two main groups of use cases (b2b and b2GW/ 1168 Server); removed some specific use cases and added them instead as 1169 flavors to the base use case (Simple video communciation) 1171 o - Changed the fromulation of F19 1173 o - Removed the requirement on an API for DTMF 1174 o - Removed "FX3: There SHOULD be a mapping of the minimum needed 1175 data for setting up connections into SIP, so that the restriction 1176 to SIP-carriable data can be verified. Not a rew on the browser 1177 but rather on a document" 1179 o - (see http://www.ietf.org/mail-archive/web/rtcweb/current/ 1180 msg00227.html for more details) 1182 o -Added text on informing user of that mic/cam is being used and 1183 that it must be possible to revoce permission to use them in 1184 section 7. 1186 Changes from draft-holmberg-rtcweb-ucreqs-01 1188 o - Draft name changed to draft-ietf-rtcweb-ucreqs 1190 o - Use-case grouping introduced 1192 o - Additional use-cases added 1194 o - Additional reqs added (derived from use cases): F19-F25, A16-A17 1196 Changes from draft-holmberg-rtcweb-ucreqs-00 1198 o - Mapping between use-cases and requirements added (Harald 1199 Alvestrand, 090311) 1201 o - Additional security considerations text (Harald Alvestrand, 1202 090311) 1204 o - Clarification that user applications are assumed to be executed 1205 by a browser (Ted Hardie, 080311) 1207 o - Editorial corrections and clarifications 1209 10. Normative References 1211 [RFC2804] IAB IESG, "IETF Policy on Wiretapping", RFC 2804, May 1212 2000. 1214 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1215 for Application Designers", BCP 145, RFC 5405, November 1216 2008. 1218 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 1219 "Requirements and Analysis of Media Security Management 1220 Protocols", RFC 5479, April 2009. 1222 Appendix A. API requirements 1224 This section contains the requirements on the API derived from the 1225 use-cases in Section 3. 1227 REQ-ID DESCRIPTION 1228 ---------------------------------------------------------------- 1229 A1 The Web API must provide means for the 1230 application to ask the browser for permission 1231 to use cameras and microphones as input devices. 1232 ---------------------------------------------------------------- 1233 A2 The Web API must provide means for the web 1234 application to control how streams generated 1235 by input devices are used. 1236 ---------------------------------------------------------------- 1237 A3 The Web API must provide means for the web 1238 application to control the local rendering of 1239 streams (locally generated streams and streams 1240 received from a peer). 1241 ---------------------------------------------------------------- 1242 A4 The Web API must provide means for the web 1243 application to initiate sending of 1244 stream/stream components to a peer. 1245 ---------------------------------------------------------------- 1246 A5 The Web API must provide means for the web 1247 application to control the media format (codec) 1248 to be used for the streams sent to a peer. 1250 NOTE: The level of control depends on whether 1251 the codec negotiation is handled by the browser 1252 or the web application. 1253 ---------------------------------------------------------------- 1254 A6 The Web API must provide means for the web 1255 application to modify the media format for 1256 streams sent to a peer after a media stream 1257 has been established. 1258 ---------------------------------------------------------------- 1259 A7 The Web API must provide means for 1260 informing the web application of whether the 1261 establishment of a stream with a peer was 1262 successful or not. 1263 ---------------------------------------------------------------- 1264 A8 The Web API must provide means for the web 1265 application to mute/unmute a stream or stream 1266 component(s). When a stream is sent to a peer 1267 mute status must be preserved in the stream 1268 received by the peer. 1270 ---------------------------------------------------------------- 1271 A9 The Web API must provide means for the web 1272 application to cease the sending of a stream 1273 to a peer. 1274 ---------------------------------------------------------------- 1275 A10 The Web API must provide means for the web 1276 application to cease processing and rendering 1277 of a stream received from a peer. 1278 ---------------------------------------------------------------- 1279 A11 The Web API must provide means for 1280 informing the web application when a 1281 stream from a peer is no longer received. 1282 ---------------------------------------------------------------- 1283 A12 The Web API must provide means for 1284 informing the web application when high 1285 loss rates occur. 1286 ---------------------------------------------------------------- 1287 A13 The Web API must provide means for the web 1288 application to apply spatialization effects to 1289 audio streams. 1290 ---------------------------------------------------------------- 1291 A14 The Web API must provide means for the web 1292 application to detect the level in audio 1293 streams. 1294 ---------------------------------------------------------------- 1295 A15 The Web API must provide means for the web 1296 application to adjust the level in audio 1297 streams. 1298 ---------------------------------------------------------------- 1299 A16 The Web API must provide means for the web 1300 application to mix audio streams. 1301 ---------------------------------------------------------------- 1302 A17 The Web API must provide a way to identify 1303 streams such that an application is able to 1304 match streams on a sending peer with the same 1305 stream on all receiving peers. 1306 ---------------------------------------------------------------- 1307 A18 The Web API must provide a mechanism for sending 1308 and receiving isolated discrete chunks of data. 1309 ---------------------------------------------------------------- 1310 A19 The Web API must provide means for the web 1311 application to indicate the type of audio signal 1312 (speech, audio) for audio stream(s)/stream 1313 component(s). 1314 ---------------------------------------------------------------- 1315 A20 It must be possible for an initiator or a 1316 responder web application to indicate the types 1317 of media it is willing to accept incoming 1318 streams for when setting up a connection (audio, 1319 video, other). The types of media to be accepted 1320 can be a subset of the types of media the browser 1321 is able to accept. 1322 ---------------------------------------------------------------- 1323 A21 The Web API must provide means for the 1324 application to ask the browser for permission 1325 to the screen, a certain area on the screen 1326 or what a certain application displays on the 1327 screen as input to streams. 1328 ---------------------------------------------------------------- 1329 A22 The Web API must provide means for the 1330 application to specify several STUN and/or 1331 TURN servers to use. 1332 ---------------------------------------------------------------- 1333 A23 The Web API must provide means for the 1334 application to specify the priority to 1335 apply for outgoing streams and data. 1336 ---------------------------------------------------------------- 1337 A24 The Web API must provide a mechanism for sending 1338 and receiving files. 1339 ---------------------------------------------------------------- 1340 A25 It must be possible for the application to 1341 instruct the browser to refrain from exposing 1342 the host IP address to the application 1343 ---------------------------------------------------------------- 1344 A26 The Web API must provide means for the 1345 application to obtain the statistics (related 1346 to transport, and collected by the browser) 1347 needed to estimate quality of service. 1348 ---------------------------------------------------------------- 1350 Authors' Addresses 1352 Christer Holmberg 1353 Ericsson 1354 Hirsalantie 11 1355 Jorvas 02420 1356 Finland 1358 Email: christer.holmberg@ericsson.com 1359 Stefan Hakansson 1360 Ericsson 1361 Laboratoriegrand 11 1362 Lulea 97128 1363 Sweden 1365 Email: stefan.lk.hakansson@ericsson.com 1367 Goran AP Eriksson 1368 Ericsson 1369 Farogatan 6 1370 Stockholm 16480 1371 Sweden 1373 Email: goran.ap.eriksson@ericsson.com