--- 1/draft-ietf-rtcweb-use-cases-and-requirements-15.txt 2015-01-23 01:14:54.657457013 -0800 +++ 2/draft-ietf-rtcweb-use-cases-and-requirements-16.txt 2015-01-23 01:14:54.721458534 -0800 @@ -1,19 +1,19 @@ RTCWEB Working Group C. Holmberg Internet-Draft S. Hakansson Intended status: Informational G. Eriksson -Expires: June 20, 2015 Ericsson - December 17, 2014 +Expires: July 27, 2015 Ericsson + January 23, 2015 Web Real-Time Communication Use-cases and Requirements - draft-ietf-rtcweb-use-cases-and-requirements-15.txt + draft-ietf-rtcweb-use-cases-and-requirements-16.txt Abstract This document describes web based real-time communication use-cases. Requirements on the browser functionality are derived from the use- cases. This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WGs efforts so far. It is @@ -29,25 +29,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 20, 2015. + This Internet-Draft will expire on July 27, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -85,23 +85,23 @@ 4. Requirements summary . . . . . . . . . . . . . . . . . . . . 18 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Browser requirements . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 22 6.2. Browser Considerations . . . . . . . . . . . . . . . . . 22 6.3. Web Application Considerations . . . . . . . . . . . . . 23 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 9. Normative References . . . . . . . . . . . . . . . . . . . . 29 + 9. Normative References . . . . . . . . . . . . . . . . . . . . 30 Appendix A. API requirements . . . . . . . . . . . . . . . . . . 30 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction This document presents a few use-cases of web applications that are executed in a browser and use real-time communication capabilities. In most of the use-cases all end-user clients are web applications, but there are some use-cases where at least one of the end-user clients is of another type (e.g. a mobile phone or a SIP User Agent (UA)). @@ -325,26 +325,27 @@ 3.3.4. Simple Video Communication Service, global service provider 3.3.4.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 3.3.1). What is added is that the service provider is operating over large geographical areas (or even globally). - Assuming that ICE will be used, this means that the service provider - would like to be able to provide several STUN and TURN servers (via - the app) to the browser; selection of which one(s) to use is part of - the ICE processing. Other reasons for wanting to provide several - STUN and TURN servers include support for IPv4 and IPv6, load - balancing and redundancy. + Assuming that the Interactive Connectivity Establishment (ICE) + mechanism [RFC5245] will be used, this means that the service + provider would like to be able to provide several STUN and TURN + servers (via the app) to the browser; selection of which one(s) to + use is part of the ICE processing. Other reasons for wanting to + provide several STUN and TURN servers include support for IPv4 and + IPv6, load balancing and redundancy. Note that ICE support being mandatory does not preclude a WebRTC endpoint from supporting more traversal mechanisms than ICE using STUN and TURN. 3.3.4.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- @@ -425,37 +426,37 @@ 3.3.7. Simple Video Communication Service, QoS 3.3.7.1. Description This use-case is almost identical to the Simple Video Communication Service, access change use-case (Section 3.3.6). The use of Quality of Service (QoS) capabilities is added: The user in the previous use case that starts a trip is behind a - common residential router that supports prioritization of traffic. + common residential router that supports differentiation of traffic. In addition, the user's provider of cellular access has QoS support enabled. The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular. 3.3.7.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- F22 The browser should be able to take advantage of available capabilities (supplied by network - nodes) to prioritize voice, video and data + nodes) to differentiate voice, video and data appropriately. ---------------------------------------------------------------- 3.3.8. Simple Video Communication Service with screen sharing 3.3.8.1. Description This use-case has the audio and video communication of the Simple Video Communication Service use-case (Section 3.3.1). @@ -531,42 +532,42 @@ is the video showing the game, the application used in the talent scout's mobile sets higher priority for that stream. 3.3.10.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F22 The browser should be able to take advantage of available capabilities (supplied by network - nodes) to prioritize voice, video and data + nodes) to differentiate voice, video and data appropriately. ---------------------------------------------------------------- F25 The browser must be able to render several concurrent audio and video streams. ---------------------------------------------------------------- A17, A23 3.3.11. Multiparty video communication 3.3.11.1. Description In this use-case, the Simple Video Communication Service use-case (Section 3.3.1) is extended by allowing multiparty sessions. No central server is involved - the browser of each participant sends and receives streams to and from all other session participants. The web application in the browser of each user is responsible for setting up streams to all receivers. In order to enhance the user experience, the web application renders - the audio coming from different particiapants so that it is + the audio coming from different participants so that it is experienced to come from different spatial locations. This is done automatically, but users can change how the different participants are placed in the (virtual) room. In addition the levels in the audio signals are adjusted before mixing. Another feature intended to enhance the use experience is that the video window that displays the video of the currently speaking peer is highlighted. Each video stream received is by default displayed in a thumbnail @@ -628,21 +629,21 @@ spatialization and mixing. "Other sound objects" could for example be a file with the sound of the tank; that file could be stored locally or remotely. 3.3.12.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F22 The browser should be able to take advantage of available capabilities (supplied by network - nodes) to prioritize voice, video and data + nodes) to differentiate voice, video and data appropriately. ---------------------------------------------------------------- F23 The browser must be able to transmit streams and data to several peers concurrently. ---------------------------------------------------------------- F24 The browser must be able to receive streams and data from multiple peers concurrently. ---------------------------------------------------------------- F25 The browser must be able to render several concurrent audio and video streams. @@ -891,21 +892,21 @@ servers that are supplied by entities other than the web application (i.e. the network provider). ---------------------------------------------------------------- F21 The browser must be able to send streams and data to a peer in the presence of Firewalls that only allows traffic via a HTTP Proxy, when Firewall policy allows WebRTC traffic. ---------------------------------------------------------------- F22 The browser should be able to take advantage of available capabilities (supplied by network - nodes) to prioritize voice, video and data + nodes) to differentiate voice, video and data appropriately. ---------------------------------------------------------------- Requirements related to multiple peers and streams ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F23 The browser must be able to transmit streams and data to several peers concurrently. ---------------------------------------------------------------- F24 The browser must be able to receive streams and @@ -988,34 +989,34 @@ 6.2. Browser Considerations The browser is expected to provide mechanisms for getting user consent to use device resources such as camera and microphone. The browser is expected to provide mechanisms for informing the user that device resources such as camera and microphone are in use ("hot"). - The browser is expected to provide mechanisms for users to revise and - even completely revoke consent to use device resources such as camera - and microphone. + The browser must provide mechanisms for users to revise and even + completely revoke consent to use device resources such as camera and + microphone. The browser is expected to provide mechanisms for getting user consent to use the screen (or a certain part of it) or what a certain application displays on the screen as source for streams. The browser is expected to provide mechanisms for informing the user that the screen, part thereof or an application is serving as a stream source ("hot"). - The browser is expected to provide mechanisms for users to revise and - even completely revoke consent to use the screen, part thereof or an + The browser must provide mechanisms for users to revise and even + completely revoke consent to use the screen, part thereof or an application is serving as a stream source. The browser is expected to provide mechanisms in order to assure that streams are the ones the recipient intended to receive. The browser is expected to provide mechanisms that allows the users to verify that the streams received have not be manipulated (F12). The browser needs to ensure that media is not sent, and that received media is not rendered, until the associated stream establishment and @@ -1031,26 +1032,52 @@ receiving media streams. 7. Acknowledgements The authors wish to thank Bernard Aboba, Gunnar Hellstrom, Martin Thomson, Lars Eggert, Matthew Kaufman, Emil Ivov, Eric Rescorla, Eric Burger, John Leslie, Dan Wing, Richard Barnes, Barry Dingle, Dale Worley, Ted hardie, Mary Barnes, Dan Burnett, Stephan Wenger, Harald Alvestrand, Cullen Jennings, Andrew Hutton and everyone else in the RTCWEB community that have provided comments, feedback, text and - improvement proposals on the document. + improvement proposals on the document. A big thank you to everyone + that provided comments as part of the IESG evaluation, and to + everyone else that provided comments and input in order to improve + the document. 8. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] + Changes from draft-ietf-rtcweb-use-cases-and-requirements-15 + + o Changes based on comment from Stephen Farrell: + + o - A1 modified, to also cover access to the local file stystem. + + o Changes based on comments from Benoit Claise: + + o - RFC 5245 added to references. + + o - Note added to Annex A, indicating that the API requirements are + not normative. + + o Changes based on comments from Brian Carpenter: + + o - RFC 7258 added to references. + + o - Terminology fixes: + + o -- 'prioritize' -> 'differentiate'. + + o -- 'prioritization' -> 'differentiation'. + Changes from draft-ietf-rtcweb-use-cases-and-requirements-14 o Changes based on comments from the ops-dir: o - Editorial fixes. o - F13: 'per-packet basis' -> 'per IP packet basis'. o - F22: Text corrected in one occurance. @@ -1325,38 +1351,50 @@ o - Editorial corrections and clarifications 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000. + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", RFC 5245, April + 2010. + [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008. [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, April 2009. + [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an + Attack", BCP 188, RFC 7258, May 2014. + Appendix A. API requirements This section contains the requirements on the API derived from the use-cases in Section 3. + NOTE: As W3C is responsible for the API, the API requirements in this + specification are not normative. + REQ-ID DESCRIPTION ---------------------------------------------------------------- A1 The Web API must provide means for the application to ask the browser for permission - to use cameras and microphones as input devices. + to use cameras and microphones as input devices, + and to have access to the local file system. ---------------------------------------------------------------- A2 The Web API must provide means for the web application to control how streams generated by input devices are used. ---------------------------------------------------------------- A3 The Web API must provide means for the web application to control the local rendering of streams (locally generated streams and streams received from a peer). ----------------------------------------------------------------