idnits 2.17.1 draft-ietf-rtcweb-use-cases-and-requirements-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 28, 2011) is 4625 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: February 29, 2012 Ericsson 6 August 28, 2011 8 Web Real-Time Communication Use-cases and Requirements 9 draft-ietf-rtcweb-use-cases-and-requirements-03.txt 11 Abstract 13 This document describes web based real-time communication use-cases. 14 Based on the use-cases, the document also derives requirements 15 related to the browser, and the API used by web applications to 16 request and control media stream services provided by the browser. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 29, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 57 4.2. Browser-to-browser use-cases . . . . . . . . . . . . . . . 3 58 4.2.1. Simple Video Communication Service . . . . . . . . . . 3 59 4.2.2. Simple Video Communication Service, NAT/FW that 60 blocks UDP . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2.3. Simple Video Communication Service, access change . . 4 62 4.2.4. Simple Video Communication Service, QoS . . . . . . . 5 63 4.2.5. Simple video communication service with 64 inter-operator calling . . . . . . . . . . . . . . . . 5 65 4.2.6. Hockey Game Viewer . . . . . . . . . . . . . . . . . . 6 66 4.2.7. Multiparty video communication . . . . . . . . . . . . 6 67 4.2.8. Multiparty on-line game with voice communication . . . 7 68 4.2.9. Distributed Music Band . . . . . . . . . . . . . . . . 8 69 4.3. Browser - GW/Server use cases . . . . . . . . . . . . . . 8 70 4.3.1. Telephony terminal . . . . . . . . . . . . . . . . . . 8 71 4.3.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . . 8 72 4.3.3. Video conferencing system with central server . . . . 9 73 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 5.2. Browser requirements . . . . . . . . . . . . . . . . . . . 10 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12 79 7.2. Browser Considerations . . . . . . . . . . . . . . . . . . 13 80 7.3. Web Application Considerations . . . . . . . . . . . . . . 13 81 8. Additional use cases . . . . . . . . . . . . . . . . . . . . . 13 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 83 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 This document presents a few use-case of web applications that are 92 executed in a browser and use real-time communication capabilities. 93 Based on the use-cases, the document derives requirements related to 94 the browser and the API used by web applications in the browser. 96 The requirements related to the browser are named "Fn" and are 97 described in section Section 5.2 99 The requirements related to the API are named "An" and are described 100 in the external document [webrtc_reqs] 102 The document focuses on requirements related to real-time media 103 streams. Requirements related to privacy, signalling between the 104 browser and web server etc are currently not considered. 106 2. Conventions 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in BCP 14, RFC 2119 111 [RFC2119]. 113 3. Definitions 115 TBD 117 4. Use-cases 119 4.1. Introduction 121 This section describes web based real-time communication use-cases, 122 from which requirements are later derived. 124 4.2. Browser-to-browser use-cases 126 4.2.1. Simple Video Communication Service 128 4.2.1.1. Description 130 In the service the users have loaded, and logged into, a video 131 communication web application into their browsers, provided by the 132 same service provider. The web service publishes information about 133 user login status, by pushing updates to the web application in the 134 browsers. By selecting an online peer user, a 1-1 video 135 communication session between the browsers of the peers is initiated. 136 The invited user might accept or reject the session. 138 When the session has been established, a self-view, as well as the 139 video sent from the remote peer, are displayed. The users can change 140 the sizes of the video displays during the session. The users can 141 also pause sending of media (audio, video, or both), and mute 142 incoming media. 144 Any session participant can end the session at any time. 146 The users are using communication devices of different makes, with 147 different Operating Systems and Browsers from different vendors. 149 One user has an unreliable internet connection. It sometimes has 150 packet losses, and is sometimes goes down completely. 152 One user is located behind a Network Address Translator (NAT). 154 4.2.1.2. Derived Requirements 156 F1, F2, F3, F4, F5, F6, F8, F9, F10, F22, F25 158 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 160 4.2.2. Simple Video Communication Service, NAT/FW that blocks UDP 162 4.2.2.1. Description 164 This use case is almost identical to the previos one. The difference 165 is that one of the users is behind a NAT that blocks UDP traffic. 167 4.2.2.2. Derived Requirements 169 F1, F2, F3, F4, F5, F6, F8, F9, F10, F22, F23, F25, F26 171 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 173 4.2.3. Simple Video Communication Service, access change 175 4.2.3.1. Description 177 This use case is almost identical to "4.2.1 Simple Video 178 Communication Service". The difference is that the user changes 179 network access during the session: 181 The communication device used byt one of the users have several 182 network adapters (Ethernet, WiFi, Cellular). The communication 183 device is access the internet using Ethernet, but the user has to 184 start a trip during the session. The communication device 185 automatically changes to use WiFi when the ethernet cable is removed 186 and then moves to cellular access to the internet when moving out of 187 WiFi coverage. The session continues even though the access method 188 changes. 190 4.2.3.2. Derived Requirements 192 F1, F2, F3, F4, F5, F6, F8, F9, F10, F22, F23, F25 194 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 196 4.2.4. Simple Video Communication Service, QoS 198 4.2.4.1. Description 200 This use case is almost identical to the previos one. The use of QoS 201 capabilities is added: 203 The user in the previous use case that starts a trip is behind a 204 common residential router that supports prioritization of traffic. 205 In addition, the user's provider of cellular access has QoS support 206 enabled. The user is able to take advantage of the QoS support both 207 when accessing via the residential router and when using cellular. 209 4.2.4.2. Derived Requirements 211 F1, F2, F3, F4, F5, F6, F8, F9, F10, F21, F22, F23, F25 213 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 215 4.2.5. Simple video communication service with inter-operator calling 217 4.2.5.1. Description 219 Two users have logged into two different web applications, provided 220 by different service providers. 222 The service providers are interconnected by some means, but exchange 223 no more information about the users than what can be carried using 224 SIP. 226 NOTE: More profiling of what this means may be needed. 228 Each web service publishes information about user login status for 229 users that have a relationship with the other user; how this is 230 established is out of scope. 232 The same functionality as in the "4.2.1 Simple Video Communication 233 Service" is available. 235 The same issues with connectivity apply. 237 4.2.5.2. Derived requirements 239 F1, F2, F3, F4, F5, F6, F8, F9, F10, F22, F24, F25 241 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13 243 4.2.6. Hockey Game Viewer 245 4.2.6.1. Description 247 An ice-hockey club uses an application that enables talent scouts to, 248 in real-time, show and discuss games and players with the club 249 manager. The talent scouts use a mobile phone with two cameras, one 250 front-facing and one rear facing. 252 The club manager uses a desktop for viewing the game and discussing 253 with the talent scout. The video stream captured by the front facing 254 camera (that is capturing the game) of the mobile phone is shown in a 255 big window on the desktop screen, while a thumbnail of the rear 256 facing camera is overlaid. 258 Most of the mobile phone screen is covered by a self view of the 259 front facing camera. A thumbnail of the rear facing cameras view is 260 overlaid. 262 4.2.6.2. Derived Requirements 264 F1, F2, F3, F4, F5, F6, F8, F9, F10, F14 266 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A15 268 4.2.7. Multiparty video communication 270 4.2.7.1. Description 272 In this use case the simple video communication service is extended 273 by allowing multiparty sessions. No central server is involved - the 274 browser of each participant sends and receives streams to and from 275 all other session participants. The web application in the browser 276 of each user is responsible for setting up streams to all receivers. 278 The audio sent by each participant is a mono stream. However, in 279 order to enhance intelligibility, the web application pans the audio 280 from different participants differently when rendering the audio. 281 This is done automatically, but users can change how the different 282 participants are placed in the (virtual) room. 284 Each video stream received is by default displayed in a thumbnail 285 frame within the browser, but users can change the display size. 287 Note: What this uses case adds in terms of requirements is 288 capabilities to send streams to and receive streams from several 289 peers concurrently, as well as the capabilities to render the video 290 from all recevied streams and be able to spatialize and mix the audio 291 from all received streams locally in the browser. 293 4.2.7.2. Derived Requirements 295 F1, F2, F3, F4, F5, F6, F8, F9, F10, F11, F12, F13, F14, F22 297 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15 299 4.2.8. Multiparty on-line game with voice communication 301 4.2.8.1. Description 303 In this use-case, the voice part of the multiparty video 304 communication application is used in the context of an on-line game. 305 The received voice audio media is rendered together with game sound 306 objects. For example, the sound of a tank moving from left to right 307 over the screen must be rendered and played to the user together with 308 the voice media. 310 Quick updates of the game state is required. 312 Note: the difference regarding local audio processing compared to the 313 "Multiparty video communication" use case is that other sound objects 314 than the streams must be possible to be included in the 315 spatialization and mixing. "Other sound objects" could for example a 316 file with the sound of the tank, that file could be stored locally or 317 remotely. 319 4.2.8.2. Derived Requirements 321 F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13, F15, F20 323 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16 325 4.2.9. Distributed Music Band 327 4.2.9.1. Description 329 In this use-case, a music band is playing music while the members are 330 at different physical locations. No central server is used, instead 331 all streams are set up in a mesh fashion. 333 Discussion: This use case was briefly discussed at the Quebec webrtc 334 meeting and it got support. So far the only concrete requirement 335 (A17) derived is that the application must be able to ask the browser 336 to treat the audio signal as audio (in contrast to speech). However, 337 the use case should be further analysed to determine other 338 requirements (could be e.g. on delay mic->speaker, level control of 339 audio signals, etc.). 341 4.2.9.2. Derived Requirements 343 F1, F2, F3, F4, F5, F6, F8, F9, F11, F12, F13 345 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A14, A15, A17 347 4.3. Browser - GW/Server use cases 349 4.3.1. Telephony terminal 351 4.3.1.1. Description 353 A mobile telephony operator allows its customers to use a web browser 354 to access their services. After a simple log in the user can place 355 and receive calls in the same way as when using a normal mobile 356 phone. When a call is received or placed, the identity will be shown 357 in the same manner as when a mobile phone used. 359 4.3.1.2. Derived Requirements 361 F1, F2, F3, F4, F5, F6, F8, F9, F10, F18 363 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A13 365 4.3.2. Fedex Call 367 4.3.2.1. Description 369 Alice uses her web browser with a service something like Skype to be 370 able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should 371 be able to hear the initial prompts from the fedex IVR and when the 372 IVR says press 1, there should be a way for Alice to navigate the 373 IVR. 375 4.3.2.2. Derived Requirements 377 F1, F2, F3, F4, F5, F6, F8, F9, F10, F18, F19 379 A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A13 381 4.3.3. Video conferencing system with central server 383 4.3.3.1. Description 385 An organization uses a video communication system that supports the 386 establishment of multiparty video sessions using a central conference 387 server. 389 The browsers of all participants send an audio stream (mono or stereo 390 depending on the equipment of a participant) to the central server. 391 The central server mixes the audio streams and sends towards the 392 participants a mixed stereo audio stream. 394 Each participant sends two video streams in a simulcast fashion 395 towards the server, one low resolution and one high resolution. At 396 each participant one high resolution video is displayed in a large 397 window, while a number of low resolution videos are displayed in 398 smaller windows. The server selects what video streams to be 399 forwarded as main- and thumbnail videos, based on speech activity. 400 As the video streams to display can change quite frequently (as the 401 conversation flows) it is important that the delay from when a video 402 stream is selected for display until the video can be displayed is 403 short. 405 The organization has an internal network set up with an aggressive 406 firewall handling access to the internet. If users can not 407 physically access the internal network, they can establish a Virtual 408 Private Network (VPN). 410 It is essential that the communication can not be eavesdropped. 412 All participant are authenticated by the central server, and 413 authorized to connect to the central server. The participants are 414 identified to each other by the central server, and the participants 415 do not have access to each others' credentials such as e-mail 416 addresses or login IDs. 418 Note: This use case adds requirements on support for fast stream 419 switches F7, on encryption of media and on ability to traverse very 420 restrictive FWs. It also introduces simulcast, but no concrete 421 requirement is put for this. 423 4.3.3.2. Derived Requirements 425 F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F14, F16, F17 427 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A15 429 5. Requirements 431 5.1. General 433 This section contains the browser requirements, derived from the use- 434 cases in section 4. For the API requirements refer to [webrtc_reqs]. 436 NOTE: It is assumed that the user applications are executed on a 437 browser. Whether the capabilities to implement specific browser 438 requirements are implemented by the browser application, or are 439 provided to the browser application by the underlying Operating 440 System (OS), is outside the scope of this document. 442 5.2. Browser requirements 444 REQ-ID DESCRIPTION 445 --------------------------------------------------------------- 446 F1 The browser MUST be able to use microphones and 447 cameras as input devices to generate streams. 448 ---------------------------------------------------------------- 449 F2 The browser MUST be able to send streams to a 450 peer in presence of NATs. 451 ---------------------------------------------------------------- 452 F3 Transmitted streams MUST be rate controlled. 453 ---------------------------------------------------------------- 454 F4 The browser MUST be able to receive, process and 455 render streams from peers. 456 ---------------------------------------------------------------- 457 F5 The browser MUST be able to render good quality 458 audio and video even in presence of reasonable 459 levels of jitter and packet losses. 461 TBD: What is a reasonable level? 462 ---------------------------------------------------------------- 463 F6 The browser MUST be able to handle high loss and 464 jitter levels in a graceful way. 465 ---------------------------------------------------------------- 466 F7 The browser MUST support fast stream switches. 468 ---------------------------------------------------------------- 469 F8 The browser MUST detect when a stream from a 470 peer is not received any more 471 ---------------------------------------------------------------- 472 F9 When there are both incoming and outgoing audio 473 streams, echo cancellation MUST be made available to 474 avoid disturbing echo during conversation. 476 QUESTION: How much control should be left to the 477 web application? 478 ---------------------------------------------------------------- 479 F10 The browser MUST support synchronization of 480 audio and video. 482 QUESTION: How much control should be left to the 483 web application? 484 ---------------------------------------------------------------- 485 F11 The browser MUST be able to transmit streams to 486 several peers concurrently. 487 ---------------------------------------------------------------- 488 F12 The browser MUST be able to receive streams from 489 multiple peers concurrently. 490 ---------------------------------------------------------------- 491 F13 The browser MUST be able to pan, mix and render 492 several concurrent audio streams. 493 ---------------------------------------------------------------- 494 F14 The browser MUST be able to render several 495 concurrent video streams 496 ---------------------------------------------------------------- 497 F15 The browser MUST be able to process and mix 498 sound objects (media that is retrieved from another 499 source than the established media stream(s) with the 500 peer(s) with audio streams). 501 ---------------------------------------------------------------- 502 F16 Streams MUST be able to pass through restrictive 503 firewalls. 504 ---------------------------------------------------------------- 505 F17 It MUST be possible to protect streams from 506 eavesdropping. 507 ---------------------------------------------------------------- 508 F18 The browser MUST support an audio media format 509 (codec) that is commonly supported by existing 510 telephony services. 512 QUESTION: G.711? 513 ---------------------------------------------------------------- 514 F19 there should be a way to navigate 515 the IVR 516 ---------------------------------------------------------------- 517 F20 The browser must be able to send short 518 latency datagram traffic to a peer browser 519 ---------------------------------------------------------------- 520 F21 The browser MUST be able to take advantage of 521 capabilities to prioritize voice and video 522 appropriately. 523 ---------------------------------------------------------------- 524 F22 The browser SHOULD use encoding of streams 525 suitable for the current rendering (e.g. 526 video display size) and SHOULD change parameters 527 if the rendering changes during the session 528 ---------------------------------------------------------------- 529 F23 It MUST be possible to move from one network 530 interface to another one 531 ---------------------------------------------------------------- 532 F24 The browser MUST be able to initiate and accept a 533 media session where the data needed for establishment 534 can be carried in SIP. 535 ---------------------------------------------------------------- 536 F25 The browser MUST support a baseline audio and 537 video codec 538 ---------------------------------------------------------------- 539 F26 The browser MUST be able to send streams to a 540 peer in presence of NATs that block UDP traffic. 541 ---------------------------------------------------------------- 543 6. IANA Considerations 545 TBD 547 7. Security Considerations 549 7.1. Introduction 551 A malicious web application might use the browser to perform Denial 552 Of Service (DOS) attacks on NAT infrastructure, or on peer devices. 553 Also, a malicious web application might silently establish outgoing, 554 and accept incoming, streams on an already established connection. 556 Based on the identified security risks, this section will describe 557 security considerations for the browser and web application. 559 7.2. Browser Considerations 561 The browser is expected to provide mechanisms for getting user 562 consent to use device resources such as camera and microphone. 564 The browser is expected to provide mechanisms for informing the user 565 that device resources such as camera and microphone are in use 566 ("hot"). 568 The browser is expected to provide mechanisms for users to revise 569 consent to use device resources such as camera and microphone. 571 The browser is expected to provide mechanisms in order to assure that 572 streams are the ones the recipient intended to receive. 574 The browser is needs to ensure that media is not sent, and that 575 received media is not rendered, until the associated stream 576 establishment and handshake procedures with the remote peer have been 577 successfully finished. 579 The browser needs to ensure that the stream negotiation procedures 580 are not seen as Denial Of Service (DOS) by other entities. 582 7.3. Web Application Considerations 584 The web application is expected to ensure user consent in sending and 585 receiving media streams. 587 8. Additional use cases 589 Several additional use cases have been discusses. At this point 590 these use cases are not included as requirement deriving use cases 591 for different reasons (lack of documentation, overlap with existing 592 use cases, lack of consensus). For completeness these additional use 593 cases are listed below: 594 1. Use cases regarding different situations when being invited to a 595 "session", e.g. browser open, browser open but another tab 596 active, browser open but active in session, browser closed, .... 597 (Matthew Kaufman); discussed at webrtc meeting 598 2. Different TURN provider scenarios (Cullen Jennings); discussed 599 at the webrtc meeting 600 3. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/ 601 rtcweb/current/msg00525.html 602 4. Local Recording and Remote recording (John): Discussed a _lot_ 603 on the mail lists (rtcweb as well as public-webrtc late August 604 2011. Not concluded at time of writing. 606 5. Emergency access for disabled (Bernard Aboba) http:// 607 www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html 608 6. Clue use cases (Roni Even) http://tools.ietf.org/html/ 609 draft-ietf-clue-telepresence-use-cases-01 610 7. Rohan red cross (Cullen Jennings); http://www.ietf.org/ 611 mail-archive/web/rtcweb/current/msg00323.html 612 8. Remote assistance (ala VNC or RDP) - User is helping another 613 user on their computer with either view-only or view-with- 614 control, either of just the browser of the the entire screen. ht 615 tp://www.ietf.org/mail-archive/web/rtcweb/current/msg00543.html 616 9. Security camera/baby monitor usage http://www.ietf.org/ 617 mail-archive/web/rtcweb/current/msg00543.html 618 10. Large multiparty session http://www.ietf.org/mail-archive/web/ 619 rtcweb/current/msg00530.html 621 9. Acknowledgements 623 Harald Alvestrand and Ted Hardie have provided comments and feedback 624 on the draft. 626 Harald Alvestrand and Cullen Jennings have provided additional use- 627 cases. 629 Thank You to everyone in the RTCWEB community that have provided 630 comments, feedback and improvement proposals on the draft content. 632 10. Change Log 634 [RFC EDITOR NOTE: Please remove this section when publishing] 636 Changes from draft-ietf-rtcweb-use-cases-and-requirements-02 638 o Removed desrciption/list of API requirements, instead 639 o Reference to W3C webrtc_reqs document for API requirements 641 Changes from draft-ietf-rtcweb-ucreqs-01 643 o Changed Intended status to Information 644 o Changed "Ipr" to "trust200902" 645 o Added use case "Simple video communication service, NAT/FW that 646 blocks UDP", and derived new req F26 647 o Added use case "Distributed Music Band" and derived new req A17 648 o Added F24 as requirement derived from use case "Simple video 649 communication service with inter-operator calling" 651 o Added section "Additional use cases" 652 o Added text about ID handling to multiparty with central server use 653 case 654 o Re-phrased A1 slightly 656 Changes from draft-ietf-rtcweb-ucreqs-00 658 o - Reshuffled: Just two main groups of use cases (b2b and b2GW/ 659 Server); removed some specific use cases and added them instead as 660 flavors to the base use case (Simple video communciation) 661 o - Changed the fromulation of F19 662 o - Removed the requirement on an API for DTMF 663 o - Removed "FX3: There SHOULD be a mapping of the minimum needed 664 data for setting up connections into SIP, so that the restriction 665 to SIP-carriable data can be verified. Not a rew on the browser 666 but rather on a document" 667 o - (see 668 http://www.ietf.org/mail-archive/web/rtcweb/current/msg00227.html 669 for more details) 670 o -Added text on informing user of that mic/cam is being used and 671 that it must be possible to revoce permission to use them in 672 section 7. 673 Changes from draft-holmberg-rtcweb-ucreqs-01 674 o - Draft name changed to draft-ietf-rtcweb-ucreqs 675 o - Use-case grouping introduced 676 o - Additional use-cases added 677 o - Additional reqs added (derived from use cases): F19-F25, A16-A17 679 Changes from draft-holmberg-rtcweb-ucreqs-00 680 o - Mapping between use-cases and requirements added (Harald 681 Alvestrand, 090311) 682 o - Additional security considerations text (Harald Alvestrand, 683 090311) 684 o - Clarification that user applications are assumed to be executed 685 by a browser (Ted Hardie, 080311) 686 o - Editorial corrections and clarifications 688 11. References 690 11.1. Normative References 692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, March 1997. 695 11.2. Informative References 697 [webrtc_reqs] 698 "Webrt requirements, 699 http://dev.w3.org/2011/webrtc/editor/webrtc_reqs.html". 701 Authors' Addresses 703 Christer Holmberg 704 Ericsson 705 Hirsalantie 11 706 Jorvas 02420 707 Finland 709 Email: christer.holmberg@ericsson.com 711 Stefan Hakansson 712 Ericsson 713 Laboratoriegrand 11 714 Lulea 97128 715 Sweden 717 Email: stefan.lk.hakansson@ericsson.com 719 Goran AP Eriksson 720 Ericsson 721 Farogatan 6 722 Stockholm 16480 723 Sweden 725 Email: goran.ap.eriksson@ericsson.com