Internet Engineering Task Force (IETF) J. Ott
Request for Comments: 5760 Aalto University
Category: Standards Track J. Chesterfield
ISSN: 2070-1721 University of Cambridge
E. Schooler
Intel
February 2010
Internet Engineering Task Force (IETF) J. Ott
Request for Comments: 5760 Aalto University
Category: Standards Track J. Chesterfield
ISSN: 2070-1721 University of Cambridge
E. Schooler
Intel
February 2010
RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback
具有单播反馈的单源多播会话的RTP控制协议（RTCP）扩展
Abstract
摘要
This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism.
本文档指定了实时传输控制协议（RTCP）的扩展，以使用对多播发送方的单播反馈。所提出的扩展适用于单源多播会话，例如源特定多播（SSM）通信，其中传统的多对多组通信模型不可用或不需要。此外，它可以应用于任何可能受益于发件人控制的汇总报告机制的组。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc5760.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5760.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions and Acronyms ........................................4
3. Definitions .....................................................5
4. Basic Operation .................................................6
5. Packet Types ...................................................10
6. Simple Feedback Model ..........................................11
7. Distribution Source Feedback Summary Model .....................13
8. Mixer/Translator Issues ........................................36
9. Transmission Interval Calculation ..............................37
10. SDP Extensions ................................................39
11. Security Considerations .......................................41
12. Backwards Compatibility .......................................51
13. IANA Considerations ...........................................51
14. References ....................................................53
Appendix A. Examples for Sender-Side Configurations ...............57
Appendix B. Distribution Report Processing at the Receiver ........60
1. Introduction ....................................................3
2. Conventions and Acronyms ........................................4
3. Definitions .....................................................5
4. Basic Operation .................................................6
5. Packet Types ...................................................10
6. Simple Feedback Model ..........................................11
7. Distribution Source Feedback Summary Model .....................13
8. Mixer/Translator Issues ........................................36
9. Transmission Interval Calculation ..............................37
10. SDP Extensions ................................................39
11. Security Considerations .......................................41
12. Backwards Compatibility .......................................51
13. IANA Considerations ...........................................51
14. References ....................................................53
Appendix A. Examples for Sender-Side Configurations ...............57
Appendix B. Distribution Report Processing at the Receiver ........60
The Real-time Transport Protocol (RTP) [1] provides a real-time transport mechanism suitable for unicast or multicast communication between multimedia applications. Typical uses of RTP are for real-time or near real-time group communication of audio and video data streams. An important component of the RTP protocol is the control channel, defined as the RTP Control Protocol (RTCP). RTCP involves the periodic transmission of control packets between group members, enabling group size estimation and the distribution and calculation of session-specific information such as packet loss and round-trip time to other hosts. An additional advantage of providing a control channel for a session is that a third-party session monitor can listen to the traffic to establish network conditions and to diagnose faults based on receiver locations.
实时传输协议（RTP）[1]提供了一种适用于多媒体应用程序之间单播或多播通信的实时传输机制。RTP的典型用途是用于音频和视频数据流的实时或近实时组通信。RTP协议的一个重要组成部分是控制通道，定义为RTP控制协议（RTCP）。RTCP涉及组成员之间控制数据包的定期传输，支持组大小估计以及特定于会话的信息（如数据包丢失和到其他主机的往返时间）的分布和计算。为会话提供控制信道的另一个优点是，第三方会话监视器可以监听通信量，以建立网络条件并基于接收器位置诊断故障。
RTP was designed to operate in either a unicast or multicast mode. In multicast mode, it assumes an Any Source Multicast (ASM) group model, where both one-to-many and many-to-many communication are supported via a common group address in the range 224.0.0.0 through 239.255.255.255. To enable Internet-wide multicast communication, intra-domain routing protocols (those that operate only within a single administrative domain, e.g., the Distance Vector Multicast Routing Protocol (DVMRP) [16] and Protocol Independent Multicast (PIM) [17][18]) are used in combination with inter-domain routing protocols (those that operate across administrative domain borders, e.g., Multicast BGP (MBGP) [19] and the Multicast Source Discovery Protocol (MSDP) [20]). Such routing protocols enable a host to join a single multicast group address and send data to or receive data from all members in the group with no prior knowledge of the membership. However, there is a great deal of complexity involved at the routing level to support such a multicast service in the network.
RTP设计为在单播或多播模式下运行。在多播模式下，它采用任意源多播（ASM）组模型，其中通过224.0.0.0到239.255.255.255范围内的公共组地址支持一对多和多对多通信。为了实现互联网范围的多播通信，域内路由协议（仅在单个管理域内运行的协议，例如距离向量多播路由协议（DVMRP）[16]和协议独立多播协议（PIM）[17][18]）与域间路由协议结合使用（跨管理域边界运行的，例如多播BGP（MBGP）[19]和多播源发现协议（MSDP）[20]）。此类路由协议使主机能够加入单个多播组地址，并向组中的所有成员发送数据或从中接收数据，而事先不知道成员身份。然而，在网络中支持此类多播服务的路由级别涉及大量复杂性。
Many-to-many communication is not always available or desired by all group applications. For example, with Source-Specific Multicast (SSM) [8][9] and satellite communication, the multicast distribution channel only supports source-to-receiver traffic. In other cases, such as large ASM groups with a single active data source and many passive receivers, it is sub-optimal to create a full routing-level mesh of multicast sources just for the distribution of RTCP control packets. Thus, an alternative solution is preferable.
并非所有组应用程序都可以使用或需要多对多通信。例如，对于源特定多播（SSM）[8][9]和卫星通信，多播分发通道仅支持源到接收器的通信。在其他情况下，例如具有单个主动数据源和多个被动接收器的大型ASM组，仅为RTCP控制数据包的分发创建多播源的完整路由级别网格是次优的。因此，替代解决方案更可取。
Although a one-to-many multicast topology may simplify routing and may be a closer approximation to the requirements of certain RTP applications, unidirectional communication makes it impossible for receivers in the group to share RTCP feedback information with other group members. In this document, we specify a solution to that problem. We introduce unicast feedback as a new method to distribute
尽管一对多组播拓扑可以简化路由，并且可能更接近于某些RTP应用程序的要求，但单向通信使得组中的接收器无法与其他组成员共享RTCP反馈信息。在本文档中，我们指定了该问题的解决方案。我们引入单播反馈作为一种新的分发方法
RTCP control information amongst all session members. This method is designed to operate under any group communication model, ASM or SSM. The RTP data stream protocol itself is unaltered.
所有会话成员之间的RTCP控制信息。该方法设计用于任何群组通信模型，ASM或SSM。RTP数据流协议本身是不变的。
Scenarios under which the unicast feedback method can provide benefit include but are not limited to:
单播反馈方法可以提供好处的场景包括但不限于：
a) SSM groups with a single sender.
a) SSM组只有一个发送方。
The proposed extensions allow SSM groups that do not have many-to-many communication capability to receive RTP data streams and to continue to participate in the RTP control protocol (RTCP) by using multicast in the source-to-receiver direction and unicast to send receiver feedback to the source on the standard RTCP port.
建议的扩展允许不具备多对多通信能力的SSM组接收RTP数据流，并通过在源到接收器方向上使用多播和单播向标准RTCP端口上的源发送接收器反馈，继续参与RTP控制协议（RTCP）。
b) One-to-many broadcast networks.
b) 一对多广播网络。
Unicast feedback may also be beneficial to one-to-many broadcast networks, such as a satellite network with a terrestrial low-bandwidth return channel or a broadband cable link. Unlike the SSM network, these networks may have the ability for a receiver to multicast return data to the group. However, a unicast feedback mechanism may be preferable for routing simplicity.
单播反馈也可有益于一对多广播网络，例如具有地面低带宽返回信道或宽带电缆链路的卫星网络。与SSM网络不同，这些网络可能具有接收器多播向组返回数据的能力。然而，为了路由的简单性，单播反馈机制可能更可取。
c) ASM with a single sender.
c) 与单个发送者的ASM。
A unicast feedback approach can be used by an ASM application with a single sender to reduce the load on the multicast routing infrastructure that does not scale as efficiently as unicast routing does. Because this is no more efficient than a standard multicast group RTP communication scenario, it is not expected to replace the traditional mechanism.
具有单个发送方的ASM应用程序可以使用单播反馈方法来减少多播路由基础结构上的负载，该基础结构的扩展效率不如单播路由。因为这并不比标准的多播组RTP通信场景更有效，所以预计它不会取代传统的机制。
The modifications proposed in this document are intended to supplement the existing RTCP feedback mechanisms described in Section 6 of [1].
本文件中提出的修改旨在补充[1]第6节中描述的现有RTCP反馈机制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [13].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[13]中所述进行解释。
The following acronyms are used throughout this document:
本文件中使用了以下首字母缩略词：
ASM Any Source Multicast SSM Source-Specific Multicast
ASM任意源多播SSM源特定多播
Distribution Source: In an SSM context, only one entity distributes RTP data and redistributes RTCP information to all receivers. This entity is called the Distribution Source. It is also responsible for forwarding RTCP feedback to the Media Senders and thus creates a virtual multicast environment in which RTP and RTCP can be applied.
分发源：在SSM上下文中，只有一个实体分发RTP数据并将RTCP信息重新分发给所有接收方。此实体称为分发源。它还负责将RTCP反馈转发给媒体发送者，从而创建一个可以应用RTP和RTCP的虚拟多播环境。
Note that heterogeneous networks consisting of ASM multiple-sender groups, unicast-only clients, and/or SSM single-sender receiver groups MAY be connected via translators or mixers to create a single-source group (see Section 8 for details).
请注意，由ASM多个发送方组、仅单播客户端和/或SSM单发送方-接收方组组成的异构网络可通过转换器或混频器连接，以创建单个源组（有关详细信息，请参阅第8节）。
Media Sender: A Media Sender is an entity that originates RTP packets for a particular media session. In RFC 3550, a Media Sender is simply called a source. However, as the RTCP SSM system architecture includes a Distribution Source, to avoid confusion, in this document a media source is commonly referred to as a Media Sender. There may often be a single Media Sender that is co-located with the Distribution Source. But although there MUST be only one Distribution Source, there MAY be multiple Media Senders on whose behalf the Distribution Source forwards RTP and RTCP packets.
媒体发送方：媒体发送方是为特定媒体会话生成RTP数据包的实体。在RFC3550中，媒体发送器简称为源。但是，由于RTCP SSM系统架构包括分发源，为避免混淆，在本文档中，媒体源通常称为媒体发送方。通常可能有一个媒体发送方与分发源位于同一位置。但是，尽管必须只有一个分发源，但可能有多个媒体发送者，分发源代表这些发送者转发RTP和RTCP数据包。
RTP and RTCP Channels: The data distributed from the source to the receivers is referred to as the RTP channel and the control information as the RTCP channel. With standard RTP/RTCP, these channels typically share the same multicast address but are differentiated via port numbers as specified in [1]. In an SSM context, the RTP channel is multicast from the Distribution Source to the receivers. In contrast, the RTCP or feedback channel is actually the collection of unicast channels between the receivers and the Distribution Source via the Feedback Target(s). Thus, bidirectional communication is accomplished by using SSM in the direction from Distribution Source to the receivers and using the unicast feedback channel in the direction from receivers to Distribution Source. As discussed in the next section, the nature of the channels between the Distribution Source and the Media Sender(s) may vary.
RTP和RTCP通道：从源发送到接收器的数据称为RTP通道，控制信息称为RTCP通道。对于标准RTP/RTCP，这些通道通常共享相同的多播地址，但通过[1]中指定的端口号进行区分。在SSM上下文中，RTP信道是从分发源到接收器的多播。相反，RTCP或反馈信道实际上是接收机和分发源之间通过反馈目标的单播信道的集合。因此，通过在从分发源到接收器的方向上使用SSM和在从接收器到分发源的方向上使用单播反馈信道来实现双向通信。如下一节所述，分发源和媒体发送者之间的渠道性质可能会有所不同。
(Unicast RTCP) Feedback Target: The Feedback Target is a logical function to which RTCP unicast feedback traffic is addressed. The functions of the Feedback Target and the Distribution Source MAY be co-located or integrated in the same entity. In this case, for a session defined as having
（单播RTCP）反馈目标：反馈目标是RTCP单播反馈通信的逻辑功能。反馈目标和分配源的功能可以位于同一实体中或集成在同一实体中。在这种情况下，对于定义为
a Distribution Source A, on ports n for the RTP channel and k for the RTCP channel, the unicast RTCP Feedback Target is identified by an IP address of Distribution Source A on port k, unless otherwise stated in the session description. See Section 10 for details on how the address is specified. The Feedback Target MAY also be implemented in one or more entities different from the Distribution Source, and different RTP receivers MAY use different Feedback Target instances, e.g., for aggregation purposes. In this case, the Feedback Target instance(s) MUST convey the feedback received from the RTP receivers to the Distribution Source using the RTCP mechanisms specified in this document. If disjoint, the Feedback Target instances MAY be organized in arbitrary topological structures: in parallel, hierarchical, or chained. But the Feedback Target instance(s) and Distribution Source MUST share, e.g., through configuration, enough information to be able to provide coherent RTCP information to the RTP receivers based upon the RTCP feedback collected by the Feedback Target instance(s) -- as would be done if both functions were part of the same entity.
除非会话描述中另有说明，否则在RTP通道的端口n和RTCP通道的端口k上的分发源a上，单播RTCP反馈目标由端口k上分发源a的IP地址标识。有关如何指定地址的详细信息，请参见第10节。反馈目标还可以在不同于分发源的一个或多个实体中实现，并且不同的RTP接收器可以使用不同的反馈目标实例，例如，用于聚合目的。在这种情况下，反馈目标实例必须使用本文档中指定的RTCP机制将从RTP接收器接收到的反馈传递给分发源。如果不相交，反馈目标实例可以按任意拓扑结构组织：并行、分层或链接。但反馈目标实例和分发源必须共享（例如，通过配置）足够的信息，以便能够基于反馈目标实例收集的RTCP反馈向RTP接收器提供一致的RTCP信息——如果两个功能都是同一实体的一部分，则会这样做。
In order for unicast feedback to work, each receiver MUST direct its RTCP reports to a single specific Feedback Target instance.
为了使单播反馈工作，每个接收器必须将其RTCP报告定向到单个特定的反馈目标实例。
SSRC: Synchronization source as defined in [1]. This 32-bit value uniquely identifies each member in a session.
SSRC:[1]中定义的同步源。此32位值唯一标识会话中的每个成员。
Report blocks: Report block is the standard terminology for an RTCP reception report. RTCP [1] encourages the stacking of multiple report blocks in Sender Report (SR) and Receiver Report (RR) packets. As a result, a variable-size feedback packet may be created by one source that reports on multiple other sources in the group. The summarized reporting scheme builds upon this model through the inclusion of multiple summary report blocks in one packet. However, stacking of reports from multiple receivers is not permitted in the Simple Feedback Model (see Section 6).
报告块：报告块是RTCP接收报告的标准术语。RTCP[1]鼓励在发送方报告（SR）和接收方报告（RR）数据包中堆叠多个报告块。结果，可变大小的反馈包可以由一个源创建，该源报告组中的多个其他源。摘要报告方案通过在一个数据包中包含多个摘要报告块来构建此模型。但是，在简单反馈模型中，不允许多个接收者的报告堆叠（见第6节）。
As indicated by the definitions of the preceding section, one or more Media Senders send RTP packets to the Distribution Source. The Distribution Source relays the RTP packets to the receivers using a source-specific multicast arrangement. In the reverse direction, the receivers transmit RTCP packets via unicast to one or more instances of the Feedback Target. The Feedback Target sends either the original RTCP reports (the Simple Feedback Model) or summaries of these reports (the Summary Feedback Model) to the Distribution
如前一节的定义所示，一个或多个媒体发送方向分发源发送RTP数据包。分发源使用特定于源的多播安排将RTP分组中继到接收机。在相反方向上，接收机通过单播向反馈目标的一个或多个实例发送RTCP分组。反馈目标向分发服务器发送原始RTCP报告（简单反馈模型）或这些报告的摘要（摘要反馈模型）
Source. The Distribution Source in turn relays the RTCP reports and/or summaries to the Media Senders. The Distribution Source also transmits the RTCP Sender Reports and Receiver Reports or summaries back to the receivers, using source-specific multicast.
来源分发源将RTCP报告和/或摘要转发给媒体发送者。分发源还使用特定于源的多播将RTCP发送方报告和接收方报告或摘要发送回接收方。
When the Feedback Target(s) are co-located (or integrated) with the Distribution Source, redistribution of original or summarized RTCP reports is trivial. When the Feedback Target(s) are physically and/or topologically distinct from the Distribution Source, each Feedback Target either relays the RTCP packets to the Distribution Source or summarizes the reports and forwards an RTCP summary report to the Distribution Source. Coordination between multiple Feedback Targets is beyond the scope of this specification.
当反馈目标与分发源位于同一位置（或集成）时，重新分发原始或汇总的RTCP报告是微不足道的。当反馈目标在物理和/或拓扑上与分发源不同时，每个反馈目标要么将RTCP数据包中继到分发源，要么汇总报告并将RTCP汇总报告转发到分发源。多个反馈目标之间的协调超出了本规范的范围。
The Distribution Source MUST be able to communicate with all group members in order for either mechanism to work. The general architecture is displayed below in Figure 1. There may be a single Media Sender or multiple Media Senders (Media Sender i, 1<=i<=M) on whose behalf the Distribution Source disseminates RTP and RTCP packets. The base case, which is expected to be the most common case, is that the Distribution Source is co-located with a particular Media Sender. A basic assumption is that communication is multicast (either SSM or ASM) in the direction of the Distribution Source to the receivers (R(j), 1<=j<=N) and unicast in the direction of the receivers to the Distribution Source.
分发源必须能够与所有组成员通信，以使任一机制工作。图1显示了通用架构。可能有一个或多个媒体发送者（媒体发送者i，1<=i<=M），分发源代表其分发RTP和RTCP数据包。基本情况（预计是最常见的情况）是分发源与特定媒体发送方位于同一位置。一个基本假设是，通信是在分发源方向上向接收器（R（j），1<=j<=N）的多播（SSM或ASM）和在接收器方向上向分发源的单播。
Communication between Media Sender(s) and the Distribution Source may be performed in numerous ways:
媒体发送方和分发源之间的通信可以通过多种方式执行：
i. Unicast only: The Media Sender(s) MAY send RTP and RTCP via unicast to the Distribution Source and receive RTCP via unicast.
i. 仅单播：媒体发送方可通过单播向分发源发送RTP和RTCP，并通过单播接收RTCP。
ii. Any Source Multicast (ASM): The Media Sender(s) and the Distribution Source MAY be in the same ASM group, and RTP and RTCP packets are exchanged via multicast.
二,。任意源多播（ASM）：媒体发送方和分发源可能位于同一ASM组中，RTP和RTCP数据包通过多播进行交换。
iii. Source-Specific Multicast (SSM): The Media Sender(s) and the Distribution Source MAY be in an SSM group with the source being the Distribution Source. RTP and RTCP packets from the Media Senders are sent via unicast to the Distribution Source, while RTCP packets from the Distribution Source are sent via multicast to the Media Senders.
iii.特定于源的多播（SSM）：媒体发送方和分发源可能位于SSM组中，其中源是分发源。来自媒体发送方的RTP和RTCP数据包通过单播发送到分发源，而来自分发源的RTCP数据包通过多播发送到媒体发送方。
Note that this SSM group MAY be identical to the SSM group used for RTP/RTCP delivery from the Distribution Source to the receivers or it MAY be a different one.
请注意，此SSM组可能与用于从分发源到接收器的RTP/RTCP交付的SSM组相同，也可能是不同的SSM组。
Note that Figure 1 below shows a logical diagram and, therefore, no details about the above options for the communication between Media Sender(s), Distribution Source, Feedback Target(s), and receivers are provided.
请注意，下面的图1显示了一个逻辑图，因此，没有提供有关媒体发送方、分发源、反馈目标和接收方之间通信的上述选项的详细信息。
Configuration information needs to be supplied so that (among other reasons):
需要提供配置信息，以便（除其他原因外）：
o Media Sender(s) know the transport address of the Distribution Source or the transport address of the (ASM or SSM) multicast group used for the contribution link;
o 媒体发送方知道分发源的传输地址或用于贡献链路的（ASM或SSM）多播组的传输地址；
o the Distribution Source knows either the unicast transport address(es) or the (ASM or SSM) multicast transport address(es) to reach the Media Sender(s);
o 分发源知道到达媒体发送方的单播传输地址或（ASM或SSM）多播传输地址；
o receivers know the addresses of their respectively responsible Feedback Targets; and
o 接收者知道各自负责的反馈对象的地址；和
o the Feedback Targets know the transport address of the Distribution Source.
o 反馈目标知道分发源的传输地址。
The precise setup and configuration of the Media Senders and their interaction with the Distribution Source is beyond the scope of this document (appropriate Session Description Protocol (SDP) descriptions MAY be used for this purpose), which only specifies how the various components interact within an RTP session. Informative examples for different configurations of the Media Sources and the Distribution Source are given in Appendix A.
媒体发送器的精确设置和配置及其与分发源的交互超出了本文档的范围（为此目的，可使用适当的会话描述协议（SDP）描述），本文档仅指定了RTP会话中各个组件的交互方式。附录A中给出了媒体源和分发源不同配置的信息示例。
Future specifications may be defined to address these aspects.
可以定义未来的规范来解决这些方面。
Source-specific
+--------+ +-----+ Multicast
|Media | | | +----------------> R(1)
|Sender 1|<----->| D S | | |
+--------+ | I O | +--+ |
| S U | | | |
+--------+ | T R | | +-----------> R(2) |
|Media |<----->| R C |->+ +---- : | |
|Sender 2| | I E | | +------> R(n-1) | |
+--------+ | B | | | | | |
: | U | +--+--> R(n) | | |
: | T +-| | | | |
| I | |<---------+ | | |
+--------+ | O |F|<---------------+ | |
|Media | | N |T|<--------------------+ |
|Sender M|<----->| | |<-------------------------+
+--------+ +-----+ Unicast
Source-specific
+--------+ +-----+ Multicast
|Media | | | +----------------> R(1)
|Sender 1|<----->| D S | | |
+--------+ | I O | +--+ |
| S U | | | |
+--------+ | T R | | +-----------> R(2) |
|Media |<----->| R C |->+ +---- : | |
|Sender 2| | I E | | +------> R(n-1) | |
+--------+ | B | | | | | |
: | U | +--+--> R(n) | | |
: | T +-| | | | |
| I | |<---------+ | | |
+--------+ | O |F|<---------------+ | |
|Media | | N |T|<--------------------+ |
|Sender M|<----->| | |<-------------------------+
+--------+ +-----+ Unicast
FT = Feedback Target Transport from the Feedback Target to the Distribution Source is via unicast or multicast RTCP if they are not co-located.
FT=反馈目标从反馈目标到分发源的传输是通过单播或多播RTCP进行的，如果它们不在同一位置。
Figure 1: System Architecture
图1：系统架构
The first method proposed to support unicast RTCP feedback, the 'Simple Feedback Model', is a basic reflection mechanism whereby all Receiver RTCP packets are unicast to the Feedback Target, which relays them unmodified to the Distribution Source. Subsequently, these packets are forwarded by the Distribution Source to all receivers on the multicast RTCP channel. The advantage of using this method is that an existing receiver implementation requires little modification in order to use it. Instead of sending reports to a multicast address, a receiver uses a unicast address yet still receives forwarded RTCP traffic on the multicast control channel. This method also has the advantage of being backwards compatible with standard RTP/RTCP implementations. The Simple Feedback Model is specified in Section 6.
第一种支持单播RTCP反馈的方法是“简单反馈模型”，它是一种基本的反射机制，所有接收机RTCP数据包都是单播到反馈目标的，而反馈目标则将它们不经修改地中继到分发源。随后，分发源将这些数据包转发给多播RTCP信道上的所有接收器。使用这种方法的优点是，现有的接收器实现只需要很少的修改就可以使用它。接收器使用单播地址而不是向多播地址发送报告，但仍然在多播控制信道上接收转发的RTCP流量。该方法还具有向后兼容标准RTP/RTCP实现的优点。第6节规定了简单反馈模型。
The second method, the 'Distribution Source Feedback Summary Model', is a summarized reporting scheme that provides savings in bandwidth by consolidating Receiver Reports at the Distribution Source, optionally with help from the Feedback Target(s), into summary packets that are then distributed to all the receivers. The Distribution Source Feedback Summary Model is specified in Section 7.
第二种方法，即“分发源反馈摘要模型”，是一种摘要报告方案，通过将分发源处的接收器报告（可选地在反馈目标的帮助下）合并成摘要数据包，然后分发给所有接收器，从而节省带宽。第7节规定了分销源反馈汇总模型。
The advantage of the latter scheme is apparent for large group sessions where the basic reflection mechanism outlined above generates a large amount of packet forwarding when it replicates all the information to all the receivers. Clearly, this technique requires that all session members understand the new summarized packet format outlined in Section 7.1. Additionally, the summarized scheme provides an optional mechanism to send distribution information or histograms about the feedback data reported by the whole group. Potential uses for the compilation of distribution information are addressed in Section 7.4.
后一种方案的优点对于大型组会话是显而易见的，其中，当上面概述的基本反射机制将所有信息复制到所有接收器时，会生成大量的分组转发。显然，这种技术要求所有会话成员都理解第7.1节中概述的新摘要数据包格式。此外，汇总方案提供了一种可选机制，用于发送关于整个组报告的反馈数据的分布信息或直方图。第7.4节介绍了编制分销信息的潜在用途。
To differentiate between the two reporting methods, a new SDP identifier is created and discussed in Section 10. The reporting method MUST be decided prior to the start of the session. A Distribution Source MUST NOT change the method during a session.
为了区分这两种报告方法，在第10节中创建并讨论了一个新的SDP标识符。报告方法必须在会议开始前决定。分发源在会话期间不得更改方法。
In a session using SSM, the network SHOULD prevent any multicast data from the receiver being distributed further than the first hop router. Additionally, any data heard from a non-unicast-capable receiver by other hosts on the same subnet SHOULD be filtered out by the host IP stack so that it does not cause problems with respect to the calculation of the receiver RTCP bandwidth share.
在使用SSM的会话中，网络应防止来自接收器的任何多播数据被分发到比第一跳路由器更远的地方。此外，同一子网上的其他主机从不支持单播的接收器听到的任何数据都应由主机IP堆栈过滤掉，这样就不会导致接收器RTCP带宽共享计算方面的问题。
The RTCP packet types defined in [1], [26], and [15] are:
[1]、[26]和[15]中定义的RTCP数据包类型为：
Type Description Payload number
-------------------------------------------------------
SR Sender Report 200
RR Receiver Report 201
SDES Source Description 202
BYE Goodbye 203
APP Application-Defined 204
RTPFB Generic RTP feedback 205
PSFB Payload-specific feedback 206
XR RTCP Extension 207
Type Description Payload number
-------------------------------------------------------
SR Sender Report 200
RR Receiver Report 201
SDES Source Description 202
BYE Goodbye 203
APP Application-Defined 204
RTPFB Generic RTP feedback 205
PSFB Payload-specific feedback 206
XR RTCP Extension 207
This document defines one further RTCP packet format:
本文件定义了另一种RTCP数据包格式：
Type Description Payload number
---------------------------------------------------------
RSI Receiver Summary Information 209
Type Description Payload number
---------------------------------------------------------
RSI Receiver Summary Information 209
Within the Receiver Summary Information packet, there are various types of information that may be reported and encapsulated in optional sub-report blocks:
在接收器摘要信息包内，有各种类型的信息可以报告并封装在可选的子报告块中：
Name Long Name Value
------------------------------------------------------------------
IPv4 Address IPv4 Feedback Target Address 0
IPv6 Address IPv6 Feedback Target Address 1
DNS Name DNS name indicating Feedback Target Address 2
Reserved Reserved for Assignment by Standards Action 3
Loss Loss distribution 4
Jitter Jitter distribution 5
RTT Round-trip time distribution 6
Cumulative loss Cumulative loss distribution 7
Collisions SSRC collision list 8
Reserved Reserved for Assignment by Standards Action 9
Stats General statistics 10
RTCP BW RTCP bandwidth indication 11
Group Info RTCP group and average packet size 12
- Unassigned 13 - 255
Name Long Name Value
------------------------------------------------------------------
IPv4 Address IPv4 Feedback Target Address 0
IPv6 Address IPv6 Feedback Target Address 1
DNS Name DNS name indicating Feedback Target Address 2
Reserved Reserved for Assignment by Standards Action 3
Loss Loss distribution 4
Jitter Jitter distribution 5
RTT Round-trip time distribution 6
Cumulative loss Cumulative loss distribution 7
Collisions SSRC collision list 8
Reserved Reserved for Assignment by Standards Action 9
Stats General statistics 10
RTCP BW RTCP bandwidth indication 11
Group Info RTCP group and average packet size 12
- Unassigned 13 - 255
As with standard RTP/RTCP, the various reports MAY be combined into a single RTCP packet, which SHOULD NOT exceed the path MTU. Packets continue to be sent at a rate that is inversely proportional to the group size in order to scale the amount of traffic generated.
与标准RTP/RTCP一样，各种报告可以组合成单个RTCP数据包，该数据包不应超过路径MTU。数据包继续以与组大小成反比的速率发送，以缩放生成的通信量。
The Simple Feedback Model uses the same packet types as traditional RTCP feedback described in [1]. Receivers still generate Receiver Reports with information on the quality of the stream received from the Distribution Source. The Distribution Source still MUST create Sender Reports that include timestamp information for stream synchronization and round-trip time calculation. Both Media Senders and receivers are required to send SDES packets as outlined in [1]. The rules for generating BYE and APP packets as outlined in [1] also apply.
简单反馈模型使用与[1]中描述的传统RTCP反馈相同的数据包类型。接收器仍然生成接收器报告，其中包含关于从分发源接收的流的质量的信息。分发源仍然必须创建发送方报告，其中包含用于流同步和往返时间计算的时间戳信息。媒体发送方和接收方都需要发送SDES数据包，如[1]所述。[1]中概述的生成BYE和APP数据包的规则也适用。
For the Simple Feedback Model, the Distribution Source MUST provide a basic packet-reflection mechanism. It is the default behavior for any Distribution Source and is the minimum requirement for acting as a Distribution Source to a group of receivers using unicast RTCP feedback.
对于简单的反馈模型，分发源必须提供基本的包反射机制。这是任何分发源的默认行为，也是使用单播RTCP反馈作为一组接收器的分发源的最低要求。
The Distribution Source (unicast Feedback Target) MUST listen for unicast RTCP data sent to the RTCP port. All valid unicast RTCP packets received on this port MUST be forwarded by the Distribution Source to the group on the multicast RTCP channel. The Distribution
分发源（单播反馈目标）必须侦听发送到RTCP端口的单播RTCP数据。在该端口上接收的所有有效单播RTCP数据包必须由分发源转发到多播RTCP通道上的组。分布
Source MUST NOT stack report blocks received from different receivers into one packet for retransmission to the group. Every RTCP packet from each receiver MUST be reflected individually.
源不得将从不同接收器接收的报告块堆叠到一个数据包中，以便重新传输到组。来自每个接收器的每个RTCP数据包必须单独反映。
If the Media Sender(s) are not part of the SSM group for RTCP packet reflection, the Distribution Source MUST also forward the RTCP packets received from the receivers to the Media Sender(s). If there is more than one Media Sender and these Media Senders do not communicate via ASM with the Distribution Source and each other, the Distribution Source MUST forward each RTCP packet originated by one Media Sender to all other Media Senders.
如果媒体发送方不是用于RTCP数据包反射的SSM组的一部分，则分发源还必须将从接收方接收的RTCP数据包转发给媒体发送方。如果有多个媒体发送者，且这些媒体发送者不通过ASM与分发源通信，且彼此之间不通信，则分发源必须将一个媒体发送者发起的每个RTCP数据包转发给所有其他媒体发送者。
The Distribution Source MUST forward RTCP packets originating from the Media Sender(s) to the receivers.
分发源必须将源自媒体发送方的RTCP数据包转发给接收方。
The reflected or forwarded RTCP traffic SHOULD NOT be counted as its own traffic in the transmission interval calculation by the Distribution Source. In other words, the Distribution Source SHOULD NOT consider reflected packets as part of its own control data bandwidth allowance. However, reflected packets MUST be processed by the Distribution Source and the average RTCP packet size, RTCP transmission rate, and RTCP statistics MUST be calculated. The algorithm for computing the allowance is explained in Section 9.
在分配源的传输间隔计算中，反射或转发的RTCP通信量不应算作其自身的通信量。换句话说，分发源不应该考虑反射包作为其自身控制数据带宽容差的一部分。但是，分发源必须处理反射的数据包，并且必须计算平均RTCP数据包大小、RTCP传输速率和RTCP统计信息。第9节解释了计算余量的算法。
If the Feedback Target function is disjoint from the Distribution Source, the Feedback Target(s) MUST forward all RTCP packets from the receivers or another Feedback Target -- directly or indirectly -- to the Distribution Source.
如果反馈目标函数与分发源不相交，则反馈目标必须将来自接收器或其他反馈目标的所有RTCP数据包直接或间接转发到分发源。
Receivers MUST listen on the RTP channel for data and on the RTCP channel for control. Each receiver MUST calculate its share of the control bandwidth R/n, in accordance with the profile in use, so that a fraction of the RTCP bandwidth, R, allocated to receivers is divided equally between the number of unique receiver SSRCs in the session, n. R may be rtcp_bw * 0.75 or rtcp_bw * 0.5 (depending on the ratio of senders to receivers as per [1]) or may be set explicitly by means of an SDP attribute [10]. See Section 9 for further information on the calculation of the bandwidth allowance. When a receiver is eligible to transmit, it MUST send a unicast Receiver Report packet to the Feedback Target following the rules defined in Section 9.
接收机必须在RTP信道上监听数据，在RTCP信道上监听控制。每个接收机必须根据使用中的配置文件计算其控制带宽R/n的份额，以便分配给接收机的RTCP带宽R的一部分在会话中唯一接收机SSRC的数量n之间平均分配。R可以是rtcp_bw*0.75或rtcp_bw*0.5（取决于根据[1]的发送方与接收方的比率），或者可以通过SDP属性明确设置[10]。有关带宽余量计算的更多信息，请参见第9节。当接收器有资格传输时，它必须按照第9节中定义的规则向反馈目标发送单播接收器报告包。
When a receiver observes either RTP packets or RTCP Sender Reports from a Media Sender with an SSRC that collides with its own chosen SSRC, it MUST change its own SSRC following the procedures of [1]. The receiver MUST do so immediately after noticing and before sending any (further) RTCP feedback messages.
当接收方观察到媒体发送方的RTP数据包或RTCP发送方报告时，其SSRC与其自己选择的SSRC发生冲突，必须按照[1]中的过程更改自己的SSRC。接收方必须在注意到并发送任何（进一步）RTCP反馈信息后立即这样做。
If a receiver has out-of-band information available about the Media Sender SSRC(s) used in the media session, it MUST NOT use the same SSRC for itself. Even if such out-of-band information is available, a receiver MUST obey the above collision-resolution mechanisms.
如果接收器具有关于媒体会话中使用的媒体发送方SSRC的带外信息，则其自身不得使用相同的SSRC。即使这种带外信息可用，接收机也必须遵守上述冲突解决机制。
Further mechanisms defined in [1] apply for resolving SSRC collisions between receivers.
[1]中定义的其他机制适用于解决接收器之间的SSRC冲突。
Media Senders listen on a unicast or multicast transport address for RTCP reports sent by the receivers (and forwarded by the Distribution Source) or other Media Senders (forwarded by the Distribution Source if needed). Processing and general operation follows [1].
媒体发送方在单播或多播传输地址上侦听接收方（并由分发源转发）或其他媒体发送方（如需要，由分发源转发）发送的RTCP报告。处理和一般操作如下[1]。
A Media Sender that observes an SSRC collision with another entity that is not also a Media Sender MAY delay its own collision-resolution actions as per [1], by 5 * 1.5 * Td, with Td being the deterministic calculated reporting interval, for receivers to see whether the conflict still exists. SSRC collisions with other Media Senders MUST be acted upon immediately.
观察到SSRC与另一实体（并非媒体发送方）发生冲突的媒体发送方可根据[1]将其自身的冲突解决行动延迟5*1.5*Td，Td为确定的计算报告间隔，以便接收方查看冲突是否仍然存在。必须立即处理与其他媒体发送器的SSRC冲突。
Note: This gives precedence to Media Senders and places the burden of collision resolution on the RTP receivers.
注意：这将优先考虑媒体发送器，并将冲突解决的负担置于RTP接收器上。
Sender SSRC information MAY be communicated out-of-band, e.g., by means of SDP media descriptions. Therefore, senders SHOULD NOT change their own SSRC aggressively or unnecessarily.
发送方SSRC信息可在带外传送，例如通过SDP媒体描述。因此，发件人不应主动或不必要地更改自己的SSRC。
In the Distribution Source Feedback Summary Model, the Distribution Source is required to summarize the information received from all the Receiver Reports generated by the receivers and place the information into summary reports. The Distribution Source Feedback Summary Model introduces a new report block format, the Receiver Summary Information (RSI) report, and a number of optional sub-report block formats, which are enumerated in Section 7.1. As described in Section 7.3, individual instances of the Feedback Target may provide preliminary summarization to reduce the processing load at the Distribution Source.
在分发源反馈汇总模型中，分发源需要汇总从接收者生成的所有接收者报告中接收到的信息，并将信息放入汇总报告中。分发源反馈摘要模型引入了一种新的报告块格式、接收者摘要信息（RSI）报告和许多可选的子报告块格式，这些格式在第7.1节中列举。如第7.3节所述，反馈目标的各个实例可以提供初步总结，以减少分发源的处理负载。
Sub-reports appended to the RSI report block provide more detailed information on the overall session characteristics reported by all receivers and can also convey important information such as the feedback address and reporting bandwidth. Which sub-reports are mandatory and which ones are optional is defined below.
附加到RSI报告块的子报告提供关于所有接收者报告的整体会话特征的更详细信息，并且还可以传递重要信息，例如反馈地址和报告带宽。下面定义了哪些子报告是必需的，哪些是可选的。
From an RTP perspective, the Distribution Source is an RTP receiver, generating its own Receiver Reports and sending them to the receiver group and to the Media Senders. In the Distribution Source Feedback Summary Model, an RSI report block MUST be appended to all RRs the Distribution Source generates.
从RTP的角度来看，分发源是一个RTP接收器，生成自己的接收器报告并将其发送到接收器组和媒体发送者。在分发源反馈摘要模型中，必须将RSI报告块附加到分发源生成的所有RRs。
In addition, the Distribution Source MUST forward the RTCP SR reports and SDES packets of Media Senders without alteration. If the Distribution Source is actually a Media Sender, even if it is the only session sender, it MUST generate its own Sender Report (SR) packets for its role as a Media Sender and its Receiver Reports in its role as the Distribution Source.
此外，分发源必须转发媒体发送方的RTCP SR报告和SDES数据包，不得更改。如果分发源实际上是媒体发送方，即使它是唯一的会话发送方，它也必须为其作为媒体发送方的角色生成自己的发送方报告（SR）数据包，并为其作为分发源的角色生成接收方报告。
The Distribution Source MUST use its own SSRC value for transmitting summarization information and MUST perform proper SSRC collision detection and resolution.
分发源必须使用自己的SSRC值来传输摘要信息，并且必须执行适当的SSRC冲突检测和解决。
The Distribution Source MUST send at least one Receiver Summary Information packet for each reporting interval. The Distribution Source MAY additionally stack sub-report blocks after the RSI packet. If it does so, each sub-report block MUST correspond to the RSI packet and constitutes an enhancement to the basic summary information required by the receivers to calculate their reporting time interval. For this reason, additional sub-report blocks are not required but recommended. The compound RTCP packets containing the RSI packet and the optional corresponding sub-report blocks MUST be formed according to the rules defined in [1] for receiver-issued packets, e.g., they MUST begin with an RR packet, contain at least an SDES packet with a CNAME, and MAY contain further RTCP packets and SDES items.
分发源必须为每个报告间隔发送至少一个接收器摘要信息包。分发源还可以在RSI分组之后堆叠子报告块。如果这样做，则每个子报告块必须对应于RSI分组，并且构成对接收器计算其报告时间间隔所需的基本摘要信息的增强。因此，不需要额外的子报告块，但建议使用。包含RSI数据包和可选对应子报告块的复合RTCP数据包必须根据[1]中针对接收方发布的数据包定义的规则形成，例如，它们必须以RR数据包开始，至少包含带有CNAME的SDES数据包，并且可能包含更多RTCP数据包和SDES项目。
Every RSI packet MUST contain either a Group and Average Packet Size sub-report or an RTCP Bandwidth sub-report for bandwidth indications to the receivers.
每个RSI数据包必须包含一个组和平均数据包大小子报告或一个RTCP带宽子报告，用于向接收器显示带宽。
All numeric values comprising multiple (usually two or four) octets MUST be encoded in network byte order.
所有包含多个（通常为两个或四个）八位字节的数值必须按网络字节顺序编码。
The RSI report block has a fixed header size followed by a variable length report:
RSI报告块具有固定的标题大小，后跟可变长度的报告：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=RSI=209 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Summarized SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp (most significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp (least significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sub-report blocks :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=RSI=209 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Summarized SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp (most significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp (least significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sub-report blocks :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RSI packet includes the following fields:
RSI数据包包括以下字段：
Length: 16 bits As defined in [1], the length of the RTCP packet in 32-bit words minus one, including the header and any padding.
长度：如[1]中所定义的16位，RTCP数据包的32位字长度减去1，包括报头和任何填充。
SSRC: 32 bits The SSRC of the Distribution Source.
SSRC:32位分配源的SSRC。
Summarized SSRC: 32 bits The SSRC (of the Media Sender) of which this report contains a summary.
摘要SSRC：32位（媒体发送方的）SSRC，此报告包含其摘要。
Timestamp: 64 bits Indicates the wallclock time when this report was sent. Wallclock time (absolute date and time) is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900 [1]. The wallclock time MAY (but need not) be NTP-synchronized but it MUST provide a consistent behavior in the advancement of time (similar to NTP). The full-resolution NTP timestamp is used, which is a 64-bit, unsigned, fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits. This format is similar to RTCP Sender Reports (Section 6.4.1 of [1]). The timestamp value is used to enable detection of duplicate packets, reordering, and to provide a chronological profile of the feedback reports.
时间戳：64位表示发送此报告时的挂钟时间。Wallclock时间（绝对日期和时间）使用网络时间协议（NTP）的时间戳格式表示，相对于1900年1月1日的0h UTC，以秒为单位[1]。挂钟时间可以（但不需要）是NTP同步的，但它必须在时间推进过程中提供一致的行为（类似于NTP）。使用全分辨率NTP时间戳，它是一个64位无符号定点数字，整数部分在前32位，小数部分在后32位。该格式类似于RTCP发送方报告（第6.4.1节，共[1]）。时间戳值用于检测重复数据包、重新排序，并提供反馈报告的时间配置文件。
For RSI reports, this document also introduces a sub-report block format specific to the RSI packet. The sub-report blocks are appended to the RSI packet using the following generic format. All sub-report blocks MUST be 32-bit aligned.
对于RSI报告，本文档还介绍了特定于RSI数据包的子报告块格式。子报告块使用以下通用格式附加到RSI数据包。所有子报告块必须32位对齐。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRBT-specific data +
| |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRBT-specific data +
| |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SRBT: 8 bits Sub-Report Block Type. The sub-report block type identifier. The values for the sub-report block types are defined in Section 5.
SRBT：8位子报告块类型。子报表块类型标识符。第5节定义了子报告块类型的值。
Length: 8 bits The length of the sub-report in 32-bit words.
长度：8位子报告的长度，32位字。
SRBT-specific data: <length * 4 - 2> octets This field may contain type-specific information based upon the SRBT value.
特定于SRBT的数据：<length*4-2>八位字节此字段可能包含基于SRBT值的特定于类型的信息。
For the sub-report blocks that convey distributions of values (Loss, Jitter, RTT, Cumulative Loss), a flexible 'data bucket'-style report is used. This format divides the data set into variable-size buckets that are interpreted according to the guide fields at the head of the report block.
对于传递值分布（损耗、抖动、RTT、累积损耗）的子报告块，使用灵活的“数据桶”式报告。此格式将数据集划分为可变大小的存储桶，这些存储桶根据报告块头部的引导字段进行解释。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SRBT | Length | NDB | MF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Distribution Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Distribution Value |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Distribution Buckets |
| ... |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SRBT | Length | NDB | MF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Distribution Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Distribution Value |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Distribution Buckets |
| ... |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
The SRBT and length fields are calculated as explained in Section 7.1.2.
SRBT和长度字段的计算如第7.1.2节所述。
Number of distribution buckets (NDB): 12 bits The number of distribution buckets of data. The size of each bucket can be calculated using the formula ((length * 4) - 12) * 8 / NDB number of bits. The calculation is based on the length of the whole sub-report block in octets (length * 4) minus the header of 12 octets. Providing 12 bits for the NDB field enables bucket sizes as small as 2 bits for a full-length packet of MTU 1500 bytes. The bucket size in bits must always be divisible by 2 to ensure proper byte alignment. A bucket size of 2 bits is fairly restrictive, however, and it is expected that larger bucket sizes will be more practical for most distributions.
分发桶数（NDB）：12位数据的分发桶数。每个存储桶的大小可以使用公式（（长度*4）-12）*8/NDB位数计算。计算基于整个子报告块的长度（以八位字节为单位）（长度*4）减去12个八位字节的标题。为NDB字段提供12位可以使MTU 1500字节的全长数据包的存储桶大小小到2位。以位为单位的存储桶大小必须始终可以被2整除，以确保正确的字节对齐。但是，2位的存储桶大小具有相当大的限制性，预计对于大多数发行版来说，更大的存储桶大小更为实用。
Multiplicative Factor (MF): 4 bits 2^MF indicates the multiplicative factor to be applied to each distribution bucket value. Possible values of MF are 0 - 15, creating a range of values from MF = 1, 2, 4 ... 32768. Appendix B gives an example of the use of the multiplicative factor; it is meant to provide more "bits" without having them -- the bucket values get scaled up by the MF.
乘法因子（MF）：4位2^MF表示应用于每个分配桶值的乘法因子。MF的可能值为0-15，从MF=1、2、4创建一个值范围。。。32768附录B给出了乘法因子的使用示例；这意味着提供更多的“位”，而不需要它们——存储桶的值会被MF放大。
Length: 8 bits The length field tells the receiver the full length of the sub-report block in 32-bit words (i.e., length * 4 bytes) and enables the receiver to identify the bucket size. For example, given no MTU restrictions, the data portion of a distribution packet may be only as large as 1008 bytes (255 * 4 - 12), providing up to 4032 data buckets of length 2 bits, or 2016 data buckets of length 4 bits, etc.
长度：8位长度字段以32位字（即长度*4字节）告诉接收器子报告块的完整长度，并使接收器能够识别存储桶大小。例如，在没有MTU限制的情况下，分发包的数据部分可能只有1008字节（255*4-12）大，最多提供4032个长度为2位的数据桶，或2016个长度为4位的数据桶，等等。
Minimum distribution value (min): 32 bits The minimum distribution value, in combination with the maximum distribution value, indicates the range covered by the data bucket values.
最小分布值（min）：32位最小分布值与最大分布值组合，表示数据桶值所覆盖的范围。
Maximum distribution value (max): 32 bits The maximum distribution value, in combination with the minimum distribution value, indicates the range covered by the data bucket values. The significance and range of the distribution values is defined in the individual subsections for each distribution type (DT).
最大分布值（max）：32位最大分布值与最小分布值组合表示数据存储桶值所覆盖的范围。每个分布类型（DT）的各个小节中定义了分布值的重要性和范围。
Distribution buckets: each bucket is ((length * 4) - 12) * 8 / NDB bits The size and number of buckets is calculated as outlined above based upon the value of NDB and the length of the packet. The values for distribution buckets are equally distributed; according to the following formula, distribution bucket x (with 0 <= x < NDB) covers the value range:
分发存储桶：每个存储桶为（（长度*4）-12）*8/NDB位。存储桶的大小和数量根据NDB值和数据包的长度如上所述进行计算。分配桶的值分布均匀；根据以下公式，分配桶x（0<=x<NDB）涵盖了数值范围：
x = 0; [min, min + (max - min) / NDB]
x > 0; [min + (x) * (max - min) / NDB,
min + (x + 1) * (max - min) / NDB]
x = 0; [min, min + (max - min) / NDB]
x > 0; [min + (x) * (max - min) / NDB,
min + (x + 1) * (max - min) / NDB]
Interpretation of the minimum, maximum, and distribution values in the sub-report block is sub-report-specific and is addressed individually in the sections below. The size of the sub-report block is variable, as indicated by the packet length field.
子报告块中最小值、最大值和分布值的解释是特定于子报告的，并在以下各节中单独说明。如数据包长度字段所示，子报告块的大小是可变的。
Note that, for any bucket-based reporting, if the Distribution Source and the Feedback Target(s) are disjoint entities, out-of-band agreement on the bucket-reporting granularity is recommended to allow the Distribution Source to forward accurate information in these kinds of reports to the receivers.
请注意，对于任何基于bucket的报告，如果分发源和反馈目标是不相交的实体，建议就bucket报告粒度达成带外协议，以允许分发源将此类报告中的准确信息转发给接收者。
The Loss sub-report block allows a receiver to determine how its own reception quality relates to the other recipients. A receiver may use this information, e.g., to drop out of a session (instead of sending lots of error repair feedback) if it finds itself isolated at the lower end of the reception quality scale.
丢失子报告块允许接收方确定其自身接收质量与其他接收方的关系。接收机可以使用该信息，例如，如果它发现自己处于接收质量等级的低端，则退出会话（而不是发送大量错误修复反馈）。
The Loss sub-report block indicates the distribution of losses as reported by the receivers to the Distribution Source. Values are expressed as a fixed-point number with the binary point at the left edge of the field similar to the "fraction lost" field in SR and RR packets, as defined in [1]. The Loss sub-report block type (SRBT) is 4.
损耗子报告块指示由接收器向分布源报告的损耗分布。值表示为一个定点数字，二进制点位于字段的左边缘，类似于SR和RR数据包中的“分数丢失”字段，如[1]中所定义。损失子报告块类型（SRBT）为4。
Valid results for the minimum distribution value field are 0 - 254. Similarly, valid results for the maximum distribution value field are 1 - 255. The minimum distribution value MUST always be less than the maximum.
最小分布值字段的有效结果为0-254。类似地，最大分布值字段的有效结果为1-255。最小分布值必须始终小于最大值。
For examples on processing summarized loss report sub-blocks, see Appendix B.
有关处理汇总损失报告子块的示例，请参见附录B。
A Jitter sub-report block indicates the distribution of the estimated statistical variation of the RTP data packet inter-arrival time reported by the receivers to the Distribution Source. This allows receivers both to place their own observed jitter values in context with the rest of the group and to approximate dynamic parameters for playout buffers. See [1] for details on the calculation of the values and the relevance of the jitter results. Jitter values are measured in timestamp units with the rate used by the Media Sender and expressed as unsigned integers. The minimum distribution value MUST always be less than the maximum. The Jitter sub-report block type (SRBT) is 5.
抖动子报告块指示由接收机向分布源报告的RTP数据分组到达间时间的估计统计变化的分布。这使得接收机既可以将自己观察到的抖动值与组中的其他部分放在一起，也可以近似地计算播放缓冲区的动态参数。有关值的计算和抖动结果的相关性的详细信息，请参见[1]。抖动值以时间戳单位和媒体发送器使用的速率测量，并表示为无符号整数。最小分布值必须始终小于最大值。抖动子报告块类型（SRBT）为5。
Since timestamp units are payload-type specific, the relevance of a jitter value is impacted by any change in the payload type during a session. Therefore, a Distribution Source MUST NOT report jitter distribution values for at least 2 reporting intervals after a payload type change occurs.
由于时间戳单元是特定于有效负载类型的，因此抖动值的相关性受到会话期间有效负载类型的任何变化的影响。因此，在有效负载类型发生变化后，分布源不得在至少2个报告间隔内报告抖动分布值。
A Round-Trip Time sub-report indicates the distribution of round-trip times from the Distribution Source to the receivers, providing receivers with a global view of the range of values in the group. The Distribution Source is capable of calculating the round-trip time to any other member since it forwards all the SR packets from the Media Sender(s) to the group. If the Distribution Source is not itself a Media Sender, it can calculate the round-trip time from itself to any of the receivers by maintaining a record of the SR sender timestamp and the current time as measured from its own system clock. The Distribution Source consequently calculates the round-trip time from the Receiver Report by identifying the corresponding SR timestamp and subtracting the RR advertised holding time as reported by the receiver from its own time difference measurement, as calculated by the time the RR packet is received and the recorded time the SR was sent.
往返时间子报告表示从分布源到接收器的往返时间分布，为接收器提供组中值范围的全局视图。分发源能够计算到任何其他成员的往返时间，因为它将所有SR数据包从媒体发送方转发到组。如果分发源本身不是媒体发送器，则它可以通过维护SR发送器时间戳的记录和从其自身系统时钟测量的当前时间来计算从其自身到任何接收器的往返时间。因此，分发源通过识别相应的SR时间戳并从其自身的时间差测量中减去由接收机报告的RR广告保持时间（由接收RR分组的时间和发送SR的记录时间计算）来从接收机报告计算往返时间。
The Distribution Source has the option of distributing these round-trip time estimations to the whole group, uses of which are described in Section 7.4. The round-trip time is expressed in units of 1/65536 seconds and indicates an absolute value. This is calculated by the Distribution Source, based on the Receiver Report responses declaring the time difference since an original Sender Report and on the holding time at the receiver. The minimum distribution value MUST always be less than the maximum. The Round-Trip Time sub-report block type (SRBT) is 6.
配电源可选择将这些往返时间估计值分配给整个组，其用途见第7.4节。往返时间以1/65536秒为单位，表示绝对值。这由分发源根据接收方报告响应（声明自原始发送方报告以来的时间差）和接收方的等待时间计算得出。最小分布值必须始终小于最大值。往返时间子报告块类型（SRBT）为6。
Note that if the Distribution Source and the Feedback Target functions are disjoint, it is only possible for the Distribution Source to determine RTT if all the Feedback Targets forward all RTCP reports from the receivers immediately (i.e., do not perform any preliminary summarization) and include at least the RR packet.
注意，如果分发源和反馈目标函数是不相交的，则只有当所有反馈目标立即转发来自接收器的所有RTCP报告（即，不执行任何初步汇总）并且至少包括RR数据包时，分发源才可能确定RTT。
The cumulative loss field in a Receiver Report [1], in contrast to the fraction lost field, is intended to provide some historical perspective on the session performance, i.e., the total number of lost packets since the receiver joined the session. The cumulative loss value provides a longer-term average by summing over a larger sample set (typically the whole session). The Distribution Source MAY record the values as reported by the receiver group and report a distribution of values. Values are expressed as a fixed-point number with the binary point at the left edge of the field, in the same manner as the Loss sub-report block. Since the individual Receiver Reports give the cumulative number of packets lost but not the cumulative number sent, which is required as a denominator to calculate the long-term fraction lost, the Distribution Source MUST maintain a record of the cumulative number lost and extended highest sequence number received, as reported by each receiver at some point in the past. Ideally, the recorded values are from the first report received. Subsequent calculations are then based on (<the new cumulative loss value> - <the recorded value>) / (<new extended highest sequence number> - <recorded sequence number>).
接收器报告[1]中的累积丢失字段与分数丢失字段相反，旨在提供会话性能的一些历史观点，即自接收器加入会话以来丢失的数据包总数。累积损失值通过对更大的样本集（通常是整个会话）求和来提供长期平均值。分布源可以记录由接收器组报告的值，并报告值的分布。值表示为定点数字，二进制点位于字段的左边缘，方式与损失子报告块相同。由于各个接收器报告给出了丢失的数据包的累积数量，但没有给出发送的累积数量，这是计算长期丢失分数所需的分母，因此分发源必须保留丢失的累积数量和接收到的扩展最高序列号的记录，正如每个接收者在过去某个时候所报告的那样。理想情况下，记录的值来自收到的第一份报告。随后的计算基于（<新累积损失值>-<记录值>）/（<新扩展最高序列号>-<记录序列号>）。
Valid results for the minimum distribution value field are 0 - 254. Similarly, valid results for the maximum distribution value field are 1 - 255. The minimum distribution value MUST always be less than the maximum. The Cumulative Loss sub-report block type (SRBT) is 7.
最小分布值字段的有效结果为0-254。类似地，最大分布值字段的有效结果为1-255。最小分布值必须始终小于最大值。累积损失子报告块类型（SRBT）为7。
The Feedback Target Address block provides a dynamic mechanism for the Distribution Source to signal an alternative unicast RTCP feedback address to the receivers. If a block of this type is included, receivers MUST override any static SDP address information for the session with the Feedback Target address provided in this sub-report block.
反馈目标地址块为分发源提供一种动态机制，以向接收机发送替代单播RTCP反馈地址的信号。如果包含此类型的块，则接收器必须使用此子报告块中提供的反馈目标地址覆盖会话的任何静态SDP地址信息。
If a Feedback Target Address sub-report block is used, it MUST be included in every RTCP packet originated by the Distribution Source to ensure that all receivers understand the information. In this manner, receiver behavior should remain consistent even in the face of packet loss or when there are late session arrivals.
如果使用反馈目标地址子报告块，则必须将其包含在分发源发起的每个RTCP数据包中，以确保所有接收者都理解该信息。以这种方式，即使在分组丢失或会话延迟到达时，接收器行为也应保持一致。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT={0,1,2} | Length | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT={0,1,2} | Length | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SRBT: 8 bits The type of sub-report block that corresponds to the type of address is as follows:
SRBT:8位与地址类型对应的子报告块类型如下：
0: IPv4 address 1: IPv6 address 2: DNS name
0:IPv4地址1:IPv6地址2:DNS名称
Length: 8 bits The length of the sub-report block in 32-bit words. For an IPv4 address, this should be 2 (i.e., total length = 4 + 4 = 2 * 4 octets). For an IPv6 address, this should be 5. For a DNS name, the length field indicates the number of 32-bit words making up the string plus 1 byte and any additional padding required to reach the next word boundary.
长度：8位—子报告块的长度（32位字）。对于IPv4地址，这应该是2（即总长度=4+4=2*4个八位字节）。对于IPv6地址，该值应为5。对于DNS名称，长度字段表示组成字符串的32位字数加上1个字节以及到达下一个字边界所需的任何额外填充。
Port: 2 octets The port number to which receivers send feedback reports. A port number of 0 is invalid and MUST NOT be used.
端口：2个八位字节接收器向其发送反馈报告的端口号。端口号0无效，不能使用。
Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name) The address to which receivers send feedback reports. For IPv4 and IPv6, fixed-length address fields are used. A DNS name is an arbitrary-length string that is padded with null bytes to the next 32-bit boundary. The string MAY contain Internationalizing Domain Names in Applications (IDNA) domain names and MUST be UTF-8 encoded [11].
地址：4个八位字节（IPv4）、16个八位字节（IPv6）或n个八位字节（DNS名称）接收器向其发送反馈报告的地址。对于IPv4和IPv6，使用固定长度的地址字段。DNS名称是一个任意长度的字符串，在下一个32位边界上填充空字节。该字符串可能包含应用程序（IDNA）域名中的国际化域名，并且必须是UTF-8编码的[11]。
A Feedback Target Address block for a certain address type (i.e., with a certain SRBT of 0, 1, or 2) MUST NOT occur more than once within a packet. Numerical Feedback Target Address blocks for IPv4 and IPv6 MAY both be present. If so, the resulting transport addresses MUST point to the same logical entity.
特定地址类型（即，特定SRBT为0、1或2）的反馈目标地址块在数据包内不得出现多次。IPv4和IPv6的数字反馈目标地址块可能都存在。如果是这样，则生成的传输地址必须指向同一逻辑实体。
If a Feedback Target address block with an SRBT indicating a DNS name is present, there SHOULD NOT be any other numerical Feedback Target Address blocks present.
如果存在SRBT指示DNS名称的反馈目标地址块，则不应存在任何其他数字反馈目标地址块。
The Feedback Target Address presents a significant security risk if accepted from unauthenticated RTCP packets. See Sections 11.3 and 11.4 for further discussion.
如果从未经验证的RTCP数据包中接受反馈目标地址，则会带来严重的安全风险。进一步讨论见第11.3节和第11.4节。
The Collision SSRC sub-report provides the Distribution Source with a mechanism to report SSRC collisions amongst the group. In the event that a non-unique SSRC is discovered based on the tuple [SSRC, CNAME], the collision is reported in this block and the affected nodes must reselect their respective SSRC identifiers.
碰撞SSRC子报告为分发源提供了报告组中SSRC碰撞的机制。如果基于元组[SSRC，CNAME]发现非唯一SSRC，则此块中会报告冲突，受影响的节点必须重新选择各自的SSRC标识符。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT=8 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Collision SSRC :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT=8 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Collision SSRC :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Collision SSRC: n * 32 bits This field contains a list of SSRCs that are duplicated within the group. Usually this is handled by the hosts upon detection of the same SSRC; however, since receivers in an SSM session using the Distribution Source Feedback Summary Model no longer have a global view of the session, the collision algorithm is handled by the Distribution Source. SSRCs that collide are listed in the packet. Each Collision SSRC is reported only once for each collision detection. If more Collision SSRCs need to be reported than fit into an MTU, the reporting is done in a round robin fashion so that all Collision SSRCs have been reported once before the second round of reporting starts. On receipt of the packet, receiver(s) MUST detect the collision and select another SSRC, if the collision pertains to them.
冲突SSRC:n*32位此字段包含组内重复的SSRC列表。通常，这是由主机在检测到相同的SSRC时处理的；但是，由于使用分发源反馈摘要模型的SSM会话中的接收器不再具有会话的全局视图，因此冲突算法由分发源处理。碰撞的SSRC列在数据包中。对于每个碰撞检测，每个碰撞SSRC仅报告一次。如果需要报告的碰撞SSRC数量超过MTU的数量，则以循环方式进行报告，以便在第二轮报告开始之前报告所有碰撞SSRC一次。在接收到数据包时，接收方必须检测到冲突并选择另一个SSRC（如果冲突与他们有关）。
The Collision sub-report block type (SRBT) is 8.
碰撞子报告块类型（SRBT）为8。
Collision detection is only possible at the Distribution Source. If the Distribution Source and Feedback Target functions are disjoint and collision reporting across RTP receiver SSRCs shall be provided, the Feedback Targets(s) MUST forward the RTCP reports from the RTP receivers, including at least the RR and the SDES packets to the Distribution Source.
碰撞检测只能在分发源处进行。如果分配源和反馈目标功能不相交，并且应提供RTP接收器SSRC之间的冲突报告，则反馈目标必须将RTP接收器的RTCP报告转发给分配源，至少包括RR和SDES数据包。
In system settings in which, by explicit configuration or implementation, RTP receivers are not going to act as Media Senders in a session (e.g., for various types of television broadcasting), SSRC collision detection MAY be omitted for RTP receivers. In system settings in which an RTP receiver MAY become a Media Sender (e.g., any conversational application), SSRC collision detection MUST be provided for RTP receivers.
在系统设置中，通过显式配置或实现，RTP接收机不会在会话中充当媒体发送器（例如，对于各种类型的电视广播），对于RTP接收机，SSRC冲突检测可以省略。在RTP接收器可能成为媒体发送器的系统设置中（例如，任何对话应用程序），必须为RTP接收器提供SSRC冲突检测。
Note: The purpose of SSRC collision reporting is to ensure unique identification of RTCP entities. This is of particular relevance for Media Senders so that an RTP receiver can properly associate each of the multiple incoming media streams (via the Distribution Source) with the correct sender. Collision resolution for Media Senders is not affected by the Distribution Source's collision reporting because all SR reports are always forwarded among the senders and to all receivers. Collision resolution for RTP receivers is of particular relevance for those receivers capable of becoming a Media Sender. RTP receivers that will, by configuration or implementation choice, not act as a sender in a particular RTP session, do not necessarily need to be aware of collisions as long as the those entities receiving and processing RTCP feedback messages from the receivers are capable of disambiguating the various RTCP receivers (e.g., by CNAME).
注：SSRC冲突报告的目的是确保RTCP实体的唯一标识。这对于媒体发送者特别相关，以便RTP接收器可以将多个传入媒体流中的每一个（经由分发源）与正确的发送者适当地关联。媒体发送方的冲突解决方案不受分发源的冲突报告的影响，因为所有SR报告始终在发送方之间转发给所有接收方。RTP接收机的冲突解决对于那些能够成为媒体发送方的接收机来说特别重要。通过配置或实现选择，将不作为特定RTP会话中的发送方的RTP接收器不一定需要知道冲突，只要接收和处理来自接收器的RTCP反馈消息的那些实体能够消除各种RTCP接收器的歧义（例如，通过CNAME）。
Note also that RTP receivers should be able to deal with the changing SSRCs of a Media Sender (like any RTP receiver has to do.) and, if possible, be prepared to continuously render a media stream nevertheless.
还请注意，RTP接收器应该能够处理媒体发送器的不断变化的SSRC（就像任何RTP接收器必须做的那样），并且，如果可能，仍然要准备好连续呈现媒体流。
The General Statistics sub-report block is used if specifying buckets is deemed too complex. With the General Statistics sub-report block, only aggregated values are reported back. The rules for the generation of these values are provided in point b of Section 7.2.1.
如果认为指定存储桶太复杂，则使用“常规统计”子报告块。对于“常规统计信息”子报表块，只报告聚合值。第7.2.1节b点提供了生成这些值的规则。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT=10 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MFL | HCNL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Median inter-arrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT=10 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MFL | HCNL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Median inter-arrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Median fraction lost (MFL): 8 bits The median fraction lost indicated by Receiver Reports forwarded to this Distribution Source, expressed as a fixed-point number with the binary point at the left edge of the field. A value of all '1's indicates that the MFL value is not provided.
中值分数丢失（MFL）：8位由转发到此分布源的接收器报告指示的中值分数丢失，表示为固定点数，二进制点位于字段左边缘。所有'1'的值表示未提供MFL值。
Highest cumulative number of packets lost (HCNL): 24 bits Highest 'cumulative number of packets lost' value out of the most recent RTCP RR packets from any of the receivers. A value of all '1's indicates that the HCNL value is not provided.
最高累计丢失数据包数（HCNL）：来自任何接收器的最新RTCP RR数据包中最高的24位“累计丢失数据包数”值。所有“1”的值表示未提供HCNL值。
Median inter-arrival jitter: 32 bits Median 'inter-arrival jitter' value out of the most recent RTCP RR packets from the receiver set. A value of all '1's indicates that this value is not provided.
中值到达间抖动：来自接收器集的最新RTCP RR数据包的32位中值“到达间抖动”值。所有“1”的值表示未提供此值。
The General Statistics sub-report block type (SRBT) is 10.
常规统计子报表块类型（SRBT）为10。
Note that, in case the Distribution Source and the Feedback Target functions are disjoint, it is only possible for the Distribution Source to determine the median of the inter-arrival jitter if all the Feedback Targets forward all RTCP reports from the receivers immediately and include at least the RR packet.
注意，在分布源和反馈目标函数不相交的情况下，只有当所有反馈目标立即转发来自接收机的所有RTCP报告并且至少包括RR分组时，分布源才可能确定到达间抖动的中值。
This sub-report block is used to inform the Media Senders and receivers about either the maximum RTCP bandwidth that is supposed to be used by each Media Sender or the maximum bandwidth allowance to be used by each receiver. The value is applied universally to all Media Senders or all receivers. Each receiver MUST base its RTCP transmission interval calculation on the average size of the RTCP packets sent by itself. Conversely, each Media Sender MUST base its RTCP transmission interval calculation on the average size of the RTCP packets sent by itself.
此子报告块用于通知媒体发送方和接收方每个媒体发送方应使用的最大RTCP带宽或每个接收方应使用的最大带宽余量。该值普遍应用于所有媒体发送方或所有接收方。每个接收器必须根据自身发送的RTCP数据包的平均大小计算其RTCP传输间隔。相反，每个媒体发送器必须根据自身发送的RTCP数据包的平均大小计算其RTCP传输间隔。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT=11 | Length |S|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTCP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT=11 | Length |S|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTCP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender (S): 1 bit The contained bandwidth value applies to each Media Sender.
发送方：1位包含的带宽值适用于每个媒体发送方。
Receivers (R): 1 bit The contained bandwidth value applies to each RTP receiver.
接收器（R）：1位包含的带宽值应用于每个RTP接收器。
Reserved: 14 bits MUST be set to zero upon transmission and ignored upon reception.
保留：传输时14位必须设置为零，接收时忽略。
RTCP Bandwidth: 32 bits If the S bit is set to 1, this field indicates the maximum bandwidth allocated to each individual Media Sender. This also informs the receivers about the RTCP report frequency to expect from the senders. This is a fixed-point value with the binary point in between the second and third bytes. The value represents the bandwidth allocation per receiver in kilobits per second, with values in the range 0 <= BW < 65536.
RTCP带宽：32位如果S位设置为1，此字段表示分配给每个媒体发送器的最大带宽。这还将通知接收方发送方预期的RTCP报告频率。这是一个定点值，二进制点位于第二字节和第三字节之间。该值表示每个接收器的带宽分配，单位为千比特/秒，值的范围为0<=BW<65536。
If the R bit is set to 1, this field indicates the maximum bandwidth allocated per receiver for sending RTCP data relating to the session. This is a fixed-point value with the binary point in between the second and third bytes. The value represents the bandwidth allocation per receiver in kilobits per second, with values in the range 0 <= BW < 65536. Each receiver MUST use this value for its bandwidth allowance.
如果R位设置为1，则此字段表示为发送与会话相关的RTCP数据而为每个接收器分配的最大带宽。这是一个定点值，二进制点位于第二字节和第三字节之间。该值表示每个接收器的带宽分配，单位为千比特/秒，值的范围为0<=BW<65536。每个接收器必须使用此值作为其带宽余量。
This report block SHOULD only be used when the Group and Average Packet Size sub-report block is NOT included. The RTCP Bandwidth Indication sub-report block type (SRBT) is 11.
仅当不包括组和平均数据包大小子报告块时，才应使用此报告块。RTCP带宽指示子报告块类型（SRBT）为11。
This sub-report block is used to inform the Media Senders and receivers about the size of the group (used for calculating feedback bandwidth allocation) and the average packet size of the group. This sub-report MUST always be present, appended to every RSI packet, unless an RTCP Bandwidth Indication sub-report block is included (in which case it MAY, but need not, be present).
此子报告块用于通知媒体发送方和接收方组的大小（用于计算反馈带宽分配）和组的平均分组大小。除非包含RTCP带宽指示子报告块，否则该子报告必须始终存在，并附加到每个RSI数据包中（在这种情况下，它可能存在，但无需存在）。
Note: The RTCP Bandwidth Indication sub-report block allows the Distribution Source to hide the actual group size from the receivers while still avoiding feedback implosion.
注意：RTCP带宽指示子报告块允许分发源向接收器隐藏实际组大小，同时仍然避免反馈内爆。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT=12 | Length | Average Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Group Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT=12 | Length | Average Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Group Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Group size: 32 bits This field provides the Distribution Source's view of the number of receivers in a session. Note that the number of Media Senders is not explicitly reported since it can be derived by observing the RTCP SR packets forwarded by the Distribution Source. The group size is calculated according to the rules outlined in [1]. When this sub-report block is included, this field MUST always be present.
组大小：32位此字段提供分发源在会话中接收器数量的视图。请注意，由于可以通过观察分发源转发的RTCP SR数据包来导出媒体发送方的数量，因此未明确报告媒体发送方的数量。根据[1]中概述的规则计算组大小。包含此子报告块时，此字段必须始终存在。
Average RTCP packet size: 16 bits This field provides the Distribution Source's view of the average RTCP packet size as locally calculated, following the rules defined in [1]. The value is an unsigned integer, counting octets. When this sub-report block is included, this field MUST always be present.
平均RTCP数据包大小：16位此字段提供分发源根据[1]中定义的规则本地计算的平均RTCP数据包大小的视图。该值是一个无符号整数，包含八位字节。包含此子报告块时，此字段必须始终存在。
The Group and Average Packet Size sub-report block type (SRBT) is 12.
组和平均数据包大小子报告块类型（SRBT）为12。
In the Distribution Source Feedback Summary Model, the Distribution Source (the unicast Feedback Target) MUST listen for unicast RTCP packets sent to the RTCP port. All RTCP packets received on this port MUST be processed by the Distribution Source, as described below. The processing MUST take place per Media Sender SSRC for which Receiver Reports are received.
在分发源反馈摘要模型中，分发源（单播反馈目标）必须侦听发送到RTCP端口的单播RTCP数据包。此端口上接收的所有RTCP数据包必须由分发源处理，如下所述。必须按照接收到接收者报告的媒体发送者SSRC进行处理。
The Distribution Source acts like a regular RTCP receiver. In particular, it receives an RTP stream from each RTP Media Sender(s) and MUST calculate the proper reception statistics for these RTP streams. It MUST transmit the resulting information as report blocks contained in each RTCP packet it sends (in an RR packet).
分发源的作用类似于常规RTCP接收器。特别是，它从每个RTP媒体发送器接收RTP流，并且必须计算这些RTP流的正确接收统计信息。它必须将结果信息作为包含在其发送的每个RTCP数据包（在RR数据包中）中的报告块进行传输。
Note: This information may help to determine the transmission characteristics of the feed path from the RTP sender to the Distribution Source (if these are separate entities).
注意：此信息可能有助于确定从RTP发送方到分发源（如果这些是单独的实体）的馈送路径的传输特性。
The Distribution Source is responsible for accepting RTCP packets from the receivers and for interpreting and storing per-receiver information, as defined in [1]. The importance of providing these
分发源负责接收来自接收器的RTCP数据包，并解释和存储每个接收器的信息，如[1]中所定义。提供这些服务的重要性
functions is apparent when creating the RSI and sub-report block reports since incorrect information can have serious implications. Section 11 addresses the security risks in detail.
在创建RSI和子报告块报告时，功能是显而易见的，因为不正确的信息可能会产生严重影响。第11节详细讨论了安全风险。
As defined in [1], all RTCP reports from the Distribution Source MUST start with an RR report, followed by any relevant SDES fields. Then the Distribution Source MUST append an RSI header and sub-reports containing any summarization-specific data. In addition, either the Group and Average Packet Size sub-report or the Receiver RTCP Bandwidth sub-report block MUST be appended to the RSI header.
如[1]中所定义，来自分发源的所有RTCP报告必须以RR报告开头，后跟任何相关SDES字段。然后，分发源必须附加一个RSI头和包含任何摘要特定数据的子报告。此外，必须将组和平均数据包大小子报告或接收器RTCP带宽子报告块附加到RSI报头。
A Distribution Source has the option of masking the group size by including only an RTCP Bandwidth sub-report. If both sub-reports are included, the receiver is expected to give precedence to the information contained in the Receiver RTCP Bandwidth sub-report.
分发源可以通过仅包含RTCP带宽子报告来屏蔽组大小。如果两个子报告都包括在内，则接收机应优先考虑接收机RTCP带宽子报告中包含的信息。
The Receiver RTCP Bandwidth sub-report block provides the Distribution Source with the capability to control the amount of feedback from the receivers, and the bandwidth value MAY be increased or decreased based upon the requirements of the Distribution Source. Regardless of the value selected by the Distribution Source for the Receiver RTCP Bandwidth sub-report block, the Distribution Source MUST continue to forward Sender Reports and RSI packets at the rate allowed by the total RTCP bandwidth allocation. See Section 9 for further details about the frequency of reports.
接收器RTCP带宽子报告块为分发源提供控制来自接收器的反馈量的能力，并且带宽值可以根据分发源的要求增加或减少。无论分发源为接收方RTCP带宽子报告块选择的值如何，分发源必须继续以总RTCP带宽分配允许的速率转发发送方报告和RSI数据包。有关报告频率的更多详细信息，请参见第9节。
A Distribution Source MAY start out reporting group size and switch to Receiver RTCP Bandwidth reporting later on and vice versa. If the Distribution Source does so, it SHOULD ensure that the correspondingly indicated values for the Receiver RTCP Bandwidth sub-report roughly match, i.e., are at least the same order of magnitude.
分发源可以开始报告组大小，然后切换到接收器RTCP带宽报告，反之亦然。如果分布源这样做，则应确保接收器RTCP带宽子报告的相应指示值大致匹配，即至少为相同数量级。
In order to identify SSRC collisions, the Distribution Source is responsible for maintaining a record of each SSRC and the corresponding CNAME within at least one reporting interval by the group, in order to differentiate between clients. It is RECOMMENDED that an updated list of more than one interval be maintained to increase accuracy. This mechanism should prevent the possibility of collisions since the combination of SSRC and CNAME should be unique, if the CNAME is generated correctly. If collisions are not detected, the Distribution Source will have an inaccurate impression of the group size. Since the statistical probability is very low that collisions will both occur and be undetectable, this should not be a significant concern. In particular, the clients would have to randomly select the same SSRC and have the same username + IP address (e.g., using private address space behind a NAT router).
为了识别SSRC冲突，分发源负责在集团至少一个报告间隔内维护每个SSRC和相应CNAME的记录，以便区分客户端。建议保留一个以上间隔的更新列表，以提高准确性。如果正确生成CNAME，则此机制应防止冲突的可能性，因为SSRC和CNAME的组合应是唯一的。如果未检测到碰撞，分布源将对组大小有不准确的印象。由于统计概率很低，碰撞既会发生又无法检测，因此这不应该是一个重大问题。特别是，客户端必须随机选择相同的SSRC，并具有相同的用户名+IP地址（例如，使用NAT路由器后面的专用地址空间）。
The Distribution Source is responsible for aggregating reception-quality information received in RR packets. In doing so, the Distribution Source MUST consider the report blocks received in every RR packet and MUST NOT consider the report blocks of an SR packet.
分发源负责聚合在RR分组中接收的接收质量信息。在这样做时，分发源必须考虑在每个RR包中接收到的报告块，并且不能考虑SR包的报告块。
Note: the receivers will get the information contained in the SR packets anyway by packet forwarding, so duplication of this information should be avoided.
注意：接收方无论如何都会通过数据包转发获得SR数据包中包含的信息，因此应避免重复该信息。
For the optional sub-report blocks, the Distribution Source MAY decide which are the most significant feedback values to convey and MAY choose not to include any. The packet format provides flexibility in the amount of detail conveyed by the data points. There is a tradeoff between the granularity of the data and the accuracy of the data based on the multiplicative factor (MF), the number of buckets, and the min and max values. In order to focus on a particular region of a distribution, the Distribution Source can adjust the minimum and maximum values and either increase the number of buckets, and possibly the factorization, or decrease the number of buckets and provide more accurate values. See Appendix B for detailed examples on how to convey a summary of RTCP Receiver Reports as RSI sub-report block information.
对于可选的子报告块，分发源可以决定要传达的最重要的反馈值，并且可以选择不包括任何反馈值。数据包格式在数据点传输的细节量方面提供了灵活性。基于乘法因子（MF）、桶数以及最小值和最大值，在数据粒度和数据准确性之间存在折衷。为了专注于分布的特定区域，分布源可以调整最小值和最大值，或者增加存储桶的数量，可能还包括因子分解，或者减少存储桶的数量并提供更准确的值。有关如何将RTCP接收方报告摘要作为RSI子报告块信息传达的详细示例，请参见附录B。
For each value the Distribution Source decides to include in an RSI packet, it MUST adhere to the following measurement rules.
对于分发源决定包含在RSI数据包中的每个值，它必须遵守以下度量规则。
a) If the Distribution Source intends to use a sub-report to convey a distribution of values (Sections 7.1.3 to 7.1.7), it MUST keep per-receiver state, i.e., remember the last value V reported by the respective receiver. If a new value is reported by a receiver, the existing value MUST be replaced by the new one. The value MUST be deleted (along with the entire entry) if the receiver is timed out (as per Section 6.3.5 of [1]) or has sent a BYE packet (as per Section 6.3.7 of [1]).
a) 如果分配源打算使用子报告传达值的分配（第7.1.3节至第7.1.7节），则必须保持每个接收器的状态，即记住各接收器报告的最后一个值V。如果接收者报告新值，则必须用新值替换现有值。如果接收器超时（根据[1]第6.3.5节）或发送了BYE数据包（根据[1]第6.3.7节），则必须删除该值（连同整个条目）。
All the values collected in this way MUST be included in the creation of the subsequent Distribution sub-report block.
以这种方式收集的所有值都必须包含在后续分发子报告块的创建中。
The results should correspond as closely as possible to the values received during the interval since the last report. The Distribution Source may stack as many sub-report blocks as required in order to convey different distributions. If the distribution size exceeds the largest packet length (1008 bytes data portion), more packets MAY be stacked with additional information (but in total SHOULD NOT exceed the path MTU).
结果应尽可能接近自上次报告以来的间隔期间收到的值。分发源可以根据需要堆叠任意多个子报告块，以便传递不同的分发。如果分布大小超过最大分组长度（1008字节数据部分），则可以使用附加信息堆叠更多分组（但总的来说不应超过路径MTU）。
All stacked sub-reports MUST be internally consistent, i.e., generated from the same session data. Overlapping of distributions is therefore allowed, and variation in values should only occur as a result of data set granularity, with the more accurate bucket sizes taking precedence in the event that values differ. Non-divisible values MUST be rounded up or down to the closest bucket value, and the number of data buckets must always be an even number, padding where necessary with an additional zero bucket value to maintain consistency.
所有堆叠的子报告必须内部一致，即从相同的会话数据生成。因此，允许分布重叠，值的变化只应作为数据集粒度的结果出现，在值不同的情况下，更精确的bucket大小优先。不可分割的值必须向上或向下舍入到最接近的bucket值，并且数据bucket的数量必须始终为偶数，必要时使用额外的零bucket值填充，以保持一致性。
Note: This intentionally provides persistent full coverage of the entire session membership to avoid oscillations due to changing membership samples.
注意：这有意地提供对整个会话成员的持久完全覆盖，以避免由于更改成员资格样本而引起的振荡。
Scheduling the transmission of summarization reports is left to the discretion of the Distribution Source. However, the Distribution Source MUST adhere to the bandwidth limitations for Receiver Reports as defined for the respective AV profile in use.
摘要报告的传输安排由分发源自行决定。但是，分发源必须遵守为使用中的各个AV配置文件定义的接收器报告的带宽限制。
b) If the Distribution Source intends to report a short summary using the General Statistics sub-report block format, defined in Section 7.1.10, for EACH of the values included in the report (MFL, HCNL, average inter-arrival jitter), it MUST keep a timer T_summary as well as a sufficient set of variables to calculate the summaries for the last three reporting intervals. This MAY be achieved by keeping per-receiver state (i.e., remember the last value V reported by the respective receiver) or by maintaining summary variables for each of these intervals.
b) 如果分发源打算使用第7.1.10节中定义的通用统计子报告块格式，为报告中包含的每个值（MFL、HCNL、平均到达间抖动）报告一份简短摘要，它必须保留一个计时器T_摘要以及一组足够的变量，以计算最后三个报告间隔的摘要。这可以通过保持每个接收器的状态（即，记住各个接收器报告的最后一个值V）或通过保持每个间隔的汇总变量来实现。
The summary values are included here to reflect the current group situation. By recording the last three reporting intervals, the Distribution Source incorporates reports from all members while allowing for individual RTCP Receiver Report packet losses. The process of collecting these values also aims to avoid resetting any of the values and then having to send out an RSI report based upon just a few values collected. If data is available for less than three reporting intervals (as will be the case for the first two reports sent), only those values available are considered.
此处包含的汇总值反映了当前的集团情况。通过记录最后三个报告间隔，分发源合并来自所有成员的报告，同时允许单个RTCP接收器报告数据包丢失。收集这些值的过程还旨在避免重置任何值，然后仅根据收集的几个值发送RSI报告。如果数据可用时间少于三个报告间隔（发送的前两个报告就是这种情况），则只考虑这些可用值。
The timer T_summary MUST be initialized as T_summary = 1.5 * Td, where Td is the deterministic reporting interval, and MUST be updated following timer reconsideration whenever the group size or the average RTCP size ("avg_rtcp_size") changes. This choice should allow each receiver to report once per interval.
计时器T_摘要必须初始化为T_摘要=1.5*Td，其中Td是确定的报告间隔，并且必须在组大小或平均RTCP大小（“avg_RTCP_大小”）改变时在计时器重新考虑后更新。此选项应允许每个接收器每间隔报告一次。
Td
__^__
t0/ \ t1 t2 t3 t4 t5
---+---------+---------+---------+---------+---------+------->
\____ ____/ : : : :
: V : : : : :
:T_summary: : : : :
:=1.5 * Td: : : : :
\______________ ______________/ : :
: V : : :
: 3 * T_summary : :
: : : :
\______________ ______________/ :
: V :
: 3 * T_summary :
: :
\______________ ______________/
V
3 * T_summary
Td
__^__
t0/ \ t1 t2 t3 t4 t5
---+---------+---------+---------+---------+---------+------->
\____ ____/ : : : :
: V : : : : :
:T_summary: : : : :
:=1.5 * Td: : : : :
\______________ ______________/ : :
: V : : :
: 3 * T_summary : :
: : : :
\______________ ______________/ :
: V :
: 3 * T_summary :
: :
\______________ ______________/
V
3 * T_summary
Figure 2: Overview of Summarization Reporting
图2：总结报告概述
Figure 2 depicts how the summarization reporting shall be performed. At time t3, the RTCP reports collected from t0 through t3 are included in the RSI reporting; at time t4, those from t1 through t4; and so on. The RSI summary report sent MUST NOT include any RTCP report from more than three reporting intervals ago, e.g., the one sent at time t5, must not include reports received at the Distribution Source prior to t2.
图2描述了总结报告应如何执行。在时间t3，从t0到t3收集的RTCP报告包括在RSI报告中；在时间t4，从t1到t4的那些；等等发送的RSI摘要报告不得包括三个以上报告间隔之前的任何RTCP报告，例如，在时间t5发送的报告，不得包括t2之前在分发源收到的报告。
When following the Feedback Summary Model, the Distribution Source MAY reflect any other RTCP packets of potential relevance to the receivers (such as APP, RTPFB, PSFB) to the receiver group. Also, it MAY decide not to forward other RTCP packets not needed by the receivers such as BYE, RR, SDES (because the Distribution Source performs collision resolution), group size estimation, and RR aggregation. The Distribution Source MUST NOT forward RR packets to the receiver group.
当遵循反馈摘要模型时，分发源可将与接收器（例如APP、RTPFB、PSFB）潜在相关的任何其他RTCP分组反映到接收器组。此外，它可能决定不转发接收机不需要的其他RTCP包，例如BYE、RR、SDE（因为分发源执行冲突解决）、组大小估计和RR聚合。分发源不得将RR数据包转发到接收器组。
If the Distribution Source is able to interpret and aggregate information contained in any RTCP packets other than RR, it MAY include the aggregated information along with the RSI packet in its own compound RTCP packet.
如果分发源能够解释和聚合包含在除RR以外的任何RTCP分组中的信息，则它可以将聚合信息连同RSI分组包括在其自己的复合RTCP分组中。
Aggregation MAY be a null operation, i.e., the Distribution Source MAY simply append one or more RTCP packets from receivers to the compound RTCP packet (containing at least RR, SDES, and RSI from the Distribution Source).
聚合可以是空操作，即，分发源可以简单地将来自接收器的一个或多个RTCP分组附加到复合RTCP分组（至少包含来自分发源的RR、sde和RSI）。
Note: This is likely to be useful only for a few cases, e.g., to forward aggregated information from RTPFB Generic NACK packets and thereby maintain the damping property of [15].
注：这可能仅在少数情况下有用，例如，转发来自RTPFB通用NACK数据包的聚合信息，从而保持[15]的阻尼特性。
Note: This entire processing rule implies that the flow of information contained in non-RR RTCP packets may terminate at the Distribution Source, depending on its capabilities and configuration.
注意：整个处理规则意味着非RR RTCP数据包中包含的信息流可能在分发源终止，具体取决于其功能和配置。
The configuration of the RTCP SSM media session (expressed in SDP) MUST specify explicitly which processing the Distribution Source will apply to which RTCP packets. See Section 10.1 for details.
RTCP SSM媒体会话的配置（以SDP表示）必须明确指定分发源将应用于哪个RTCP数据包的哪个处理。详见第10.1节。
If the Media Sender(s) are not part of the SSM group for RTCP packet reflection, the Distribution Source MUST explicitly inform the Media Senders of the receiver group. To achieve this, the Distribution Source has two options: 1) it forwards the RTCP RR and SDES packets received from the receivers to the Media Sender(s); or 2) if the Media Senders also support the RTCP RSI packet, the Distribution Source sends the RSI packets not just to the receivers but also to the Media Senders.
如果媒体发送方不属于RTCP数据包反射的SSM组，则分发源必须明确通知媒体发送方接收方组。为此，分发源有两个选项：1）它将从接收器接收的RTCP RR和SDES数据包转发给媒体发送器；或2）如果媒体发送方也支持RTCP RSI数据包，则分发源不仅将RSI数据包发送给接收方，还将发送给媒体发送方。
If the Distribution Source decides to forward RR and SDES packets unchanged, it MAY also forward any other RTCP packets to the senders.
如果分发源决定不改变地转发RR和SDES数据包，它还可以将任何其他RTCP数据包转发给发送方。
If the Distribution Source decides to forward RSI packets to the senders, the considerations of Section 7.2.2 apply.
如果分发源决定将RSI数据包转发给发送方，则第7.2.2节的注意事项适用。
The Distribution Source also receives RTCP (including SR) packets from the RTP Media Senders.
分发源还从RTP媒体发送器接收RTCP（包括SR）数据包。
The Distribution Source MUST forward all RTCP packets from the Media Senders to the RTP receivers.
分发源必须将所有RTCP数据包从媒体发送方转发到RTP接收方。
If there is more than one Media Sender and these Media Senders do not communicate via ASM with the Distribution Source and each other, the Distribution Source MUST forward each RTCP packet from any one Media Sender to all other Media Senders.
如果有多个媒体发送者，且这些媒体发送者不通过ASM与分发源通信，且彼此之间不通信，则分发源必须将每个RTCP数据包从任何一个媒体发送者转发给所有其他媒体发送者。
As noted above, the Distribution Source is a receiver from an RTP perspective. The Distribution Sources MUST calculate its deterministic transmission interval Td as every other receiver; however, it MAY adjust its available data rate depending on the destination transport address and its local operation:
如上所述，从RTP的角度来看，分发源是接收机。分布源必须像其他接收器一样计算其确定的传输间隔Td；但是，它可以根据目的地传输地址及其本地操作调整其可用数据速率：
1. For sending its own RTCP reports to the SSM group towards the receivers, the Distribution Source MAY use up to the joint share of all receivers as it is forwarding summaries on behalf of all of them. Thus, the Distribution Source MAY send its reports up to every Td/R time units, with R being the number of receivers.
1. 为了向接收者发送其自己的RTCP报告给SSM集团，分发源可以使用最多所有接收者的共同份额，因为它代表所有接收者转发摘要。因此，分发源可以向每个Td/R时间单位发送其报告，其中R是接收机的数量。
2. For sending its own RTCP reports to the Media Senders only (i.e., if the Media Senders are not part of the SSM group), the allocated rate depends on the operation of the Distribution Source:
2. 对于仅向媒体发送者发送其自己的RTCP报告（即，如果媒体发送者不属于SSM组），分配的速率取决于分发源的操作：
a) If the Distribution Source only sends RSI packets along with its own RTCP RR packets, the same rate calculation applies as for #1 above.
a) 如果分发源仅发送RSI数据包及其自己的RTCP RR数据包，则与上述#1相同的速率计算适用。
b) If the Distribution Source forwards RTCP packets from all other receivers to the Media Senders, then it MUST adhere to the same bandwidth share for its own transmissions as all other receivers and use the calculation as per [1].
b) 如果分发源将RTCP数据包从所有其他接收器转发到媒体发送器，则其自身传输必须遵守与所有其他接收器相同的带宽共享，并按照[1]使用计算。
A Distribution Source observing RTP packets from a Media Sender with an SSRC that collides with its own chosen SSRC MUST change its own SSRC following the procedures of [1] and MUST do so immediately after noticing.
观察来自媒体发送方的RTP数据包的分发源的SSRC与其自己选择的SSRC发生冲突，必须按照[1]中的程序更改其自己的SSRC，并且必须在注意到后立即更改。
A Distribution Source MAY use out-of-band information about the Media Sender SSRC(s) used in the media session when available to avoid SSRC collisions with Media Senders. Nevertheless, the Distribution Source MUST monitor Sender Report (SR) packets to detect any changes, observe collisions, and then follow the above collision-resolution procedure.
分发源可以使用有关媒体会话中使用的媒体发送方SSRC的带外信息（如果可用），以避免SSRC与媒体发送方发生冲突。不过，分发源必须监视发送方报告（SR）数据包以检测任何更改、观察冲突，然后遵循上述冲突解决过程。
For collision resolution between the Distribution Source and receivers or the Feedback Target(s) (if a separate entity, as described in the next subsection), the Distribution Source and the Feedback Target (if separate) operate similar to ordinary receivers.
对于分配源和接收器或反馈目标（如果是单独的实体，如下一小节所述）之间的冲突解决，分配源和反馈目标（如果是单独的）的操作与普通接收器类似。
If the Distribution Source and the Feedback Target are disjoint, the processing of the Distribution Source is limited by the amount of RTCP feedback information made available by the Feedback Target.
如果分发源和反馈目标不相交，则分发源的处理受反馈目标提供的RTCP反馈信息量的限制。
The Feedback Target(s) MAY simply forward all RTCP packets incoming from the RTP receivers to the Distribution Source, in which case the Distribution Source will have all the necessary information available to perform all the functions described above.
反馈目标可以简单地将从RTP接收器传入的所有RTCP分组转发到分发源，在这种情况下，分发源将具有可用于执行上述所有功能的所有必要信息。
The Feedback Target(s) MAY also perform aggregation of incoming RTCP packets and send only aggregated information to the Distribution Source. In this case, the Feedback Target(s) MUST use correctly formed RTCP packets to communicate with the Distribution Source and they MUST operate in concert with the Distribution Source so that the Distribution Source and the Feedback Target(s) appear to be operating as a single entity. The Feedback Target(s) MUST report their observed receiver group size to the Distribution Source, either explicitly by means of RSI packets or implicitly by forwarding all RR packets.
反馈目标还可以执行传入RTCP分组的聚合，并且仅向分发源发送聚合信息。在这种情况下，反馈目标必须使用正确形成的RTCP数据包与分发源通信，并且它们必须与分发源协同工作，以便分发源和反馈目标看起来是作为单个实体工作的。反馈目标必须通过RSI数据包显式地或通过转发所有RR数据包隐式地向分发源报告其观察到的接收器组大小。
Note: For example, for detailed statistics reporting, the Distribution Source and the Feedback Target(s) may need to agree on a common reporting granularity so that the Distribution Source can aggregate the buckets incoming from various Feedback Targets into a coherent report sent to the receivers.
注：例如，对于详细的统计报告，分发源和反馈目标可能需要就通用的报告粒度达成一致，以便分发源可以将从各种反馈目标传入的bucket聚合为发送给接收者的一致报告。
The joint behavior of the Distribution Source and Feedback Target(s) MUST be reflected in the (SDP-based) media session description as per Section 7.2.2.
根据第7.2.2节，分发源和反馈目标的联合行为必须反映在（基于SDP的）媒体会话描述中。
If the Feedback Target performs summarization functions, it MUST also act as a receiver and choose a unique SSRC for its own reporting towards the Distribution Source. The collision-resolution considerations for receivers apply.
如果反馈目标执行摘要功能，则它还必须充当接收者，并为自己向分发源的报告选择唯一的SSRC。适用于接收器的冲突解决注意事项。
An RTP receiver MUST process RSI packets and adapt session parameters, such as the RTCP bandwidth, based on the information received. The receiver no longer has a global view of the session and will therefore be unable to receive information from individual receivers aside from itself. However, the information conveyed by the Distribution Source can be extremely detailed, providing the receiver with an accurate view of the session quality overall, without the processing overhead associated with listening to and analyzing all Receiver Reports.
RTP接收器必须处理RSI数据包，并根据接收到的信息调整会话参数，如RTCP带宽。接收器不再具有会话的全局视图，因此除了自身之外，将无法从单个接收器接收信息。然而，分发源传送的信息可以非常详细，从而为接收器提供会话质量的整体准确视图，而不需要与侦听和分析所有接收器报告相关联的处理开销。
The RTP receiver MUST process the report blocks contained in any RTP SR and RR packets to complete its view of the RTP session.
RTP接收器必须处理任何RTP SR和RR数据包中包含的报告块，以完成其RTP会话视图。
The SSRC collision list MUST be checked against the SSRC selected by the receiver to ensure there are no collisions as MUST be incoming RTP packets from the Media Senders. A receiver observing RTP packets from a Media Sender with an SSRC that collides with its own chosen SSRC MUST change its own SSRC following the procedures of [1]. The receiver MUST do so immediately after noticing and before sending any (further) RTCP feedback messages.
必须对照接收方选择的SSRC检查SSRC冲突列表，以确保与来自媒体发送方的传入RTP数据包一样没有冲突。接收端观察到来自媒体发送方的RTP数据包时，SSRC与其自己选择的SSRC发生冲突，必须按照[1]的过程更改自己的SSRC。接收方必须在注意到并发送任何（进一步）RTCP反馈信息后立即这样做。
A Group and Average Packet Size sub-report block is most likely to be appended to the RSI header (either a Group Size sub-report or an RTCP Bandwidth sub-report MUST be included). The group size n allows a receiver to calculate its share of the RTCP bandwidth, r. Given R, the total available RTCP bandwidth share for receivers (in the SSM RTP session) r = R/(n). For the group size calculation, the RTP receiver MUST NOT include the Distribution Source, i.e., the only RTP receiver sending RSI packets.
组和平均数据包大小子报告块最有可能附加到RSI头（必须包括组大小子报告或RTCP带宽子报告）。组大小n允许接收机计算其在RTCP带宽中的份额r。给定R，接收机的总可用RTCP带宽共享（在SSM RTP会话中）R=R/（n）。对于组大小计算，RTP接收器不得包括分发源，即唯一发送RSI数据包的RTP接收器。
The receiver RTCP bandwidth field MAY override this value. If the receiver RTCP bandwidth field is present, the receiver MUST use this value as its own RTCP reporting bandwidth r.
receiver RTCP带宽字段可能会覆盖此值。如果存在接收方RTCP带宽字段，则接收方必须将此值用作其自身的RTCP报告带宽r。
If the RTCP bandwidth field was used by the Distribution Source in an RTCP session but this field was not included in the last five RTCP RSI reports, the receiver MUST revert to calculating its bandwidth share based upon the group size information.
如果分发源在RTCP会话中使用了RTCP带宽字段，但该字段未包含在最近五个RTCP RSI报告中，则接收器必须恢复到基于组大小信息计算其带宽共享。
If the receiver has not received any RTCP RSI packets from the Distribution Source for a period of five times the sender reporting interval, it MUST cease transmitting RTCP Receiver Reports until the next RTCP RSI packet is received.
如果接收方在发送方报告间隔的五倍时间内没有从分发源接收到任何RTCP RSI数据包，则必须停止发送RTCP接收方报告，直到收到下一个RTCP RSI数据包。
The receiver can use the summarized data as desired. This data is most useful in providing the receiver with a more global view of the conditions experienced by other receivers and enables the client to place itself within the distribution and establish the extent to which its reported conditions correspond to the group reports as a whole. Appendix B provides further information and examples of data processing at the receiver.
接收器可以根据需要使用汇总数据。该数据在向接收者提供其他接收者所经历的情况的更全局视图方面最为有用，并使客户能够将自己置于分销范围内，并确定其报告的情况与整个集团报告相对应的程度。附录B提供了接收器数据处理的进一步信息和示例。
The receiver SHOULD assume that any sub-report blocks in the same packet correspond to the same data set received by the Distribution Source during the last reporting time interval. This applies to packets with multiple blocks, where each block conveys a different range of values.
接收器应假设同一数据包中的任何子报告块对应于分发源在上一个报告时间间隔内接收的相同数据集。这适用于具有多个块的数据包，其中每个块传递不同范围的值。
A receiver MUST NOT rely on all of the RTCP packets it sends reaching the Media Senders or any other receiver. While RR statistics will be aggregated, BYE packets will be processed, and SSRC collisions will usually be announced, processing and/or forwarding of further RTCP packets is up to the discretion of the Distribution Source and will be performed as specified in the session description.
接收方不得依赖其发送的到达媒体发送方或任何其他接收方的所有RTCP数据包。虽然将聚合RR统计信息，处理BYE数据包，并且通常会宣布SSRC冲突，但进一步RTCP数据包的处理和/或转发由分发源决定，并将按照会话描述中的规定执行。
If a receiver has out-of-band information available about the Media Sender SSRC(s) used in the media session, it MUST NOT use the same SSRC for itself. The receiver MUST be aware that such out-of-band information may be outdated (i.e., that the sender SSRC(s) may have changed) and MUST follow the above collision-resolution procedure if necessary.
如果接收器具有关于媒体会话中使用的媒体发送方SSRC的带外信息，则其自身不得使用相同的SSRC。接收方必须意识到，此类带外信息可能已经过时（即，发送方SSRC可能已经更改），必要时必须遵循上述冲突解决程序。
A receiver MAY use such Media Sender SSRC information when available but MUST beware of potential changes to the SSRC (which can only be learned from Sender Report (SR) packets).
接收方可在可用时使用此类媒体发送方SSRC信息，但必须注意SSRC的潜在变化（只能从发送方报告（SR）数据包中获知）。
Media Senders listen on a unicast or multicast transport address for RTCP reports sent by the receivers (and forwarded by the Distribution Source) or other Media Senders (optionally forwarded by the Distribution Source).
媒体发送方在单播或多播传输地址上侦听接收方（并由分发源转发）或其他媒体发送方（可选地由分发源转发）发送的RTCP报告。
Unlike in the case of the simple forwarding model, Media Senders MUST be able to process RSI packets from the Distribution Source to determine the group size and their own RTCP bandwidth share. Media Senders MUST also be capable of determining the group size (and their corresponding RTCP bandwidth share) from listening to (forwarded) RTCP RR and SR packets (as mandated in [1]).
与简单转发模型不同，媒体发送者必须能够处理来自分发源的RSI数据包，以确定组大小和他们自己的RTCP带宽共享。媒体发送方还必须能够通过侦听（转发）RTCP RR和SR数据包（如[1]中规定）来确定组大小（及其相应的RTCP带宽共享）。
As long as they send RTP packets, they MUST also send RTCP SRs, as defined in [1].
只要它们发送RTP数据包，它们还必须发送RTCP SRs，如[1]中所定义。
A Media Sender that observes an SSRC collision with another entity that is not also a Media Sender MAY delay its own collision-resolution actions, as per [1], by 5 * 1.5 * Td, with Td being the deterministic calculated reporting interval, for receivers to see whether the conflict still exists. SSRC collisions with other Media Senders MUST be acted upon immediately.
根据[1]，观察到与非媒体发送方的另一实体发生SSRC冲突的媒体发送方可将其自身的冲突解决行动延迟5*1.5*Td，Td是确定的计算报告间隔，以便接收方查看冲突是否仍然存在。必须立即处理与其他媒体发送器的SSRC冲突。
Note: This gives precedence to Media Senders and places the burden of collision resolution on RTP receivers.
注意：这将优先考虑媒体发送器，并将冲突解决的负担置于RTP接收器上。
Sender SSRC information MAY be communicated out-of-band, e.g., by means of SDP media descriptions. Therefore, senders SHOULD NOT change their own SSRC eagerly or unnecessarily.
发送方SSRC信息可在带外传送，例如通过SDP媒体描述。因此，发件人不应急于或不必要地更改自己的SSRC。
The original RTP specification allows a session to use mixers and translators to help connect heterogeneous networks into one session. There are a number of issues, however, which are raised by the unicast feedback model proposed in this document. The term 'mixer' refers to devices that provide data stream multiplexing where multiple sources are combined into one stream. Conversely, a translator does not multiplex streams but simply acts as a bridge between two distribution mechanisms, e.g., a unicast-to-multicast network translator. Since the issues raised by this document apply equally to either a mixer or translator, the latter are referred to from this point onwards as mixer-translator devices.
原始RTP规范允许会话使用混频器和转换器帮助将异构网络连接到一个会话中。然而，本文提出的单播反馈模型提出了许多问题。术语“混合器”是指提供数据流多路复用的设备，其中多个源被组合成一个流。相反，转换器不复用流，而只是充当两个分发机制（例如，单播到多播网络转换器）之间的桥梁。由于本文件提出的问题同样适用于混音器或翻译器，因此从这一点起，后者被称为混音器翻译器设备。
A mixer-translator between distribution networks in a session must ensure that all members in the session receive all the relevant traffic to enable the usual operation by the clients. A typical use may be to connect an older implementation of an RTP client with an SSM distribution network, where the client is not capable of unicasting feedback to the source. In this instance, the mixer-translator must join the session on behalf of the client and send and receive traffic from the session to the client. Certain hybrid scenarios may have different requirements.
会话中分发网络之间的混音转换器必须确保会话中的所有成员都接收到所有相关通信量，以支持客户端的正常操作。典型的用途可能是将较旧的RTP客户端实现与SSM分发网络连接，其中客户端无法单播到源的反馈。在这种情况下，混音器转换器必须代表客户端加入会话，并从会话向客户端发送和接收通信量。某些混合方案可能有不同的要求。
The mixer-translator MUST adhere to the SDP description [5] for the single-source session (Section 11) and use the feedback mechanism indicated. Implementers of receivers SHOULD be aware that when a mixer-translator is present in the session, more than one Media Sender may be active, since the mixer-translator may be forwarding traffic to the SSM receivers either from multiple unicast sources or from an ASM session. Receivers SHOULD still forward unicast RTCP reports in the usual manner to their assigned Feedback Target/Distribution Source, which in this case -- by assumption -- would be the mixer-translator itself. It is RECOMMENDED that the simple packet-reflection mechanism be used under these circumstances, since attempting to coordinate RSI + summarization reporting between more than one source may be complicated unless the mixer-translator is capable of summarization.
混音器转换器必须遵守单源会话（第11节）的SDP说明[5]，并使用指示的反馈机制。接收机的实现者应当知道，当混频器转换器存在于会话中时，多个媒体发送器可能处于活动状态，因为混频器转换器可能正在从多个单播源或ASM会话向SSM接收机转发通信量。接收者仍应以通常的方式将单播RTCP报告转发给其指定的反馈目标/分发源，在这种情况下，假设是混音器转换器本身。建议在这些情况下使用简单的数据包反射机制，因为尝试在多个源之间协调RSI+摘要报告可能会很复杂，除非混音器转换器能够进行摘要。
Encryption and security issues are discussed in detail in Section 11. A mixer-translator MUST be able to follow the same security policy as the client in order to unicast RTCP feedback to the source, and it therefore MUST be able to apply the same authentication and/or encryption policy required for the session. Transparent bridging and
第11节详细讨论了加密和安全问题。混音器转换器必须能够遵循与客户端相同的安全策略，以便将RTCP反馈单播到源，因此必须能够应用会话所需的相同身份验证和/或加密策略。透明桥接和
subsequent unicast feedback to the source, where the mixer-translator is not acting as the Distribution Source, is only allowed if the mixer-translator can conduct the same source authentication as required by the receivers. A translator MAY forward unicast packets on behalf of a client but SHOULD NOT translate between multicast-to-unicast flows towards the source without authenticating the source of the feedback address information.
只有当混音器转换器能够按照接收机的要求进行相同的源认证时，才允许对源进行后续单播反馈，混音器转换器不作为分发源。转换器可以代表客户端转发单播分组，但在未认证反馈地址信息的源的情况下，不应在朝向源的多播到单播流之间进行转换。
The Control Traffic Bandwidth referred to in [1] is an arbitrary amount that is intended to be supplied by a session-management application (e.g., SDR [21]) or decided based upon the bandwidth of a single sender in a session.
[1]中提到的控制业务带宽是预定由会话管理应用程序（例如，SDR[21]）提供或基于会话中单个发送方的带宽决定的任意量。
The RTCP transmission interval calculation either remains the same as in the original RTP specification [1] or uses the algorithm in [10] when bandwidth modifiers have been specified for the session.
RTCP传输间隔计算要么与原始RTP规范[1]中的相同，要么在为会话指定带宽修饰符时使用[10]中的算法。
If the Distribution Source is operating in Simple Feedback Model (which may be indicated in the corresponding session description for the media session but which the receiver also notices from the absence of RTCP RSI packets), a receiver MUST calculate the number of other members in a session based upon its own SSRC count, derived from the forwarded Sender and Receiver Reports it receives. The receiver MUST calculate the average RTCP packet size from all the RTCP packets it receives.
如果分发源在简单反馈模式下运行（可能在媒体会话的相应会话描述中指出，但接收方也注意到没有RTCP RSI数据包），则接收方必须根据其自身的SSRC计数计算会话中其他成员的数量，从转发的发送方和接收方报告派生。接收器必须根据其接收的所有RTCP数据包计算平均RTCP数据包大小。
If the Distribution Source is operating in Distribution Source Feedback Summary Model, the receiver MUST use either the group size field and the average RTCP packet size field or the Receiver Bandwidth field from the respective sub-report blocks appended to the RSI packet.
如果分发源在分发源反馈摘要模型中运行，则接收器必须使用附加到RSI数据包的相应子报告块中的组大小字段和平均RTCP数据包大小字段或接收器带宽字段。
A receiver uses these values as input to the calculation of the deterministic calculated interval as per [1] and [10].
接收机使用这些值作为输入，根据[1]和[10]计算确定的计算间隔。
If operating in Simple Feedback Model, the Distribution Source MUST calculate the transmission interval for its Receiver Reports and associated RTCP packets, based upon the above control traffic bandwidth, and MUST count itself as RTP receiver. Receiver Reports will be forwarded as they arrive without further consideration. The Distribution Source MAY choose to validate that all or selected receivers roughly adhere to the calculated bandwidth constraints and
如果在简单反馈模型中运行，则分发源必须根据上述控制流量带宽计算其接收器报告和相关RTCP数据包的传输间隔，并且必须将自身计为RTP接收器。接收人报告到达时将转发，无需进一步考虑。分发源可以选择验证所有或选定的接收机大致遵守计算出的带宽约束，并且
MAY choose to drop excess packets for receivers that do not. In all cases, the average RTCP packet size is determined from the forwarded Media Senders' and receivers' RTCP packets and from those originated by the Distribution Source.
可能会选择丢弃多余的数据包，以便接收不需要的数据包。在所有情况下，平均RTCP数据包大小由转发媒体发送方和接收方的RTCP数据包以及分发源发起的RTCP数据包确定。
If operating in Distribution Source Feedback Summary Model, the Distribution Source does not share the forward RTCP bandwidth with any of the receivers. Therefore, the Distribution Source SHOULD use the full RTCP bandwidth for its Receiver Reports and associated RTCP packets, as well as RTCP RSI packets. In this case, the average RTCP packet size is only determined from the RTCP packets originated by the Distribution Source.
如果在分布源反馈摘要模型中运行，则分布源不与任何接收机共享前向RTCP带宽。因此，分发源应为其接收器报告和相关RTCP数据包以及RTCP RSI数据包使用完整的RTCP带宽。在这种情况下，平均RTCP数据包大小仅由分发源发起的RTCP数据包确定。
The Distribution Source uses these values as input to the calculation of the deterministic calculated interval as per [1] and [10].
根据[1]和[10]，分布源使用这些值作为计算确定性计算间隔的输入。
In Simple Feedback Model, the Media Senders obtain all RTCP SRs and RRs as they would in an ASM session, except that the packets are forwarded by the Distribution Source. They MUST perform their RTCP group size estimate and calculation of the deterministic transmission interval as per [1] and [10].
在简单反馈模型中，媒体发送方获得所有RTCP SRs和RRs，就像在ASM会话中一样，但数据包由分发源转发。他们必须按照[1]和[10]进行RTCP组大小估计和确定性传输间隔计算。
In Distribution Source Feedback Summary Model, the Media Senders obtain all RTCP SRs as they would in an ASM session. They receive either RTCP RR reports as in ASM (in case these packets are forwarded by the Distribution Source) or RSI packets containing summaries. In the former case, they MUST perform their RTCP group size estimate and calculation of the deterministic transmission interval as per [1] and [10]. In the latter case, they MUST combine the information obtained from the Sender Reports and the RSI packets to create a complete view of the group size and the average RTCP packet size and perform the calculation of the deterministic transmission interval, as per [1] and [10], based upon these input values.
在分发源反馈摘要模型中，媒体发送方获得所有RTCP SR，就像在ASM会话中一样。它们接收ASM中的RTCP RR报告（如果这些数据包由分发源转发）或包含摘要的RSI数据包。在前一种情况下，他们必须按照[1]和[10]进行RTCP组大小估计和确定性传输间隔计算。在后一种情况下，他们必须结合从发送方报告和RSI数据包获得的信息，以创建组大小和平均RTCP数据包大小的完整视图，并根据[1]和[10]根据这些输入值计算确定的传输间隔。
If the RTP session is an AVPF session [15] or an SAVPF session [28] (as opposed to a regular AVP [6] session), the receivers MAY modify their RTCP report scheduling, as defined in [15]. Use of AVPF or SAVPF does not affect the Distribution Source's RTCP transmission or forwarding behavior.
如果RTP会话是AVPF会话[15]或SAVPF会话[28]（与常规AVP[6]会话相反），则接收方可以修改其RTCP报告调度，如[15]中所定义。使用AVPF或SAVPF不会影响分发源的RTCP传输或转发行为。
It is RECOMMENDED that a Distribution Source and possible separate Feedback Target(s) be configured to forward AVPF/SAVPF-specific RTCP packets in order to not counteract the damping mechanism built into AVPF; optionally, they MAY aggregate the feedback information from
建议配置分配源和可能的单独反馈目标，转发AVPF/SAVPF特定RTCP数据包，以避免抵消AVPF中内置的阻尼机制；或者，他们可以聚合来自的反馈信息
the receivers as per Section 7.2.2. If only generic feedback packets that are understood by the Distribution Source and that can easily be aggregated are in use, the Distribution MAY combine several incoming RTCP feedback packets and forward the aggregate along with its next RTCP RR/RSI packet. In any case, the Distribution Source and Feedback Target(s) SHOULD minimize the extra delay when forwarding feedback information, but the Distribution Source MUST stay within its RTCP bandwidth constraints.
接收器应符合第7.2.2节的要求。如果仅使用分发源理解且易于聚合的通用反馈包，则分发可以组合多个传入的RTCP反馈包，并将聚合与其下一个RTCP RR/RSI包一起转发。在任何情况下，分发源和反馈目标应在转发反馈信息时将额外延迟降至最低，但分发源必须保持在其RTCP带宽限制范围内。
In the event that specific APP packets without a format and summarization mechanism understood by the Feedback Target(s) and/or the Distribution Source are to be used, it is RECOMMENDED that such packets are forwarded with minimal delay. Otherwise, the capability of the receiver to send timely feedback messages is likely to be affected.
如果要使用没有反馈目标和/或分发源理解的格式和摘要机制的特定APP包，建议以最小延迟转发此类包。否则，接收器及时发送反馈消息的能力可能会受到影响。
The Session Description Protocol (SDP) [5] is used as a means to describe media sessions in terms of their transport addresses, codecs, and other attributes. Signaling that RTCP feedback will be provided via unicast, as specified in this document, requires another session parameter in the session description. Similarly, other SSM RTCP feedback parameters need to be provided, such as the summarization model at the sender and the target unicast address to which to send feedback information. This section defines the SDP parameters that are needed by the proposed mechanisms in this document (and that have been registered with IANA).
会话描述协议（SDP）[5]用作根据传输地址、编解码器和其他属性描述媒体会话的方法。如本文件所述，通过单播发送RTCP反馈信号需要会话描述中的另一个会话参数。类似地，需要提供其他SSM RTCP反馈参数，例如发送方的摘要模型和要向其发送反馈信息的目标单播地址。本节定义了本文件中提出的机制所需的SDP参数（已在IANA注册）。
A new session-level attribute MUST be used to indicate the use of unicast instead of multicast feedback: "rtcp-unicast".
必须使用新的会话级别属性来指示使用单播而不是多播反馈：“rtcp单播”。
This attribute uses one parameter to specify the model of operation. An optional set of parameters specifies the behavior for RTCP packet types (and subtypes).
此属性使用一个参数指定操作模型。一组可选参数指定RTCP数据包类型（和子类型）的行为。
rtcp-unicast:reflection
rtcp单播：反射
This attribute MUST be used to indicate the "Simple Feedback" model of operation where packet reflection is used by the Distribution Source (without further processing).
此属性必须用于指示分发源使用包反射（无需进一步处理）的“简单反馈”操作模型。
rtcp-unicast:rsi *(SP <processing>:<rtcp-type>])
rtcp-unicast:rsi *(SP <processing>:<rtcp-type>])
This attribute MUST be used to indicate the "Distribution Source Feedback Summary" model of operation. In this model, a list or parameters may be used to explicitly specify how RTCP packets originated by receivers are handled. Options for processing a given RTCP packet type are:
此属性必须用于指示“分发源反馈摘要”操作模式。在该模型中，可以使用列表或参数来明确指定如何处理由接收器发起的RTCP数据包。处理给定RTCP数据包类型的选项有：
aggr: The Distribution Source has means for aggregating the contents of the RTCP packets and will do so.
aggr：分发源具有聚合RTCP数据包内容的方法，并将这样做。
forward: The Distribution Source will forward the RTCP packet unchanged.
转发：分发源将原封不动地转发RTCP数据包。
term: The Distribution Source will terminate the RTCP packet.
术语：分发源将终止RTCP数据包。
The default rules applying if no parameters are specified are as follows:
如果未指定参数，则应用的默认规则如下：
RR and SDES packets MUST be aggregated and MUST lead to RSI packets being generated. All other RTP packets MUST be terminated at the Distribution Source (or Feedback Target(s)).
RR和SDES数据包必须聚合，并且必须导致生成RSI数据包。所有其他RTP数据包必须在分发源（或反馈目标）处终止。
The SDP description needs only to specify deviations from the default rules. Aggregation of RR packets and forwarding of SR packets MUST NOT be changed.
SDP描述只需指定与默认规则的偏差。不得更改RR数据包的聚合和SR数据包的转发。
The token for the new SDP attribute is "rtcp-unicast" and the formal SDP ABNF syntax for the new attribute value is as follows:
新SDP属性的标记为“rtcp unicast”，新属性值的正式SDP ABNF语法如下：
att-value = "reflection" / "rsi" *(SP rsi-rule)
att value=“反射”/“rsi”*（SP rsi规则）
rsi-rule = processing ":" rtcp-type
rsi规则=处理“：“rtcp类型
processing = "aggr" / "forward" / "term" / token ;keep it extensible
processing = "aggr" / "forward" / "term" / token ;keep it extensible
rtcp-type = 3*3DIGIT ;the RTCP type (192, 193, 202--209)
rtcp-type = 3*3DIGIT ;the RTCP type (192, 193, 202--209)
In a Source-Specific Multicast RTCP session, the address of the Distribution Source needs to be indicated both for source-specific joins to the multicast group and for addressing unicast RTCP packets on the backchannel from receivers to the Distribution Source.
在特定于源的多播RTCP会话中，需要为特定于源的多播组连接和从接收器到分发源的反向通道上的单播RTCP数据包寻址指示分发源的地址。
This is achieved by following the proposal for SDP source filters documented in [4]. According to the specification, only the inclusion model ("a=source-filter:incl") MUST be used for SSM RTCP.
这是通过遵循[4]中记录的SDP源过滤器建议来实现的。根据规范，SSM RTCP只能使用包含模型（“a=源过滤器：incl”）。
There SHOULD be exactly one "a=source-filter:incl" attribute listing the address of the Distribution Source. The RTCP port MUST be derived from the m= line of the media description.
应该只有一个“a=source filter:incl”属性列出分发源的地址。RTCP端口必须从介质描述的m=行派生。
An alternative Feedback Target Address and port MAY be supplied using the SDP RTCP attribute [7], e.g., a=rtcp:<port> IN IP4 192.0.2.1. This attribute only defines the transport address of the Feedback Target and does not affect the SSM group specification for media stream reception.
可使用SDP RTCP属性[7]提供备选反馈目标地址和端口，例如IP4 192.0.2.1中的a=RTCP:<port>。此属性仅定义反馈目标的传输地址，不影响媒体流接收的SSM组规范。
Two "source-filter" attributes MAY be present to indicate an IPv4 and an IPv6 representation of the same Distribution Source.
可能存在两个“源筛选器”属性，以指示同一分发源的IPv4和IPv6表示形式。
The SSRC information for the Media Sender(s) MAY be communicated explicitly out of band (i.e., outside the RTP session). One option for doing so is the Session Description Protocol (SDP) [5]. If such an indication is desired, the "ssrc" attribute [12] MUST be used for this purpose. As per [12], the "cname" Source Attribute MUST be present. Further Source Attributes MAY be specified as needed.
媒体发送器的SSRC信息可以在带外（即，在RTP会话之外）显式地传送。这样做的一个选项是会话描述协议（SDP）[5]。如果需要此类指示，则必须使用“ssrc”属性[12]。根据[12]，必须存在“cname”源属性。可根据需要指定其他源属性。
If used in an SDP session description of an RTCP-SSM session, the ssrc MUST contain the SSRC intended to be used by the respective Media Sender and the cname MUST equal the CNAME for the Media Sender. If present, the role SHOULD indicate the function of the RTP entity identified by this line; presently, only the "media-sender" role is defined.
如果在RTCP-SSM会话的SDP会话描述中使用，ssrc必须包含拟由相应媒体发送方使用的ssrc，并且cname必须等于媒体发送方的cname。如果存在，该角色应指明该行标识的RTP实体的功能；目前，仅定义了“媒体发送者”角色。
Example:
例子：
a=ssrc:314159 cname:iptv-sender@example.com
a=ssrc:314159 cname:iptv-sender@example.com
In the above example, the Media Sender is identified to use the SSRC identifier 314159 and the CNAME iptv-sender@example.com.
在上述示例中，媒体发送方被标识为使用SSRC标识符314159和CNAME iptv-sender@example.com.
The level of security provided by the current RTP/RTCP model MUST NOT be diminished by the introduction of unicast feedback to the source. This section identifies the security weaknesses introduced by the feedback mechanism, potential threats, and level of protection that MUST be adopted. Any suggestions on increasing the level of security
当前RTP/RTCP模型提供的安全级别不得因向源引入单播反馈而降低。本节确定了反馈机制引入的安全弱点、潜在威胁以及必须采用的保护级别。有没有关于提高安全级别的建议
provided to RTP sessions above the current standard are RECOMMENDED but OPTIONAL. The final section outlines some security frameworks that are suitable to conform to this specification.
建议为RTP会话提供高于当前标准的内容，但这是可选的。最后一节概述了一些适用于符合本规范的安全框架。
RTP/RTCP is a protocol that carries real-time multimedia traffic, and therefore a main requirement is for any security framework to maintain as low overhead as possible. This includes the overhead of different applications and types of cryptographic operations as well as the overhead to deploy or to create security infrastructure for large groups.
RTP/RTCP是一种承载实时多媒体通信的协议，因此，任何安全框架都需要尽可能低的开销。这包括不同应用程序和加密操作类型的开销，以及为大型组部署或创建安全基础架构的开销。
Although the distribution of session parameters (typically encoded as SDP objects) through the Session Announcement Protocol (SAP) [22], email, or the web is beyond the scope of this document, it is RECOMMENDED that the distribution method employs adequate security measures to ensure the integrity and authenticity of the information. Suitable solutions that meet the security requirements outlined here are included at the end of this section.
尽管通过会话公告协议（SAP）[22]、电子邮件或web分发会话参数（通常编码为SDP对象）超出了本文档的范围，但建议分发方法采用适当的安全措施，以确保信息的完整性和真实性。本节末尾包含满足此处概述的安全要求的合适解决方案。
In practice, the multicast and group distribution mechanism, e.g., the SSM routing tree, is not immune to source IP address spoofing or traffic snooping; however, such concerns are not discussed here. In all the following discussions, security weaknesses are addressed from the transport level or above.
在实践中，多播和组分发机制，例如SSM路由树，不能避免源IP地址欺骗或流量窥探；然而，这里不讨论这些问题。在以下所有讨论中，安全弱点都是从传输级别或更高级别解决的。
Attacks on media distribution and the feedback architecture proposed in this document may take a variety of forms. A detailed outline of the types of attacks follows:
对本文档中提出的媒体分发和反馈体系结构的攻击可能有多种形式。攻击类型的详细概述如下：
a) Denial of Service (DoS)
a) 拒绝服务（DoS）
DoS is a major area of concern. Due to the nature of the communication architecture, a DoS can be generated in a number of ways by using the unicast feedback channel to the attacker's advantage.
DoS是一个主要关注领域。由于通信体系结构的性质，通过利用单播反馈通道，攻击者可以通过多种方式生成拒绝服务。
b) Packet Forgery
b) 包伪造
Another potential area for attack is packet forgery. In particular, it is essential to protect the integrity of certain influential packets since compromise could directly affect the transmission characteristics of the whole group.
另一个潜在的攻击领域是数据包伪造。特别是，必须保护某些有影响的数据包的完整性，因为泄露可能直接影响整个组的传输特性。
c) Session Replay
c) 会话重播
The potential for session recording and subsequent replay is an additional concern. An attacker may not actually need to understand packet content but simply have the ability to record the data stream and, at a later time, replay it to any receivers that are listening.
会话录制和后续重播的可能性是另一个问题。攻击者实际上可能不需要了解数据包内容，只需要能够记录数据流，并在稍后将其重播给正在侦听的任何接收器。
d) Eavesdropping on a Session
d) 窃听会话
The consequences of an attacker eavesdropping on a session already constitutes a security weakness; in addition, eavesdropping might facilitate other types of attacks and is therefore considered a potential threat. For example, an attacker might be able to use the eavesdropped information to perform an intelligent DoS attack.
攻击者窃听会话的后果已经构成安全弱点；此外，窃听可能会助长其他类型的攻击，因此被视为潜在威胁。例如，攻击者可能能够使用被窃听的信息执行智能DoS攻击。
To better understand the requirements of the solution, the threats outlined above are addressed for each of the three communication contexts:
为了更好地理解解决方案的要求，针对三种通信环境中的每一种，都解决了上述威胁：
a) Source-to-Receiver Communication
a) 源到接收机通信
The downstream communication channel, from the source to the receivers, is critical to protect since it controls the behavior of the group; it conveys the bandwidth allocation for each receiver, and hence the rate at which the RTCP traffic is unicast, directly back to the source. All traffic that is distributed over the downstream channel is generated by a single source. Both the RTP data stream and the RTCP control data from the source are included in this context, with the RTCP data generated by the source being indirectly influenced by the group feedback.
从源到接收器的下游通信信道对保护至关重要，因为它控制着群体的行为；它将每个接收器的带宽分配以及RTCP通信量单播的速率直接传回源。分布在下游通道上的所有流量都由一个源生成。来自源的RTP数据流和RTCP控制数据都包含在该上下文中，源生成的RTCP数据受到组反馈的间接影响。
The downstream channel is vulnerable to the four types of attack outlined above. The denial of service attack is possible but less of a concern than the other types. The worst case effect of DoS would be the transmission of large volumes of traffic over the distribution channel, with the potential to reach every receiver but only on a one-to-one basis. Consequently, this threat is no more pronounced than the current multicast ASM model. The real danger of denial of service attacks in this context comes indirectly via compromise of the source RTCP traffic. If receivers are provided with an incorrect group size estimate or bandwidth allowance, the return traffic to the source may create a distributed DoS effect on the source. Similarly, an incorrect feedback address -- whether as a result of a malicious attack or
下游通道容易受到上述四种类型的攻击。拒绝服务攻击是可能的，但与其他类型的攻击相比，它不那么令人担忧。拒绝服务的最坏影响是通过分销渠道传输大量流量，有可能到达每个接收器，但只能以一对一的方式。因此，这种威胁并不比当前的多播ASM模型更明显。在这种情况下，拒绝服务攻击的真正危险来自于源RTCP通信量的泄露。如果向接收机提供了不正确的组大小估计值或带宽余量，则到源的返回流量可能会对源产生分布式DoS效应。类似地，错误的反馈地址——无论是由于恶意攻击还是
by mistake, e.g., an IP address configuration error (e.g., typing) -- could directly create a denial of service attack on another host.
如果出现错误，例如IP地址配置错误（例如键入），可能会直接在另一台主机上造成拒绝服务攻击。
An additional concern relating to Denial of service attacks would come indirectly through the generation of fake BYE packets, causing the source to adjust the advertised group size. A Distribution Source MUST follow the correct rules for timing out members in a session prior to reporting a change in the group size, which allows the authentic SSRC sufficient time to continue to report and, consequently, cancel the fake BYE report.
另一个与拒绝服务攻击有关的问题是，通过生成虚假的BYE数据包，间接导致源调整公布的组大小。分发源必须遵循正确的规则，在报告组大小的变化之前，对会话中的成员进行超时，这允许真实的SSRC有足够的时间继续报告，从而取消假BYE报告。
The danger of packet forgery in the worst case may be to maliciously instigate a denial of service attack, e.g., if an attacker were capable of spoofing the source address and injecting incorrect packets into the data stream or intercepting the source RTCP traffic and modifying the fields.
在最坏的情况下，数据包伪造的危险可能是恶意发起拒绝服务攻击，例如，如果攻击者能够欺骗源地址并将不正确的数据包注入数据流，或者拦截源RTCP流量并修改字段。
The replay of a session would have the effect of recreating the receiver feedback to the source address at a time when the source is not expecting additional traffic from a potentially large group. The consequence of this type of attack may be less effective on its own, but in combination with other attacks might be serious.
会话的重播会在源不期望来自潜在大组的额外通信量时，重新创建对源地址的接收器反馈。这种类型的攻击的后果本身可能不太有效，但与其他攻击相结合可能会很严重。
Eavesdropping on the session would provide an attacker with information on the characteristics of the source-to-receiver traffic, such as the frequency of RTCP traffic. If RTCP traffic is unencrypted, this might also provide valuable information on characteristics such as group size, Media Source SSRC(s), and transmission characteristics of the receivers back to the source.
会话窃听会向攻击者提供有关源到接收器流量特征的信息，例如RTCP流量的频率。如果RTCP通信量未加密，这还可能提供有关组大小、媒体源SSRC和接收器返回源的传输特性等特征的有价值信息。
b) Receiver-to-Distribution-Source Communication
b) 接收机到分配源通信
The second context is the return traffic from the group to the Distribution Source. This traffic should only consist of RTCP packets and should include Receiver Reports, SDES information, BYE reports, extended reports (XR), feedback messages (RTPFB, PSFB) and possibly application-specific packets. The effects of compromise on a single or subset of receivers are not likely to have as great an impact as in context (a); however, much of the responsibility for detecting compromise of the source data stream relies on the receivers.
第二个上下文是从组到分发源的返回流量。此流量应仅由RTCP数据包组成，并应包括接收器报告、SDES信息、BYE报告、扩展报告（XR）、反馈消息（RTPFB、PSFB）以及可能的特定于应用程序的数据包。妥协对单个或子集接收者的影响不可能像上下文（a）中那样大；然而，检测源数据流泄露的大部分责任依赖于接收器。
The effects of compromise of critical Distribution Source control information can be seriously amplified in the present context. A large group of receivers may unwittingly generate a distributed
在目前的情况下，关键分布源控制信息泄露的影响可能会被严重放大。一大群接收器可能会无意中生成分布式
DoS attack on the Distribution Source in the event that the integrity of the source RTCP channel has been compromised and the compromise is not detected by the individual receivers.
在源RTCP通道的完整性受到损害且单个接收器未检测到该损害的情况下，对分发源进行DoS攻击。
An attacker capable of instigating a packet forgery attack could introduce false RTCP traffic and create fake SSRC identifiers. Such attacks might slow down the overall control channel data rate since an incorrect perception of the group size may be created. Similarly, the creation of fake BYE reports by an attacker would cause some group size instability, but should not be effective as long as the correct timeout rules are applied by the source in removing SSRC entries from its database.
能够发起数据包伪造攻击的攻击者可能会引入虚假RTCP流量并创建虚假SSRC标识符。此类攻击可能会降低总体控制通道数据速率，因为可能会产生对组大小的错误感知。类似地，攻击者创建虚假的BYE报告会导致某些组大小不稳定，但只要源在从其数据库中删除SSRC条目时应用了正确的超时规则，就不会有效。
A replay attack on receiver return data to the source would have the same implications as the generation of false SSRC identifiers and RTCP traffic to the source. Therefore, ensuring authenticity and freshness of the data source is important.
对发送到源的接收器返回数据的重播攻击与向源生成错误的SSRC标识符和RTCP通信量具有相同的含义。因此，确保数据源的真实性和新鲜性非常重要。
Eavesdropping in this context potentially provides an attacker with a great deal of potentially personal information about a large group of receivers available from SDES packets. It would also provide an attacker with information on group traffic-generation characteristics and parameters for calculating individual receiver bandwidth allowances.
在这种情况下，窃听可能会为攻击者提供大量关于SDES数据包中可用的大量接收器的潜在个人信息。它还将向攻击者提供有关组通信量生成特性和参数的信息，以计算单个接收器带宽余量。
c) Receiver-to-Feedback-Target Communication
c) 接收机到反馈目标通信
The third context is the return traffic from the group to the Feedback Target. It suffers from the same threats as the receiver-to-source context, with the difference being that now a large group of receivers may unwittingly generate a distributed DoS (DDos) attack on the Feedback Target, where it is impossible to discern if the DDoS is deliberate or due merely to a misconfiguration of the Feedback Target Address. While deliberate attacks can be mitigated by properly authenticating messages that communicate the Feedback Target Address (i.e., the SDP session description and the Feedback Target Address sub-report block carried in RTCP), a misconfigured address will originate from an authenticated source and hence cannot be prevented using security mechanisms.
第三个上下文是从组到反馈目标的返回流量。它受到与接收方到源上下文相同的威胁，不同之处在于，现在一大群接收方可能会无意中对反馈目标产生分布式拒绝服务（DDos）攻击，无法辨别DDos是故意的还是仅仅由于反馈目标地址配置错误。虽然可以通过正确验证传递反馈目标地址（即，SDP会话描述和RTCP中携带的反馈目标地址子报告块）的消息来减轻故意攻击，但错误配置的地址将源自经过验证的源，因此无法使用安全机制来防止。
Furthermore, the Feedback Target is unable to communicate its predicament with either the Distribution Source or the session receivers. From the feedback packets received, the Feedback Target cannot tell either which SSM multicast group the feedback belongs to or the Distribution Source, making further analysis and suppression difficult. The Feedback Target may not even support RTCP or listen on the port number in question.
此外，反馈目标无法与分发源或会话接收器传达其困境。从接收到的反馈数据包中，反馈目标无法分辨反馈属于哪个SSM多播组或分发源，这使得进一步的分析和抑制变得困难。反馈目标甚至可能不支持RTCP或侦听相关端口号。
Note that because the DDoS occurs inside of the RTCP session and because the unicast receivers adhere to transmission interval calculations ([1], [10]), the bandwidth misdirected toward the Feedback Target in the misconfigured case will be limited to a percentage of the session bandwidth, i.e., the Control Traffic Bandwidth established for the session.
请注意，由于DDoS发生在RTCP会话内部，并且由于单播接收器遵守传输间隔计算（[1]，[10]），因此在错误配置的情况下，错误定向到反馈目标的带宽将被限制为会话带宽的百分比，即。，为会话建立的控制通信带宽。
To address these threats, this section presents the security requirements for each context.
为了应对这些威胁，本节介绍了每种环境的安全要求。
a) The main threat in the source-to-receiver context concerns denial of service attacks through possible packet forgery. The forgery may take the form of interception and modification of packets from the source, or it may simply inject false packets into the distribution channel. To combat these attacks, data integrity and source authenticity MUST be applied to source traffic. Since the consequences of eavesdropping do not affect the operation of the protocol, confidentiality is not a requirement in this context. However, without confidentiality, access to personal and group characteristics information would be unrestricted to an external listener. Therefore, confidentiality is RECOMMENDED.
a) 源到接收器上下文中的主要威胁涉及通过可能的数据包伪造进行的拒绝服务攻击。伪造可以采取截获和修改来自源的数据包的形式，也可以简单地将虚假数据包注入分发通道。为了打击这些攻击，必须对源流量应用数据完整性和源真实性。由于窃听的后果不影响议定书的运作，因此在这方面不要求保密。但是，如果没有保密性，对个人和群体特征信息的访问将不受外部听众的限制。因此，建议保密。
b) The threats in the receiver-to-source context concern the same kinds of attacks, but are considered less important than the downstream traffic compromise. All the security weaknesses are also applicable to the current RTP/RTCP security model, and therefore only recommendations towards protection from compromise are made. Data integrity is RECOMMENDED to ensure that interception and modification of an individual receiver's RTCP traffic can be detected. This would protect against the false influence of group control information and the potentially more serious compromise of future services provided by the distribution functionality. In order to ensure security, data integrity and authenticity of receiver traffic is therefore also RECOMMENDED. With respect to data confidentiality, the same situation applies as in the first context, and it is RECOMMENDED that precautions be taken to protect the privacy of the data.
b) 接收方到源上下文中的威胁涉及相同类型的攻击，但被认为不如下游流量危害重要。所有的安全弱点也适用于当前的RTP/RTCP安全模型，因此只提出了防止泄露的建议。建议使用数据完整性，以确保能够检测到单个接收器RTCP通信量的拦截和修改。这将防止组控制信息的错误影响，以及分发功能提供的未来服务可能受到更严重的损害。因此，为了确保安全性，还建议接收机通信的数据完整性和真实性。关于数据保密性，与第一种情况相同，建议采取预防措施保护数据隐私。
c) The threats to the receiver-to-feedback-target context are similar to those in the receiver-to-source context, and thus the recommendations to protect against them are similar.
c) 接收者对反馈目标环境的威胁与接收者对源环境的威胁相似，因此针对这些威胁的保护建议也相似。
However, there are a couple situations with broader issues to solve, which are beyond the scope of this document.
但是，还有一些情况需要解决更广泛的问题，这些问题超出了本文件的范围。
1. An endpoint experiencing DDoS or the side effects of a misconfigured RTCP session may not even be a participant in the session, i.e., may not be listening on the respective port number and may even support RTCP, so it will be unable to react within RTCP. Determining that there is a problem will be up to network administrators and, possibly, anti-malware software that can perform correlation across receiver nodes.
1. 遇到DDoS或错误配置的RTCP会话的副作用的端点甚至可能不是会话的参与者，即，可能没有监听相应的端口号，甚至可能支持RTCP，因此它将无法在RTCP内做出反应。确定是否存在问题将取决于网络管理员，也可能取决于可以跨接收器节点执行关联的反恶意软件。
2. With misconfiguration, unfortunately the normally desirable usage of SRTP and SRTCP becomes undesirable. Because the packet content is encrypted, neither the misconfigured Feedback Target nor the network administrator have the ability to determine the root cause of the traffic.
2. 不幸的是，由于配置错误，通常理想的SRTP和SRTCP用法变得不可取。由于数据包内容是加密的，因此配置错误的反馈目标和网络管理员都无法确定流量的根本原因。
In the case where the misconfigured Feedback Target happens to be a node participating in the session or is an RTCP-enabled node, the Feedback Target Address block provides a dynamic mechanism for the Distribution Source to signal an alternative unicast RTCP feedback address to the receivers. As this type of packet MUST be included in every RTCP packet originated by the Distribution Source, all receivers would be able to obtain the corrected Feedback Target information. In this manner, receiver behavior should remain consistent even in the face of packet loss or when there are late-session arrivals. The only caveat is that the misconfigured Feedback Target is largely uninvolved in the repair of this situation and thus relies on others for the detection of the problem.
如果配置错误的反馈目标恰好是参与会话的节点或启用RTCP的节点，则反馈目标地址块为分发源提供了一种动态机制，以向接收器发送替代单播RTCP反馈地址的信号。由于这种类型的数据包必须包含在分发源发起的每个RTCP数据包中，因此所有接收器都能够获得正确的反馈目标信息。以这种方式，即使在分组丢失或会话延迟到达时，接收器行为也应保持一致。唯一需要注意的是，配置错误的反馈目标在很大程度上与修复这种情况无关，因此需要依赖其他人来检测问题。
An additional security consideration, which is not a component of this specification but which has a direct influence upon the general security, is the origin of the session-initiation data. This involves the SDP parameters that are communicated to the members prior to the start of the session via channels such as an HTTP server, email, SAP, or other means. It is beyond the scope of this document to place any strict requirements on the external communication of such information; however, suitably secure SDP communication approaches are outlined in Section 11.7.
另一个安全考虑因素是会话启动数据的来源，它不是本规范的组成部分，但对一般安全性有直接影响。这涉及SDP参数，这些参数在会话开始之前通过HTTP服务器、电子邮件、SAP或其他方式传递给成员。对此类信息的外部沟通提出任何严格要求超出了本文件的范围；然而，第11.7节概述了适当安全的SDP通信方法。
As identified in the previous sections, source authenticity is a fundamental requirement of the protocol. However, it is important to also clarify the model of trust that would be acceptable to achieve this requirement. There are two fundamental models that apply in this instance:
如前几节所述，源真实性是协议的基本要求。然而，还必须澄清为达到这一要求而可接受的信任模式。在这种情况下，有两种基本模型适用：
a) The shared-key model, where all authorized group members share the same key and can equally encrypt/decrypt the data. This method assumes that an out-of-band method is applied to the distribution of the shared group key, ensuring that every key-holder is individually authorized to receive the key and, in the event of member departures from the group, a re-keying exercise can occur. The advantage of this model is that the costly processing associated with one-way key-authentication techniques is avoided, as well as the need to execute additional cipher operations with alternative key sets on the same data set, e.g., in the event that data confidentiality is also applied. The disadvantage is that, for very large groups where the receiver set becomes effectively untrusted, a shared key does not offer much protection.
a) 共享密钥模型，其中所有授权的组成员共享相同的密钥，并且可以平等地加密/解密数据。此方法假设将带外方法应用于共享组密钥的分发，确保每个密钥持有者都有权单独接收密钥，并且在成员离开组时，可以进行重新密钥操作。该模型的优点是，避免了与单向密钥认证技术相关的昂贵处理，以及在相同数据集上使用备用密钥集执行额外密码操作的需要，例如，在数据保密性也适用的情况下。缺点是，对于接收器集实际上不受信任的非常大的组，共享密钥不能提供太多保护。
b) The public-key authentication model, using cryptosystems such as RSA-based or PGP authentication, provides a more secure method of source authentication at the expense of generating higher processing overhead. This is typically not recommended for real-time data streams but, in the case of RTCP reports, which are distributed with a minimum interval of 5 seconds, this may be a viable option (the processing overhead might still be too great for small, low-powered devices and should therefore be considered with caution). Wherever possible, however, the use of public key source authentication is preferable to the shared key model identified above.
b) 公钥身份验证模型使用基于RSA或PGP身份验证等密码系统，提供了一种更安全的源身份验证方法，但会产生更高的处理开销。这通常不建议用于实时数据流，但在RTCP报告（以最小5秒的间隔分发）的情况下，这可能是一个可行的选择（对于小型、低功耗设备，处理开销可能仍然太大，因此应谨慎考虑）。然而，在可能的情况下，使用公钥源身份验证比上述共享密钥模型更可取。
As concerns requirements for protocol acceptability, either model is acceptable although it is RECOMMENDED that the more secure public-key-based options be applied wherever possible.
关于协议可接受性的要求，尽管建议尽可能应用更安全的基于公钥的选项，但这两种模型都是可以接受的。
This section presents some existing security mechanisms that are RECOMMENDED to suitably address the requirements outlined in Section 11.5. This is only intended as a guideline and it is acknowledged that there are other solutions that would also be suitable to comply with the specification.
本节介绍了一些建议适当满足第11.5节所述要求的现有安全机制。这仅作为一个指南，并且承认还有其他解决方案也适用于遵守本规范。
a) SAP, HTTPS, Email -- Initial distribution of the SDP parameters for the session SHOULD use a secure mechanism such as the SAP authentication framework, which allows an authentication certificate to be attached to the session announcements. Other methods might involve HTTPS or signed email content from a trusted source. However, some more commonly used techniques for distributing session information and starting media streams are the Real-Time Streaming Protocol (RTSP) [25] and SIP [14].
a) SAP、HTTPS、电子邮件——会话SDP参数的初始分发应使用安全机制，如SAP身份验证框架，该框架允许将身份验证证书附加到会话公告。其他方法可能涉及来自可信来源的HTTPS或签名电子邮件内容。然而，用于分发会话信息和启动媒体流的一些更常用的技术是实时流协议（RTSP）[25]和SIP[14]。
b) RTSP -- RTSP provides a client- or server-initiated stream control mechanism for real-time multimedia streams. The session parameters are conveyed using SDP syntax and may adopt standard HTTP authentication mechanisms in combination with suitable network (e.g., IPsec)- or transport (e.g., Transport Layer Security (TLS))-level security.
b) RTSP——RTSP为实时多媒体流提供客户端或服务器启动的流控制机制。会话参数使用SDP语法传送，并且可以采用标准HTTP认证机制与适当的网络（例如，IPsec）或传输（例如，传输层安全（TLS））级安全相结合。
c) SIP -- A typical use of SIP involving a unicast feedback identifier might be a client wishing to dynamically join a multi-party call on a multicast address using unicast RTCP feedback. The client would be required to authenticate the SDP session descriptor information returned by the SIP server. The recommended method for this, as outlined in the SIP specification [14], is to use an S/MIME message body containing the session parameters signed with an acceptable certificate.
c) SIP——涉及单播反馈标识符的SIP的典型用途可能是希望使用单播RTCP反馈在多播地址上动态加入多方呼叫的客户端。客户端需要对SIP服务器返回的SDP会话描述符信息进行身份验证。如SIP规范[14]所述，推荐的方法是使用S/MIME消息体，其中包含使用可接受证书签名的会话参数。
For the purposes of this profile, it is acceptable to use any suitably secure authentication mechanism that establishes the identity and integrity of the information provided to the client.
出于本概要文件的目的，可以使用任何适当安全的认证机制来确定提供给客户的信息的身份和完整性。
11.6.2. Suitable Security Solutions for RTP Sessions with Unicast Feedback
11.6.2. 适用于具有单播反馈的RTP会话的安全解决方案
a) SRTP -- SRTP [3] is the recommended Audio/Video Transport (AVT) security framework for RTP sessions. It specifies the general packet formats and cipher operations that are used and provides the flexibility to select different stream ciphers based on preference/requirements. It can provide confidentiality of the RTP and RTCP packets as well as protection against integrity compromise and replay attacks. It provides authentication of the data stream using the shared-key trust model. Any suitable key-distribution mechanism can be used in parallel to the SRTP streams.
a) SRTP——SRTP[3]是RTP会话的推荐音频/视频传输（AVT）安全框架。它指定了使用的通用数据包格式和密码操作，并提供了根据偏好/要求选择不同流密码的灵活性。它可以提供RTP和RTCP数据包的机密性，以及针对完整性泄露和重放攻击的保护。它使用共享密钥信任模型提供数据流的身份验证。任何合适的密钥分配机制都可以与SRTP流并行使用。
b) IPSEC -- A more general group security profile that might be used is the Group Domain of Interpretation [23], which defines the process of applying IPSec mechanisms to multicast groups. This requires the use of the Encapsulating Security Payload (ESP) in tunnel mode as the framework and it provides the capability to authenticate -- either using a shared key or individually through public-key mechanisms. It should be noted that using IPSec would break the 'transport-independent' condition of RTP and would therefore not be useable for anything other than IP-based communication.
b) IPSEC——可能使用的更通用的组安全配置文件是组域解释[23]，它定义了将IPSEC机制应用于多播组的过程。这需要在隧道模式下使用封装安全有效负载（ESP）作为框架，并提供身份验证功能——使用共享密钥或单独通过公钥机制。应该注意的是，使用IPSec将打破RTP的“传输独立”条件，因此除了基于IP的通信之外，不能用于任何其他用途。
c) TESLA - Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [24] is a scheme that provides a more flexible approach to data authentication using time-based key disclosure. The
c) TESLA-定时高效流丢失容忍认证（TESLA）[24]是一种使用基于时间的密钥公开提供更灵活的数据认证方法的方案。这个
authentication uses one-way, pseudo-random key functions based on key chain hashes that have a short period of authenticity based on the key disclosure intervals from the source. As long as the receiver can ensure that the encrypted packet is received prior to the key disclosure by the source, which requires loose time synchronization between source and receivers, it can prove the authenticity of the packet. The scheme does introduce a delay into the packet distribution/decryption phase due to the key disclosure delay; however, the processing overhead is much lower than other standard public-key mechanisms and therefore may be more suited to small or energy-restricted devices.
身份验证使用基于密钥链散列的单向伪随机密钥函数，该散列具有基于源密钥公开间隔的短时间真实性。只要接收方能够确保加密包在源公开密钥之前被接收，这需要源和接收方之间的松散时间同步，就可以证明包的真实性。由于密钥公开延迟，该方案在分组分发/解密阶段引入延迟；然而，处理开销远低于其他标准公钥机制，因此可能更适合小型或能量受限的设备。
a) MIKEY -- Multimedia Internet KEYing (MIKEY) [29] is the preferred solution for SRTP sessions providing a shared group-key distribution mechanism and intra-session rekeying facilities. If a partly protected communication channel exists, keys may also be conveyed using SDP as per [27].
a) MIKEY——多媒体互联网密钥（MIKEY）[29]是SRTP会话的首选解决方案，提供共享组密钥分发机制和会话内密钥更新设施。如果存在部分受保护的通信信道，也可根据[27]使用SDP传送钥匙。
b) GSAKMP -- The Group Secure Association Key Management Protocol (GSAKMP) is the general solution favored for Multicast Secure group-key distribution. It is the recommended key distribution solution for Group Domain of Interpretation (GDOI) [RFC3547] sessions.
b) GSAKMP——组安全关联密钥管理协议（GSAKMP）是多播安全组密钥分发的通用解决方案。它是组解释域（GDOI）[RFC3547]会话的推荐密钥分发解决方案。
As noted above, the security mechanisms in place will not help in case an authorized source spreads properly authenticated and integrity-protected yet incorrect information about the Feedback Target. In this case, the accidentally communicated Feedback Target will receive RTCP packets from a potentially large group of receivers -- the RTCP rate fortunately limited by the RTCP timing rules.
如上所述，如果授权源传播正确的身份验证和完整性保护，但反馈目标的信息不正确，那么现有的安全机制将不会有帮助。在这种情况下，意外通信的反馈目标将从潜在的大量接收器接收RTCP数据包——RTCP速率幸运地受到RTCP定时规则的限制。
Yet, the RTCP packets do not provide much context information and, if encrypted, do not provide any context, making it difficult for the entity running (the network with) the Feedback Target to debug and correct this problem, e.g., by tracking down and informing the origin of the misconfiguration.
然而，RTCP数据包不提供太多上下文信息，如果加密，也不提供任何上下文，这使得运行（带有反馈目标的网络）的实体难以调试和纠正此问题，例如，通过跟踪并通知错误配置的来源。
One suitable approach may be to provide explicit context information in RTCP packets that would allow determining the source. While such an RTCP packet could be defined in this specification, it would be of no use when using SRTP/SRTCP and encryption of RTCP reports. Therefore, and because the extensions in this document may not be the
一种合适的方法可以是在RTCP分组中提供显式上下文信息，以允许确定源。虽然这种RTCP数据包可以在本规范中定义，但在使用SRTP/SRTCP和RTCP报告加密时，它将毫无用处。因此，由于本文档中的扩展可能不是
only case that may face such a problem, it is desirable to find a solution that is applicable to RTP at large. Such mechanisms are for further study in the AVT WG.
只有在可能面临此类问题的情况下，才需要找到一种适用于RTP的解决方案。这些机制有待AVT工作组进一步研究。
The use of unicast feedback to the source should not present any serious backwards compatibility issues. The RTP data streams should remain unaffected, as should the RTCP packets from the Media Sender(s) that continue to enable inter-stream synchronization in the case of multiple streams. The unicast transmission of RTCP data to a source that does not have the ability to redistribute the traffic either by simple reflection or through summaries could have serious security implications, as outlined in Section 11, but would not actually break the operation of RTP. For RTP-compliant receivers that do not understand the unicast mechanisms, the RTCP traffic may still reach the group in the event that an ASM distribution network is used, in which case there may be some duplication of traffic due to the reflection channel, but this should be ignored. It is anticipated, however, that typically the distribution network will not enable the receiver to multicast RTCP traffic, in which case the data will be lost and the RTCP calculations will not include those receivers. It is RECOMMENDED that any session that may involve non-unicast-capable clients should always use the simple packet-reflection mechanism to ensure that the packets received can be understood by all clients.
使用对源的单播反馈不应出现任何严重的向后兼容性问题。RTP数据流应保持不受影响，来自媒体发送方的RTCP数据包也应保持不受影响，在多个流的情况下，RTP数据包应继续启用流间同步。如第11节所述，将RTCP数据单播传输到无法通过简单反射或摘要重新分配流量的源可能会产生严重的安全影响，但实际上不会中断RTP的运行。对于不了解单播机制的RTP兼容接收机，在使用ASM分发网络的情况下，RTCP通信量仍可能到达组，在这种情况下，由于反射信道，可能存在一些通信量重复，但这一点应忽略。然而，预计通常配电网不会使接收器能够多播RTCP流量，在这种情况下，数据将丢失，RTCP计算将不包括这些接收器。建议可能涉及不支持单播的客户端的任何会话始终使用简单的数据包反射机制，以确保所有客户端都能理解接收到的数据包。
The following contact information shall be used for all registrations included here:
以下联系信息应用于此处包含的所有注册：
Contact: Joerg Ott
mail: jo@acm.org
tel: +358-9-470-22460
Contact: Joerg Ott
mail: jo@acm.org
tel: +358-9-470-22460
Based on the guidelines suggested in [2], a new RTCP packet format has been registered with the RTCP Control Packet type (PT) Registry:
根据[2]中建议的指南，新的RTCP数据包格式已在RTCP控制数据包类型（PT）注册表中注册：
Name: RSI Long name: Receiver Summary Information Value: 209 Reference: This document.
名称：RSI长名称：接收方摘要信息值：209参考：本文档。
This document defines a substructure for RTCP RSI packets. A new sub-registry has been set up for the sub-report block type (SRBT) values for the RSI packet, with the following registrations created initially:
本文件定义了RTCP RSI数据包的子结构。已为RSI数据包的子报告块类型（SRBT）值设置了一个新的子注册表，最初创建了以下注册表：
Name: IPv4 Address Long name: IPv4 Feedback Target Address Value: 0 Reference: This document.
名称：IPv4地址长名称：IPv4反馈目标地址值：0引用：此文档。
Name: IPv6 Address Long name: IPv6 Feedback Target Address Value: 1 Reference: This document.
名称：IPv6地址长名称：IPv6反馈目标地址值：1参考：本文档。
Name: DNS Name Long name: DNS Name indicating Feedback Target Address Value: 2 Reference: This document.
名称：DNS名称长名称：指示反馈目标地址值的DNS名称：2参考：此文档。
Name: Loss Long name: Loss distribution Value: 4 Reference: This document.
名称：损失长名称：损失分布值：4参考：本单据。
Name: Jitter Long name: Jitter Distribution Value: 5 Reference: This document.
名称：抖动长名称：抖动分布值：5参考：本文档。
Name: RTT Long name: Round-trip time distribution Value: 6 Reference: This document.
名称：RTT长名称：往返时间分布值：6参考：本文档。
Name: Cumulative loss Long name: Cumulative loss distribution Value: 7 Reference: This document.
名称：累计损失长名称：累计损失分布值：7参考：本单据。
Name: Collisions Long name: SSRC Collision list Value: 8 Reference: This document.
名称：冲突长名称：SSRC冲突列表值：8参考：本文档。
Name: Stats Long name: General statistics Value: 10 Reference: This document.
名称：统计长名称：一般统计值：10参考：本文档。
Name: RTCP BW Long name: RTCP Bandwidth indication Value: 11 Reference: This document.
名称：RTCP BW长名称：RTCP带宽指示值：11参考：本文档。
Name: Group Info Long name: RTCP Group and Average Packet size Value: 12 Reference: This document.
名称：组信息长名称：RTCP组和平均数据包大小值：12参考：本文档。
The value 3 shall be reserved as a further way of specifying a Feedback Target Address. The value 3 MUST only be allocated for a use defined in an IETF Standards Track document.
应保留值3，作为指定反馈目标地址的进一步方式。值3只能分配给IETF标准跟踪文档中定义的用途。
Further values may be registered on a first come, first served basis. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter as well as the syntax and semantics of the associated sub-report block. The general registration procedures of [5] apply.
其他价值可按先到先得的原则进行登记。对于每个新注册，必须存在一个永久、稳定且可公开访问的文档，该文档指定已注册参数的语义以及关联子报表块的语法和语义。[5]中的一般注册程序适用。
In the registry for SDP parameters, the attribute named "rtcp-unicast" has been registered as follows:
在SDP参数注册表中，名为“rtcp unicast”的属性已按如下方式注册：
SDP Attribute ("att-field"):
SDP属性（“att字段”）：
Attribute Name: rtcp-unicast Long form: RTCP Unicast feedback address Type of name: att-field Type of attribute: Media level only Subject to charset: No Purpose: RFC 5760 Reference: RFC 5760 Values: See this document.
属性名称：rtcp单播长格式：rtcp单播反馈地址名称类型：att字段属性类型：媒体级别仅受字符集约束：无用途：RFC 5760参考：RFC 5760值：参见本文档。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[2] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[3] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[4] Quinn, B. and R. Finlayson, "Session Description Protocol (SDP) Source Filters", RFC 4570, July 2006.
[4] Quinn，B.和R.Finlayson，“会话描述协议（SDP）源过滤器”，RFC 45702006年7月。
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[5] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[6] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[7] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[7] Huitema，C.，“会话描述协议（SDP）中的实时控制协议（RTCP）属性”，RFC 3605，2003年10月。
[8] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific Protocol Independent Multicast in 232/8", BCP 120, RFC 4608, August 2006.
[8] Meyer，D.，Rockell，R.，和G.Shepherd，“232/8中的源特定协议独立多播”，BCP 120，RFC 4608，2006年8月。
[9] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[9] Holbrook，H.，Cain，B.，和B.Haberman，“为源特定多播使用Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）”，RFC 4604，2006年8月。
[10] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[10] Casner，S.，“RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽修饰符”，RFC 3556，2003年7月。
[11] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[11] Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[12] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.
[12] Lennox，J.，Ott，J.，和T.Schierl，“会话描述协议（SDP）中的源特定媒体属性”，RFC 55762009年6月。
[13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[13] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[14] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[15] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[15] Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[16] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress, October 2003.
[16] “距离向量多播路由协议”，正在进行的工作，2003年10月。
[17] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[17] Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 4601，2006年8月。
[18] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[18] Adams，A.，Nicholas，J.，和W.Siadak，“协议独立多播-密集模式（PIM-DM）：协议规范（修订版）”，RFC 39732005年1月。
[19] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[19] Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[20] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[20] Fenner，B.，Ed.，和D.Meyer，Ed.，“多播源发现协议（MSDP）”，RFC3618，2003年10月。
[21] Session Directory Rendez-vous (SDR), developed at University College London by Mark Handley and the Multimedia Research Group, http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/.
[21] 会议目录Rendez-vous（SDR），由马克·汉德利和多媒体研究小组在伦敦大学学院开发，http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/.
[22] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[22] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[23] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[23] Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的群体领域”，RFC 3547，2003年7月。
[24] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[24] Perrig，A.，Song，D.，Canetti，R.，Tygar，J.，和B.Briscoe，“定时高效流丢失容忍认证（TESLA）：多播源认证转换介绍”，RFC 40822005年6月。
[25] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[25] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[26] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[26] Friedman，T.，Ed.，Caceres，R.，Ed.，和A.Clark，Ed.，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[27] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[27] Andreasen，F.，Baugher，M.和D.Wing，“媒体流的会话描述协议（SDP）安全描述”，RFC 4568，2006年7月。
[28] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008.
[28] Ott，J.和E.Carrara，“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”，RFC 51242008年2月。
[29] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[29] Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
This appendix describes a few common setups, focusing on the contribution side, i.e., the communications between the Media Sender(s) and the Distribution Source. In all cases, the same session description may be used for the distribution side as defined in the main part of this document. This is because this specification defines only the media stream setup between the Distribution Source and the receivers.
本附录描述了一些常见的设置，重点是贡献端，即媒体发送方和分发源之间的通信。在所有情况下，相同的会话描述可用于本文档主要部分中定义的分发端。这是因为该规范仅定义分发源和接收器之间的媒体流设置。
In the simplest case, the Distribution Source is identical to the Media Sender as depicted in Figure 3. Obviously, no further configuration for the interaction between the Media Sender and the Distribution Source is necessary.
在最简单的情况下，分发源与媒体发送器相同，如图3所示。显然，没有必要对媒体发送者和分发源之间的交互进行进一步的配置。
Source-specific
+--------+ Multicast
| | +----------------> R(1)
|M D S | | |
|E I O | +--+ |
|D S U | | | |
|I T R | | +-----------> R(2) |
|A R C |->+----- : | |
| = I E | | +------> R(n-1) | |
|S B | | | | | |
|E U | +--+--> R(n) | | |
|N T | | | | |
|D I |<---------+ | | |
|E O |<---------------+ | |
|R N |<--------------------+ |
| |<-------------------------+
+--------+ Unicast
Source-specific
+--------+ Multicast
| | +----------------> R(1)
|M D S | | |
|E I O | +--+ |
|D S U | | | |
|I T R | | +-----------> R(2) |
|A R C |->+----- : | |
| = I E | | +------> R(n-1) | |
|S B | | | | | |
|E U | +--+--> R(n) | | |
|N T | | | | |
|D I |<---------+ | | |
|E O |<---------------+ | |
|R N |<--------------------+ |
| |<-------------------------+
+--------+ Unicast
Figure 3: Media Source == Distribution Source
Figure 3: Media Source == Distribution Source
In a slightly more complex scenario, the Media Sender and the Distribution Source are separate entities running on the same or different machines. Hence, the Media Sender needs to deliver the media stream(s) to the Distribution Source. This can be done either via unicasting the RTP stream, via ASM multicast, or via SSM. In this case, the Distribution Source is responsible for forwarding the RTP packets comprising the media stream and the RTCP Sender Reports towards the receivers and conveying feedback from the receivers, as well as from itself, to the Media Sender.
在稍微复杂一点的场景中，媒体发送器和分发源是在相同或不同机器上运行的独立实体。因此，媒体发送方需要将媒体流传送到分发源。这可以通过RTP流的单播、ASM多播或SSM来实现。在这种情况下，分发源负责将包括媒体流和RTCP发送方报告的RTP分组转发给接收方，并将来自接收方以及来自其自身的反馈传递给媒体发送方。
This scenario is depicted in Figure 4. The communication setup between the Media Sender and the Distribution Source may be statically configured or SDP may be used in conjunction with some signaling protocol to convey the session parameters. Note that it is a local configuration matter of the Distribution Source how to associate a session between the Media Sender and itself (the Contribution session) with the corresponding session between itself and the receivers (the Distribution session).
此场景如图4所示。媒体发送器和分发源之间的通信设置可以是静态配置的，或者SDP可以与一些信令协议结合使用以传送会话参数。请注意，如何将媒体发送者与自身之间的会话（贡献会话）与自身与接收者之间的对应会话（分发会话）相关联是分发源的本地配置问题。
Source-specific
+-----+ Multicast
| | +----------------> R(1)
| D S | | |
| I O | +--+ |
| S U | | | |
+--------+ | T R | | +-----------> R(2) |
| Media |<---->| R C |->+----- : | |
| Sender | | I E | | +------> R(n-1) | |
+--------+ | B | | | | | |
| U | +--+--> R(n) | | |
| T | | | | |
| I |<---------+ | | |
| O |<---------------+ | |
| N |<--------------------+ |
| |<-------------------------+
+-----+ Unicast
Source-specific
+-----+ Multicast
| | +----------------> R(1)
| D S | | |
| I O | +--+ |
| S U | | | |
+--------+ | T R | | +-----------> R(2) |
| Media |<---->| R C |->+----- : | |
| Sender | | I E | | +------> R(n-1) | |
+--------+ | B | | | | | |
| U | +--+--> R(n) | | |
| T | | | | |
| I |<---------+ | | |
| O |<---------------+ | |
| N |<--------------------+ |
| |<-------------------------+
+-----+ Unicast
Contribution Distribution Session Session (unicast or ASM) (SSM)
贡献分发会话（单播或ASM）（SSM）
Figure 4: One Media Sender Separate from Distribution Source
图4：一个独立于分发源的媒体发送器
Similar considerations apply if three Media Senders transmit to an SSM multicast group via the Distribution Source and individually send their media stream RTP packets via unicast to the Distribution Source.
如果三个媒体发送方通过分发源向SSM多播组发送数据，并分别通过单播向分发源发送其媒体流RTP数据包，则类似的注意事项也适用。
In this case, the responsibilities of the Distribution Source are a superset to the previous case; the Distribution Source also needs to relay media traffic from each Media Sender to the receivers and to forward (aggregated) feedback from the receivers to the Media Senders. In addition, the Distribution Source relays RTCP packets (SRs) from each Media Sender to the other two.
在这种情况下，分销源的责任是前一种情况的超集；分发源还需要将媒体流量从每个媒体发送者中继到接收者，并将来自接收者的反馈转发（聚合）到媒体发送者。此外，分发源将RTCP数据包（SRs）从每个媒体发送器中继到其他两个媒体发送器。
The configuration of the Media Senders is identical to the previous case. It is just the Distribution Source that must be aware that there are multiple senders and then perform the necessary relaying. The transport address for the RTP session at the Distribution Source may be identical for all Media Senders (which may make correlation easier) or different addresses may be used.
介质发送器的配置与前一种情况相同。只有分发源必须知道有多个发送方，然后执行必要的中继。分发源处的RTP会话的传输地址对于所有媒体发送方可能是相同的（这可能使关联更容易），或者可以使用不同的地址。
This setup is depicted in Figure 5.
此设置如图5所示。
Source-specific
+-----+ Multicast
+--------+ | | +----------------> R(1)
| Media |<---->| D S | | |
|Sender 1| | I O | +--+ |
+--------+ | S U | | | |
| T R | | +-----------> R(2) |
+--------+ | R C |->+----- : | |
| Media |<---->| I E | | +------> R(n-1) | |
|Sender 2| | B | | | | | |
+--------+ | U | +--+--> R(n) | | |
| T | | | | |
+--------+ | I |<---------+ | | |
| Media |<---->| O |<---------------+ | |
|Sender 3| | N |<--------------------+ |
+--------+ | |<-------------------------+
+-----+ Unicast
Source-specific
+-----+ Multicast
+--------+ | | +----------------> R(1)
| Media |<---->| D S | | |
|Sender 1| | I O | +--+ |
+--------+ | S U | | | |
| T R | | +-----------> R(2) |
+--------+ | R C |->+----- : | |
| Media |<---->| I E | | +------> R(n-1) | |
|Sender 2| | B | | | | | |
+--------+ | U | +--+--> R(n) | | |
| T | | | | |
+--------+ | I |<---------+ | | |
| Media |<---->| O |<---------------+ | |
|Sender 3| | N |<--------------------+ |
+--------+ | |<-------------------------+
+-----+ Unicast
Contribution Distribution Session Session (unicast) (SSM)
贡献分发会话（单播）（SSM）
Figure 5: Three Media Senders, Unicast Contribution
图5：三个媒体发送器，单播贡献
In this final example, the individual unicast contribution sessions between the Media Senders and the Distribution Source are replaced by a single ASM contribution group (i.e., a single common RTP session). Consequently, all Media Senders receive each other's traffic by means of IP-layer multicast and the Distribution Source no longer needs to perform explicit forwarding between the Media Senders. Of course, the Distribution Source still forwards feedback information received from the receivers (optionally as summaries) to the ASM contribution group.
在最后一个示例中，媒体发送方和分发源之间的单个单播贡献会话被单个ASM贡献组（即单个公共RTP会话）替换。因此，所有媒体发送方通过IP层多播接收彼此的流量，分发源不再需要在媒体发送方之间执行显式转发。当然，分发源仍然将从接收者接收到的反馈信息（可选地作为摘要）转发给ASM贡献组。
The ASM contribution group may be statically configured or the necessary information can be communicated using a standard SDP session description for a multicast session. Again, it is up to the implementation of the Distribution Source to properly associate the ASM contribution session and the SSM distribution sessions.
ASM贡献组可以是静态配置的，或者可以使用多播会话的标准SDP会话描述来传送必要的信息。同样，要将ASM贡献会话和SSM分发会话正确关联起来，这取决于分发源的实现。
Figure 6 shows this scenario.
图6显示了这个场景。
_ Source-specific
/ \ +-----+ Multicast
+--------+ | | | | +----------------> R(1)
| Media |<->| A | | D S | | |
|Sender 1| | S | | I O | +--+ |
+--------+ | M | | S U | | | |
| | | T R | | +-----------> R(2) |
+--------+ | G | | R C |->+----- : | |
| Media |<->| r |<->| I E | | +------> R(n-1) | |
|Sender 2| | o | | B | | | | | |
+--------+ | u | | U | +--+--> R(n) | | |
| p | | T | | | | |
+--------+ | | | I |<---------+ | | |
| Media |<->| | | O |<---------------+ | |
|Sender 3| \_/ | N |<--------------------+ |
+--------+ | |<-------------------------+
+-----+ Unicast
_ Source-specific
/ \ +-----+ Multicast
+--------+ | | | | +----------------> R(1)
| Media |<->| A | | D S | | |
|Sender 1| | S | | I O | +--+ |
+--------+ | M | | S U | | | |
| | | T R | | +-----------> R(2) |
+--------+ | G | | R C |->+----- : | |
| Media |<->| r |<->| I E | | +------> R(n-1) | |
|Sender 2| | o | | B | | | | | |
+--------+ | u | | U | +--+--> R(n) | | |
| p | | T | | | | |
+--------+ | | | I |<---------+ | | |
| Media |<->| | | O |<---------------+ | |
|Sender 3| \_/ | N |<--------------------+ |
+--------+ | |<-------------------------+
+-----+ Unicast
Contribution Distribution Session Session (ASM) (SSM)
贡献分配会话（ASM）（SSM）
Figure 6: Three Media Senders in ASM Group
图6:ASM组中的三个媒体发送器
Example processing of Loss Distribution Values
损失分布值的示例处理
X values represent the loss percentage. Y values represent the number of receivers.
X值表示损失百分比。Y值表示接收器的数量。
Number of x values is the NDB value
x值的数量是NDB值
xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV)
xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV)
First data point = MnDV,first ydata
第一个数据点=MnDV，第一个ydata
then
然后
For each ydata => xdata += (MnDV + (xrange / NDB))
For each ydata => xdata += (MnDV + (xrange / NDB))
Packet Variables -> factor,NDB,MnDVL,MaDV
Code variables -> xrange, ydata[NDB],x,y
Packet Variables -> factor,NDB,MnDVL,MaDV
Code variables -> xrange, ydata[NDB],x,y
xrange = MaDV - MnDV
x = MnDV;
xrange = MaDV - MnDV
x = MnDV;
for(i=0; i<NDB; i++) {
y = (ydata[i] * factor);
/*OUTPUT x and y values*/
x += (xrange / NDB);
}
for(i=0; i<NDB; i++) {
y = (ydata[i] * factor);
/*OUTPUT x and y values*/
x += (xrange / NDB);
}
Providing a distribution function in a feedback message has a number of uses for different types of applications. Although this appendix enumerates potential uses for the distribution scheme, it is anticipated that future applications might benefit from it in ways not addressed in this document. Due to the flexible nature of the summarization format, future extensions may easily be added. Some of the scenarios addressed in this section envisage potential uses beyond a simple SSM architecture, for example, single-source group topologies where every receiver may in fact also be capable of becoming the source. Another example may be multiple SSM topologies, which, when combined, make up a larger distribution tree.
在反馈消息中提供分发功能对于不同类型的应用程序有许多用途。尽管本附录列举了分配方案的潜在用途，但预计未来的应用可能会从中受益，但本文档中并未提及。由于摘要格式的灵活性，将来很容易添加扩展。本节讨论的一些场景设想了超出简单SSM体系结构的潜在用途，例如，每个接收器实际上也可以成为源的单源组拓扑。另一个示例可能是多个SSM拓扑，当组合起来时，它们构成一个更大的分布树。
A distribution of values is useful as input into any algorithm, multicast or otherwise, that could be optimized or tuned as a result of having access to the feedback values for all group members. Following is a list of example areas that might benefit from distribution information:
值的分布可作为任何算法（多播或其他）的输入，该算法可作为访问所有组成员的反馈值的结果进行优化或调整。以下是可能受益于分发信息的示例区域列表：
- The parameterization of a multicast Forward Error Correction (FEC) algorithm. Given an accurate estimate of the distribution of reported losses, a source or other distribution agent that does not have a global view would be able to tune the degree of redundancy built into the FEC stream. The distribution might help to identify whether the majority of the group is experiencing high levels of loss, or whether in fact the high loss reports are only from a small subset of the group. Similarly, this data might enable a
- 多播前向纠错（FEC）算法的参数化。给出报告损失分布的准确估计，没有全局视图的源或其他分布代理将能够调整FEC流中内置的冗余度。该分布可能有助于确定集团的大多数成员是否经历了高水平的损失，或者实际上高损失报告是否仅来自集团的一小部分。类似地，此数据可能会启用
receiver to make a more informed decision about whether it should leave a group that includes a very high percentage of the worst-case reporters.
接收者需要做出更明智的决定，决定是否应该离开一个包括非常高比例的最坏情况记者的小组。
- The organization of a multicast data stream into useful layers for layered coding schemes. The distribution of packet losses and delay would help to identify what percentage of members experience various loss and delay levels, and thus how the data stream bandwidth might be partitioned to suit the group conditions. This would require the same algorithm to be used by both senders and receivers in order to derive the same results.
- 将多播数据流组织成有用的层，用于分层编码方案。分组丢失和延迟的分布将有助于确定经历各种丢失和延迟级别的成员的百分比，从而确定如何划分数据流带宽以适应组条件。这将要求发送方和接收方使用相同的算法，以便得出相同的结果。
- The establishment of a suitable feedback threshold. An application might be interested to generate feedback values when above (or below) a particular threshold. However, determining an appropriate threshold may be difficult when the range and distribution of feedback values is not known a priori. In a very large group, knowing the distribution of feedback values would allow a reasonable threshold value to be established, and in turn would have the potential to prevent message implosion if many group members share the same feedback value. A typical application might include a sensor network that gauges temperature or some other natural phenomenon. Another example is a network of mobile devices interested in tracking signal power to assist with hand-off to a different distribution device when power becomes too low.
- 建立合适的反馈阈值。应用程序可能有兴趣在高于（或低于）特定阈值时生成反馈值。然而，当反馈值的范围和分布先验未知时，确定适当的阈值可能是困难的。在一个非常大的组中，了解反馈值的分布将允许建立一个合理的阈值，反过来，如果许多组成员共享相同的反馈值，则有可能防止消息内爆。典型的应用可能包括测量温度或其他自然现象的传感器网络。另一个例子是对跟踪信号功率感兴趣的移动设备网络，以在功率变得过低时协助切换到不同的分配设备。
- The tuning of Suppression algorithms. Having access to the distribution of round-trip times, bandwidth, and network loss would allow optimization of wake-up timers and proper adjustment of the Suppression interval bounds. In addition, biased wake-up functions could be created not only to favor the early response from more capable group members but also to smooth out responses from subsequent respondents and to avoid bursty response traffic.
- 抑制算法的调整。访问往返时间、带宽和网络损耗的分布将允许优化唤醒计时器和适当调整抑制间隔界限。此外，可以创建有偏见的唤醒功能，不仅有利于更有能力的团队成员的早期响应，还可以平滑后续响应者的响应，避免突发响应流量。
- Leader election among a group of processes based on the maximum or minimum of some attribute value. Knowledge of the distribution of values would allow a group of processes to select a leader process or processes to act on behalf of the group. Leader election can promote scalability when group sizes become extremely large.
- 基于某个属性值的最大值或最小值在一组进程中进行的领导者选举。了解价值分布将允许一组流程选择一个或多个领导流程代表该集团行事。当团队规模变得非常大时，领导人选举可以促进可伸缩性。
The following example demonstrates two different ways to convey loss data using the generic format of a Loss sub-report block (Section 7.1.4). The same techniques could also be applied to representing other distribution types.
以下示例演示了使用损失子报告块的通用格式传递损失数据的两种不同方式（第7.1.4节）。同样的技术也可以应用于表示其他分布类型。
1) The first method attempts to represent the data in as few bytes as possible.
1) 第一种方法尝试用尽可能少的字节表示数据。
2) The second method conveys all values without providing any savings in bandwidth.
2) 第二种方法在不节省带宽的情况下传递所有值。
Data Set X values indicate loss percentage reported; Y values indicate the number of receivers reporting that loss percentage.
数据集X值表示报告的损失百分比；Y值表示报告该损失百分比的接收者数量。
X - 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 Y - 1000| 800 | 6 | 1800 | 2600 | 3120 | 2300 | 1100 | 200 | 103
X-0 | 1 | 2 | 3 | 5 | 6 | 7 | 8 | 9 Y-1000 | 800 | 6 | 1800 | 2600 | 3120 | 2300 | 1100 | 200 | 103
X - 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 Y - 74 | 21 | 30 | 65 | 60 | 80 | 6 | 7 | 4 | 5
X-10 | 11 | 12 | 13 | 14 | 16 | 17 | 18 | 19 Y-74 | 21 | 30 | 65 | 60 | 80 | 6 | 7 | 4 | 5
X - 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 Y - 2 | 10 | 870 | 2300 | 1162 | 270 | 234 | 211 | 196 | 205
X-20 | 21 | 22 | 23 | 24 | 25 | 27 | 28 | 29 Y-2 | 10 | 870 | 2300 | 1162 | 270 | 234 | 211 | 196 205
X - 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 Y - 163 | 174 | 103 | 94 | 76 | 52 | 68 | 79 | 42 | 4
X-30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 Y-163 | 174 | 103 | 94 | 76 | 52 | 68 | 79 | 42 | 4
Constant value Due to the size of the multiplicative factor field being 4 bits, the maximum multiplicative value is 15.
常量值由于乘法因子字段的大小为4位，最大乘法值为15。
The distribution type field of this packet would be value 1 since it represents loss data.
此数据包的分发类型字段的值为1，因为它表示丢失数据。
Example: 1st Method
示例：第1种方法
Description The minimal method of conveying data, i.e., small amount of bytes used to convey the values.
描述传输数据的最小方法，即用于传输值的少量字节。
Algorithm Attempt to fit the data set into a small sub-report size, selected length of 8 octets
算法尝试将数据集放入一个小的子报表大小中，选定长度为8个八位字节
Can we split the range (0 - 39) into 16 4-bit values? The largest bucket value would, in this case, be the bucket for X values 5 - 7.5, the sum of which is 5970. An MF value of 9 will generate a multiplicative factor of 2^9, or 512 -- which, multiplied by the max bucket value, produces a maximum real value of 7680.
我们可以将范围（0-39）拆分为16个4位值吗？在这种情况下，最大的桶值将是X值5-7.5的桶，其总和为5970。MF值为9将生成2^9或512的乘法因子，乘以最大桶值，将生成7680的最大实际值。
The packet fields will contain the values:
数据包字段将包含以下值：
Header distribution Block
Distribution Type: 1
Number of Data Buckets: 16
Multiplicative Factor: 9
Packet Length field: 5 (5 * 4 => 20 bytes)
Minimum Data Value: 0
Maximum Data Value: 39
Data Bucket values: (each value is 16-bits)
Header distribution Block
Distribution Type: 1
Number of Data Buckets: 16
Multiplicative Factor: 9
Packet Length field: 5 (5 * 4 => 20 bytes)
Minimum Data Value: 0
Maximum Data Value: 39
Data Bucket values: (each value is 16-bits)
Results, 4-bit buckets:
结果，4位存储桶：
X - 0 - 2.5 | 2.5 - 5 | 5 - 7.5 | 7.5 - 10
(Y - 1803 | 4403 | 5970 | 853 ) ACTUAL
Y - 4 | 9 | 12 | 2
X - 0 - 2.5 | 2.5 - 5 | 5 - 7.5 | 7.5 - 10
(Y - 1803 | 4403 | 5970 | 853 ) ACTUAL
Y - 4 | 9 | 12 | 2
X - 10 - 12.5 | 12.5 - 15 | 15 - 17.5 | 17.5 - 20
(Y - 110 | 140 | 89.5 | 12.5) ACTUAL
Y - 0 | 0 | 0 | 0
X - 10 - 12.5 | 12.5 - 15 | 15 - 17.5 | 17.5 - 20
(Y - 110 | 140 | 89.5 | 12.5) ACTUAL
Y - 0 | 0 | 0 | 0
X - 20 - 22.5 | 22.5 - 25 | 25 - 27.5 | 27.5 - 30
(Y - 447 | 3897 | 609.5 | 506.5) ACTUAL
Y - 1 | 8 | 1 | 1
X - 20 - 22.5 | 22.5 - 25 | 25 - 27.5 | 27.5 - 30
(Y - 447 | 3897 | 609.5 | 506.5) ACTUAL
Y - 1 | 8 | 1 | 1
X - 30 - 32.5 | 32.5 - 35 | 35 - 37.5 | 37.5 - 40
(Y - 388.5 | 221.5 | 159.5 | 85.5) ACTUAL
Y - 1 | 0 | 0 | 0
X - 30 - 32.5 | 32.5 - 35 | 35 - 37.5 | 37.5 - 40
(Y - 388.5 | 221.5 | 159.5 | 85.5) ACTUAL
Y - 1 | 0 | 0 | 0
Example: 2nd Method
示例：第二种方法
Description This demonstrates the most accurate method for representing the data set. This method doesn't attempt to optimise any values.
描述这演示了表示数据集的最精确方法。此方法不尝试优化任何值。
Algorithm Identify the highest value and select buckets large enough to convey the exact values, i.e., no multiplicative factor.
算法确定最高值并选择足够大的桶来传递精确值，即没有乘法因子。
The highest value is 3120. This requires 12 bits (closest 2 bit boundary) to represent, therefore it will use 60 bytes to represent the entire distribution. This is within the max packet size; therefore, all data will fit within one sub-report block. The multiplicative value will be 1.
最高值为3120。这需要12位（最接近的2位边界）来表示，因此它将使用60字节来表示整个分布。这在最大数据包大小内；因此，所有数据都将放在一个子报告块中。乘法值将为1。
The packet fields will contain the values:
数据包字段将包含以下值：
Header Distribution Block
Distribution Type: 1
Number of Data Buckets: 40
Multiplicative Factor: 0
Packet Length field: 18 (18 * 4 => 72 bytes)
Minimum Loss Value: 0
Maximum Loss Value: 39
Header Distribution Block
Distribution Type: 1
Number of Data Buckets: 40
Multiplicative Factor: 0
Packet Length field: 18 (18 * 4 => 72 bytes)
Minimum Loss Value: 0
Maximum Loss Value: 39
Bucket values are the same as the initial data set.
Bucket值与初始数据集相同。
Result Selecting one of the three methods outlined above might be done by a congestion parameter or by user preference. The overhead associated with processing the packets is likely to differ very little between the techniques. The savings in bandwidth are apparent, however, using 20, 52, and 72 octets respectively. These values would vary more widely for a larger data set with less correlation between results.
结果选择上述三种方法中的一种可能通过拥塞参数或用户偏好来完成。与处理分组相关联的开销在这两种技术之间可能相差很小。然而，分别使用20、52和72个八位组，带宽的节省是显而易见的。对于结果之间相关性较小的较大数据集，这些值的变化更大。
Acknowledgements
致谢
The authors would like to thank Magnus Westerlund, Dave Oran, Tom Taylor, and Colin Perkins for detailed reviews and valuable comments.
作者要感谢Magnus Westerlund、Dave Oran、Tom Taylor和Colin Perkins的详细评论和宝贵意见。
Authors' Addresses
作者地址
Joerg Ott Aalto University School of Science and Technology Department of Communications and Networking PO Box 13000 FIN-00076 Aalto
约尔格·奥特阿尔托大学科技学院通信和网络系邮箱13000 FIN-00076阿尔托
EMail: jo@acm.org
EMail: jo@acm.org
Julian Chesterfield University of Cambridge Computer Laboratory, 15 JJ Thompson Avenue Cambridge CB3 0FD UK
朱利安切斯特菲尔德剑桥大学计算机实验室，15 JJ汤普森大道剑桥CB3 0FD英国
EMail: julianchesterfield@cantab.net
EMail: julianchesterfield@cantab.net
Eve Schooler Intel Research / CTL MS RNB6-61 2200 Mission College Blvd. Santa Clara, CA, USA 95054-1537
Eve Schooler Intel Research/CTL MS RNB6-61使命学院大道2200号。美国加利福尼亚州圣克拉拉95054-1537
EMail: eve_schooler@acm.org
EMail: eve_schooler@acm.org