--- 1/draft-ietf-rtcweb-use-cases-and-requirements-14.txt 2014-12-17 05:15:30.187509876 -0800 +++ 2/draft-ietf-rtcweb-use-cases-and-requirements-15.txt 2014-12-17 05:15:30.247511302 -0800 @@ -1,135 +1,149 @@ RTCWEB Working Group C. Holmberg Internet-Draft S. Hakansson Intended status: Informational G. Eriksson -Expires: August 16, 2014 Ericsson - February 12, 2014 +Expires: June 20, 2015 Ericsson + December 17, 2014 Web Real-Time Communication Use-cases and Requirements - draft-ietf-rtcweb-use-cases-and-requirements-14.txt + draft-ietf-rtcweb-use-cases-and-requirements-15.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 + being published to record the early conclusions of the working group. + It will not be used as a set of rigid guidelines that specifications + and implementations will be held to in the future. + Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 August 16, 2014. + This Internet-Draft will expire on June 20, 2015. Copyright Notice Copyright (c) 2014 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 described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Common requirements . . . . . . . . . . . . . . . . . . . 4 3.3. Browser-to-browser use-cases . . . . . . . . . . . . . . 4 3.3.1. Simple Video Communication Service . . . . . . . . . 4 3.3.2. Simple Video Communication Service, NAT/Firewall that - blocks UDP . . . . . . . . . . . . . . . . . . . . . 6 + blocks UDP . . . . . . . . . . . . . . . . . . . . . 7 3.3.3. Simple Video Communication Service, Firewall that only allows traffic via a HTTP Proxy . . . . . . . . 7 3.3.4. Simple Video Communication Service, global service provider . . . . . . . . . . . . . . . . . . . . . . 7 3.3.5. Simple Video Communication Service, enterprise aspects . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.6. Simple Video Communication Service, access change . . 9 - 3.3.7. Simple Video Communication Service, QoS . . . . . . . 9 + 3.3.7. Simple Video Communication Service, QoS . . . . . . . 10 3.3.8. Simple Video Communication Service with screen sharing . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.3.9. Simple Video Communication Service with file exchange 10 + 3.3.9. Simple Video Communication Service with file exchange 11 3.3.10. Hockey Game Viewer . . . . . . . . . . . . . . . . . 11 3.3.11. Multiparty video communication . . . . . . . . . . . 12 - 3.3.12. Multiparty on-line game with voice communication . . 13 + 3.3.12. Multiparty on-line game with voice communication . . 14 3.4. Browser - GW/Server use cases . . . . . . . . . . . . . . 15 3.4.1. Telephony terminal . . . . . . . . . . . . . . . . . 15 - 3.4.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . 15 - 3.4.3. Video conferencing system with central server . . . . 16 - 4. Requirements summary . . . . . . . . . . . . . . . . . . . . 17 - 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 4.2. Browser requirements . . . . . . . . . . . . . . . . . . 17 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 - 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 21 - 6.2. Browser Considerations . . . . . . . . . . . . . . . . . 21 - 6.3. Web Application Considerations . . . . . . . . . . . . . 22 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 - 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 9. Normative References . . . . . . . . . . . . . . . . . . . . 28 - Appendix A. API requirements . . . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 + 3.4.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . 16 + 3.4.3. Video conferencing system with central server . . . . 17 + 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 + Appendix A. API requirements . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 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 UA). + clients is of another type (e.g. a mobile phone or a SIP User Agent + (UA)). Based on the use-cases, the document derives requirements related to browser functionality. These requirements are named "Fn", where n is an integer, and are listed in conjunction with the use-cases. A summary is provided in Section 4.2. 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 proposed to be used in a later phase to evaluate the protocols and solutions developed by the WG. This document also lists requirements related to the API to be used by web applications as an appendix. The reason is that the W3C WebRTC WG has decided to not develop its own use-case/requirement document, but instead use this document. These requirements are - named "An", where n is an integer, and are described in Appendix A- + named "An", where n is an integer, and are described in Appendix A. + + 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 + being published to record the early conclusions of the working group. + It will not be used as a set of rigid guidelines that specifications + and implementations will be held to in the future. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. Use-cases - 3.1. Introduction This section describes web based real-time communication use-cases, from which requirements are derived. The following considerations are applicable to all use cases: o Clients can be on IPv4-only o Clients can be on IPv6-only @@ -135,24 +149,26 @@ o Clients can be on IPv6-only o Clients can be on dual-stack o Clients can be connected to networks with different throughput capabilities o Clients can be on variable-media-quality networks (wireless) o Clients can be on congested networks + o Clients can be on firewalled networks with no UDP allowed - o Clients can be on networks with a NAT using any type of Mapping - and Filtering behaviors (as described in RFC4787). + o Clients can be on networks with a NAT or IPv4-IPv6 translation + devices using any type of Mapping and Filtering behaviors (as + described in RFC4787). 3.2. Common requirements The requirements retrived from the Simple Video Communication Service use-case (Section 3.3.1) by default apply to all other use-cases, and are considred common. For each individual use-case, only the additional requirements are listed. 3.3. Browser-to-browser use-cases @@ -168,24 +184,24 @@ online user, a 1-1 audiovisual communication session between the browsers of the two peers is initiated. The invited user might accept or reject the session. During session establishment a self-view is displayed, and once the session has been established the video sent from the remote peer is displayed in addition to the self-view. During the session, each user can select to remove and re-insert the self-view as often as desired. Each user can also change the sizes of his/her two video displays during the session. Each user can also pause sending of - media (audio, video, or both) and mute incoming media + media (audio, video, or both) and mute incoming media. It is essential that media and data be encrypted, authenticated and - integrity protected on a per-packet basis and that media and data + integrity protected on a per IP packet basis and that media and data packets failing the integrity check not be delivered to the application. The application gives the users the opportunity to stop it from exposing the host IP address to the application of the other user. Any session participant can end the session at any time. The two users may be using communication devices with different operating systems and browsers from different vendors. @@ -211,52 +227,51 @@ ---------------------------------------------------------------- F4 The browser must be able to receive, process and render streams and data ("render" does not apply for data) from peers. ---------------------------------------------------------------- F5 The browser should be able to render good quality audio and video even in the presence of reasonable levels of jitter and packet losses. ---------------------------------------------------------------- F6 The browser must detect when a stream from a - peer is not received anymore + peer is not received anymore. ---------------------------------------------------------------- F7 When there are both incoming and outgoing audio streams, echo cancellation must be made available to avoid disturbing echo during conversation. ---------------------------------------------------------------- F8 The browser must support synchronization of audio and video. ---------------------------------------------------------------- F9 The browser should use encoding of streams suitable for the current rendering (e.g. video display size) and should change parameters - if the rendering changes during the session + if the rendering changes during the session. ---------------------------------------------------------------- F10 The browser must support a baseline audio and - video codec + video codec. ---------------------------------------------------------------- F11 It must be possible to protect streams and data - from wiretapping [RFC2804]. - + from wiretapping [RFC2804][RFC7258]. ---------------------------------------------------------------- F12 The browser must enable verification, given the right circumstances and by use of other trusted communication, that streams and data received have not been manipulated by any party. ---------------------------------------------------------------- F13 The browser must encrypt, authenticate and integrity protect media and data on a - per-packet basis, and must drop incoming media - and data packets that fail the per-packet + per IP packet basis, and must drop incoming media + and data packets that fail the per IP packet integrity check. In addition, the browser must support a mechanism for cryptographically binding media and data security keys to the user identity (see R-ID-BINDING in [RFC5479]). ---------------------------------------------------------------- F14 The browser must make it possible to set up a call between two parties without one party learning the other party's host IP address. ---------------------------------------------------------------- F15 The browser must be able to collect statistics, @@ -422,22 +439,24 @@ 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 must be able to receive streams and - data from multiple peers concurrently. + F22 The browser should be able to take advantage + of available capabilities (supplied by network + nodes) to prioritize 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). But in addition to this, one of the users can share what is being @@ -517,21 +535,21 @@ ---------------------------------------------------------------- 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 appropriately. ---------------------------------------------------------------- F25 The browser must be able to render several - concurrent video streams + 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 @@ -566,27 +584,27 @@ ---------------------------------------------------------------- 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 data from multiple peers concurrently. ---------------------------------------------------------------- F25 The browser must be able to render several - concurrent video streams + concurrent audio and video streams. ---------------------------------------------------------------- F26 The browser must be able to mix several audio streams. ---------------------------------------------------------------- F27 The browser must be able to apply spatialization - effects when playing audio streams. + effects to audio streams. ---------------------------------------------------------------- F28 The browser must be able to measure the voice activity level in audio streams. ---------------------------------------------------------------- F29 The browser must be able to change the voice activity level in audio streams. ---------------------------------------------------------------- A13, A14, A15, A16 @@ -621,21 +638,21 @@ nodes) to prioritize 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 video streams + concurrent audio and video streams. ---------------------------------------------------------------- F26 The browser must be able to mix several audio streams. ---------------------------------------------------------------- F27 The browser must be able to apply spatialization effects when playing audio streams. ---------------------------------------------------------------- F28 The browser must be able to measure the voice activity level in audio streams. ---------------------------------------------------------------- @@ -758,21 +773,21 @@ 3.4.3.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F16 The browser must support insertion of reference frames in outgoing media streams when requested by a peer. ---------------------------------------------------------------- F25 The browser must be able to render several - concurrent video streams + concurrent audio and video streams. ---------------------------------------------------------------- 4. Requirements summary 4.1. General This section contains the requirements on the browser derived from the use-cases in Section 3. NOTE: It is assumed that the user applications are executed on a @@ -820,21 +836,21 @@ ---------------------------------------------------------------- F9 The browser should use encoding of streams suitable for the current rendering (e.g. video display size) and should change parameters if the rendering changes during the session ---------------------------------------------------------------- F10 The browser must support a baseline audio and video codec ---------------------------------------------------------------- F11 It must be possible to protect streams and data - from wiretapping [RFC2804]. + from wiretapping [RFC2804][RFC7258]. ---------------------------------------------------------------- F12 The browser must enable verification, given the right circumstances and by use of other trusted communication, that streams and data received have not been manipulated by any party. ---------------------------------------------------------------- F13 The browser must encrypt, authenticate and integrity protect media and data on a per-packet basis, and must drop incoming media @@ -887,23 +903,24 @@ ---------------------------------------------------------------- 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 data from multiple peers concurrently. + ---------------------------------------------------------------- F25 The browser must be able to render several - concurrent video streams + concurrent audio and video streams. ---------------------------------------------------------------- F26 The browser must be able to mix several audio streams. ---------------------------------------------------------------- Requirements related to audio processing ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F27 The browser must be able to apply spatialization effects when playing audio streams. @@ -1019,21 +1037,44 @@ 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. 8. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] + 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. + + o - F25: 'audio' added. + + o Changes based on comments from IESG + + o - Editorial fixes. + + o - Disclaimer text suggested by Alissa Cooper added. + + o - F11: Reference to RFC 7258 added. + + o - F27: 'when playing' removed. + Changes from draft-ietf-rtcweb-use-cases-and-requirements-10 + o Described that the API requirements are really from a W3C perspective and are supplied as an appendix in the introduction. Moved API requirements to an Appendix. o Removed the "Conventions" section with the key-words and reference to RFC2119. Also changed uppercase MUST's/SHOULD's to lowercase. o Added a note on the proposed use of the document to the introduction. @@ -1157,27 +1198,28 @@ 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 http://www.ietf.org/mail-archive/web/rtcweb/current/ msg01648.html and http://lists.w3.org/Archives/Public/public- webrtc/2011Sep/0102.html) o Added use-case on sharing as decided in http://www.ietf.org/mail- archive/web/rtcweb/current/msg01700.html, derived reqs F30 and A21 - o Added the list of common considerations proposed in mail http:// - www.ietf.org/mail-archive/web/rtcweb/current/msg01562.html to the - Introduction of the use-case section + o Added the list of common considerations proposed in mail + http://www.ietf.org/mail-archive/web/rtcweb/current/msg01562.html + to the Introduction of the use-case section Changes from draft-ietf-rtcweb-use-cases-and-requirements-04 - o Most changes based on the input from Dan Burnett http:// - www.ietf.org/mail-archive/web/rtcweb/current/msg00948.html + + o Most changes based on the input from Dan Burnett + http://www.ietf.org/mail-archive/web/rtcweb/current/msg00948.html o Many editorial changes o 4.2.1.1 Clarified o Some clarification added to 4.3.1.1 as a note o F-requirements updated (see reply to Dan's mail). o Almost all A-requirements updated to start "The Web API MUST