RFC 7478
Web Real-Time Communication Use Cases and Requirements
Web Real-Time Communication Use Cases and Requirements ✨
Okay bestie, this one is the RFC that lays out the web-based real-time communication use cases 🎀. It's RFC 7478, titled "Web Real-Time Communication Use Cases and Requirements". The authors are C. Holmberg, S. Hakansson, and G. Eriksson, all from Ericsson 💅. It's Informational, not Standards Track, with ISSN 2070-1721, and it was published in March 2015 🦋. The title block has no Obsoletes or Updates entries, so this doc doesn't replace or change any other RFC 🌸.
Abstract
Here's the tea: this doc describes web-based real-time communication use cases, and the browser functionality requirements come from those use cases 💖.
It was written in an early phase of the work with pretty minor updates later on. It hasn't really been a tool for deciding features or scope for the WG's efforts so far 🙈. It's being published to record the WG's early conclusions. It is not going to be used as a set of rigid guidelines that specifications and implementations get held to in the future 💜.
Status of This Memo
This doc is not an Internet Standards Track specification. It's published for informational purposes 🧚.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the details 🤓.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7478 🔗.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date this doc was published. Please read these carefully, because they describe your rights and restrictions with respect to this document 📜. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💅.
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 ................................................291. Introduction 🎀
This doc shows off a few use cases of web apps that run in a browser and use real-time communication capabilities 🌸. In most of these use cases, every end-user client is a web app. But in some, at least one end-user client is a different type of thing, like a mobile phone or a SIP User Agent (UA) 📱.
Based on these use cases, the doc derives requirements about browser functionality. Each requirement is named "Fn", where n is an integer, and they're listed alongside the use cases they come from. You'll find a summary in Section 3.2 ✨.
This doc was also developed in an early phase with pretty minor updates later. It hasn't really served as a tool for deciding features or scope for the WG's efforts so far 🙈. It's proposed to be used in a later phase to evaluate the protocols and solutions the WG develops 💅.
The doc also lists the API requirements that web apps use, as an appendix 🧚. The reason is that the W3C WebRTC WG decided not to make its own use-case or requirement doc and will use this one instead 🫶. These requirements are named "An", where n is an integer, and they're described in Appendix A 💖.
Again, this doc was developed in an early phase with rather minor updates at later stages. It hasn't really served as a tool for deciding features or scope for the WG's efforts so far. It's being published to record the WG's early conclusions. 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 the web-based real-time communication use cases that the requirements come from 💜.
These considerations apply to all the 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) 🧚
2.2. Common Requirements 🎀
The requirements pulled from the Simple Video Communication Service use case (Section 2.3.1) apply to every other use case by default, so they're considered common 💖. For each use case, only the additional requirements get listed 🫶.
2.3. Browser-to-Browser Use Cases 👑
2.3.1. Simple Video Communication Service ✨
2.3.1.1. Description 💬
Okay so, two or more users load a video communication web app into their browsers. It's provided by the same service provider, and they're logged into the service it gives them 🌸. The web service pushes updates about user login status to the web app in the browsers, so everyone's status is always up to date 📲. When one online user picks a peer who's also online, a 1:1 audiovisual communication session starts between the two peers' browsers 🎥. The invited user can accept or reject the session 🙈.
During session setup, a self view shows up. Once the session is established, the video coming from the remote peer shows up too, next to the self view 🪞. During the session, each user can:
- select to remove and reinsert the self-view as often as they want 💅,
- change the sizes of their two video displays during the session, and 📐
- pause the sending of media (audio, video, or both) and mute incoming media 🔇.
Lowkey the most important part: media and data have to be encrypted, authenticated, and integrity protected on a per-IP-packet basis. Media and data packets that fail the integrity check must not be delivered to the application 🔐. That's a whole vibe, fr fr 😭.
The application lets the users stop it from exposing their host IP address to the other user's application 🙈. Bestie, that's a privacy win 💜.
Any session participant can end the session at any time 🧚.
The two users might be on communication devices with different operating systems and browsers from different vendors 🌈.
Last thing: the web service monitors the quality of the service (focusing on the quality of audio and video) that the end users experience 📊. It's giving main character energy 👑✨.
2.3.1.2. Common Requirements 🎀
okay bestie, this is the big checklist for the basic video call. every single one of these is a "the browser has to do this" kind of thing, so let's go 💅
----------------------------------------------------------------
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.
----------------------------------------------------------------
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, A262.3.2. Simple Video Communication Service: NAT/Firewall That Blocks UDP ✨
2.3.2.1. Description 🦋
this one is basically the same vibe as the simple video call (Section 2.3.1) 💖 the twist is that one of the users is stuck 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 💜
again, almost identical to the simple video call (Section 2.3.1) 🫶 the difference: 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 is almost identical to the simple video call (Section 2.3.1) ✨ what's added is that the service provider is operating over large geographical areas (or even globally) 🔥
assuming the Interactive Connectivity Establishment (ICE) mechanism [RFC5245] will be used, 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 🫶 picking which one(s) to use is part of the ICE processing. other reasons to want 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 call (Section 2.3.1) 🎀
what's added is the aspects of 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 wants to audit all WebRTC-based application sessions used from inside the company towards any external peer 🕵️ 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 🚫 when employees use WebRTC applications from an external service provider, the company still wants the traffic to stay inside their internal network and not load the straddling TURN server 🙅♀️ so they deploy a STUN server that lets the WebRTC client work out its server reflexive address on the internal side ✨ this also enables cases where both peers are 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 achievable with autoconfiguration methods 🌸 the WebRTC functionality will need to use both network specific STUN and TURN resources and the 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 is almost identical to the simple video call (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) 🔌 it's accessing the Internet over Ethernet, but the user has to start a trip during the session ✈️ the device automatically switches to Wi-Fi when the Ethernet cable is removed, then moves to cellular access when it leaves Wi-Fi coverage 📶 the session keeps going 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.
----------------------------------------------------------------2.3.7. Simple Video Communication Service: QoS ⭐
2.3.7.1. Description 🎀
this is almost identical to the Simple Video Communication Service: Access Change use case (Section 2.3.6) 💅 QoS (Quality of Service) capabilities are added:
the user from the previous use case who starts a trip is behind a common residential router that supports differentiation of traffic 🏠 plus, the user's cellular provider has QoS support enabled 📡 the user can take advantage of QoS 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 ✨
Okay so this use case starts with the exact same audio and video chat as the Simple Video Communication Service use case (Section 2.3.1) 📞🎀
But wait, there's more! 💅 One of the users can also share whatever is on her or his screen with a peer. She can share the entire screen, just a part of the screen she picks herself, or what one selected app is showing. Main character energy 🦋
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 💖
Same deal here: this use case gets all the audio and video vibes of the Simple Video Communication Service use case (Section 3.3.1) 🎧📹
Then it adds the file swap 🫶 Both users can send and receive files stored on the file system of the device they're using. Iconic. ✨
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 🧚
Okay this one is so fun. 🥹 An ice-hockey club has an app that lets talent scouts show and talk about games and players with the club manager, in real-time. The scouts are on a mobile phone with two cameras, one front-facing and one rear-facing 📱✨
The club manager is on a desktop with one camera 💻 and watches the game while chatting with the scout.
Before the game starts and during breaks, the scout and the manager have a 1:1 audiovisual call 🎀 On the phone, only the camera facing the scout is used. The phone screen shows the manager's video with a picture-in-picture thumbnail of the rear-facing camera (self view). On the desktop, the scout's video is shown with a picture-in-picture thumbnail of the desktop camera (self view). Cute and cozy 🌷
Now, when the game is actually happening, the scout turns on the front-facing camera, and that stream gets sent to the desktop. The rear-facing camera stream keeps going the whole time 💜 The front-camera video of the game shows up big on the desktop, with picture-in-picture thumbnails of the rear-facing camera and the desktop camera (self view). On the phone, the game is shown from the front-facing camera, with thumbnails of the rear-facing camera (self view) and the desktop camera 🏒🔥
Since the game is the star of the show in this phase, the app on the scout's phone gives that stream higher priority ⭐ Obsessed.
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
2.3.11. Multiparty Video Communication 👑
2.3.11.1. Description 🌈
This use case takes the Simple Video Communication Service use case (Section 2.3.1) and levels it up with multiparty sessions 🎉 There's no central server involved. Each person's browser sends and receives streams to and from every other participant directly. The web app in each user's browser handles setting up streams to all the receivers 💅
To make it feel more immersive, the web app places the audio from each person so it sounds like it's coming from a different spot in space 🧚 This happens automatically, but users can rearrange where everyone sits in the (virtual) room. The audio levels also get adjusted before everything is mixed 🎧
Another nice touch is that the video window of whoever is currently speaking gets highlighted ✨
Each incoming video shows up as a little thumbnail in the browser by default, but users can make it bigger or smaller 🍓
Note: What this use case adds, requirement-wise, is the ability to send streams to and receive streams from several peers at once. It also means rendering video from all the received streams, and being able to spatialize, level adjust, and mix the audio from all the received streams locally in the browser. It also adds the ability to measure the audio level and activity 🫶
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 one builds on the last one 🫶 Here, the voice part of the multiparty video call is used inside an online game. The incoming voice audio gets rendered together with game sound objects. For example, if a tank rolls from left to right across the screen, its sound has to be rendered and played to the user alongside the voices 🎧💥
Game state updates need to be quick, and they get higher priority than the voice 🏃♀️💨
Note: The local audio processing differs from the "Multiparty Video Communication" use case in one way: other sound objects, not just the streams, have to be possible to include in the spatialization and mixing. For example, the "other sound object" could be a file with the tank sound. 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
2.4. Browser - GW/Server Use Cases 🌐
2.4.1. Telephony Terminal 📱
2.4.1.1. Description 💕
A mobile phone company lets its customers use a web browser to reach their services 💻 After a quick log in, you can place and receive calls just like you would on a regular mobile phone. When a call comes in or goes out, the identity shows up the same way it does on a phone 📲
Note: "place and receive calls in the same way as when using a normal mobile phone" means you can dial a number, and your mobile operator has made your phone contacts available online. They can be clicked to call, and they can be used to show who's calling. If the person isn't in your contacts, the number is shown instead 🙈 Your call logs are also available online and get updated with calls made or received from the browser. For people receiving calls from the web browser, the usual identity (the phone number of the mobile phone) is 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 💅
okay so Alice is using her web browser with a service that lets her call PSTN numbers (aka the regular phone network, bestie 📱). She dials 1-800-123-4567. Alice should be able to hear the first prompts from the FedEx Interactive Voice Responder (IVR) 👂, and when the IVR says press 1, there should be a way for her to actually navigate the menu. literally the whole vibe is "can I get through this call without rage-quitting" 😭🫶
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 ✨
okay this one is giving big org energy 🏢💖. An organization uses a video communication system that supports multiparty video sessions through a central conference server. Main character energy for the server, fr 👑
Each participant's browser sends an audio stream to the central server. The stream type can be mono, stereo, or 5.1, depending on what equipment the participant has 🎧. The central server mixes those audio streams together (and while mixing, it can naturally add effects like spatialization 🔥), then sends each participant a mixed audio stream to play for the user.
Each participant's browser also sends video to the server. For each participant, one high-resolution video shows up in a big window, while a bunch of low-resolution videos sit in smaller windows like little thumbnails 🦋. The server picks which video streams become the main and thumbnail videos based on who is talking. Because the streams can switch pretty often as the convo flows, it is important that the delay between a stream being selected for display and it actually showing up is short. no lag, no drama 💅
All participants are authenticated by the central server and authorized to connect to it. The participants are identified to each other by the central server, but they do not get access to each other's credentials, like 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, and 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 is where we round up the requirements the browser needs, all derived from the use cases in Section 2. iykyk 🫶
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 ✨
okay so this is the big checklist for what the browser itself has to be able to do, bestie 💖 I've split it into groups, and every row has a REQ-ID so we can point at it later 🎀 Heads up, the BCP 14 key words are in here doing real work, so I kept every single one exactly where it lives 🫶
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.
----------------------------------------------------------------
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.
----------------------------------------------------------------
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.
----------------------------------------------------------------
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.
----------------------------------------------------------------
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 💀
okay this is where things get SERIOUS bestie 😭 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. 🛡️
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. 🚫 users get the final say, bestie!
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. 💌 no sneaky streams showing up uninvited
The browser is expected to provide mechanisms that allow the users to verify that the streams received have not be manipulated (F12). 🕵️♀️ like checking the receipts before you pay
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. 🤝 no awkward media before the handshake is done, ngl
The browser needs to ensure that the stream negotiation procedures are not seen as DoS by other entities. 🛡️ nobody should think your negotiation is a DoS attack, periodt
4.3. Web Application Considerations 💻
The web application is expected to ensure user consent in sending and receiving media streams. 💖 the app has to respect consent on both ends, iykyk
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>.
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. 💅 these ones are the W3C's call, not ours
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.
----------------------------------------------------------------
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.
----------------------------------------------------------------
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.
----------------------------------------------------------------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. 🫶 the whole RTCWEB community is iconic
Authors' Addresses 🦋
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: christer.holmberg@ericsson.comStefan Hakansson
Ericsson
Laboratoriegrand 11
Lulea 97128
Sweden
EMail: stefan.lk.hakansson@ericsson.comGoran AP Eriksson
Ericsson
Farogatan 6
Stockholm 16480
Sweden
EMail: goran.ap.eriksson@ericsson.com📦 where this page comes from
- ietf: rfc7478 2015-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms