doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

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, <http://www.rfc-editor.org/info/rfc2804>.
+
+   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
+              (ICE): A Protocol for Network Address Translator (NAT)
+              Traversal for Offer/Answer Protocols", RFC 5245, April
+              2010, <http://www.rfc-editor.org/info/rfc5245>.
+
+   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
+              for Application Designers", BCP 145, RFC 5405, November
+              2008, <http://www.rfc-editor.org/info/rfc5405>.
+
+   [RFC5479]  Wing, D., Ed., Fries, S., Tschofenig, H., and F. Audet,
+              "Requirements and Analysis of Media Security Management
+              Protocols", RFC 5479, April 2009,
+              <http://www.rfc-editor.org/info/rfc5479>.
+
+   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
+              Attack", BCP 188, RFC 7258, May 2014,
+              <http://www.rfc-editor.org/info/rfc7258>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+