--- 1/draft-ietf-rtcweb-use-cases-and-requirements-06.txt 2012-04-02 15:13:56.290755540 +0200 +++ 2/draft-ietf-rtcweb-use-cases-and-requirements-07.txt 2012-04-02 15:13:56.330756599 +0200 @@ -1,19 +1,19 @@ RTCWEB Working Group C. Holmberg Internet-Draft S. Hakansson Intended status: Informational G. Eriksson -Expires: April 6, 2012 Ericsson - October 4, 2011 +Expires: October 4, 2012 Ericsson + April 2, 2012 Web Real-Time Communication Use-cases and Requirements - draft-ietf-rtcweb-use-cases-and-requirements-06.txt + draft-ietf-rtcweb-use-cases-and-requirements-07.txt Abstract This document describes web based real-time communication use-cases. Based on the use-cases, the document also derives requirements related to the browser, and the API used by web applications to request and control media stream services provided by the browser. Status of this Memo @@ -23,25 +23,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 April 6, 2012. + This Internet-Draft will expire on October 4, 2012. Copyright Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + Copyright (c) 2012 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 @@ -59,41 +59,41 @@ 4.2.2. Simple Video Communication Service, NAT/FW that blocks UDP . . . . . . . . . . . . . . . . . . . . . . 5 4.2.3. Simple Video Communication Service, global service provider . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.4. Simple Video Communication Service, enterprise aspects . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.5. Simple Video Communication Service, access change . . 6 4.2.6. Simple Video Communication Service, QoS . . . . . . . 7 4.2.7. Simple Video Communication Service with sharing . . . 7 4.2.8. Simple video communication service with - inter-operator calling . . . . . . . . . . . . . . . . 8 + inter-operator calling . . . . . . . . . . . . . . . . 7 4.2.9. Hockey Game Viewer . . . . . . . . . . . . . . . . . . 8 4.2.10. Multiparty video communication . . . . . . . . . . . . 9 4.2.11. Multiparty on-line game with voice communication . . . 10 - 4.2.12. Distributed Music Band . . . . . . . . . . . . . . . . 11 + 4.2.12. Distributed Music Band . . . . . . . . . . . . . . . . 10 4.3. Browser - GW/Server use cases . . . . . . . . . . . . . . 11 4.3.1. Telephony terminal . . . . . . . . . . . . . . . . . . 11 - 4.3.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . . 12 + 4.3.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . . 11 4.3.3. Video conferencing system with central server . . . . 12 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Browser requirements . . . . . . . . . . . . . . . . . . . 13 5.3. API requirements . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 18 - 7.2. Browser Considerations . . . . . . . . . . . . . . . . . . 19 + 7.2. Browser Considerations . . . . . . . . . . . . . . . . . . 18 7.3. Web Application Considerations . . . . . . . . . . . . . . 19 - 8. Additional use-cases . . . . . . . . . . . . . . . . . . . . . 20 + 8. Additional use-cases . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 - 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction This document presents a few use-cases of web applications that are executed in a browser and use real-time communication capabilities. Based on the use-cases, the document derives requirements related to @@ -204,34 +204,28 @@ 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. - Note that the additional requirements derived are termed FaI/AaI - where aI means "assuming ICE". - 4.2.3.2. Derived Requirements - F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28 - - FaI1 - - A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 + F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F31 - AaI1 + A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A22 4.2.4. Simple Video Communication Service, enterprise aspects + 4.2.4.1. Description This use-case is similar to the Simple Video Communication Service use-case (Section 4.2.1). What is added is aspects when using the service in enterprises. ICE is assumed in the further description of this use-case. An enterprise that uses a RTCWEB based web application for communication desires to audit all RTCWEB based application session @@ -247,28 +241,23 @@ TURN server, thus they deploy a STUN server allowing the RTCWEB client to determine its server reflexive address on the internal side. Thus enabling cases where peers are both on the internal side to connect without the traffic leaving the internal network. It must be possibele to configure the browsers used in the enterprise with network specific STUN and TURN servers. This should be possible to achieve by autoconfiguration methods. The RTCWEB functionality will need to utilize both network specific STUN and TURN resources and STUN and TURN servers provisioned by the web application. - Note that the additional requirements derived are termed FaI/AaI - where aI means "assuming ICE". - 4.2.4.2. Derived Requirements - F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28 - - FaI2 + F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F25, F28, F32 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 4.2.5. Simple Video Communication Service, access change 4.2.5.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 4.2.1).The difference is that the user changes network access during the session: @@ -711,24 +699,24 @@ video codec ---------------------------------------------------------------- F29 The browser MUST be able to send streams to a peer in the presence of NATs that block UDP traffic. ---------------------------------------------------------------- F30 The browser MUST be able to use the screen (or a specific area of the screen) or what a certain application displays on the screen to generate streams. ---------------------------------------------------------------- - FaI1 The browser MUST be able to use several STUN + F31 The browser MUST be able to use several STUN and TURN servers ---------------------------------------------------------------- - FaI2 There browser MUST support that STUN and TURN + F32 There browser MUST support that STUN and TURN servers to use are supplied by other entities than the service provided (i.e. the network provider) ---------------------------------------------------------------- 5.3. API requirements REQ-ID DESCRIPTION ---------------------------------------------------------------- A1 The Web API MUST provide means for the application to ask the browser for permission @@ -823,21 +811,21 @@ other). The types of media he's willing to accept can be a subset of the types of media the browser is able to accept. ---------------------------------------------------------------- A21 The Web API MUST provide means for the application to ask the browser for permission to the screen, a certain area on the screen or what a certain application displays on the screen as input to streams. ---------------------------------------------------------------- - AaI1 The Web API MUST provide means for the + A22 The Web API MUST provide means for the application to specify several STUN and/or TURN servers to use. ---------------------------------------------------------------- 6. IANA Considerations TBD 7. Security Considerations @@ -938,22 +926,26 @@ Harald Alvestrand and Cullen Jennings have provided additional use- cases. Thank You to everyone in the RTCWEB community that have provided comments, feedback and improvement proposals on the draft content. 10. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] - Changes from draft-ietf-rtcweb-use-cases-and-requirements-05 + Changes from draft-ietf-rtcweb-use-cases-and-requirements-06 + + o Renaming of requirements (FaI1 -> F31), (FaI2 -> F32) and (AaI1 -> + A22) + Changes from draft-ietf-rtcweb-use-cases-and-requirements-05 o Added use-case "global service provider", derived reqs associated with several STUN/TURN servers o Added use-case "enterprise aspects", derived req associated with enabling the network provider to supply STUN and TURN servers o The requirements from the above are ICE specific and labeled accordingly o Separated the requirements phrased like "processing such as pan, mix and render" for audio to be specific reqs on spatialization, level measurement, level adjustment and mixing (discussed on the lists in