From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7478.txt | 1627 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1627 insertions(+) create mode 100644 doc/rfc/rfc7478.txt (limited to 'doc/rfc/rfc7478.txt') diff --git a/doc/rfc/rfc7478.txt b/doc/rfc/rfc7478.txt new file mode 100644 index 0000000..5ef6648 --- /dev/null +++ b/doc/rfc/rfc7478.txt @@ -0,0 +1,1627 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Holmberg +Request for Comments: 7478 S. Hakansson +Category: Informational G. Eriksson +ISSN: 2070-1721 Ericsson + March 2015 + + + Web Real-Time Communication Use Cases and Requirements + +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 WG's efforts so far. It + is being published to record the early conclusions of the WG. 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 document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7478. + + + + + + + + + + + + + + +Holmberg, et al. Informational [Page 1] + +RFC 7478 WebRTC March 2015 + + +Copyright Notice + + 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 + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Holmberg, et al. Informational [Page 2] + +RFC 7478 WebRTC March 2015 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. Use Cases .......................................................4 + 2.1. Introduction ...............................................4 + 2.2. Common Requirements ........................................5 + 2.3. Browser-to-Browser Use Cases ...............................5 + 2.3.1. Simple Video Communication Service ..................5 + 2.3.2. Simple Video Communication Service: + NAT/Firewall That Blocks UDP ........................8 + 2.3.3. Simple Video Communication Service: Firewall + That Only Allows Traffic via an HTTP Proxy ..........8 + 2.3.4. Simple Video Communication Service: Global + Service Provider ....................................8 + 2.3.5. Simple Video Communication Service: + Enterprise Aspects ..................................9 + 2.3.6. Simple Video Communication Service: Access Change ..10 + 2.3.7. Simple Video Communication Service: QoS ............11 + 2.3.8. Simple Video Communication Service with + Screen Sharing .....................................11 + 2.3.9. Simple Video Communication Service with + File Exchange ......................................12 + 2.3.10. Hockey Game Viewer ................................12 + 2.3.11. Multiparty Video Communication ....................14 + 2.3.12. Multiparty Online Game with Voice Communication ...15 + 2.4. Browser - GW/Server Use Cases .............................17 + 2.4.1. Telephony Terminal .................................17 + 2.4.2. FedEx Call .........................................17 + 2.4.3. Video Conferencing System with Central Server ......18 + 3. Requirements Summary ...........................................19 + 3.1. General ...................................................19 + 3.2. Browser Requirements ......................................19 + 4. Security Considerations ........................................23 + 4.1. Introduction ..............................................23 + 4.2. Browser Considerations ....................................24 + 4.3. Web Application Considerations ............................24 + 5. Normative References ...........................................25 + Appendix A. API Requirements ......................................26 + Acknowledgements ..................................................29 + Authors' Addresses ................................................29 + + + + + + + + + + + +Holmberg, et al. Informational [Page 3] + +RFC 7478 WebRTC March 2015 + + +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)). + + 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 3.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 WG's 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 or requirement + document, but instead will use this document. These requirements are + 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 WG's efforts so far. It + is being published to record the early conclusions of the WG. It + will not be used as a set of rigid guidelines that specifications and + implementations will be held to in the future. + +2. Use Cases + +2.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 + + o Clients can be on dual-stack + + + + +Holmberg, et al. Informational [Page 4] + +RFC 7478 WebRTC March 2015 + + + 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 or IPv4-IPv6 translation + devices using any type of Mapping and Filtering behaviors (as + described in RFC 4787). + +2.2. Common Requirements + + The requirements retrieved from the + Simple Video Communication Service use case (Section 2.3.1) by + default apply to all other use cases and are considered common. For + each use case, only the additional requirements are listed. + +2.3. Browser-to-Browser Use Cases + +2.3.1. Simple Video Communication Service + +2.3.1.1. Description + + Two or more users have loaded a video communication web application + into their browsers, provided by the same service provider, and + logged into the service it provides. The web service publishes + information about user login status by pushing updates to the web + application in the browsers. When one online user selects a peer + 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: + + o select to remove and reinsert the self-view as often as desired, + + o change the sizes of his/her two video displays during the session, + and + + o pause the sending of media (audio, video, or both) and mute + incoming media. + + + + +Holmberg, et al. Informational [Page 5] + +RFC 7478 WebRTC March 2015 + + + It is essential that media and data be encrypted, authenticated, and + 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. + + The web service monitors the quality of the service (focus on quality + of audio and video) that the end users experience. + +2.3.1.2. Common Requirements + + ---------------------------------------------------------------- + REQ-ID DESCRIPTION + ---------------------------------------------------------------- + F1 The browser must be able to use microphones and + cameras as input devices to generate streams. + ---------------------------------------------------------------- + F2 The browser must be able to send streams and + data to a peer in the presence of NATs. + ---------------------------------------------------------------- + F3 Transmitted streams and data must be rate + controlled (meaning that the browser must, regardless + of application behavior, reduce send rate when + there is congestion). + ---------------------------------------------------------------- + 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. + + + + + + + + + +Holmberg, et al. Informational [Page 6] + +RFC 7478 WebRTC March 2015 + + + ---------------------------------------------------------------- + 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. + ---------------------------------------------------------------- + F10 The browser must support a baseline audio and + video codec. + ---------------------------------------------------------------- + F11 It must be possible to protect streams and data + 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-IP-packet basis, and it 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, + related to the transport of audio and video + between peers, needed to estimate quality of + experience. + ---------------------------------------------------------------- + + A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A25, A26 + + + + + +Holmberg, et al. Informational [Page 7] + +RFC 7478 WebRTC March 2015 + + +2.3.2. Simple Video Communication Service: NAT/Firewall That Blocks UDP + +2.3.2.1. Description + + This use case is almost identical to the + Simple Video Communication Service use case (Section 2.3.1). The + difference is that one of the users is behind a NAT/firewall that + blocks UDP traffic. + +2.3.2.2. Additional Requirements + + ---------------------------------------------------------------- + REQ-ID DESCRIPTION + ---------------------------------------------------------------- + F18 The browser must be able to send streams and + data to a peer in the presence of NATs and + firewalls that block UDP traffic. + ---------------------------------------------------------------- + +2.3.3. Simple Video Communication Service: Firewall That Only Allows + Traffic via an HTTP Proxy + +2.3.3.1. Description + + This use case is almost identical to the + Simple Video Communication Service use case (Section 2.3.1). The + difference is that one of the users is behind a firewall that only + allows traffic via an HTTP Proxy. + +2.3.3.2. Additional Requirements + + ---------------------------------------------------------------- + REQ-ID DESCRIPTION + ---------------------------------------------------------------- + F21 The browser must be able to send streams and + data to a peer in the presence of firewalls that only + allow traffic via an HTTP Proxy, when firewall policy + allows WebRTC traffic. + ---------------------------------------------------------------- + +2.3.4. Simple Video Communication Service: Global Service Provider + +2.3.4.1. Description + + This use case is almost identical to the + Simple Video Communication Service use case (Section 2.3.1). What is + added is that the service provider is operating over large + geographical areas (or even globally). + + + +Holmberg, et al. Informational [Page 8] + +RFC 7478 WebRTC March 2015 + + + 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 Session Traversal + Utilities for NAT (STUN) and Traversal Using Relay NAT (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. + +2.3.4.2. Additional Requirements + + ---------------------------------------------------------------- + REQ-ID DESCRIPTION + ---------------------------------------------------------------- + F19 The browser must be able to use several STUN + and TURN servers. + ---------------------------------------------------------------- + + A22 + +2.3.5. Simple Video Communication Service: Enterprise Aspects + +2.3.5.1. Description + + This use case is similar to the Simple Video Communication Service + use case (Section 2.3.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 WebRTC-based web application for + communication desires to audit all WebRTC-based application sessions + used from inside the company towards any external peer. To be able + to do this, they deploy a TURN server that straddles the boundary + between the internal and the external network. + + The firewall will block all attempts to use STUN with an external + destination unless they go to the enterprise auditing TURN server. + In cases where employees are using WebRTC applications provided by an + external service provider, they still want the traffic to stay inside + their internal network and in addition not load the straddling TURN + server; thus, they deploy a STUN server allowing the WebRTC client to + determine its server reflexive address on the internal side. Thus, + enabling cases where peers are both on the internal side to connect + + + +Holmberg, et al. Informational [Page 9] + +RFC 7478 WebRTC March 2015 + + + without the traffic leaving the internal network. It must be + possible 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 WebRTC functionality will + need to utilize both network specific STUN and TURN resources and + STUN and TURN servers provisioned by the web application. + +2.3.5.2. Additional Requirements + + ---------------------------------------------------------------- + REQ-ID DESCRIPTION + ---------------------------------------------------------------- + F20 The browser must support the use of STUN and TURN + servers that are supplied by entities other than + the web application (i.e., the network provider). + ---------------------------------------------------------------- + +2.3.6. Simple Video Communication Service: Access Change + +2.3.6.1. Description + + This use case is almost identical to the + Simple Video Communication Service use case (Section 2.3.1). The + difference is that the user changes network access during the + session. + + The communication device used by one of the users has several network + adapters (Ethernet, Wi-Fi, Cellular). The communication device is + accessing the Internet using Ethernet, but the user has to start a + trip during the session. The communication device automatically + changes to use Wi-Fi when the Ethernet cable is removed and then + moves to cellular access to the Internet when moving out of Wi-Fi + coverage. The session continues even though the access method + changes. + +2.3.6.2. Additional Requirements + + ---------------------------------------------------------------- + REQ-ID DESCRIPTION + ---------------------------------------------------------------- + F17 The communication session must survive across a + change of the network interface used by the + session. + ---------------------------------------------------------------- + + + + + + + +Holmberg, et al. Informational [Page 10] + +RFC 7478 WebRTC March 2015 + + +2.3.7. Simple Video Communication Service: QoS + +2.3.7.1. Description + + This use case is almost identical to the + Simple Video Communication Service: Access Change use case + (Section 2.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 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. + +2.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 differentiate voice, video, and data + appropriately. + ---------------------------------------------------------------- + +2.3.8. Simple Video Communication Service with Screen Sharing + +2.3.8.1. Description + + This use case has the audio and video communication of the + Simple Video Communication Service use case (Section 2.3.1). + + However, in addition to this, one of the users can share what is + being displayed on her/his screen with a peer. The user can choose + to share the entire screen, part of the screen (part selected by the + user), or what a selected application displays with the peer. + + + + + + + + + + +Holmberg, et al. Informational [Page 11] + +RFC 7478 WebRTC March 2015 + + +2.3.8.2. Additional Requirements + + ---------------------------------------------------------------- + REQ-ID DESCRIPTION + ---------------------------------------------------------------- + F36 The browser must be able to generate streams + using the entire user display, a specific area + of the user display, or the information being + displayed by a specific application. + ---------------------------------------------------------------- + + A21 + +2.3.9. Simple Video Communication Service with File Exchange + +2.3.9.1. Description + + This use case has the audio and video communication of the + Simple Video Communication Service use case (Section 3.3.1). + + However, in addition to this, the users can send and receive files + stored in the file system of the device used. + +2.3.9.2. Additional Requirements + + ---------------------------------------------------------------- + REQ-ID DESCRIPTION + ---------------------------------------------------------------- + F35 The browser must be able to send reliable + data traffic to a peer browser. + ---------------------------------------------------------------- + + A21, A24 + +2.3.10. Hockey Game Viewer + +2.3.10.1. Description + + An ice-hockey club uses an application that enables talent scouts to, + in real-time, show and discuss games and players with the club + manager. The talent scouts use a mobile phone with two cameras: one + front facing and one rear facing. + + The club manager uses a desktop, equipped with one camera, for + viewing the game and discussing with the talent scout. + + + + + + +Holmberg, et al. Informational [Page 12] + +RFC 7478 WebRTC March 2015 + + + Before the game starts, and during game breaks, the talent scout and + the manager have a 1:1 audiovisual communication session. On the + mobile phone, only the camera facing the talent scout is used. On + the user display of the mobile phone, the video of the club manager + is shown with a picture-in-picture thumbnail of the rear-facing + camera (self view). On the display of the desktop, the video of the + talent scout is shown with a picture-in-picture thumbnail of the + desktop camera (self view). + + When the game is ongoing, the talent scout activates the use of the + front-facing camera, and that stream is sent to the desktop (the + stream from the rear-facing camera continues to be sent all the + time). The video stream captured by the front-facing camera (that is + capturing the game) of the mobile phone is shown in a big window on + the desktop screen, with picture-in-picture thumbnails of the rear- + facing camera and the desktop camera (self view). On the display of + the mobile phone the game is shown (front-facing camera) with + picture-in-picture thumbnails of the rear-facing camera (self view) + and the desktop camera. Because the most important stream in this + phase is the video showing the game, the application used in the + talent scout's mobile phone sets higher priority for that stream. + +2.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 differentiate voice, video, and data + appropriately. + ---------------------------------------------------------------- + F25 The browser must be able to render several + concurrent audio and video streams. + ---------------------------------------------------------------- + + A17, A23 + + + + + + + + + + + + + + +Holmberg, et al. Informational [Page 13] + +RFC 7478 WebRTC March 2015 + + +2.3.11. Multiparty Video Communication + +2.3.11.1. Description + + In this use case, the Simple Video Communication Service use case + (Section 2.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 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 user experience is the + highlighting of the video window that displays the video of the + currently speaking peer. + + Each video stream received is, by default, displayed in a thumbnail + frame within the browser, but users can change the display size. + + Note: What this use case adds in terms of requirements are + capabilities to send streams to and receive streams from several + peers concurrently as well as the capabilities to render the video + from all received streams and be able to spatialize, level adjust, + and mix the audio from all received streams locally in the browser. + It also adds the capability to measure the audio level/activity. + + + + + + + + + + + + + + + + + + + + +Holmberg, et al. Informational [Page 14] + +RFC 7478 WebRTC March 2015 + + +2.3.11.2. Additional Requirements + + ---------------------------------------------------------------- + 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 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 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 + +2.3.12. Multiparty Online Game with Voice Communication + +2.3.12.1. Description + + This use case is based on the previous one. In this use case, the + voice part of the multiparty video communication use case is used in + the context of an online game. The received voice audio media is + rendered together with game sound objects. For example, the sound of + a tank moving from left to right over the screen must be rendered and + played to the user together with the voice media. + + Quick updates of the game state are required, and they have higher + priority than the voice. + + Note: the difference regarding local audio processing compared to the + "Multiparty Video Communication" use case is that other sound objects + than the streams must be possible to be included in the + + + + + +Holmberg, et al. Informational [Page 15] + +RFC 7478 WebRTC March 2015 + + + 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. + +2.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 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. + ---------------------------------------------------------------- + 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. + ---------------------------------------------------------------- + F29 The browser must be able to change the + voice activity level in audio streams. + ---------------------------------------------------------------- + F30 The browser must be able to process and mix + sound objects (media that is retrieved from + another source than the established media + stream(s) with the peer(s) with audio streams). + ---------------------------------------------------------------- + F34 The browser must be able to send short + latency unreliable datagram traffic to a + peer browser [RFC5405]. + ---------------------------------------------------------------- + + A13, A14, A15, A16, A17, A18, A23 + + + + + +Holmberg, et al. Informational [Page 16] + +RFC 7478 WebRTC March 2015 + + +2.4. Browser - GW/Server Use Cases + +2.4.1. Telephony Terminal + +2.4.1.1. Description + + A mobile telephony operator allows its customers to use a web browser + to access their services. After a simple log in, the user can place + and receive calls in the same way as when using a normal mobile + phone. When a call is received or placed, the identity is shown in + the same manner as when a mobile phone is used. + + Note: "place and receive calls in the same way as when using a normal + mobile phone" means that you can dial a number and your mobile + telephony operator has made available your phone contacts online so + that they are available and can be clicked to call and they can be + used to present the identity of an incoming call. If the callee is + not in your phone contacts, the number is displayed. Furthermore, + your call logs are available, and updated with the calls made/ + received from the browser. For people receiving calls made from the + web browser, the usual identity (i.e., the phone number of the mobile + phone) will be presented. + +2.4.1.2. Additional Requirements + + ---------------------------------------------------------------- + REQ-ID DESCRIPTION + ---------------------------------------------------------------- + F31 The browser must support an audio media format + (codec) that is commonly supported by existing + telephony services. + ---------------------------------------------------------------- + F33 The browser must be able to initiate and + accept a media session where the data needed + for establishment can be carried in SIP. + ---------------------------------------------------------------- + +2.4.2. FedEx Call + +2.4.2.1. Description + + Alice uses her web browser with a service that allows her to call + Public Switched Telephone Network (PSTN) numbers. Alice calls + 1-800-123-4567. Alice should be able to hear the initial prompts + from the FedEx Interactive Voice Responder (IVR), and when the IVR + says press 1, there should be a way for Alice to navigate the IVR. + + + + + +Holmberg, et al. Informational [Page 17] + +RFC 7478 WebRTC March 2015 + + +2.4.2.2. Additional Requirements + + ---------------------------------------------------------------- + REQ-ID DESCRIPTION + ---------------------------------------------------------------- + F31 The browser must support an audio media format + (codec) that is commonly supported by existing + telephony services. + ---------------------------------------------------------------- + F32 There should be a way to navigate + a dual-tone multi-frequency signaling (DTMF) + based Interactive Voice Response (IVR) system. + ---------------------------------------------------------------- + +2.4.3. Video Conferencing System with Central Server + +2.4.3.1. Description + + An organization uses a video communication system that supports the + establishment of multiparty video sessions using a central conference + server. + + The browser of each participant sends an audio stream (type in terms + of mono, stereo, 5.1 -- depending on the equipment of the + participant) to the central server. The central server mixes the + audio streams (and can in the mixing process naturally add effects + such as spatialization) and sends towards each participant a mixed + audio stream that is played to the user. + + The browser of each participant sends video towards the server. For + each participant, one high-resolution video is displayed in a large + window, while a number of low-resolution videos are displayed in + smaller windows. The server selects what video streams to be + forwarded as main and thumbnail videos, respectively, based on speech + activity. As the video streams to display can change quite + frequently (as the conversation flows), it is important that the + delay from when a video stream is selected for display until the + video can be displayed is short. + + All participants are authenticated by the central server and + authorized to connect to the central server. The participants are + identified to each other by the central server, and the participants + do not have access to each others' credentials such as email + addresses or login IDs. + + Note: This use case adds requirements on support for fast stream + switches (F16). There exist several solutions that enable the server + to forward one high-resolution and several low-resolution video + + + +Holmberg, et al. Informational [Page 18] + +RFC 7478 WebRTC March 2015 + + + streams: a) each browser could send a high-resolution, but scalable + stream, and the server could send just the base layer for the low- + resolution streams, b) each browser could in a simulcast fashion send + one high-resolution and one low-resolution stream, and the server + just selects, or c) each browser sends just a high-resolution stream, + the server transcodes into low-resolution streams as required. + +2.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 audio and video streams. + ---------------------------------------------------------------- + +3. Requirements Summary + +3.1. General + + This section contains the requirements on the browser derived from + the use cases in Section 2. + + Note: It is assumed that the user applications are executed on a + browser. Whether the capabilities to implement specific browser + requirements are implemented by the browser application, or are + provided to the browser application by the underlying operating + system, is outside the scope of this document. + +3.2. Browser Requirements + + ---------------------------------------------------------------- + Common, basic requirements + ---------------------------------------------------------------- + REQ-ID DESCRIPTION + ---------------------------------------------------------------- + F1 The browser must be able to use microphones and + cameras as input devices to generate streams. + ---------------------------------------------------------------- + F2 The browser must be able to send streams and + data to a peer in the presence of NATs. + + + + + + + +Holmberg, et al. Informational [Page 19] + +RFC 7478 WebRTC March 2015 + + + ---------------------------------------------------------------- + F3 Transmitted streams and data must be rate + controlled (meaning that the browser must, regardless + of application behavior, reduce send rate when + there is congestion). + ---------------------------------------------------------------- + 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. + ---------------------------------------------------------------- + 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 + ---------------------------------------------------------------- + F10 The browser must support a baseline audio and + video codec. + ---------------------------------------------------------------- + F11 It must be possible to protect streams and data + 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. + + + + + + + + + + +Holmberg, et al. Informational [Page 20] + +RFC 7478 WebRTC March 2015 + + + ---------------------------------------------------------------- + F13 The browser must encrypt, authenticate, and + integrity protect media and data on a + per-IP-packet basis, and it 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, + related to the transport of audio and video + between peers, needed to estimate quality of + experience. + ---------------------------------------------------------------- + Requirements related to network and topology + ---------------------------------------------------------------- + REQ-ID DESCRIPTION + ---------------------------------------------------------------- + F16 The browser must support insertion of reference frames + in outgoing media streams when requested by a peer. + ---------------------------------------------------------------- + F17 The communication session must survive across a + change of the network interface used by the + session. + ---------------------------------------------------------------- + F18 The browser must be able to send streams and + data to a peer in the presence of NATs and + firewalls that block UDP traffic. + ---------------------------------------------------------------- + F19 The browser must be able to use several STUN + and TURN servers. + ---------------------------------------------------------------- + F20 The browser must support the use of STUN and TURN + 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 + allow traffic via an HTTP Proxy, when firewall policy + allows WebRTC traffic. + + + + + + +Holmberg, et al. Informational [Page 21] + +RFC 7478 WebRTC March 2015 + + + ---------------------------------------------------------------- + F22 The browser should be able to take advantage + of available capabilities (supplied by network + 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 + data from multiple peers concurrently. + ---------------------------------------------------------------- + F25 The browser must be able to render several + 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. + ---------------------------------------------------------------- + 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. + ---------------------------------------------------------------- + F30 The browser must be able to process and mix + sound objects (media that is retrieved from + another source than the established media + stream(s) with the peer(s) with audio streams). + ---------------------------------------------------------------- + Requirements related to legacy interop + ---------------------------------------------------------------- + REQ-ID DESCRIPTION + ---------------------------------------------------------------- + F31 The browser must support an audio media format + (codec) that is commonly supported by existing + telephony services. + + + + +Holmberg, et al. Informational [Page 22] + +RFC 7478 WebRTC March 2015 + + + ---------------------------------------------------------------- + F32 There should be a way to navigate + a dual-tone multi-frequency signaling (DTMF) + based Interactive Voice Response (IVR) system. + ---------------------------------------------------------------- + F33 The browser must be able to initiate and + accept a media session where the data needed + for establishment can be carried in SIP. + ---------------------------------------------------------------- + Other requirements + ---------------------------------------------------------------- + REQ-ID DESCRIPTION + ---------------------------------------------------------------- + F34 The browser must be able to send short + latency unreliable datagram traffic to a + peer browser [RFC5405]. + ---------------------------------------------------------------- + F35 The browser must be able to send reliable + data traffic to a peer browser. + ---------------------------------------------------------------- + F36 The browser must be able to generate streams + using the entire user display, a specific area + of the user display or the information being + displayed by a specific application. + ---------------------------------------------------------------- + +4. Security Considerations + +4.1. Introduction + + A malicious web application might use the browser to perform Denial- + of-Service (DoS) attacks on NAT infrastructure, or on peer devices. + For example, a malicious web application might leak TURN credentials + to unauthorized parties, allowing them to consume the TURN server's + bandwidth. To address this risk, web applications should be prepared + to revoke TURN credentials and issue new ones. Also, a malicious web + application might silently establish outgoing, and accept incoming, + streams on an already established connection. + + Based on the identified security risks, this section will describe + security considerations for the browser and web application. + + + + + + + + + + +Holmberg, et al. Informational [Page 23] + +RFC 7478 WebRTC March 2015 + + +4.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 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 must provide mechanisms for users to revise and even + completely revoke consent to use the screen, part thereof, or an + application 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 allow 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 + handshake procedures with the remote peer have been successfully + finished. + + The browser needs to ensure that the stream negotiation procedures + are not seen as DoS by other entities. + +4.3. Web Application Considerations + + The web application is expected to ensure user consent in sending and + receiving media streams. + + + + + + + + +Holmberg, et al. Informational [Page 24] + +RFC 7478 WebRTC March 2015 + + +5. Normative References + + [RFC2804] IAB and , "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., Ed., 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, + . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Holmberg, et al. Informational [Page 25] + +RFC 7478 WebRTC March 2015 + + +Appendix A. API Requirements + + This section contains the requirements on the API derived from the + use cases in Section 2. + + Note: As the 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 + 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). + ---------------------------------------------------------------- + A4 The web API must provide means for the web + application to initiate the sending of a + stream / stream components to a peer. + ---------------------------------------------------------------- + A5 The web API must provide means for the web + application to control the media format (codec) + to be used for the streams sent to a peer. + + Note: The level of control depends on whether + the codec negotiation is handled by the browser + or the web application. + ---------------------------------------------------------------- + A6 The web API must provide means for the web + application to modify the media format for + streams sent to a peer after a media stream + has been established. + ---------------------------------------------------------------- + A7 The web API must provide means for + informing the web application of whether or not + the establishment of a stream with a peer was + successful. + + + + + + +Holmberg, et al. Informational [Page 26] + +RFC 7478 WebRTC March 2015 + + + ---------------------------------------------------------------- + A8 The web API must provide means for the web + application to mute/unmute a stream or stream + component(s). When a stream is sent to a peer, + mute status must be preserved in the stream + received by the peer. + ---------------------------------------------------------------- + A9 The web API must provide means for the web + application to cease the sending of a stream + to a peer. + ---------------------------------------------------------------- + A10 The web API must provide means for the web + application to cease the processing and rendering + of a stream received from a peer. + ---------------------------------------------------------------- + A11 The web API must provide means for + informing the web application when a + stream from a peer is no longer received. + ---------------------------------------------------------------- + A12 The web API must provide means for + informing the web application when high + loss rates occur. + ---------------------------------------------------------------- + A13 The web API must provide means for the web + application to apply spatialization effects to + audio streams. + ---------------------------------------------------------------- + A14 The web API must provide means for the web + application to detect the level in audio + streams. + ---------------------------------------------------------------- + A15 The web API must provide means for the web + application to adjust the level in audio + streams. + ---------------------------------------------------------------- + A16 The web API must provide means for the web + application to mix audio streams. + ---------------------------------------------------------------- + A17 The web API must provide a way to identify + streams such that an application is able to + match streams on a sending peer with the same + stream on all receiving peers. + ---------------------------------------------------------------- + A18 The web API must provide a mechanism for sending + and receiving isolated discrete chunks of data. + + + + + + +Holmberg, et al. Informational [Page 27] + +RFC 7478 WebRTC March 2015 + + + ---------------------------------------------------------------- + A19 The web API must provide means for the web + application to indicate the type of audio signal + (speech, audio) for audio stream(s) / stream + component(s). + ---------------------------------------------------------------- + A20 It must be possible for an initiator or a + responder web application to indicate the types + of media it is willing to accept incoming + streams for when setting up a connection (audio, + video, other). The types of media to be accepted + 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 use the screen, a certain area on the screen, + or what a certain application displays on the + screen as input to streams. + ---------------------------------------------------------------- + A22 The web API must provide means for the + application to specify several STUN and/or + TURN servers to use. + ---------------------------------------------------------------- + A23 The web API must provide means for the + application to specify the priority to + apply for outgoing streams and data. + ---------------------------------------------------------------- + A24 The web API must provide a mechanism for sending + and receiving files. + ---------------------------------------------------------------- + A25 It must be possible for the application to + instruct the browser to refrain from exposing + the host IP address to the application. + ---------------------------------------------------------------- + A26 The web API must provide means for the + application to obtain the statistics (related + to transport, and collected by the browser) + needed to estimate the quality of service. + ---------------------------------------------------------------- + + + + + + + + + + + +Holmberg, et al. Informational [Page 28] + +RFC 7478 WebRTC March 2015 + + +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. 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. + +Authors' Addresses + + Christer Holmberg + Ericsson + Hirsalantie 11 + Jorvas 02420 + Finland + + EMail: christer.holmberg@ericsson.com + + + Stefan Hakansson + Ericsson + Laboratoriegrand 11 + Lulea 97128 + Sweden + + EMail: stefan.lk.hakansson@ericsson.com + + + Goran AP Eriksson + Ericsson + Farogatan 6 + Stockholm 16480 + Sweden + + EMail: goran.ap.eriksson@ericsson.com + + + + + + + + + + + +Holmberg, et al. Informational [Page 29] + -- cgit v1.2.3