Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 7478 S. Hakansson
Category: Informational G. Eriksson
ISSN: 2070-1721 Ericsson
March 2015
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
Web实时通信用例和需求
Abstract
摘要
This document describes web-based real-time communication use cases. Requirements on the browser functionality are derived from the use cases.
本文档描述了基于web的实时通信用例。浏览器功能的需求源自用例。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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)).
本文档介绍了在浏览器中执行并使用实时通信功能的web应用程序的一些用例。在大多数用例中，所有最终用户客户端都是web应用程序，但是在一些用例中，至少一个最终用户客户端是另一种类型（例如，移动电话或SIP用户代理（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.
基于用例，文档导出与浏览器功能相关的需求。这些需求被命名为“Fn”，其中n是一个整数，并与用例一起列出。第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.
本文档还列出了与web应用程序使用的API相关的要求，作为附录。原因是W3C WebRTC工作组决定不开发自己的用例或需求文档，而是使用此文档。这些要求被命名为“An”，其中n是一个整数，并在附录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.
本文件是在工作的初始阶段编制的，在后期进行了较小的更新。到目前为止，它还没有真正成为确定工作组工作的特性或范围的工具。该报告正在出版，以记录工作组的早期结论。它不会被用作一套严格的指导原则，规范和实现将在未来得到遵守。
This section describes web-based real-time communication use cases, from which requirements are derived.
本节描述基于web的实时通信用例，从中派生需求。
The following considerations are applicable to all use cases:
以下注意事项适用于所有用例：
o Clients can be on IPv4-only
o 客户端只能在IPv4上
o Clients can be on IPv6-only
o 客户端只能在IPv6上
o Clients can be on dual-stack
o 客户端可以位于双堆栈上
o Clients can be connected to networks with different throughput capabilities
o 客户端可以连接到具有不同吞吐量能力的网络
o Clients can be on variable-media-quality networks (wireless)
o 客户端可以位于可变媒体质量网络（无线）上
o Clients can be on congested networks
o 客户端可能位于拥挤的网络上
o Clients can be on firewalled networks with no UDP allowed
o 客户端可以位于不允许UDP的防火墙网络上
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).
o 客户端可以位于具有NAT或IPv4-IPv6转换设备的网络上，这些设备使用任何类型的映射和过滤行为（如RFC 4787中所述）。
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.1节）检索到的需求适用于所有其他用例，并被认为是通用的。对于每个用例，只列出附加要求。
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.
两个或多个用户已将视频通信web应用程序加载到同一服务提供商提供的浏览器中，并登录到其提供的服务。web服务通过在浏览器中向web应用程序推送更新来发布有关用户登录状态的信息。当一个在线用户选择一个对等在线用户时，两个对等浏览器之间的1:1视听通信会话将启动。受邀请的用户可以接受或拒绝会话。
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 选择可根据需要删除并重新插入自视图，
o change the sizes of his/her two video displays during the session, and
o 在会话期间更改他/她的两个视频显示的大小，以及
o pause the sending of media (audio, video, or both) and mute incoming media.
o 暂停媒体（音频、视频或两者）的发送，并将传入的媒体静音。
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.
媒体和数据必须在每个IP数据包的基础上进行加密、身份验证和完整性保护，并且未通过完整性检查的媒体和数据包不得交付给应用程序。
The application gives the users the opportunity to stop it from exposing the host IP address to the application of the other user.
应用程序为用户提供了阻止其向其他用户的应用程序公开主机IP地址的机会。
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.
web服务监控最终用户体验的服务质量（关注音频和视频质量）。
----------------------------------------------------------------
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.
----------------------------------------------------------------
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.
----------------------------------------------------------------
----------------------------------------------------------------
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
A1、A2、A3、A4、A5、A6、A7、A8、A9、A10、A11、A12、A25、A26
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.1节）。区别在于其中一个用户位于阻止UDP通信的NAT/防火墙后面。
----------------------------------------------------------------
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.
----------------------------------------------------------------
----------------------------------------------------------------
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. 简单视频通信服务：仅允许通过HTTP代理进行通信的防火墙
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.1节）。区别在于其中一个用户位于防火墙后面，防火墙只允许通过HTTP代理进行通信。
----------------------------------------------------------------
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.
----------------------------------------------------------------
----------------------------------------------------------------
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.
----------------------------------------------------------------
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).
该用例几乎与简单视频通信服务用例相同（第2.3.1节）。还需要补充的是，服务提供商在大的地理区域（甚至是全球）开展业务。
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.
假设将使用交互式连接建立（ICE）机制[RFC5245]，这意味着服务提供商希望能够为NAT（STUN）提供多个会话遍历实用程序，并使用中继NAT（TURN）服务器（通过应用程序）向浏览器进行遍历；选择使用哪一个是冰处理的一部分。希望提供多个STUN和TURN服务器的其他原因包括对IPv4和IPv6的支持、负载平衡和冗余。
Note that ICE support being mandatory does not preclude a WebRTC endpoint from supporting more traversal mechanisms than ICE using STUN and TURN.
注意，强制ICE支持并不排除WebRTC端点支持比使用STUN和TURN的ICE更多的遍历机制。
----------------------------------------------------------------
REQ-ID DESCRIPTION
----------------------------------------------------------------
F19 The browser must be able to use several STUN
and TURN servers.
----------------------------------------------------------------
----------------------------------------------------------------
REQ-ID DESCRIPTION
----------------------------------------------------------------
F19 The browser must be able to use several STUN
and TURN servers.
----------------------------------------------------------------
A22
A22
This use case is similar to the Simple Video Communication Service use case (Section 2.3.1).
该用例类似于简单视频通信服务用例（第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.
增加的是在企业中使用服务时的方面。在本用例的进一步描述中假设了ICE。
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.
使用基于WebRTC的web应用程序进行通信的企业希望审核从公司内部到任何外部对等方使用的所有基于WebRTC的应用程序会话。为了做到这一点，他们部署了一个TURN服务器，它跨越了内部网络和外部网络之间的边界。
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
防火墙将阻止在外部目标上使用STUN的所有尝试，除非它们转到企业服务器。在员工使用外部服务提供商提供的WebRTC应用程序的情况下，他们仍然希望流量留在其内部网络内，并且不加载跨接转弯服务器；因此，他们部署了一个STUN服务器，允许WebRTC客户端在内部确定其服务器自反地址。因此，在对等点都位于内部的情况下，可以进行连接
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.
没有离开内部网络的流量。必须能够使用特定于网络的STUN和TURN服务器配置企业中使用的浏览器。这应该可以通过自动配置方法实现。WebRTC功能将需要利用网络特定的STUN和TURN资源以及web应用程序提供的STUN和TURN服务器。
----------------------------------------------------------------
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).
----------------------------------------------------------------
----------------------------------------------------------------
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).
----------------------------------------------------------------
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.
该用例几乎与简单视频通信服务用例相同（第2.3.1节）。不同之处在于，用户在会话期间更改网络访问。
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.
其中一个用户使用的通信设备具有多个网络适配器（以太网、Wi-Fi、蜂窝）。通信设备使用以太网访问互联网，但用户必须在会话期间开始一次旅行。当移除以太网电缆时，通信设备会自动更改为使用Wi-Fi，然后在移出Wi-Fi覆盖范围时，移动到互联网的蜂窝接入。即使访问方法更改，会话仍将继续。
----------------------------------------------------------------
REQ-ID DESCRIPTION
----------------------------------------------------------------
F17 The communication session must survive across a
change of the network interface used by the
session.
----------------------------------------------------------------
----------------------------------------------------------------
REQ-ID DESCRIPTION
----------------------------------------------------------------
F17 The communication session must survive across a
change of the network interface used by the
session.
----------------------------------------------------------------
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:
此用例与简单视频通信服务：访问更改用例（第2.3.6节）几乎相同。增加了服务质量（QoS）功能的使用：
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.
前一个用例中开始旅行的用户位于支持流量差异化的普通住宅路由器后面。此外，用户的蜂窝接入提供商启用了QoS支持。当通过住宅路由器访问和使用蜂窝网络时，用户能够利用QoS支持。
----------------------------------------------------------------
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.
----------------------------------------------------------------
----------------------------------------------------------------
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.
----------------------------------------------------------------
This use case has the audio and video communication of the Simple Video Communication Service use case (Section 2.3.1).
该用例具有简单视频通信服务用例的音频和视频通信（第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.
但是，除此之外，其中一个用户还可以与对等用户共享其屏幕上显示的内容。用户可以选择与对等方共享整个屏幕、部分屏幕（用户选择的部分）或所选应用程序显示的内容。
----------------------------------------------------------------
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.
----------------------------------------------------------------
----------------------------------------------------------------
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
A21
This use case has the audio and video communication of the Simple Video Communication Service use case (Section 3.3.1).
该用例具有简单视频通信服务用例的音频和视频通信（第3.3.1节）。
However, in addition to this, the users can send and receive files stored in the file system of the device used.
但是，除此之外，用户还可以发送和接收存储在所用设备的文件系统中的文件。
----------------------------------------------------------------
REQ-ID DESCRIPTION
----------------------------------------------------------------
F35 The browser must be able to send reliable
data traffic to a peer browser.
----------------------------------------------------------------
----------------------------------------------------------------
REQ-ID DESCRIPTION
----------------------------------------------------------------
F35 The browser must be able to send reliable
data traffic to a peer browser.
----------------------------------------------------------------
A21, A24
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).
在比赛开始之前，以及比赛休息期间，天才球探和教练进行1:1的视听交流。在手机上，只使用面向天才球探的摄像头。在移动电话的用户显示屏上，俱乐部经理的视频显示为后向摄像头的画中画缩略图（自视）。在桌面显示器上，人才侦察员的视频显示为桌面摄像头的画中画缩略图（自我查看）。
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.
当游戏进行时，天才侦察员激活前向摄像头的使用，该流被发送到桌面（来自后向摄像头的流一直被发送）。手机前向摄像头（即拍摄游戏）捕获的视频流显示在桌面屏幕上的一个大窗口中，后向摄像头和桌面摄像头的画中画缩略图（自视图）。在手机显示屏上显示游戏（前向摄像头），并显示后向摄像头（自视图）和桌面摄像头的画中画缩略图。因为在这个阶段最重要的流是显示游戏的视频，所以天才球探手机中使用的应用程序为该流设置了更高的优先级。
----------------------------------------------------------------
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.
----------------------------------------------------------------
----------------------------------------------------------------
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
A17，A23
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.
在此用例中，简单视频通信服务用例（第2.3.1节）通过允许多方会话进行扩展。不涉及中央服务器——每个参与者的浏览器向所有其他会话参与者发送和接收流。每个用户浏览器中的web应用程序负责向所有接收器设置流。
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.
为了增强用户体验，web应用程序渲染来自不同参与者的音频，以便体验来自不同空间位置的音频。这是自动完成的，但用户可以更改不同参与者在（虚拟）房间中的放置方式。此外，音频信号中的电平在混音前进行调整。
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.
注意：本用例在需求方面增加的是同时向多个对等方发送流和从多个对等方接收流的能力，以及从所有接收流渲染视频的能力，以及能够在浏览器中本地对所有接收流的音频进行空间化、电平调整和混合的能力。它还增加了测量音频级别/活动的功能。
----------------------------------------------------------------
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.
----------------------------------------------------------------
----------------------------------------------------------------
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
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.
空间化和混合。例如，“其他声音对象”可以是带有油箱声音的文件；该文件可以存储在本地或远程。
----------------------------------------------------------------
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].
----------------------------------------------------------------
----------------------------------------------------------------
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
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.
移动电话运营商允许其客户使用web浏览器访问其服务。简单登录后，用户就可以像使用普通手机一样拨打和接听电话。当接到或拨打电话时，显示身份的方式与使用手机时相同。
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.
注意：“以与使用普通移动电话相同的方式拨打和接听电话”意味着您可以拨打电话号码，并且您的移动电话运营商已使您的电话联系人在线可用，以便您可以点击这些联系人拨打电话，并且可以使用这些联系人显示来电的身份。如果被叫人不在您的手机通讯录中，则会显示该号码。此外，您的通话记录可用，并根据从浏览器发出/收到的通话进行更新。对于通过网络浏览器接听电话的人，将显示常用身份（即移动电话的电话号码）。
----------------------------------------------------------------
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.
----------------------------------------------------------------
----------------------------------------------------------------
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.
----------------------------------------------------------------
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.
Alice使用web浏览器提供一项服务，允许她拨打公共交换电话网（PSTN）号码。爱丽丝打电话1-800-123-4567。Alice应该能够听到来自联邦快递互动语音应答器（IVR）的初始提示，当IVR说按1时，Alice应该有办法导航IVR。
----------------------------------------------------------------
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.
----------------------------------------------------------------
----------------------------------------------------------------
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.
----------------------------------------------------------------
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.
每个参与者的浏览器向中央服务器发送一个音频流（按单声道、立体声、5.1格式输入，具体取决于参与者的设备）。中央服务器混合音频流（并且可以在混合过程中自然地添加诸如空间化之类的效果），并向每个参与者发送向用户播放的混合音频流。
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.
所有参与者都经过中央服务器的身份验证，并有权连接到中央服务器。参与者由中央服务器相互标识，并且参与者无权访问彼此的凭据，例如电子邮件地址或登录ID。
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
注意：此用例增加了对支持快速流交换机（F16）的要求。有几种解决方案使服务器能够转发一个高分辨率和几个低分辨率视频
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.
流：a）每个浏览器可以发送高分辨率但可扩展的流，服务器可以只发送低分辨率流的基本层；b）每个浏览器可以以同步广播方式发送一个高分辨率和一个低分辨率流，服务器只选择；或c）每个浏览器只发送一个高分辨率流，服务器根据需要将代码转换为低分辨率流。
----------------------------------------------------------------
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.
----------------------------------------------------------------
----------------------------------------------------------------
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.
----------------------------------------------------------------
This section contains the requirements on the browser derived from the use cases in Section 2.
本节包含从第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.
注意：假定用户应用程序在浏览器上执行。实现特定浏览器要求的功能是由浏览器应用程序实现的，还是由底层操作系统提供给浏览器应用程序的，不在本文档的范围内。
----------------------------------------------------------------
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.
----------------------------------------------------------------
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.
----------------------------------------------------------------
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.
----------------------------------------------------------------
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.
----------------------------------------------------------------
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.
----------------------------------------------------------------
----------------------------------------------------------------
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.
----------------------------------------------------------------
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.
恶意web应用程序可能使用浏览器对NAT基础结构或对等设备执行拒绝服务（DoS）攻击。例如，恶意web应用程序可能会将TURN凭据泄漏给未经授权的方，从而允许他们使用TURN服务器的带宽。为了解决这个风险，web应用程序应该准备撤销TURN凭据并发布新凭据。此外，恶意web应用程序可能会在已建立的连接上静默地建立传出流，并接受传入流。
Based on the identified security risks, this section will describe security considerations for the browser and web application.
根据已识别的安全风险，本节将描述浏览器和web应用程序的安全注意事项。
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).
浏览器应提供允许用户验证接收到的流是否未被操纵的机制（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.
浏览器需要确保流协商过程不会被其他实体视为DoS。
The web application is expected to ensure user consent in sending and receiving media streams.
web应用程序应确保用户同意发送和接收媒体流。
[RFC2804] IAB and , "IETF Policy on Wiretapping", RFC 2804, May 2000, <http://www.rfc-editor.org/info/rfc2804>.
[RFC2804]IAB和“IETF窃听政策”，RFC28042000年5月<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>.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月<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>.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月<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>.
[RFC5479]Wing，D.，Ed.，Fries，S.，Tschofenig，H.，和F.Audet，“媒体安全管理协议的要求和分析”，RFC 5479，2009年4月<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>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
This section contains the requirements on the API derived from the use cases in Section 2.
本节包含从第2节中的用例派生的API要求。
Note: As the W3C is responsible for the API, the API requirements in this specification are not normative.
注：由于W3C负责API，本规范中的API要求不是规范性的。
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.
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.
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.
----------------------------------------------------------------
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.
----------------------------------------------------------------
----------------------------------------------------------------
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.
作者希望感谢伯纳德·阿博巴、古纳尔·赫尔斯特伦、马丁·汤姆森、拉尔斯·艾格特、马修·考夫曼、埃米尔·伊沃夫、埃里克·雷斯科拉、埃里克·伯格、约翰·莱斯利、丹·温、理查德·巴恩斯、巴里·丁格尔、戴尔·沃利、泰德·哈迪、玛丽·巴恩斯、丹·伯内特、斯蒂芬·温格、哈拉尔德·阿尔维斯特兰、卡伦·詹宁斯、，Andrew Hutton和RTCWEB社区中对该文件提供评论、反馈、文本和改进建议的所有人。非常感谢作为IESG评估一部分提供意见的所有人，以及为改进文件而提供意见和投入的所有其他人。
Authors' Addresses
作者地址
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: christer.holmberg@ericsson.com
EMail: christer.holmberg@ericsson.com
Stefan Hakansson Ericsson Laboratoriegrand 11 Lulea 97128 Sweden
Stefan Hakanson爱立信实验室和11 Lulea 97128瑞典
EMail: stefan.lk.hakansson@ericsson.com
EMail: stefan.lk.hakansson@ericsson.com
Goran AP Eriksson Ericsson Farogatan 6 Stockholm 16480 Sweden
Goran AP Erikson Ericsson Farogatan 6斯德哥尔摩16480瑞典
EMail: goran.ap.eriksson@ericsson.com
EMail: goran.ap.eriksson@ericsson.com