Web Real-Time Communication Use Cases and Requirements

This section describes web-based real-time communication use cases, from which requirements are derived. The following considerations are applicable to all use cases: Clients can be on IPv4-only Clients can be on IPv6-only Clients can be on dual-stack Clients can be connected to networks with different throughput capabilities Clients can be on variable-media-quality networks (wireless) Clients can be on congested networks Clients can be on firewalled networks with no UDP allowed 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).

The requirements retrieved from the use case () by default apply to all other use cases and are considered common. For each use case, only the additional requirements are listed.

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: select to remove and reinsert the self-view as often as desired, change the sizes of his/her two video displays during the session, and pause the sending of media (audio, video, or both) and mute incoming media. It is essential that media and data be encrypted, authenticated, and integrity protected on a per-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.

A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A25, A26

This use case is almost identical to the use case (). The difference is that one of the users is behind a NAT/firewall that blocks UDP traffic.

This use case is almost identical to the use case (). The difference is that one of the users is behind a firewall that only allows traffic via an HTTP Proxy.

This use case is almost identical to the use case (). What is added is that the service provider is operating over large geographical areas (or even globally). Assuming that the Interactive Connectivity Establishment (ICE) mechanism 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.

A22

This use case is similar to the use case (). 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 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.

This use case is almost identical to the use case (). 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.

This use case is almost identical to the use case (). 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.

This use case has the audio and video communication of the use case (). 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.

A21

This use case has the audio and video communication of the use case (). However, in addition to this, the users can send and receive files stored in the file system of the device used.

A21, A24

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. 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.

A17, A23

In this use case, the use case () 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.

A13, A14, A15, A16

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 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.

A13, A14, A15, A16, A17, A18, A23

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.

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.

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 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.