Network Working Group T. Friedman, Ed.
Request for Comments: 3611 Paris 6
Category: Standards Track R. Caceres, Ed.
IBM Research
A. Clark, Ed.
Telchemy
November 2003
Network Working Group T. Friedman, Ed.
Request for Comments: 3611 Paris 6
Category: Standards Track R. Caceres, Ed.
IBM Research
A. Clark, Ed.
Telchemy
November 2003
RTP Control Protocol Extended Reports (RTCP XR)
RTP控制协议扩展报告（RTCP XR）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.
本文档定义了RTP控制协议（RTCP）的扩展报告（XR）数据包类型，并定义了应用程序在使用会话描述协议（SDP）时如何通知XR数据包的使用。XR数据包由报告块组成，这里定义了七种块类型。扩展报告格式的目的是传递信息，补充RTCP发送方报告（SR）和接收方报告（RR）数据包使用的报告块中包含的六个统计信息。一些应用程序，如网络特征的多播推断（MINC）或IP语音（VoIP）监控，需要其他更详细的统计数据。除了此处定义的块类型外，将来还可以通过遵循本文档提供的框架来定义其他块类型。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 7
2. XR Packet Format . . . . . . . . . . . . . . . . . . . . . . . 7
3. Extended Report Block Framework. . . . . . . . . . . . . . . . 8
4. Extended Report Blocks . . . . . . . . . . . . . . . . . . . . 9
4.1. Loss RLE Report Block. . . . . . . . . . . . . . . . . . 9
4.1.1. Run Length Chunk . . . . . . . . . . . . . . . . 15
4.1.2. Bit Vector Chunk . . . . . . . . . . . . . . . . 15
4.1.3. Terminating Null Chunk . . . . . . . . . . . . . 16
4.2. Duplicate RLE Report Block . . . . . . . . . . . . . . . 16
4.3. Packet Receipt Times Report Block. . . . . . . . . . . . 18
4.4. Receiver Reference Time Report Block . . . . . . . . . . 20
4.5. DLRR Report Block. . . . . . . . . . . . . . . . . . . . 21
4.6. Statistics Summary Report Block. . . . . . . . . . . . . 22
4.7. VoIP Metrics Report Block. . . . . . . . . . . . . . . . 25
4.7.1. Packet Loss and Discard Metrics. . . . . . . . . 27
4.7.2. Burst Metrics. . . . . . . . . . . . . . . . . . 27
4.7.3. Delay Metrics. . . . . . . . . . . . . . . . . . 30
4.7.4. Signal Related Metrics . . . . . . . . . . . . . 31
4.7.5. Call Quality or Transmission Quality Metrics . . 33
4.7.6. Configuration Parameters . . . . . . . . . . . . 34
4.7.7. Jitter Buffer Parameters . . . . . . . . . . . . 36
5. SDP Signaling. . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1. The SDP Attribute. . . . . . . . . . . . . . . . . . . . 37
5.2. Usage in Offer/Answer. . . . . . . . . . . . . . . . . . 40
5.3. Usage Outside of Offer/Answer. . . . . . . . . . . . . . 42
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 42
6.1. XR Packet Type . . . . . . . . . . . . . . . . . . . . . 42
6.2. RTCP XR Block Type Registry. . . . . . . . . . . . . . . 42
6.3. The "rtcp-xr" SDP Attribute. . . . . . . . . . . . . . . 43
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 44
A. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.1. Sequence Number Interpretation . . . . . . . . . . . . . 46
A.2. Example Burst Packet Loss Calculation. . . . . . . . . . 47
Intellectual Property Notice . . . . . . . . . . . . . . . . . . . 49
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 50
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Normative References . . . . . . . . . . . . . . . . . . . . . . . 51
Informative References . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 7
2. XR Packet Format . . . . . . . . . . . . . . . . . . . . . . . 7
3. Extended Report Block Framework. . . . . . . . . . . . . . . . 8
4. Extended Report Blocks . . . . . . . . . . . . . . . . . . . . 9
4.1. Loss RLE Report Block. . . . . . . . . . . . . . . . . . 9
4.1.1. Run Length Chunk . . . . . . . . . . . . . . . . 15
4.1.2. Bit Vector Chunk . . . . . . . . . . . . . . . . 15
4.1.3. Terminating Null Chunk . . . . . . . . . . . . . 16
4.2. Duplicate RLE Report Block . . . . . . . . . . . . . . . 16
4.3. Packet Receipt Times Report Block. . . . . . . . . . . . 18
4.4. Receiver Reference Time Report Block . . . . . . . . . . 20
4.5. DLRR Report Block. . . . . . . . . . . . . . . . . . . . 21
4.6. Statistics Summary Report Block. . . . . . . . . . . . . 22
4.7. VoIP Metrics Report Block. . . . . . . . . . . . . . . . 25
4.7.1. Packet Loss and Discard Metrics. . . . . . . . . 27
4.7.2. Burst Metrics. . . . . . . . . . . . . . . . . . 27
4.7.3. Delay Metrics. . . . . . . . . . . . . . . . . . 30
4.7.4. Signal Related Metrics . . . . . . . . . . . . . 31
4.7.5. Call Quality or Transmission Quality Metrics . . 33
4.7.6. Configuration Parameters . . . . . . . . . . . . 34
4.7.7. Jitter Buffer Parameters . . . . . . . . . . . . 36
5. SDP Signaling. . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1. The SDP Attribute. . . . . . . . . . . . . . . . . . . . 37
5.2. Usage in Offer/Answer. . . . . . . . . . . . . . . . . . 40
5.3. Usage Outside of Offer/Answer. . . . . . . . . . . . . . 42
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 42
6.1. XR Packet Type . . . . . . . . . . . . . . . . . . . . . 42
6.2. RTCP XR Block Type Registry. . . . . . . . . . . . . . . 42
6.3. The "rtcp-xr" SDP Attribute. . . . . . . . . . . . . . . 43
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 44
A. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.1. Sequence Number Interpretation . . . . . . . . . . . . . 46
A.2. Example Burst Packet Loss Calculation. . . . . . . . . . 47
Intellectual Property Notice . . . . . . . . . . . . . . . . . . . 49
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 50
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Normative References . . . . . . . . . . . . . . . . . . . . . . . 51
Informative References . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 55
This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP) [9], and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP) [4]. XR packets convey information beyond that already contained in the reception report blocks of RTCP's sender report (SR) or Receiver Report (RR) packets. The information is of use across RTP profiles, and so is not appropriately carried in SR or RR profile-specific extensions. Information used for network management falls into this category, for instance.
本文档定义了RTP控制协议（RTCP）[9]的扩展报告（XR）数据包类型，并定义了应用程序在使用会话描述协议（SDP）[4]时如何通知XR数据包的使用。XR数据包传递的信息超出了RTCP发送方报告（SR）或接收方报告（RR）数据包的接收报告块中已经包含的信息。这些信息在RTP配置文件中使用，因此在特定于SR或RR配置文件的扩展中没有适当的携带。例如，用于网络管理的信息属于这一类。
The definition is broken out over the three sections that follow the Introduction. Section 2 defines the XR packet as consisting of an eight octet header followed by a series of components called report blocks. Section 3 defines the common format, or framework, consisting of a type and a length field, required for all report blocks. Section 4 defines several specific report block types. Other block types can be defined in future documents as the need arises.
该定义在导言之后的三个部分中进行了分解。第2节将XR数据包定义为由一个八位字节的报头和一系列称为报告块的组件组成。第3节定义了所有报告块所需的通用格式或框架，由类型和长度字段组成。第4节定义了几种特定的报告块类型。其他块类型可根据需要在将来的文档中定义。
The report block types defined in this document fall into three categories. The first category consists of packet-by-packet reports on received or lost RTP packets. Reports in the second category convey reference time information between RTP participants. In the third category, reports convey metrics relating to packet receipts, that are summary in nature but that are more detailed, or of a different type, than that conveyed in existing RTCP packets.
本文档中定义的报告块类型分为三类。第一类由接收或丢失的RTP数据包的逐数据包报告组成。第二类报告在RTP参与者之间传递参考时间信息。在第三类中，报告传递与数据包接收相关的指标，这些指标本质上是摘要，但与现有RTCP数据包中传递的指标相比，这些指标更为详细，或者具有不同的类型。
All told, seven report block formats are defined by this document. Of these, three are packet-by-packet block types:
本文档总共定义了七种报告块格式。其中三种是逐包块类型：
- Loss RLE Report Block (Section 4.1): Run length encoding of reports concerning the losses and receipts of RTP packets.
- 丢失RLE报告块（第4.1节）：有关RTP数据包丢失和接收的报告的运行长度编码。
- Duplicate RLE Report Block (Section 4.2): Run length encoding of reports concerning duplicates of received RTP packets.
- 重复RLE报告块（第4.2节）：有关接收到的RTP数据包的重复报告的运行长度编码。
- Packet Receipt Times Report Block (Section 4.3): A list of reception timestamps of RTP packets.
- 数据包接收时间报告块（第4.3节）：RTP数据包的接收时间戳列表。
There are two reference time related block types:
有两种与参考时间相关的块类型：
- Receiver Reference Time Report Block (Section 4.4): Receiver-end wallclock timestamps. Together with the DLRR Report Block mentioned next, these allow non-senders to calculate round-trip times.
- 接收器参考时间报告块（第4.4节）：接收器端壁时钟时间戳。与下面提到的DLRR报告块一起，它们允许非发送方计算往返时间。
- DLRR Report Block (Section 4.5): The delay since the last Receiver Reference Time Report Block was received. An RTP data sender that receives a Receiver Reference Time Report Block can respond with a DLRR Report Block, in much the same way as, in the mechanism already defined for RTCP [9, Section 6.3.1], an RTP data receiver that receives a sender's NTP timestamp can respond by filling in the DLSR field of an RTCP reception report block.
- DLRR报告块（第4.5节）：自上次接收接收器参考时间报告块以来的延迟。接收接收方参考时间报告块的RTP数据发送方可以使用DLRR报告块进行响应，其方式与已为RTCP定义的机制[9，第6.3.1节]中的方式大致相同，接收发送方NTP时间戳的RTP数据接收方可以通过填写RTCP接收报告块的DLSR字段进行响应。
Finally, this document defines two summary metric block types:
最后，本文档定义了两种汇总度量块类型：
- Statistics Summary Report Block (Section 4.6): Statistics on RTP packet sequence numbers, losses, duplicates, jitter, and TTL or Hop Limit values.
- 统计摘要报告块（第4.6节）：RTP数据包序列号、丢失、重复、抖动和TTL或跃点限制值的统计。
- VoIP Metrics Report Block (Section 4.7): Metrics for monitoring Voice over IP (VoIP) calls.
- VoIP指标报告块（第4.7节）：用于监控IP语音（VoIP）呼叫的指标。
Before proceeding to the XR packet and report block definitions, this document provides an applicability statement (Section 1.1) that describes the contexts in which these report blocks can be used. It also defines (Section 1.2) the normative use of key words, such as MUST and SHOULD, as they are employed in this document.
在继续进行XR数据包和报告块定义之前，本文档提供了一个适用性声明（第1.1节），该声明描述了这些报告块可以使用的上下文。它还定义了（第1.2节）本文件中使用的关键词的规范用法，如必须和应该。
Following the definitions of the various report blocks, this document describes how applications that employ SDP can signal their use (Section 5). The document concludes with a discussion (Section 6) of numbering considerations for the Internet Assigned Numbers Authority (IANA), of security considerations (Section 7), and with appendices that provide examples of how to implement algorithms discussed in the text.
根据各种报告块的定义，本文档描述了使用SDP的应用程序如何发出使用信号（第5节）。本文件最后讨论了互联网分配号码管理局（IANA）的编号注意事项（第6节）、安全注意事项（第7节）以及附录，附录提供了如何实现本文中讨论的算法的示例。
The XR packets are useful across multiple applications, and for that reason are not defined as profile-specific extensions to RTCP sender or Receiver Reports [9, Section 6.4.3]. Nonetheless, they are not of use in all contexts. In particular, the VoIP metrics report block (Section 4.7) is specific to voice applications, though it can be employed over a wide variety of such applications.
XR数据包在多个应用程序中都很有用，因此未定义为RTCP发送方或接收方报告的特定于配置文件的扩展[9，第6.4.3节]。尽管如此，它们并非在所有情况下都有用。特别是，VoIP度量报告块（第4.7节）特定于语音应用程序，尽管它可以用于各种各样的此类应用程序。
The VoIP metrics report block can be applied to any one-to-one or one-to-many voice application for which the use of RTP and RTCP is specified. The use of conversational metrics (Section 4.7.5), including the R factor (as described by the E Model defined in [3]) and the mean opinion score for conversational quality (MOS-CQ), in applications other than simple two party calls is not defined; hence, these metrics should be identified as unavailable in multicast conferencing applications.
VoIP度量报告块可应用于指定使用RTP和RTCP的任何一对一或一对多语音应用程序。在除简单的两方通话以外的应用中，未定义会话指标（第4.7.5节）的使用，包括R系数（如[3]中定义的E模型所述）和会话质量平均意见分数（MOS-CQ）；因此，应将这些度量标识为在多播会议应用程序中不可用。
The packet-by-packet report block types, Loss RLE (Section 4.1), Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3), have been defined with network tomography applications, such as multicast inference of network characteristics (MINC) [11], in mind. MINC requires detailed packet receipt traces from multicast session receivers in order to infer the gross structure of the multicast distribution tree and the parameters, such as loss rates and delays, that apply to paths between the branching points of that tree.
在网络层析成像应用中，如网络特征的多播推断（MINC）[11]，定义了逐包报告块类型、丢失RLE（第4.1节）、重复RLE（第4.2节）和数据包接收时间（第4.3节）。MINC需要来自多播会话接收器的详细数据包接收跟踪，以便推断多播分发树的总体结构以及适用于该树分支点之间的路径的参数，例如丢失率和延迟。
Any real time multicast multimedia application can use the packet-by-packet report block types. Such an application could employ a MINC inference subsystem that would provide it with multicast tree topology information. One potential use of such a subsystem would be for the identification of high loss regions in the multicast tree and the identification of multicast session participants well situated to provide retransmissions of lost packets.
任何实时多播多媒体应用程序都可以使用逐包报告块类型。这样的应用程序可以使用MINC推理子系统，该子系统将为其提供多播树拓扑信息。这种子系统的一个潜在用途是识别多播树中的高丢失区域，以及识别位置良好的多播会话参与者，以提供丢失分组的重传。
Detailed packet-by-packet reports do not necessarily have to consume disproportionate bandwidth with respect to other RTCP packets. An application can cap the size of these blocks. A mechanism called "thinning" is provided for these report blocks, and can be used to ensure that they adhere to a size limit by restricting the number of packets reported upon within any sequence number interval. The rationale for, and use of this mechanism is described in [13]. Furthermore, applications might not require report blocks from all receivers in order to answer such important questions as where in the multicast tree there are paths that exceed a defined loss rate threshold. Intelligent decisions regarding which receivers send these report blocks can further restrict the portion of RTCP bandwidth that they consume.
与其他RTCP数据包相比，详细的逐数据包报告不一定要消耗不成比例的带宽。应用程序可以限制这些块的大小。为这些报告块提供了一种称为“细化”的机制，并可用于通过在任何序列号间隔内限制报告的数据包数量来确保它们遵守大小限制。[13]中描述了该机制的原理和使用。此外，应用程序可能不需要来自所有接收器的报告块来回答诸如在多播树中哪里有超过定义的丢失率阈值的路径之类的重要问题。关于哪些接收器发送这些报告块的智能决策可以进一步限制它们消耗的RTCP带宽部分。
The packet-by-packet report blocks can also be used by dedicated network monitoring applications. For such an application, it might be appropriate to allow more than 5% of RTP data bandwidth to be used for RTCP packets, thus allowing proportionately larger and more detailed report blocks.
专用网络监控应用程序也可以使用逐包报告块。对于这样的应用程序，允许RTCP数据包使用超过5%的RTP数据带宽可能是合适的，从而允许按比例增大和更详细的报告块。
Nothing in the packet-by-packet block types restricts their use to multicast applications. In particular, they could be used for network tomography similar to MINC, but using striped unicast packets instead. In addition, if it were found useful, they could be used for applications limited to two participants.
逐包块类型中的任何内容都不会限制它们在多播应用程序中的使用。特别是，它们可以用于类似于MINC的网络层析成像，但可以使用条带单播数据包。此外，如果发现有用，它们可用于限于两名参与者的应用程序。
One use to which the packet-by-packet reports are not immediately suited is for data packet acknowledgments as part of a packet retransmission mechanism. The reason is that the packet accounting technique suggested for these blocks differs from the packet accounting normally employed by RTP. In order to favor measurement
逐包报告不立即适合的一种用途是作为包重传机制的一部分用于数据包确认。原因是为这些块建议的包记帐技术不同于RTP通常采用的包记帐。为了便于测量
applications, an effort is made to interpret as little as possible at the data receiver, and leave the interpretation as much as possible to participants that receive the report blocks. Thus, for example, a packet with an anomalous SSRC ID or an anomalous sequence number might be excluded by normal RTP accounting, but would be reported upon for network monitoring purposes.
在应用程序中，尽可能少地在数据接收器处进行解释，并将解释尽可能多地留给接收报告块的参与者。因此，例如，具有异常SSRC ID或异常序列号的数据包可能被正常RTP记帐排除，但出于网络监视目的将被报告。
The Statistics Summary Report Block (Section 4.6) has also been defined with network monitoring in mind. This block type can be used equally well for reporting on unicast and multicast packet reception.
统计摘要报告块（第4.6节）的定义还考虑了网络监控。这种块类型同样适用于报告单播和多播数据包接收情况。
The reference time related block types were conceived for receiver-based TCP-friendly multicast congestion control [18]. By allowing data receivers to calculate their round trip times to senders, they help the receivers estimate the downstream bandwidth they should request. Note that if every receiver is to send Receiver Reference Time Report Blocks (Section 4.4), a sender might potentially send a number of DLRR Report Blocks (Section 4.5) equal to the number of receivers whose RTCP packets have arrived at the sender within its reporting interval. As the number of participants in a multicast session increases, an application should use discretion regarding which participants send these blocks, and how frequently.
参考时间相关的块类型用于基于接收器的TCP友好多播拥塞控制[18]。通过允许数据接收者计算他们到发送者的往返时间，他们帮助接收者估计他们应该请求的下游带宽。请注意，如果每个接收器都要发送接收器参考时间报告块（第4.4节），则发送方可能发送的DLRR报告块数量（第4.5节）可能等于其RTCP数据包在其报告间隔内到达发送方的接收器数量。随着多播会话中的参与者数量的增加，应用程序应自行决定哪些参与者发送这些块，以及发送的频率。
XR packets supplement the existing RTCP packets, and may be stacked with other RTCP packets to form compound RTCP packets [9, Section 6]. The introduction of XR packets into a session in no way changes the rules governing the calculation of the RTCP reporting interval [9, Section 6.2]. As XR packets are RTCP packets, they count as such for bandwidth calculations. As a result, the addition of extended reporting information may tend to increase the average RTCP packet size, and thus the average reporting interval. This increase may be limited by limiting the size of XR packets.
XR数据包补充现有RTCP数据包，并可与其他RTCP数据包叠加，形成复合RTCP数据包[9，第6节]。将XR数据包引入会话不会改变RTCP报告间隔计算的规则[9，第6.2节]。由于XR数据包是RTCP数据包，因此它们在计算带宽时也会计算在内。因此，添加扩展报告信息可能会增加平均RTCP数据包大小，从而增加平均报告间隔。通过限制XR数据包的大小可以限制这种增加。
The SDP signaling defined for XR packets in this document (Section 5) was done so with three use scenarios in mind: a Real Time Streaming Protocol (RTSP) controlled streaming application, a one-to-many multicast multimedia application such as a course lecture with enhanced feedback, and a Session Initiation Protocol (SIP) controlled conversational session involving two parties. Applications that employ SDP are free to use additional SDP signaling for cases not covered here. In addition, applications are free to use signaling mechanisms other than SDP.
本文档（第5节）中为XR数据包定义的SDP信令是在考虑三种使用场景的情况下完成的：实时流协议（RTSP）控制的流应用程序、一对多组播多媒体应用程序（如带有增强反馈的课程讲座）和会话启动协议（SIP）双方参与的受控会话。使用SDP的应用程序可以在此处未涉及的情况下免费使用额外的SDP信令。此外，应用程序可以自由使用SDP以外的信令机制。
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 BCP 14, RFC 2119 [1] and indicate requirement levels for compliance with this specification.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释，并表明符合本规范的要求水平。
An XR packet consists of a header of two 32-bit words, followed by a number, possibly zero, of extended report blocks. This type of packet is laid out in a manner consistent with other RTCP packets, as concerns the essential version, packet type, and length information. XR packets are thus backwards compatible with RTCP receiver implementations that do not recognize them, but that ought to be able to parse past them using the length information. A padding field and an SSRC field are also provided in the same locations that they appear in other RTCP packets, for simplicity. The format is as follows:
XR数据包由两个32位字的报头组成，后面是扩展报告块的数字（可能为零）。就基本版本、数据包类型和长度信息而言，此类数据包的布局方式与其他RTCP数据包一致。因此，XR数据包与不识别它们的RTCP接收器实现向后兼容，但应该能够使用长度信息解析过去的数据包。为简单起见，在其他RTCP数据包中显示的相同位置还提供了填充字段和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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: report blocks :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
version (V): 2 bits Identifies the version of RTP. This specification applies to RTP version two.
版本（V）：2位标识RTP的版本。本规范适用于RTP版本2。
padding (P): 1 bit If the padding bit is set, this XR packet contains some additional padding octets at the end. The semantics of this field are identical to the semantics of the padding field in the SR packet, as defined by the RTP specification.
padding（P）：1位如果设置了padding位，则此XR数据包在末尾包含一些额外的padding八位字节。该字段的语义与RTP规范定义的SR数据包中填充字段的语义相同。
reserved: 5 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
保留：5位此字段保留供将来定义。在没有这种定义的情况下，此字段中的位必须设置为零，并且必须被接收器忽略。
packet type (PT): 8 bits Contains the constant 207 to identify this as an RTCP XR packet. This value is registered with the Internet Assigned Numbers Authority (IANA), as described in Section 6.1.
数据包类型（PT）：8位包含常数207，用于将其标识为RTCP XR数据包。如第6.1节所述，该值在互联网分配号码管理局（IANA）注册。
length: 16 bits As described for the RTCP Sender Report (SR) packet (see Section 6.4.1 of the RTP specification [9]). Briefly, the length of this XR packet in 32-bit words minus one, including the header and any padding.
长度：如RTCP发送方报告（SR）数据包所述的16位（见RTP规范第6.4.1节[9]）。简而言之，此XR数据包的长度（以32位字为单位）减去1，包括标头和任何填充。
SSRC: 32 bits The synchronization source identifier for the originator of this XR packet.
SSRC:32位此XR数据包的发起方的同步源标识符。
report blocks: variable length. Zero or more extended report blocks. In keeping with the extended report block framework defined below, each block MUST consist of one or more 32-bit words.
报告块：可变长度。零个或多个扩展报告块。为了与下面定义的扩展报告块框架保持一致，每个块必须由一个或多个32位字组成。
Extended report blocks are stacked, one after the other, at the end of an XR packet. An individual block's length is a multiple of 4 octets. The XR header's length field describes the total length of the packet, including these extended report blocks.
扩展报告块依次堆叠在XR数据包的末尾。单个块的长度是4个八位字节的倍数。XR标头的长度字段描述数据包的总长度，包括这些扩展报告块。
Each block has block type and length fields that facilitate parsing. A receiving application can demultiplex the blocks based upon their type, and can use the length information to locate each successive block, even in the presence of block types it does not recognize.
每个块都有便于解析的块类型和长度字段。接收应用程序可以根据块的类型将其解复用，并且可以使用长度信息来定位每个连续块，即使存在它无法识别的块类型。
An extended report block has the following format:
扩展报告块具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT | type-specific | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: type-specific block contents :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT | type-specific | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: type-specific block contents :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits Identifies the block format. Seven block types are defined in Section 4. Additional block types may be defined in future specifications. This field's name space is managed by the Internet Assigned Numbers Authority (IANA), as described in Section 6.2.
块类型（BT）：8位标识块格式。第4节定义了七种块类型。其他块类型可在将来的规范中定义。如第6.2节所述，该字段的名称空间由互联网分配号码管理局（IANA）管理。
type-specific: 8 bits The use of these bits is determined by the block type definition.
类型特定：8位这些位的使用由块类型定义确定。
block length: 16 bits The length of this report block, including the header, in 32- bit words minus one. If the block type definition permits, zero is an acceptable value, signifying a block that consists of only the BT, type-specific, and block length fields, with a null type-specific block contents field.
块长度：16位此报告块的长度，包括标题，以32位字减去1表示。如果块类型定义允许，则零是可接受的值，表示仅由BT、类型特定和块长度字段组成的块，以及空的类型特定块内容字段。
type-specific block contents: variable length The use of this field is defined by the particular block type, subject to the constraint that it MUST be a multiple of 32 bits long. If the block type definition permits, It MAY be zero bits long.
特定于类型的块内容：可变长度此字段的使用由特定的块类型定义，受其长度必须为32位的倍数的约束。如果块类型定义允许，则其长度可能为零位。
This section defines seven extended report blocks: block types for reporting upon received packet losses and duplicates, packet reception times, receiver reference time information, receiver inter-report delays, detailed reception statistics, and voice over IP (VoIP) metrics. An implementation SHOULD ignore incoming blocks with types not relevant or unknown to it. Additional block types MUST be registered with the Internet Assigned Numbers Authority (IANA) [16], as described in Section 6.2.
本节定义了七个扩展报告块：用于报告接收到的数据包丢失和重复、数据包接收时间、接收器参考时间信息、接收器报告间延迟、详细接收统计信息和IP语音（VoIP）度量的块类型。实现应该忽略类型与其无关或未知的传入块。如第6.2节所述，其他块类型必须向互联网分配号码管理局（IANA）[16]注册。
This block type permits detailed reporting upon individual packet receipt and loss events. Such reports can be used, for example, for multicast inference of network characteristics (MINC) [11]. With MINC, one can discover the topology of the multicast tree used for distributing a source's RTP packets, and of the loss rates along links within that tree, or they could be used to provide raw data to a network management application.
这种块类型允许对单个数据包接收和丢失事件进行详细报告。例如，此类报告可用于网络特征的多播推断（MINC）[11]。使用MINC，可以发现用于分发源RTP数据包的多播树的拓扑结构，以及该树内链路的丢失率，或者它们可以用于向网络管理应用程序提供原始数据。
Since a Boolean trace of lost and received RTP packets is potentially lengthy, this block type permits the trace to be compressed through run length encoding. To further reduce block size, loss event reports can be systematically dropped from the trace in a mechanism called thinning that is described below and that is studied in [13].
由于丢失和接收的RTP数据包的布尔跟踪可能很长，因此此块类型允许通过运行长度编码对跟踪进行压缩。为了进一步减小块大小，损失事件报告可以通过一种称为细化的机制系统地从记录道中删除，该机制将在下文描述，并在[13]中进行研究。
A participant that generates a Loss RLE Report Block should favor accuracy in reporting on observed events over interpretation of those events whenever possible. Interpretation should be left to those who observe the report blocks. Following this approach implies that
生成损失RLE报告块的参与者应尽可能准确地报告观察到的事件，而不是解释这些事件。应将解释权留给观察报告块的人员。遵循这种方法意味着
accounting for Loss RLE Report Blocks will differ from the accounting for the generation of the SR and RR packets described in the RTP specification [9] in the following two areas: per-sender accounting and per-packet accounting.
在以下两个方面，丢失RLE报告块的核算与RTP规范[9]中描述的SR和RR数据包生成的核算不同：每个发送方核算和每个数据包核算。
In its per-sender accounting, an RTP session participant SHOULD NOT make the receipt of a threshold minimum number of RTP packets a condition for reporting upon the sender of those packets. This accounting technique differs from the technique described in Section 6.2.1 and Appendix A.1 of the RTP specification that allows a threshold to determine whether a sender is considered valid.
在每个发送方的计费中，RTP会话参与者不应将接收到的RTP数据包的阈值最小数量作为向这些数据包的发送方报告的条件。该计费技术不同于RTP规范第6.2.1节和附录A.1中描述的技术，该技术允许一个阈值来确定发送方是否被视为有效。
In its per-packet accounting, an RTP session participant SHOULD treat all sequence numbers as valid. This accounting technique differs from the technique described in Appendix A.1 of the RTP specification that suggests ruling a sequence number valid or invalid on the basis of its contiguity with the sequence numbers of previously received packets.
在每包计费中，RTP会话参与者应将所有序列号视为有效。该记帐技术不同于RTP规范附录A.1中描述的技术，该技术建议根据序列号与先前接收的数据包的序列号的连续性来判定序列号是否有效。
Sender validity and sequence number validity are interpretations of the raw data. Such interpretations are justified in the interest, for example, of excluding the stray old packet from an unrelated session from having an effect upon the calculation of the RTCP transmission interval. The presence of stray packets might, on the other hand, be of interest to a network monitoring application.
发送方有效性和序列号有效性是对原始数据的解释。这样的解释是合理的，例如，为了排除来自无关会话的散乱的旧分组对RTCP传输间隔的计算产生影响。另一方面，网络监控应用程序可能会对杂散分组的存在感兴趣。
One accounting interpretation that is still necessary is for a participant to decide whether the 16 bit sequence number has rolled over. Under ordinary circumstances this is not a difficult task. For example, if packet number 65,535 (the highest possible sequence number) is followed shortly by packet number 0, it is reasonable to assume that there has been a rollover. However, it is possible that the packet is an earlier one (from 65,535 packets earlier). It is also possible that the sequence numbers have rolled over multiple times, either forward or backward. The interpretation becomes more difficult when there are large gaps between the sequence numbers, even accounting for rollover, and when there are long intervals between received packets.
一个仍然需要的会计解释是参与者决定16位序列号是否已滚动。在一般情况下，这不是一项困难的任务。例如，如果数据包编号65535（可能的最高序列号）后面紧跟着数据包编号0，则可以合理地假设发生了翻滚。然而，数据包可能是较早的数据包（来自较早的65535个数据包）。序列号也可能已向前或向后滚动多次。当序列号之间存在较大的间隔时（甚至考虑到滚动），以及当接收到的数据包之间存在较长的间隔时，解释变得更加困难。
The per-packet accounting technique mandated here is for a participant to keep track of the sequence number of the packet most recently received from a sender. For the next packet that arrives from that sender, the sequence number MUST be judged to fall no more than 32,768 packets ahead or behind the most recent one, whichever choice places it closer. In the event that both choices are equally distant (only possible when the distance is 32,768), the choice MUST be the one that does not require a rollover. Appendix A.1 presents an algorithm that implements this technique.
这里强制要求的每包计费技术用于参与者跟踪最近从发送方接收的包的序列号。对于从该发送方到达的下一个数据包，序列号必须被判断为不超过32768个数据包位于最近一个数据包的前面或后面，无论选择哪个位置更靠近。如果两个选项的距离相等（仅当距离为32768时才可能），则该选项必须是不需要滚动的选项。附录A.1给出了实现该技术的算法。
Each block reports on a single RTP data packet source, identified by its SSRC. The receiver that is supplying the report is identified in the header of the RTCP packet.
每个块报告单个RTP数据包源，由其SSRC标识。提供报告的接收器在RTCP数据包的标头中标识。
Choice of beginning and ending RTP packet sequence numbers for the trace is left to the application. These values are reported in the block. The last sequence number in the trace MAY differ from the sequence number reported on in any accompanying SR or RR report.
跟踪的开始和结束RTP数据包序列号的选择留给应用程序。这些值在块中报告。跟踪中的最后一个序列号可能与随附的SR或RR报告中报告的序列号不同。
Note that because of sequence number wraparound, the ending sequence number MAY be less than the beginning sequence number. A Loss RLE Report Block MUST NOT be used to report upon a range of 65,534 or greater in the sequence number space, as there is no means of identifying multiple wraparounds.
请注意，由于序列号环绕，结束序列号可能小于开始序列号。丢失RLE报告块不得用于报告序列号空间中65534或更大的范围，因为无法识别多个包装。
The trace described by a Loss RLE report consists of a sequence of Boolean values, one for each sequence number of the trace. A value of one represents a packet receipt, meaning that one or more packets having that sequence number have been received since the most recent wraparound of sequence numbers (or since the beginning of the RTP session if no wraparound has been judged to have occurred). A value of zero represents a packet loss, meaning that there has been no packet receipt for that sequence number as of the time of the report. If a packet with a given sequence number is received after a report of a loss for that sequence number, a later Loss RLE report MAY report a packet receipt for that sequence number.
丢失RLE报告描述的跟踪由一系列布尔值组成，每个布尔值对应一个跟踪序列号。值1表示数据包接收，这意味着自最近一次序列号环绕以来（或者自RTP会话开始以来，如果判断没有发生环绕），已经接收到具有该序列号的一个或多个数据包。值为零表示数据包丢失，这意味着截至报告时该序列号尚未收到数据包。如果在该序列号的丢失报告之后接收到具有给定序列号的分组，则随后的丢失RLE报告可以报告该序列号的分组接收。
The encoding itself consists of a series of 16 bit units called chunks that describe sequences of packet receipts or losses in the trace. Each chunk either specifies a run length or a bit vector, or is a null chunk. A run length describes between 1 and 16,383 events that are all the same (either all receipts or all losses). A bit vector describes 15 events that may be mixed receipts and losses. A null chunk describes no events, and is used to round out the block to a 32 bit word boundary.
编码本身由一系列称为块的16位单元组成，这些单元描述跟踪中的数据包接收或丢失序列。每个块指定一个运行长度或位向量，或者是一个空块。运行长度描述了1到16383个相同的事件（所有收入或所有损失）。一个位向量描述了15个可能是收入和损失混合的事件。空块不描述任何事件，用于将块舍入到32位字边界。
The mapping from a sequence of lost and received packets into a sequence of chunks is not necessarily unique. For example, the following trace covers 45 packets, of which the 22nd and 24th have been lost and the others received:
从丢失和接收的数据包序列到数据块序列的映射不一定是唯一的。例如，以下跟踪覆盖45个数据包，其中第22个和第24个数据包丢失，其他数据包收到：
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
One way to encode this would be:
对其进行编码的一种方法是：
bit vector 1111 1111 1111 111 bit vector 1111 1101 0111 111 bit vector 1111 1111 1111 111 null chunk
位向量111111111111111111111111111111111111111111111111111111111111111111111111111位向量111111111111111111111空块
Another way to encode this would be:
另一种编码方式是：
run of 21 receipts bit vector 0101 1111 1111 111 run of 9 receipts null chunk
运行21个回执位向量010111111111111运行9个回执空块
The choice of encoding is left to the application. As part of this freedom of choice, applications MAY terminate a series of run length and bit vector chunks with a bit vector chunk that runs beyond the sequence number space described by the report block. For example, if the 44th packet in the same sequence was lost:
编码的选择留给应用程序。作为这种自由选择的一部分，应用程序可以使用超出报告块描述的序列号空间的位向量块终止一系列运行长度和位向量块。例如，如果相同序列中的第44个数据包丢失：
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
This could be encoded as:
这可以编码为：
run of 21 receipts bit vector 0101 1111 1111 111 bit vector 1111 1110 1000 000 null chunk
运行21位向量0101 1111 1111 111位向量1111 1110 1000 000空块
In this example, the last five bits of the second bit vector describe a part of the sequence number space that extends beyond the last sequence number in the trace. These bits have been set to zero.
在本例中，第二位向量的最后五位描述了超出跟踪中最后一个序列号的序列号空间的一部分。这些位已设置为零。
All bits in a bit vector chunk that describe a part of the sequence number space that extends beyond the last sequence number in the trace MUST be set to zero, and MUST be ignored by the receiver.
位向量块中描述超出跟踪中最后一个序列号的序列号空间部分的所有位必须设置为零，并且接收器必须忽略。
A null packet MUST appear at the end of a Loss RLE Report Block if the number of run length plus bit vector chunks is odd. The null chunk MUST NOT appear in any other context.
如果运行长度加上位向量块的数量为奇数，则空数据包必须出现在丢失RLE报告块的末尾。空块不能出现在任何其他上下文中。
Caution should be used in sending Loss RLE Report Blocks because, even with the compression provided by run length encoding, they can easily consume bandwidth out of proportion with normal RTCP packets. The block type includes a mechanism, called thinning, that allows an application to limit report sizes.
发送丢失RLE报告块时应小心，因为即使使用运行长度编码提供的压缩，它们也很容易消耗带宽，与正常RTCP数据包不相称。块类型包括一种称为细化的机制，允许应用程序限制报告大小。
A thinning value, T, selects a subset of packets within the sequence number space: those with sequence numbers that are multiples of 2^T. Packet reception and loss reports apply only to those packets. T can vary between 0 and 15. If T is zero, then every packet in the sequence number space is reported upon. If T is fifteen, then one in every 32,768 packets is reported upon.
细化值T选择序列号空间内的数据包子集：序列号为2^T倍数的数据包。数据包接收和丢失报告仅适用于这些数据包。T可以在0到15之间变化。如果T为零，则序列号空间中的每个数据包都被报告。如果T为15，则每32768个数据包中报告一个。
Suppose that the trace just described begins at sequence number 13,821. The last sequence number in the trace is 13,865. If the trace were to be thinned with a thinning value of T=2, then the following sequence numbers would be reported upon: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864. The thinned trace would be as follows:
假设刚才描述的跟踪从序列号13821开始。记录道中的最后一个序列号是13865。如果使用T=2的稀释值稀释记录道，则将报告以下序列号：13824、13828、13832、13836、13840、13844、13848、13852、13856、13860、13864。稀释痕迹如下所示：
1 1 1 1 1 0 1 1 1 1 0
1 1 1 1 1 0 1 1 1 1 0
This could be encoded as follows:
这可以按如下方式编码：
bit vector 1111 1011 1100 000 null chunk
位向量1111011100 000空块
The last four bits in the bit vector, representing sequence numbers 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are thus set to zero and are ignored by the receiver. With thinning, the loss of the 22nd packet goes unreported because its sequence number, 13,842, is not a multiple of four. Packet receipts for all sequence numbers that are not multiples of four also go unreported. However, in this example thinning has permitted the Loss RLE Report Block to be shortened by one 32 bit word.
位向量中的最后四位表示序列号13868、13872、13876和13880，扩展到跟踪之外，因此被设置为零，并被接收器忽略。通过细化，第22个数据包的丢失将不被报告，因为其序列号13842不是4的倍数。所有序列号（不是四的倍数）的数据包接收也将不被报告。然而，在此示例中，细化允许将丢失RLE报告块缩短一个32位字。
Choice of the thinning value is left to the application.
细化值的选择由应用程序决定。
The Loss RLE Report Block has the following format:
丢失RLE报告块具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=1 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=1 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits A Loss RLE Report Block is identified by the constant 1.
块类型（BT）：8位丢失RLE报告块由常量1标识。
rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
rsvd.：4位此字段保留供将来定义。在没有这种定义的情况下，此字段中的位必须设置为零，并且必须被接收器忽略。
thinning (T): 4 bits The amount of thinning performed on the sequence number space. Only those packets with sequence numbers 0 mod 2^T are reported on by this block. A value of 0 indicates that there is no thinning, and all packets are reported on. The maximum thinning is one packet in every 32,768 (amounting to two packets within each 16-bit sequence space).
细化（T）：4位序列号空间上执行的细化量。此块仅报告序列号为0 mod 2^T的数据包。值为0表示没有细化，并且所有数据包都会报告。最大细化是每32768中有一个分组（相当于每16位序列空间中有两个分组）。
block length: 16 bits Defined in Section 3.
块长度：第3节中定义的16位。
SSRC of source: 32 bits The SSRC of the RTP data packet source being reported upon by this report block.
源SSRC：32位此报告块报告的RTP数据包源的SSRC。
begin_seq: 16 bits The first sequence number that this block reports on.
begin_seq:16位此块报告的第一个序列号。
end_seq: 16 bits The last sequence number that this block reports on plus one.
end_seq:16位此块报告的最后一个序列号加1。
chunk i: 16 bits There are three chunk types: run length, bit vector, and terminating null, defined in the following sections. If the chunk is all zeroes, then it is a terminating null chunk. Otherwise, the left most bit of the chunk determines its type: 0 for run length and 1 for bit vector.
块i:16位有三种块类型：运行长度、位向量和终止null，在以下部分中定义。如果区块全为零，则它是一个终止的空区块。否则，块的最左边的位确定其类型：0表示游程长度，1表示位向量。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R| run length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R| run length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
chunk type (C): 1 bit A zero identifies this as a run length chunk.
块类型（C）：1位零将其标识为运行长度块。
run type (R): 1 bit Zero indicates a run of 0s. One indicates a run of 1s.
运行类型（R）：1位零表示0的运行。1表示运行1次。
run length: 14 bits A value between 1 and 16,383. The value MUST not be zero for a run length chunk (zeroes in both the run type and run length fields would make the chunk a terminating null chunk). Run lengths of 15 or less MAY be described with a run length chunk despite the fact that they could also be described as part of a bit vector chunk.
运行长度：14位—介于1和16383之间的值。运行长度块的值不得为零（运行类型和运行长度字段中的零将使该块成为终止的空块）。15或更少的运行长度可以用运行长度块来描述，尽管它们也可以被描述为位向量块的一部分。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| bit vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| bit vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
chunk type (C): 1 bit A one identifies this as a bit vector chunk.
块类型（C）：1位A 1将其标识为位向量块。
bit vector: 15 bits The vector is read from left to right, in order of increasing sequence number (with the appropriate allowance for wraparound).
位向量：15位向量从左到右读取，顺序为增加序列号（适当允许环绕）。
This chunk is all zeroes.
这个区块全是零。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This block type permits per-sequence-number reports on duplicates in a source's RTP packet stream. Such information can be used for network diagnosis, and provide an alternative to packet losses as a basis for multicast tree topology inference.
此块类型允许对源RTP数据包流中的重复项按序列号报告。这些信息可用于网络诊断，并提供分组丢失的替代方案，作为多播树拓扑推断的基础。
The Duplicate RLE Report Block format is identical to the Loss RLE Report Block format. Only the interpretation is different, in that the information concerns packet duplicates rather than packet losses. The trace to be encoded in this case also consists of zeros and ones, but a zero here indicates the presence of duplicate packets for a given sequence number, whereas a one indicates that no duplicates were received.
重复的RLE报告块格式与丢失的RLE报告块格式相同。只是解释不同，因为信息涉及数据包重复，而不是数据包丢失。在这种情况下，要编码的跟踪也由0和1组成，但此处的0表示给定序列号存在重复数据包，而1表示未收到重复数据包。
The existence of a duplicate for a given sequence number is determined over the entire reporting period. For example, if packet number 12,593 arrives, followed by other packets with other sequence numbers, the arrival later in the reporting period of another packet numbered 12,593 counts as a duplicate for that sequence number. The duplicate does not need to follow immediately upon the first packet of that number. Care must be taken that a report does not cover a range of 65,534 or greater in the sequence number space.
在整个报告期内，确定给定序列号是否存在重复项。例如，如果数据包编号12593到达，随后是具有其他序列号的其他数据包，则编号12593的另一个数据包在报告期间稍后的到达计数为该序列号的重复。副本不需要紧跟在该号码的第一个数据包之后。必须注意，报告在序列号空间中不包含65534或更大的范围。
No distinction is made between the existence of a single duplicate packet and multiple duplicate packets for a given sequence number. Note also that since there is no duplicate for a lost packet, a loss is encoded as a one in a Duplicate RLE Report Block.
对于给定序列号，单个重复数据包和多个重复数据包的存在没有区别。还请注意，由于丢失的数据包没有重复数据，因此在重复的RLE报告块中将丢失编码为一个。
The Duplicate RLE Report Block has the following format:
重复的RLE报告块具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=2 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=2 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits A Duplicate RLE Report Block is identified by the constant 2.
块类型（BT）：8位重复的RLE报告块由常量2标识。
rsvd.: 4 bits This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
rsvd.：4位此字段保留供将来定义。在没有这种定义的情况下，此字段中的位必须设置为零，并且必须被接收器忽略。
thinning (T): 4 bits As defined in Section 4.1.
减薄（T）：第4.1节中定义的4位。
block length: 16 bits Defined in Section 3.
块长度：第3节中定义的16位。
SSRC of source: 32 bits As defined in Section 4.1.
源的SSRC：第4.1节中定义的32位。
begin_seq: 16 bits As defined in Section 4.1.
开始顺序：第4.1节中定义的16位。
end_seq: 16 bits As defined in Section 4.1.
结束顺序：第4.1节中定义的16位。
chunk i: 16 bits As defined in Section 4.1.
块i：第4.1节中定义的16位。
This block type permits per-sequence-number reports on packet receipt times for a given source's RTP packet stream. Such information can be used for MINC inference of the topology of the multicast tree used to distribute the source's RTP packets, and of the delays along the links within that tree. It can also be used to measure partial path characteristics and to model distributions for packet jitter.
此块类型允许按序列号报告给定源的RTP数据包流的数据包接收时间。此类信息可用于对用于分发源RTP数据包的多播树的拓扑以及该树内链路的延迟进行MINC推断。它还可用于测量部分路径特性和为数据包抖动的分布建模。
Packet receipt times are expressed in the same units as in the RTP timestamps of data packets. This is so that, for each packet, one can establish both the send time and the receipt time in comparable terms. Note, however, that as an RTP sender ordinarily initializes its time to a value chosen at random, there can be no expectation that reported send and receipt times will differ by an amount equal to the one-way delay between sender and receiver. The reported times can nonetheless be useful for the purposes mentioned above.
数据包接收时间以与数据包的RTP时间戳相同的单位表示。这是为了，对于每个数据包，可以以可比较的方式确定发送时间和接收时间。但是，请注意，由于RTP发送方通常将其时间初始化为随机选择的值，因此不可能期望报告的发送和接收时间相差等于发送方和接收方之间的单向延迟。尽管如此，报告的时间对于上述目的还是有用的。
At least one packet MUST have been received for each sequence number reported upon in this block. If this block type is used to report receipt times for a series of sequence numbers that includes lost packets, several blocks are required. If duplicate packets have been received for a given sequence number, and those packets differ in their receipt times, any time other than the earliest MUST NOT be reported. This is to ensure consistency among reports.
对于此块中报告的每个序列号，必须至少接收到一个数据包。如果此块类型用于报告包含丢失数据包的一系列序列号的接收时间，则需要几个块。如果已收到给定序列号的重复数据包，且这些数据包的接收时间不同，则不得报告最早时间以外的任何时间。这是为了确保报告之间的一致性。
Times reported in RTP timestamp format consume more bits than loss or duplicate information, and do not lend themselves to run length encoding. The use of thinning is encouraged to limit the size of Packet Receipt Times Report Blocks.
以RTP时间戳格式报告的时间消耗的比特数比丢失或重复的信息多，并且不适合运行长度编码。鼓励使用细化来限制数据包接收时间报告块的大小。
The Packet Receipt Times Report Block has the following format:
数据包接收时间报告块的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=3 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet (begin_seq + 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet (end_seq - 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=3 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet (begin_seq + 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet (end_seq - 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits A Packet Receipt Times Report Block is identified by the constant 3.
块类型（BT）：8位数据包接收时间报告块由常量3标识。
rsvd.: 4 bits This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
rsvd.：4位此字段保留供将来定义。在没有这种定义的情况下，此字段中的位必须设置为零，并且必须被接收器忽略。
thinning (T): 4 bits As defined in Section 4.1.
减薄（T）：第4.1节中定义的4位。
block length: 16 bits Defined in Section 3.
块长度：第3节中定义的16位。
SSRC of source: 32 bits As defined in Section 4.1.
源的SSRC：第4.1节中定义的32位。
begin_seq: 16 bits As defined in Section 4.1.
开始顺序：第4.1节中定义的16位。
end_seq: 16 bits As defined in Section 4.1.
结束顺序：第4.1节中定义的16位。
Packet i receipt time: 32 bits The receipt time of the packet with sequence number i at the receiver. The modular arithmetic shown in the packet format diagram is to allow for sequence number rollover. It is preferable for the time value to be established at the link layer interface, or in any case as close as possible to the wire arrival time. Units and format are the same as for the timestamp in RTP data packets. As opposed to RTP data packet timestamps, in which nominal values may be used instead of system clock values in order to convey information useful for periodic playout, the receipt times should reflect the actual time as closely as possible. For a session, if the RTP timestamp is chosen at random, the first receipt time value SHOULD also be chosen at random, and subsequent timestamps offset from this value. On the other hand, if the RTP timestamp is meant to reflect the reference time at the sender, then the receipt time SHOULD be as close as possible to the reference time at the receiver.
数据包i接收时间：32位为接收端序列号为i的数据包的接收时间。数据包格式图中显示的模块化算法允许序列号滚动。优选在链路层接口处建立时间值，或在任何情况下尽可能接近导线到达时间。单位和格式与RTP数据包中的时间戳相同。与RTP数据包时间戳相反，在RTP数据包时间戳中，可以使用标称值而不是系统时钟值来传递对定期播放有用的信息，接收时间应尽可能地反映实际时间。对于会话，如果随机选择RTP时间戳，则还应随机选择第一个接收时间值，随后的时间戳将从该值偏移。另一方面，如果RTP时间戳旨在反映发送方的参考时间，则接收时间应尽可能接近接收方的参考时间。
This block extends RTCP's timestamp reporting so that non-senders may also send timestamps. It recapitulates the NTP timestamp fields from the RTCP Sender Report [9, Sec. 6.3.1]. A non-sender may estimate its round trip time (RTT) to other participants, as proposed in [18], by sending this report block and receiving DLRR Report Blocks (see next section) in reply.
此块扩展RTCP的时间戳报告，以便非发送方也可以发送时间戳。它概括了RTCP发送方报告中的NTP时间戳字段[9，第6.3.1节]。如[18]所述，非发送方可通过发送此报告块并接收DLRR报告块（见下一节）作为回复，来估计其到其他参与者的往返时间（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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=4 | reserved | block length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=4 | reserved | block length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits A Receiver Reference Time Report Block is identified by the constant 4.
块类型（BT）：8位接收器参考时间报告块由常数4标识。
reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
保留：8位此字段保留供将来定义。在没有这种定义的情况下，此字段中的位必须设置为零，并且必须被接收器忽略。
block length: 16 bits The constant 2, in accordance with the definition of this field in Section 3.
块长度：16位为常数2，符合第3节中该字段的定义。
NTP timestamp: 64 bits Indicates the wallclock time when this block was sent so that it may be used in combination with timestamps returned in DLRR Report Blocks (see next section) from other receivers to measure round-trip propagation to those receivers. Receivers should expect that the measurement accuracy of the timestamp may be limited to far less than the resolution of the NTP timestamp. The measurement uncertainty of the timestamp is not indicated as it may not be known. A report block sender that can keep track of elapsed time but has no notion of wallclock time may use the elapsed time since joining the session instead. This is assumed to be less than 68 years, so the high bit will be zero. It is permissible to use the sampling clock to estimate elapsed wallclock time. A report sender that has no notion of wallclock or elapsed time may set the NTP timestamp to zero.
NTP timestamp：64位表示发送此块时的墙时钟时间，因此它可以与从其他接收器返回的DLRR报告块（见下一节）中的时间戳结合使用，以测量到这些接收器的往返传播。接收机应期望时间戳的测量精度可被限制为远小于NTP时间戳的分辨率。时间戳的测量不确定度未显示，因为它可能未知。报告块发送方可以跟踪经过的时间，但不知道wallclock时间，可以使用加入会话后经过的时间。假设这小于68年，因此高位为零。允许使用采样时钟来估计经过的时钟时间。没有挂钟或已用时间概念的报告发送方可以将NTP时间戳设置为零。
This block extends RTCP's delay since the last Sender Report (DLSR) mechanism [9, Sec. 6.3.1] so that non-senders may also calculate round trip times, as proposed in [18]. It is termed DLRR for delay since the last Receiver Report, and may be sent in response to a Receiver Timestamp Report Block (see previous section) from a receiver to allow that receiver to calculate its round trip time to the respondent. The report consists of one or more 3 word sub-blocks: one sub-block per Receiver Report.
此块扩展了自上次发送方报告（DLSR）机制[9，第6.3.1节]以来RTCP的延迟，以便非发送方也可以按照[18]中的建议计算往返时间。它被称为DLRR，表示自上次接收器报告以来的延迟，并且可以响应接收器时间戳报告块（参见上一节）而从接收器发送，以允许该接收器计算其到响应者的往返时间。报告由一个或多个3字子块组成：每个接收器报告一个子块。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=5 | reserved | block length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| last RR (LRR) | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last RR (DLRR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=5 | reserved | block length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| last RR (LRR) | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last RR (DLRR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
block type (BT): 8 bits A DLRR Report Block is identified by the constant 5.
块类型（BT）：8位DLRR报告块由常量5标识。
reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
保留：8位此字段保留供将来定义。在没有这种定义的情况下，此字段中的位必须设置为零，并且必须被接收器忽略。
block length: 16 bits Defined in Section 3.
块长度：第3节中定义的16位。
last RR timestamp (LRR): 32 bits The middle 32 bits out of 64 in the NTP timestamp (as explained in the previous section), received as part of a Receiver Reference Time Report Block from participant SSRC_n. If no such block has been received, the field is set to zero.
最后RR时间戳（LRR）：32位NTP时间戳中64位中的中间32位（如前一节所述），作为来自参与者SSRC\n的接收器参考时间报告块的一部分接收。如果未收到此类块，则该字段设置为零。
delay since last RR (DLRR): 32 bits The delay, expressed in units of 1/65536 seconds, between receiving the last Receiver Reference Time Report Block from participant SSRC_n and sending this DLRR Report Block. If a Receiver Reference Time Report Block has yet to be received from SSRC_n, the DLRR field is set to zero (or the DLRR is omitted entirely). Let SSRC_r denote the receiver issuing this DLRR Report Block. Participant SSRC_n can compute the round-trip propagation delay to SSRC_r by recording the time A when this Receiver Timestamp Report Block is received. It calculates the total round-trip time A-LRR using the last RR timestamp (LRR) field, and then subtracting this field to leave the round-trip propagation delay as A-LRR-DLRR. This is illustrated in [9, Fig. 2].
自上次RR以来的延迟（DLRR）：32位从参与者SSRC接收上次接收器参考时间报告块到发送此DLRR报告块之间的延迟，以1/65536秒为单位。如果尚未从SSRC\n接收到接收器参考时间报告块，则DLRR字段设置为零（或完全忽略DLRR）。让SSRC_r表示发出此DLRR报告块的接收方。参与者SSRC\n可以通过记录接收此接收器时间戳报告块时的时间A来计算到SSRC\r的往返传播延迟。它使用最后一个RR时间戳（LRR）字段计算总往返时间A-LRR，然后减去该字段，将往返传播延迟保留为A-LRR-DLRR。[9，图2]对此进行了说明。
This block reports statistics beyond the information carried in the standard RTCP packet format, but is not as finely grained as that carried in the report blocks previously described. Information is recorded about lost packets, duplicate packets, jitter measurements, and TTL or Hop Limit values. Such information can be useful for network management.
此块报告的统计信息超出了标准RTCP数据包格式中包含的信息，但其粒度不如前面描述的报告块中包含的细粒度。记录有关丢失数据包、重复数据包、抖动测量以及TTL或跃点限制值的信息。这些信息可用于网络管理。
The report block contents are dependent upon a series of flag bits carried in the first part of the header. Not all parameters need to be reported in each block. Flags indicate which are and which are not reported. The fields corresponding to unreported parameters MUST be present, but are set to zero. The receiver MUST ignore any Statistics Summary Report Block with a non-zero value in any field flagged as unreported.
报告块内容取决于报头第一部分中携带的一系列标志位。并非每个块中都需要报告所有参数。标志指示哪些是报告的，哪些不是报告的。与未报告参数对应的字段必须存在，但设置为零。接收方必须忽略任何标记为未报告的字段中具有非零值的统计摘要报告块。
The Statistics Summary Report Block has the following format:
“统计信息摘要”报告块的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=6 |L|D|J|ToH|rsvd.| block length = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lost_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dup_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mean_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dev_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_ttl_or_hl | max_ttl_or_hl |mean_ttl_or_hl | dev_ttl_or_hl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=6 |L|D|J|ToH|rsvd.| block length = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lost_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dup_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mean_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dev_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_ttl_or_hl | max_ttl_or_hl |mean_ttl_or_hl | dev_ttl_or_hl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits A Statistics Summary Report Block is identified by the constant 6.
块类型（BT）：8位统计摘要报告块由常量6标识。
loss report flag (L): 1 bit Bit set to 1 if the lost_packets field contains a report, 0 otherwise.
丢失报告标志（L）：如果丢失的数据包字段包含报告，则1位设置为1，否则为0。
duplicate report flag (D): 1 bit Bit set to 1 if the dup_packets field contains a report, 0 otherwise.
重复报告标志（D）：如果dup_数据包字段包含报告，则1位设置为1，否则为0。
jitter flag (J): 1 bit Bit set to 1 if the min_jitter, max_jitter, mean_jitter, and dev_jitter fields all contain reports, 0 if none of them do.
抖动标志（J）：如果最小抖动、最大抖动、平均抖动和偏差抖动字段都包含报告，则将1位设置为1，如果没有报告，则设置为0。
TTL or Hop Limit flag (ToH): 2 bits This field is set to 0 if none of the fields min_ttl_or_hl, max_ttl_or_hl, mean_ttl_or_hl, or dev_ttl_or_hl contain reports. If the field is non-zero, then all of these fields contain reports. The value 1 signifies that they report on IPv4 TTL values. The value 2 signifies that they report on
TTL或跃点限制标志（ToH）：如果min_TTL_或_hl、max_TTL_或_hl、mean_TTL_或_hl或dev_TTL_或_hl字段均不包含报告，则此字段设置为0。如果字段非零，则所有这些字段都包含报告。值1表示它们报告IPv4 TTL值。值2表示它们报告的时间
IPv6 Hop Limit values. The value 3 is undefined and MUST NOT be used.
IPv6跃点限制值。值3未定义，不得使用。
rsvd.: 3 bits This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
rsvd.：3位此字段保留供将来定义。在没有这种定义的情况下，此字段中的位必须设置为零，并且必须被接收器忽略。
block length: 16 bits The constant 9, in accordance with the definition of this field in Section 3.
块长度：16位常量9，符合第3节中该字段的定义。
SSRC of source: 32 bits As defined in Section 4.1.
源的SSRC：第4.1节中定义的32位。
begin_seq: 16 bits As defined in Section 4.1.
开始顺序：第4.1节中定义的16位。
end_seq: 16 bits As defined in Section 4.1.
结束顺序：第4.1节中定义的16位。
lost_packets: 32 bits Number of lost packets in the above sequence number interval.
丢失的_数据包：在上述序列号间隔内丢失的数据包的32位数。
dup_packets: 32 bits Number of duplicate packets in the above sequence number interval.
dup_数据包：上述序列号间隔内的32位重复数据包数。
min_jitter: 32 bits The minimum relative transit time between two packets in the above sequence number interval. All jitter values are measured as the difference between a packet's RTP timestamp and the reporter's clock at the time of arrival, measured in the same units.
min_jitter:32位是上述序列号间隔内两个数据包之间的最小相对传输时间。所有抖动值都是以数据包的RTP时间戳和报告者到达时的时钟之间的差值来测量的，测量单位相同。
max_jitter: 32 bits The maximum relative transit time between two packets in the above sequence number interval.
max_jitter:32位以上序列号间隔内两个数据包之间的最大相对传输时间。
mean_jitter: 32 bits The mean relative transit time between each two packet series in the above sequence number interval, rounded to the nearest value expressible as an RTP timestamp.
mean_jitter:32位——上述序列号间隔内每两个数据包系列之间的平均相对传输时间，四舍五入到最接近的值，表示为RTP时间戳。
dev_jitter: 32 bits The standard deviation of the relative transit time between each two packet series in the above sequence number interval.
dev_jitter:32位是上述序列号间隔内每两个数据包系列之间相对传输时间的标准偏差。
min_ttl_or_hl: 8 bits The minimum TTL or Hop Limit value of data packets in the sequence number range.
min_ttl_或_hl:8位序列号范围内数据包的最小ttl或跃点限制值。
max_ttl_or_hl: 8 bits The maximum TTL or Hop Limit value of data packets in the sequence number range.
max_ttl_或_hl:8位序列号范围内数据包的最大ttl或跃点限制值。
mean_ttl_or_hl: 8 bits The mean TTL or Hop Limit value of data packets in the sequence number range, rounded to the nearest integer.
mean_ttl_或_hl:8位序列号范围内数据包的平均ttl或跃点限制值，四舍五入到最接近的整数。
dev_ttl_or_hl: 8 bits The standard deviation of TTL or Hop Limit values of data packets in the sequence number range.
dev_ttl_或_hl:8位序列号范围内数据包的ttl或跃点限制值的标准偏差。
The VoIP Metrics Report Block provides metrics for monitoring voice over IP (VoIP) calls. These metrics include packet loss and discard metrics, delay metrics, analog metrics, and voice quality metrics. The block reports separately on packets lost on the IP channel, and those that have been received but then discarded by the receiving jitter buffer. It also reports on the combined effect of losses and discards, as both have equal effect on call quality.
VoIP度量报告块提供用于监视IP语音（VoIP）呼叫的度量。这些度量包括数据包丢失和丢弃度量、延迟度量、模拟度量和语音质量度量。该块分别报告IP通道上丢失的数据包，以及已接收但随后被接收抖动缓冲区丢弃的数据包。它还报告了损失和丢弃的综合影响，因为两者对通话质量的影响相同。
In order to properly assess the quality of a Voice over IP call, it is desirable to consider the degree of burstiness of packet loss [14]. Following a Gilbert-Elliott model [3], a period of time, bounded by lost and/or discarded packets with a high rate of losses and/or discards, is a "burst", and a period of time between two bursts is a "gap". Bursts correspond to periods of time during which the packet loss rate is high enough to produce noticeable degradation in audio quality. Gaps correspond to periods of time during which only isolated lost packets may occur, and in general these can be masked by packet loss concealment. Delay reports include the transit delay between RTP end points and the VoIP end system processing delays, both of which contribute to the user perceived delay. Additional metrics include signal, echo, noise, and distortion levels. Call quality metrics include R factors (as described by the E Model defined in [6,3]) and mean opinion scores (MOS scores).
为了正确地评估语音IP呼叫的质量，需要考虑分组丢失的突发程度[14 ]。根据Gilbert-Elliott模型[3]，以丢失和/或丢弃数据包为界且丢失和/或丢弃率较高的一段时间为“突发”，两次突发之间的一段时间为“间隙”。突发对应于数据包丢失率高到足以导致音频质量明显下降的时间段。间隔对应于仅可能发生孤立丢失数据包的时间段，并且通常可以通过数据包丢失隐藏来掩盖这些时间段。延迟报告包括RTP端点之间的传输延迟和VoIP终端系统处理延迟，这两者都会导致用户感知的延迟。其他指标包括信号、回波、噪声和失真水平。通话质量指标包括R因子（如[6,3]中定义的E模型所述）和平均意见分数（MOS分数）。
Implementations MUST provide values for all the fields defined here. For certain metrics, if the value is undefined or unknown, then the specified default or unknown field value MUST be provided.
实现必须为此处定义的所有字段提供值。对于某些度量，如果值未定义或未知，则必须提供指定的默认值或未知字段值。
The block is encoded as seven 32-bit words:
该块编码为七个32位字：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=7 | reserved | block length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| loss rate | discard rate | burst density | gap density |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burst duration | gap duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| round trip delay | end system delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signal level | noise level | RERL | Gmin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R factor | ext. R factor | MOS-LQ | MOS-CQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RX config | reserved | JB nominal |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JB maximum | JB abs max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=7 | reserved | block length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| loss rate | discard rate | burst density | gap density |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burst duration | gap duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| round trip delay | end system delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signal level | noise level | RERL | Gmin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R factor | ext. R factor | MOS-LQ | MOS-CQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RX config | reserved | JB nominal |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JB maximum | JB abs max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits A VoIP Metrics Report Block is identified by the constant 7.
块类型（BT）：8位VoIP度量报告块由常量7标识。
reserved: 8 bits This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
保留：8位此字段保留供将来定义。在没有这种定义的情况下，此字段中的位必须设置为零，并且必须被接收器忽略。
block length: 16 bits The constant 8, in accordance with the definition of this field in Section 3.
块长度：16位常量8，符合第3节中该字段的定义。
SSRC of source: 32 bits As defined in Section 4.1.
源的SSRC：第4.1节中定义的32位。
The remaining fields are described in the following six sections: Packet Loss and Discard Metrics, Delay Metrics, Signal Related Metrics, Call Quality or Transmission Quality Metrics, Configuration Metrics, and Jitter Buffer Parameters.
其余字段在以下六个部分中描述：分组丢失和丢弃度量、延迟度量、信号相关度量、呼叫质量或传输质量度量、配置度量和抖动缓冲区参数。
It is very useful to distinguish between packets lost by the network and those discarded due to jitter. Both have equal effect on the quality of the voice stream, however, having separate counts helps identify the source of quality degradation. These fields MUST be populated, and MUST be set to zero if no packets have been received.
区分网络丢失的数据包和由于抖动而丢弃的数据包非常有用。两者对语音流的质量具有相同的影响，但是，具有单独的计数有助于识别质量下降的来源。必须填充这些字段，如果没有收到数据包，则必须将其设置为零。
loss rate: 8 bits The fraction of RTP data packets from the source lost since the beginning of reception, expressed as a fixed point number with the binary point at the left edge of the field. This value is calculated by dividing the total number of packets lost (after the effects of applying any error protection such as FEC) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. The numbers of duplicated packets and discarded packets do not enter into this calculation. Since receivers cannot be required to maintain unlimited buffers, a receiver MAY categorize late-arriving packets as lost. The degree of lateness that triggers a loss SHOULD be significantly greater than that which triggers a discard.
丢失率：8位自接收开始以来源RTP数据包丢失的部分，表示为固定点数，二进制点位于字段左边缘。通过将丢失的数据包总数（在应用任何错误保护（如FEC）后）除以预期的数据包总数，将除法结果乘以256，将最大值限制为255（以避免溢出），并取整数部分来计算此值。重复数据包和丢弃数据包的数量不计入此计算。由于接收器不能被要求维持无限的缓冲区，接收器可以将延迟到达的数据包分类为丢失。导致损失的迟到程度应明显大于导致放弃的迟到程度。
discard rate: 8 bits The fraction of RTP data packets from the source that have been discarded since the beginning of reception, due to late or early arrival, under-run or overflow at the receiving jitter buffer. This value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets discarded (excluding duplicate packet discards) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part.
丢弃率：8位源RTP数据包中自接收开始以来由于延迟或提前到达、在接收抖动缓冲区运行不足或溢出而被丢弃的部分。该值表示为固定点数，二进制点位于字段的左边缘。通过将丢弃的数据包总数（不包括重复的数据包丢弃）除以预期的数据包总数，将除法结果乘以256，将最大值限制为255（以避免溢出），并取整数部分来计算。
A burst is a period during which a high proportion of packets are either lost or discarded due to late arrival. A burst is defined, in terms of a value Gmin, as the longest sequence that (a) starts with a lost or discarded packet, (b) does not contain any occurrences of Gmin or more consecutively received (and not discarded) packets, and (c) ends with a lost or discarded packet.
突发是指由于延迟到达而丢失或丢弃大部分数据包的时间段。根据值Gmin，突发被定义为（A）以丢失或丢弃的数据包开始，（b）不包含Gmin或更多连续接收（且未丢弃）的数据包的任何出现，以及（c）以丢失或丢弃的数据包结束的最长序列。
A gap, informally, is a period of low packet losses and/or discards. Formally, a gap is defined as any of the following: (a) the period from the start of an RTP session to the receipt time of the last
非正式地说，间隙是低数据包丢失和/或丢弃的时期。从形式上讲，间隙定义为以下任何一项：（a）从RTP会话开始到最后一个会话的接收时间之间的时间段
received packet before the first burst, (b) the period from the end of the last burst to either the time of the report or the end of the RTP session, whichever comes first, or (c) the period of time between two bursts.
在第一次突发之前收到的数据包，（b）从最后一次突发结束到报告时间或RTP会话结束的时间段，以先到者为准，或（c）两次突发之间的时间段。
For the purpose of determining if a lost or discarded packet near the start or end of an RTP session is within a gap or a burst, it is assumed that the RTP session is preceded and followed by at least Gmin received packets, and that the time of the report is followed by at least Gmin received packets.
为了确定在RTP会话的开始或结束附近丢失或丢弃的分组是否在间隙或突发内，假设RTP会话之前和之后是至少Gmin接收分组，并且报告时间之后是至少Gmin接收分组。
A gap has the property that any lost or discarded packets within the gap must be preceded and followed by at least Gmin packets that were received and not discarded. This gives a maximum loss/discard rate within a gap of: 1 / (Gmin + 1).
gap具有这样一个属性：gap中任何丢失或丢弃的数据包必须至少在Gmin数据包之前和之后，且Gmin数据包已被接收且未被丢弃。这将在1/（Gmin+1）的间隙内提供最大损失/丢弃率。
A Gmin value of 16 is RECOMMENDED, as it results in gap characteristics that correspond to good quality (i.e., low packet loss rate, a minimum distance of 16 received packets between lost packets), and hence differentiates nicely between good and poor quality periods.
建议将Gmin值设为16，因为它会产生与良好质量相对应的间隙特性（即，低分组丢失率，丢失分组之间的最小距离为16个接收分组），因此可以很好地区分良好和较差的质量周期。
For example, a 1 denotes a received packet, 0 a lost packet, and X a discarded packet in the following pattern covering 64 packets:
例如，1表示接收到的分组，0表示丢失的分组，X表示丢弃的分组，模式如下，覆盖64个分组：
11110111111111111111111X111X1011110111111111111111111X111111111
|---------gap----------|--burst---|------------gap------------|
11110111111111111111111X111X1011110111111111111111111X111111111
|---------gap----------|--burst---|------------gap------------|
The burst consists of the twelve packets indicated above, starting at a discarded packet and ending at a lost packet. The first gap starts at the beginning of the session and the second gap ends at the time of the report.
突发由上述12个数据包组成，从丢弃的数据包开始，到丢失的数据包结束。第一个间隙在会议开始时开始，第二个间隙在报告时结束。
If the packet spacing is 10 ms and the Gmin value is the recommended value of 16, the burst duration is 120 ms, the burst density 0.33, the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04.
如果分组间隔为10ms且Gmin值为推荐值16，则突发持续时间为120ms，突发密度为0.33，间隔持续时间为230ms+290ms=520ms，并且间隔密度为0.04。
This would result in reported values as follows (see field descriptions for semantics and details on how these are calculated):
这将导致报告值如下（有关语义和如何计算这些值的详细信息，请参阅字段描述）：
loss rate 12, which corresponds to 5% discard rate 12, which corresponds to 5% burst density 84, which corresponds to 33% gap density 10, which corresponds to 4% burst duration 120, value in milliseconds gap duration 520, value in milliseconds
丢失率12，对应于5%丢弃率12，对应于5%突发密度84，对应于33%间隙密度10，对应于4%突发持续时间120，以毫秒为单位的值间隙持续时间520，以毫秒为单位的值
burst density: 8 bits The fraction of RTP data packets within burst periods since the beginning of reception that were either lost or discarded. This value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within burst periods by the total number of packets expected within the burst periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. This field MUST be populated and MUST be set to zero if no packets have been received.
突发密度：8位自接收开始以来突发周期内RTP数据包丢失或丢弃的部分。该值表示为固定点数，二进制点位于字段的左边缘。将突发周期内丢失或丢弃的数据包总数（不包括重复的数据包丢弃）除以突发周期内预期的数据包总数，将除法结果乘以256，将最大值限制为255（以避免溢出），并取整数部分。必须填充此字段，如果未收到任何数据包，则必须将其设置为零。
gap density: 8 bits The fraction of RTP data packets within inter-burst gaps since the beginning of reception that were either lost or discarded. The value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within gap periods by the total number of packets expected within the gap periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. This field MUST be populated and MUST be set to zero if no packets have been received.
间隙密度：8位自接收开始以来，突发间隔内RTP数据包丢失或丢弃的部分。该值表示为固定点数，二进制点位于字段的左边缘。它的计算方法是将间隔期间内丢失或丢弃的数据包总数（不包括重复的数据包丢弃）除以间隔期间内预期的数据包总数，将除法结果乘以256，将最大值限制为255（以避免溢出），并取整数部分。必须填充此字段，如果未收到任何数据包，则必须将其设置为零。
burst duration: 16 bits The mean duration, expressed in milliseconds, of the burst periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packets that mark the beginning and end of that period. It is equal to the timestamp of the end packet, plus the duration of the end packet, minus the timestamp of the beginning packet. If the actual values are not available, estimated values MUST be used. If there have been no burst periods, the burst duration value MUST be zero.
突发持续时间：16位自接收开始以来发生的突发周期的平均持续时间，以毫秒为单位。每个时段的持续时间根据标记该时段开始和结束的数据包计算。它等于结束数据包的时间戳，加上结束数据包的持续时间，减去开始数据包的时间戳。如果实际值不可用，则必须使用估计值。如果没有突发周期，则突发持续时间值必须为零。
gap duration: 16 bits The mean duration, expressed in milliseconds, of the gap periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packet that marks the end of the prior burst and the packet that marks the beginning of the subsequent burst. It is equal to the timestamp of the subsequent burst packet, minus the timestamp of the prior burst packet, plus the duration of the prior burst packet. If the actual values are not available, estimated values MUST be used. In the case of a gap that occurs at the beginning of reception, the sum of the timestamp of the prior
间隙持续时间：16位自接收开始以来发生的间隙周期的平均持续时间，以毫秒为单位。每个时段的持续时间基于标记先前突发结束的分组和标记后续突发开始的分组来计算。它等于后续突发数据包的时间戳减去先前突发数据包的时间戳，再加上先前突发数据包的持续时间。如果实际值不可用，则必须使用估计值。在接收开始时出现间隔的情况下，前一个间隔的时间戳之和
burst packet and the duration of the prior burst packet are replaced by the reception start time. In the case of a gap that occurs at the end of reception, the timestamp of the subsequent burst packet is replaced by the reception end time. If there have been no gap periods, the gap duration value MUST be zero.
突发分组和先前突发分组的持续时间被接收开始时间替换。在接收结束时出现间隙的情况下，后续突发分组的时间戳被接收结束时间替换。如果没有间隙周期，间隙持续时间值必须为零。
For the purpose of the following definitions, the RTP interface is the interface between the RTP instance and the voice application (i.e., FEC, de-interleaving, de-multiplexing, jitter buffer). For example, the time delay due to RTP payload multiplexing would be considered part of the voice application or end-system delay, whereas delay due to multiplexing RTP frames within a UDP frame would be considered part of the RTP reported delay. This distinction is consistent with the use of RTCP for delay measurements.
出于以下定义的目的，RTP接口是RTP实例和语音应用程序（即FEC、解交织、解复用、抖动缓冲）之间的接口。例如，由于RTP有效负载多路复用而产生的时间延迟将被视为语音应用程序或终端系统延迟的一部分，而由于在UDP帧内多路复用RTP帧而产生的延迟将被视为RTP报告延迟的一部分。这种区别与使用RTCP进行延迟测量是一致的。
round trip delay: 16 bits The most recently calculated round trip time between RTP interfaces, expressed in milliseconds. This value MAY be measured using RTCP, the DLRR method defined in Section 4.5 of this document, where it is necessary to convert the units of measurement from NTP timestamp values to milliseconds, or other approaches. If RTCP is used, then the reported delay value is the time of receipt of the most recent RTCP packet from source SSRC, minus the LSR (last SR) time reported in its SR (Sender Report), minus the DLSR (delay since last SR) reported in its SR. A non-zero LSR value is required in order to calculate round trip delay. A value of 0 is permissible; however, this field MUST be populated as soon as a delay estimate is available.
往返延迟：16位RTP接口之间最近计算的往返时间，以毫秒表示。可使用RTCP（本文件第4.5节中定义的DLRR方法）测量该值，其中有必要将测量单位从NTP时间戳值转换为毫秒，或采用其他方法。如果使用RTCP，则报告的延迟值是从源SSRC接收最新RTCP数据包的时间，减去其SR（发送方报告）中报告的LSR（上次SR）时间，减去其SR中报告的DLSR（自上次SR以来的延迟）。计算往返延迟需要非零LSR值。允许值为0；但是，一旦延迟估计可用，必须立即填充此字段。
end system delay: 16 bits The most recently estimated end system delay, expressed in milliseconds. End system delay is defined as the sum of the total sample accumulation and encoding delay associated with the sending direction and the jitter buffer, decoding, and playout buffer delay associated with the receiving direction. This delay MAY be estimated or measured. This value SHOULD be provided in all VoIP metrics reports. If an implementation is unable to provide the data, the value 0 MUST be used.
终端系统延迟：16位最新估计的终端系统延迟，以毫秒为单位。终端系统延迟定义为与发送方向相关联的总样本累积和编码延迟以及与接收方向相关联的抖动缓冲器、解码和播放缓冲器延迟之和。可以估计或测量该延迟。应在所有VoIP度量报告中提供此值。如果实现无法提供数据，则必须使用值0。
Note that the one way symmetric VoIP segment delay may be calculated from the round trip and end system delays is as follows; if the round trip delay is denoted, RTD and the end system delays associated with the two endpoints are ESD(A) and ESD(B) then:
注意，单向对称VoIP段延迟可根据往返和终端系统延迟计算，如下所示：；如果表示往返延迟，RTD和与两个端点相关的终端系统延迟为ESD（A）和ESD（B），则：
one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2
one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2
The following metrics are intended to provide real time information related to the non-packet elements of the voice over IP system to assist with the identification of problems affecting call quality. The values identified below must be determined for the received audio signal. The information required to populate these fields may not be available in all systems, although it is strongly recommended that this data SHOULD be provided to support problem diagnosis.
以下指标旨在提供与IP语音系统的非分组元素相关的实时信息，以帮助识别影响呼叫质量的问题。必须为接收到的音频信号确定以下确定的值。填充这些字段所需的信息可能并非在所有系统中都可用，但强烈建议提供这些数据以支持问题诊断。
signal level: 8 bits The voice signal relative level is defined as the ratio of the signal level to a 0 dBm0 reference [10], expressed in decibels as a signed integer in two's complement form. This is measured only for packets containing speech energy. The intent of this metric is not to provide a precise measurement of the signal level but to provide a real time indication that the signal level may be excessively high or low.
信号电平：8位语音信号相对电平定义为信号电平与0 dBm0参考值的比率[10]，以分贝表示为2的补码形式的有符号整数。这仅针对包含语音能量的数据包进行测量。该指标的目的不是提供信号电平的精确测量，而是提供信号电平可能过高或过低的实时指示。
signal level = 10 Log10 ( rms talkspurt power (mW) )
信号电平=10 Log10（均方根输出功率（mW））
A value of 127 indicates that this parameter is unavailable. Typical values should generally be in the -15 to -20 dBm range.
值127表示此参数不可用。典型值通常应在-15至-20 dBm范围内。
noise level: 8 bits The noise level is defined as the ratio of the silent period background noise level to a 0 dBm0 reference, expressed in decibels as a signed integer in two's complement form.
噪声级：8位噪声级定义为静默期背景噪声级与0 dBm0参考的比率，以分贝表示为2的补码形式的有符号整数。
noise level = 10 Log10 ( rms silence power (mW) )
噪声级=10 Log10（均方根静音功率（mW））
A value of 127 indicates that this parameter is unavailable.
值127表示此参数不可用。
residual echo return loss (RERL): 8 bits The residual echo return loss value may be measured directly by the VoIP end system's echo canceller or may be estimated by adding the echo return loss (ERL) and echo return loss enhancement (ERLE) values reported by the echo canceller.
剩余回波回波损耗（RERL）：8位剩余回波回波损耗值可由VoIP终端系统的回波消除器直接测量，或可通过添加回波消除器报告的回波回波损耗（ERL）和回波回波回波损耗增强（ERLE）值来估计。
RERL(dB) = ERL (dB) + ERLE (dB)
RERL(dB) = ERL (dB) + ERLE (dB)
In the case of a VoIP gateway, the source of echo is typically line echo that occurs at 2-4 wire conversion points in the network. This can be in the 8-12 dB range. A line echo canceler can provide an ERLE of 30 dB or more and hence reduce this to 40-50 dB. In the case of an IP phone, this could be acoustic coupling between handset speaker and microphone or residual acoustic echo from speakerphone operation, and may more correctly be termed terminal coupling loss (TCL). A typical handset would result in 40-50 dB of echo loss due to acoustic feedback.
在VoIP网关的情况下，回波源通常是网络中2-4线转换点处发生的线路回波。这可能在8-12 dB范围内。线路回波消除器可以提供30 dB或更高的ERLE，从而将其降低到40-50 dB。在IP电话的情况下，这可能是手机扬声器和麦克风之间的声耦合或扬声器操作产生的残余声回波，更准确地说，这可能被称为终端耦合损耗（TCL）。一个典型的手机会由于声音反馈而导致40-50分贝的回波损失。
Examples:
示例：
- IP gateway connected to circuit switched network with 2 wire loop. Without echo cancellation, typical 2-4 wire converter ERL of 12 dB. RERL = ERL + ERLE = 12 + 0 = 12 dB.
- IP网关通过2线环路连接到电路交换网络。没有回声消除，典型的2-4线转换器ERL为12 dB。RERL=ERL+ERLE=12+0=12 dB。
- IP gateway connected to circuit switched network with 2 wire loop. With echo canceler that improves echo by 30 dB. RERL = ERL + ERLE = 12 + 30 = 42 dB.
- IP网关通过2线环路连接到电路交换网络。带有回波抵消器，可将回波提高30 dB。RERL=ERL+ERLE=12+30=42 dB。
- IP phone with conventional handset. Acoustic coupling from handset speaker to microphone (terminal coupling loss) is typically 40 dB. RERL = TCL = 40 dB.
- IP电话与传统手机。从手机扬声器到麦克风的声耦合（终端耦合损耗）通常为40 dB。RERL=TCL=40 dB。
If we denote the local end of the VoIP path as A and the remote end as B, and if the sender loudness rating (SLR) and receiver loudness rating (RLR) are known for A (default values 8 dB and 2 dB respectively), then the echo loudness level at end A (talker echo loudness rating or TELR) is given by:
如果我们将VoIP路径的本地端表示为A，远程端表示为B，并且如果已知A的发送方响度等级（SLR）和接收方响度等级（RLR）（默认值分别为8 dB和2 dB），则A端的回声响度等级（说话人回声响度等级或TELR）由下式给出：
TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)
TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)
TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)
TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)
Hence, in order to incorporate echo into a voice quality estimate at the A end of a VoIP connection, it is desirable to send the ERL + ERLE value from B to A using a format such as RTCP XR.
因此，为了在VoIP连接的a端将echo合并到语音质量估计中，希望使用诸如RTCP XR的格式将ERL+ERLE值从B发送到a。
Echo related information may not be available in all VoIP end systems. As echo does have a significant effect on conversational quality, it is recommended that estimated values for echo return loss and terminal coupling loss be provided (if sensible estimates can be reasonably determined).
可能并非所有VoIP终端系统都提供与回声相关的信息。由于回波对会话质量有显著影响，建议提供回波回波损耗和终端耦合损耗的估计值（如果可以合理确定合理的估计值）。
Typical values for end systems are given below to provide guidance:
以下给出了端部系统的典型值，以提供指导：
- IP Phone with handset: typically 45 dB.
- 带手机的IP电话：通常为45分贝。
- PC softphone or speakerphone: extremely variable, consider reporting "undefined" (127).
- PC软电话或扬声器：非常多变，考虑报告“未定义”（127）。
- IP gateway with line echo canceller: typically has ERL and ERLE available.
- 带线路回波消除器的IP网关：通常有ERL和ERLE可用。
- IP gateway without line echo canceller: frequently a source of echo related problems, consider reporting either a low value (12 dB) or "undefined" (127).
- 没有线路回声消除器的IP网关：经常是回声相关问题的来源，考虑报告低值（12分贝）或“未定义”（127）。
Gmin See Configuration Parameters (Section 4.7.6, below).
Gmin见配置参数（下文第4.7.6节）。
The following metrics are direct measures of the call quality or transmission quality, and incorporate the effects of codec type, packet loss, discard, burstiness, delay etc. These metrics may not be available in all systems, however, they SHOULD be provided in order to support problem diagnosis.
以下度量是呼叫质量或传输质量的直接度量，并包含编解码器类型、数据包丢失、丢弃、突发性、延迟等的影响。这些度量可能不适用于所有系统，但是，应提供它们以支持问题诊断。
R factor: 8 bits The R factor is a voice quality metric describing the segment of the call that is carried over this RTP session. It is expressed as an integer in the range 0 to 100, with a value of 94 corresponding to "toll quality" and values of 50 or less regarded as unusable. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5 [3].
R因子：8位R因子是一个语音质量指标，描述通过RTP会话进行的呼叫段。它表示为0到100范围内的整数，值94对应于“通行费质量”，值50或更小视为不可用。该指标定义为包括延迟影响，符合ITU-T G.107[6]和ETSI TS 101 329-5[3]。
A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system.
值127表示此参数不可用。除127和上述定义的有效范围之外的值不得发送，且接收系统必须忽略。
ext. R factor: 8 bits The external R factor is a voice quality metric describing the segment of the call that is carried over a network segment external to the RTP segment, for example a cellular network. Its values are interpreted in the same manner as for the RTP R factor. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5 [3], and relates to the outward voice path from the Voice over IP termination for which this metrics block applies.
外部R系数：8位外部R系数是一个语音质量指标，描述通过RTP段外部网络段（例如蜂窝网络）进行的呼叫段。其值的解释方式与RTP R系数的解释方式相同。根据ITU-T G.107[6]和ETSI TS 101 329-5[3]，该度量被定义为包括延迟的影响，并与该度量块适用的IP语音终端的向外语音路径相关。
A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system.
值127表示此参数不可用。除127和上述定义的有效范围之外的值不得发送，且接收系统必须忽略。
Note that an overall R factor may be estimated from the RTP segment R factor and the external R factor, as follows:
注意，可根据RTP段R系数和外部R系数估算总体R系数，如下所示：
R total = RTP R factor + ext. R factor - 94
R total = RTP R factor + ext. R factor - 94
MOS-LQ: 8 bits The estimated mean opinion score for listening quality (MOS-LQ) is a voice quality metric on a scale from 1 to 5, in which 5 represents excellent and 1 represents unacceptable. This metric is defined as not including the effects of delay and can be compared to MOS scores obtained from listening quality (ACR) tests. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10. For example, a value of 35 would correspond to an estimated MOS score of 3.5.
MOS-LQ:8位听力质量的估计平均意见分数（MOS-LQ）是一个从1到5的音质指标，其中5表示优秀，1表示不可接受。该指标定义为不包括延迟的影响，可与听力质量（ACR）测试获得的MOS分数进行比较。它表示为10到50范围内的整数，对应于MOS x 10。例如，值35对应于估计的MOS分数3.5。
A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system.
值127表示此参数不可用。除127和上述定义的有效范围之外的值不得发送，且接收系统必须忽略。
MOS-CQ: 8 bits The estimated mean opinion score for conversational quality (MOS-CQ) is defined as including the effects of delay and other effects that would affect conversational quality. The metric may be calculated by converting an R factor determined according to ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an estimated MOS using the equation specified in G.107. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10, as for MOS-LQ.
MOS-CQ:8位会话质量的估计平均意见分数（MOS-CQ）定义为包括延迟的影响和其他可能影响会话质量的影响。可通过使用G.107中规定的方程式将根据ITU-T G.107[6]或ETSI TS 101 329-5[3]确定的R系数转换为估算的MOS来计算度量。与MOS-LQ一样，它表示为10到50范围内的整数，对应于MOS x 10。
A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system.
值127表示此参数不可用。除127和上述定义的有效范围之外的值不得发送，且接收系统必须忽略。
Gmin: 8 bits The gap threshold. This field contains the value used for this report block to determine if a gap exists. The recommended value of 16 corresponds to a burst period having a minimum density of 6.25% of lost or discarded packets, which may cause noticeable degradation in call quality; during gap periods, if packet loss or discard occurs, each lost or discarded packet would be preceded by and followed by a sequence of at least 16 received non-discarded packets. Note that lost or discarded
Gmin:8位间隙阈值。此字段包含此报告块用于确定是否存在间隙的值。建议值16对应于具有丢失或丢弃分组的6.25%的最小密度的突发周期，这可能导致呼叫质量的显著降低；在间隔期间，如果发生数据包丢失或丢弃，则每个丢失或丢弃的数据包之前和之后都会有至少16个接收到的非丢弃数据包的序列。注意，丢失或丢弃
packets that occur within Gmin packets of a report being generated may be reclassified as part of a burst or gap in later reports. ETSI TS 101 329-5 [3] defines a computationally efficient algorithm for measuring burst and gap density using a packet loss/discard event driven approach. This algorithm is reproduced in Appendix A.2 of the present document. Gmin MUST not be zero, MUST be provided, and MUST remain constant across VoIP Metrics report blocks for the duration of the RTP session.
在生成的报告的Gmin数据包中出现的数据包可以在以后的报告中重新分类为突发或间隙的一部分。ETSI TS 101 329-5[3]定义了一种计算效率高的算法，用于使用丢包/丢弃事件驱动方法测量突发和间隙密度。本文件附录A.2再现了该算法。Gmin不得为零，必须提供，并且在RTP会话期间，必须在VoIP度量报告块中保持恒定。
receiver configuration byte (RX config): 8 bits This byte consists of the following fields:
接收器配置字节（RX config）：8位该字节由以下字段组成：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PLC|JBA|JB rate|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PLC|JBA|JB rate|
+-+-+-+-+-+-+-+-+
packet loss concealment (PLC): 2 bits Standard (11) / enhanced (10) / disabled (01) / unspecified (00). When PLC = 11, then a simple replay or interpolation algorithm is being used to fill-in the missing packet; this approach is typically able to conceal isolated lost packets at low packet loss rates. When PLC = 10, then an enhanced interpolation algorithm is being used; algorithms of this type are able to conceal high packet loss rates effectively. When PLC = 01, then silence is being inserted in place of lost packets. When PLC = 00, then no information is available concerning the use of PLC; however, for some codecs this may be inferred.
包丢失隐藏（PLC）：2位标准（11）/增强（10）/禁用（01）/未指定（00）。当PLC=11时，则使用简单的重放或插值算法来填充丢失的数据包；这种方法通常能够以较低的丢包率隐藏孤立的丢包。当PLC=10时，则使用增强型插值算法；这种类型的算法能够有效地隐藏高丢包率。当PLC=01时，将插入静音以代替丢失的数据包。当PLC=00时，则没有关于PLC使用的信息；但是，对于某些编解码器，这可能是推断出来的。
jitter buffer adaptive (JBA): 2 bits Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When the jitter buffer is adaptive, then its size is being dynamically adjusted to deal with varying levels of jitter. When non-adaptive, the jitter buffer size is maintained at a fixed level. When either adaptive or non-adaptive modes are specified, then the jitter buffer size parameters below MUST be specified.
抖动缓冲自适应（JBA）：2位自适应（11）/非自适应（10）/保留（01）/未知（00）。当抖动缓冲区是自适应的时，它的大小将被动态调整以处理不同程度的抖动。非自适应时，抖动缓冲区大小保持在固定水平。如果指定了自适应或非自适应模式，则必须指定下面的抖动缓冲区大小参数。
jitter buffer rate (JB rate): 4 bits J = adjustment rate (0-15). This represents the implementation specific adjustment rate of a jitter buffer in adaptive mode. This parameter is defined in terms of the approximate time taken to fully adjust to a step change in peak to peak jitter from 30 ms to 100 ms such that:
抖动缓冲速率（JB速率）：4位J=调整速率（0-15）。这表示自适应模式下抖动缓冲器的特定于实现的调整率。该参数根据从30 ms到100 ms的峰-峰抖动阶跃变化完全调整所需的近似时间来定义，以便：
adjustment time = 2 * J * frame size (ms)
adjustment time = 2 * J * frame size (ms)
This parameter is intended only to provide a guide to the degree of "aggressiveness" of an adaptive jitter buffer and may be estimated. A value of 0 indicates that the adjustment time is unknown for this implementation.
该参数仅用于为自适应抖动缓冲器的“攻击性”程度提供指导，并且可以进行估计。值0表示此实现的调整时间未知。
reserved: 8 bits This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
保留：8位此字段保留供将来定义。在没有这种定义的情况下，此字段中的位必须设置为零，并且必须被接收器忽略。
The values reported in these fields SHOULD be the most recently obtained values at the time of reporting.
这些字段中报告的值应为报告时最新获得的值。
jitter buffer nominal delay (JB nominal): 16 bits This is the current nominal jitter buffer delay in milliseconds, which corresponds to the nominal jitter buffer delay for packets that arrive exactly on time. This parameter MUST be provided for both fixed and adaptive jitter buffer implementations.
jitter buffer nominal delay（JB nominal）：16位这是当前的标称抖动缓冲延迟（以毫秒为单位），对应于准时到达的数据包的标称抖动缓冲延迟。必须为固定和自适应抖动缓冲区实现提供此参数。
jitter buffer maximum delay (JB maximum): 16 bits This is the current maximum jitter buffer delay in milliseconds which corresponds to the earliest arriving packet that would not be discarded. In simple queue implementations this may correspond to the nominal size. In adaptive jitter buffer implementations, this value may dynamically vary up to JB abs max (see below). This parameter MUST be provided for both fixed and adaptive jitter buffer implementations.
抖动缓冲区最大延迟（JB最大）：16位这是当前最大抖动缓冲区延迟（毫秒），对应于不会丢弃的最早到达的数据包。在简单队列实现中，这可能对应于标称大小。在自适应抖动缓冲区实现中，该值可能会动态变化，最高可达JB abs max（见下文）。必须为固定和自适应抖动缓冲区实现提供此参数。
jitter buffer absolute maximum delay (JB abs max): 16 bits This is the absolute maximum delay in milliseconds that the adaptive jitter buffer can reach under worst case conditions. If this value exceeds 65535 milliseconds, then this field SHALL convey the value 65535. This parameter MUST be provided for adaptive jitter buffer implementations and its value MUST be set to JB maximum for fixed jitter buffer implementations.
抖动缓冲区绝对最大延迟（JB abs max）：16位这是自适应抖动缓冲区在最坏情况下可以达到的绝对最大延迟（毫秒）。如果该值超过65535毫秒，则该字段应传递值65535。必须为自适应抖动缓冲区实现提供此参数，对于固定抖动缓冲区实现，其值必须设置为JB最大值。
This section defines Session Description Protocol (SDP) [4] signaling for XR blocks that can be employed by applications that utilize SDP. This signaling is defined to be used either by applications that implement the SDP Offer/Answer model [8] or by applications that use SDP to describe media and transport configurations in connection
本节定义了可由使用SDP的应用程序使用的XR块的会话描述协议（SDP）[4]信令。此信令被定义为由实现SDP提供/应答模型[8]的应用程序使用，或由使用SDP描述连接中的媒体和传输配置的应用程序使用
with such protocols as the Session Announcement Protocol (SAP) [15] or the Real Time Streaming Protocol (RTSP) [17]. There exist other potential signaling methods that are not defined here.
使用会话公告协议（SAP）[15]或实时流协议（RTSP）[17]等协议。还有其他潜在的信令方法未在此处定义。
The XR blocks MAY be used without prior signaling. This is consistent with the rules governing other RTCP packet types, as described in [9]. An example in which signaling would not be used is an application that always requires the use of one or more XR blocks. However, for applications that are configured at session initiation, the use of some type of signaling is recommended.
XR块可以在没有事先信令的情况下使用。这与管理其他RTCP数据包类型的规则一致，如[9]所述。不使用信令的示例是始终需要使用一个或多个XR块的应用程序。但是，对于在会话启动时配置的应用程序，建议使用某种类型的信令。
Note that, although the use of SDP signaling for XR blocks may be optional, if used, it MUST be used as defined here. If SDP signaling is used in an environment where XR blocks are only implemented by some fraction of the participants, the ones not implementing the XR blocks will ignore the SDP attribute.
注意，尽管对XR块使用SDP信令可能是可选的，但如果使用，则必须按照此处的定义使用。如果在XR块仅由部分参与者实现的环境中使用SDP信令，则未实现XR块的参与者将忽略SDP属性。
This section defines one new SDP attribute "rtcp-xr" that can be used to signal participants in a media session that they should use the specified XR blocks. This attribute can be easily extended in the future with new parameters to cover any new report blocks.
本节定义了一个新的SDP属性“rtcp xr”，可用于向媒体会话中的参与者发出信号，告知他们应使用指定的xr块。将来可以使用新参数轻松扩展此属性，以覆盖任何新的报告块。
The RTCP XR blocks SDP attribute is defined below in Augmented Backus-Naur Form (ABNF) [2]. It is both a session and a media level attribute. When specified at session level, it applies to all media level blocks in the session. Any media level specification MUST replace a session level specification, if one is present, for that media block.
RTCP XR blocks SDP属性的定义如下所示，即扩充的Backus Naur表格（ABNF）[2]。它既是会话属性，也是媒体级属性。在会话级别指定时，它适用于会话中的所有媒体级别块。任何媒体级别规范都必须替换该媒体块的会话级别规范（如果存在）。
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
xr-format = pkt-loss-rle
/ pkt-dup-rle
/ pkt-rcpt-times
/ rcvr-rtt
/ stat-summary
/ voip-metrics
/ format-ext
xr-format = pkt-loss-rle
/ pkt-dup-rle
/ pkt-rcpt-times
/ rcvr-rtt
/ stat-summary
/ voip-metrics
/ format-ext
pkt-loss-rle = "pkt-loss-rle" ["=" max-size]
pkt-dup-rle = "pkt-dup-rle" ["=" max-size]
pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size]
rcvr-rtt = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size]
rcvr-rtt-mode = "all"
/ "sender"
stat-summary = "stat-summary" ["=" stat-flag *("," stat-flag)]
pkt-loss-rle = "pkt-loss-rle" ["=" max-size]
pkt-dup-rle = "pkt-dup-rle" ["=" max-size]
pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size]
rcvr-rtt = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size]
rcvr-rtt-mode = "all"
/ "sender"
stat-summary = "stat-summary" ["=" stat-flag *("," stat-flag)]
stat-flag = "loss"
/ "dup"
/ "jitt"
/ "TTL"
/ "HL"
voip-metrics = "voip-metrics"
max-size = 1*DIGIT ; maximum block size in octets
DIGIT = %x30-39
format-ext = non-ws-string
stat-flag = "loss"
/ "dup"
/ "jitt"
/ "TTL"
/ "HL"
voip-metrics = "voip-metrics"
max-size = 1*DIGIT ; maximum block size in octets
DIGIT = %x30-39
format-ext = non-ws-string
non-ws-string = 1*(%x21-FF)
CRLF = %d13.10
non-ws-string = 1*(%x21-FF)
CRLF = %d13.10
The "rtcp-xr" attribute contains zero, one, or more XR block related parameters. Each parameter signals functionality for an XR block, or a group of XR blocks. The attribute is extensible so that parameters can be defined for any future XR block (and a parameter should be defined for every future block).
“rtcp xr”属性包含零个、一个或多个xr块相关参数。每个参数表示一个XR块或一组XR块的功能。该属性是可扩展的，因此可以为任何将来的XR块定义参数（并且应该为每个将来的块定义一个参数）。
Each "rtcp-xr" parameter belongs to one of two categories. The first category, the unilateral parameters, are for report blocks that simply report on the RTP stream and related metrics. The second category, collaborative parameters, are for XR blocks that involve actions by more than one party in order to carry out their functions.
每个“rtcp xr”参数属于两个类别之一。第一类是单边参数，用于简单报告RTP流和相关度量的报告块。第二类，协作参数，用于涉及多个参与方的操作以执行其功能的XR块。
Round trip time (RTT) measurement is an example of collaborative functionality. An RTP data packet receiver sends a Receiver Reference Time Report Block (Section 4.4). A participant that receives this block sends a DLRR Report Block (Section 4.5) in response, allowing the receiver to calculate its RTT to that participant. As this example illustrates, collaborative functionality may be implemented by two or more different XR blocks. The collaborative functionality of several XR blocks may be governed by a single "rtcp-xr" parameter.
往返时间（RTT）测量是协作功能的一个示例。RTP数据包接收器发送接收器参考时间报告块（第4.4节）。接收此块的参与者发送DLRR报告块（第4.5节）作为响应，允许接收方计算其对该参与者的RTT。如该示例所示，协作功能可以由两个或多个不同的XR块实现。多个XR块的协作功能可由单个“rtcp XR”参数控制。
For the unilateral category, this document defines the following parameters. The parameter names and their corresponding XR formats are as follows:
对于单边类别，本文件定义了以下参数。参数名称及其对应的XR格式如下所示：
Parameter name XR block (block type and name)
-------------- ------------------------------------
pkt-loss-rle 1 Loss RLE Report Block
pkt-dup-rle 2 Duplicate RLE Report Block
pkt-rcpt-times 3 Packet Receipt Times Report Block
stat-summary 6 Statistics Summary Report Block
voip-metrics 7 VoIP Metrics Report Block
Parameter name XR block (block type and name)
-------------- ------------------------------------
pkt-loss-rle 1 Loss RLE Report Block
pkt-dup-rle 2 Duplicate RLE Report Block
pkt-rcpt-times 3 Packet Receipt Times Report Block
stat-summary 6 Statistics Summary Report Block
voip-metrics 7 VoIP Metrics Report Block
The "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters MAY specify an integer value. This value indicates the largest size the whole report block SHOULD have in octets. This shall be seen as an indication that thinning shall be applied if necessary to meet the target size.
“pkt loss rle”、“pkt dup rle”和“pkt rcpt times”参数可以指定整数值。此值表示整个报表块应具有的最大大小（以八位字节为单位）。这应视为必要时应进行减薄以满足目标尺寸的指示。
The "stat-summary" parameter contains a list indicating which fields SHOULD be included in the Statistics Summary report blocks that are sent. The list is a comma separated list, containing one or more field indicators. The space character (0x20) SHALL NOT be present within the list. Field indicators represent the flags defined in Section 4.6. The field indicators and their respective flags are as follows:
“stat summary”参数包含一个列表，指示发送的统计摘要报告块中应包括哪些字段。该列表是一个逗号分隔的列表，包含一个或多个字段指示符。列表中不应出现空格字符（0x20）。现场指示器表示第4.6节中定义的标志。现场指示器及其各自的标志如下所示：
Indicator Flag
--------- ---------------------------
loss loss report flag (L)
dup duplicate report flag (D)
jitt jitter flag (J)
TTL TTL or Hop Limit flag (ToH)
HL TTL or Hop Limit flag (ToH)
Indicator Flag
--------- ---------------------------
loss loss report flag (L)
dup duplicate report flag (D)
jitt jitter flag (J)
TTL TTL or Hop Limit flag (ToH)
HL TTL or Hop Limit flag (ToH)
For "loss", "dup", and "jitt", the presence of the indicator indicates that the corresponding flag should be set to 1 in the Statistics Summary report blocks that are sent. The presence of "TTL" indicates that the corresponding flag should be set to 1. The presence of "HL" indicates that the corresponding flag should be set to 2. The indicators "TTL" and "HL" MUST NOT be signaled together.
对于“丢失”、“dup”和“jitt”，指示器的存在表示应在发送的统计摘要报告块中将相应的标志设置为1。“TTL”的存在表示对应的标志应设置为1。出现“HL”表示对应的标志应设置为2。指示灯“TTL”和“HL”不得同时发出信号。
Blocks in the collaborative category are classified as initiator blocks or response blocks. Signaling SHOULD indicate which participants are required to respond to the initiator block. A party that wishes to receive response blocks from those participants can trigger this by sending an initiator block.
协作类别中的块被分类为发起程序块或响应块。信令应指示需要哪些参与者响应发起程序块。希望从这些参与者处接收响应块的一方可以通过发送启动器块来触发此操作。
The collaborative category currently consists only of one functionality, namely the RTT measurement mechanism for RTP data receivers. The collective functionality of the Receiver Reference Time Report Block and DLRR Report Block is represented by the "rcvr-rtt" parameter. This parameter takes as its arguments a mode value and, optionally, a maximum size for the DLRR report block. The mode value "all" indicates that both RTP data senders and data receivers MAY send DLRR blocks, while the mode value "sender" indicates that only active RTP senders MAY send DLRR blocks, i.e., non RTP senders SHALL NOT send DLRR blocks. If a maximum size in octets is included, any DLRR Report Blocks that are sent SHALL NOT exceed the specified size. If size limitations mean that a DLRR Report Block sender cannot report in one block upon all participants from which it has
协作类别目前仅包括一项功能，即RTP数据接收器的RTT测量机制。接收器参考时间报告块和DLRR报告块的集合功能由“rcvr rtt”参数表示。此参数将模式值和DLRR报告块的最大大小（可选）作为其参数。模式值“all”表示RTP数据发送方和数据接收方都可以发送DLRR块，而模式值“sender”表示只有活动RTP发送方可以发送DLRR块，即非RTP发送方不应发送DLRR块。如果包含以八位字节为单位的最大大小，则发送的任何DLRR报告块不得超过规定的大小。如果大小限制意味着DLRR报告块发送方无法在一个块中报告其所来自的所有参与者
received a Receiver Reference Time Report Block then it SHOULD report on participants in a round robin fashion across several report intervals.
收到接收器参考时间报告块后，它应在多个报告间隔内以循环方式报告参与者。
The "rtcp-xr" attributes parameter list MAY be empty. This is useful in cases in which an application needs to signal that it understands the SDP signaling but does not wish to avail itself of XR functionality. For example, an application in a SIP controlled session could signal that it wishes to stop using all XR blocks by removing all applicable SDP parameters in a re-INVITE message that it sends. If XR blocks are not to be used at all from the beginning of a session, it is RECOMMENDED that the "rtcp-xr" attribute not be supplied at all.
“rtcp xr”属性参数列表可能为空。这在应用程序需要发出信号表示其理解SDP信令但不希望利用XR功能的情况下非常有用。例如，SIP控制会话中的应用程序可以通过删除其发送的重新邀请消息中的所有适用SDP参数来发出信号，表示希望停止使用所有XR块。如果从会话开始就不使用XR块，建议根本不提供“rtcp XR”属性。
When the "rtcp-xr" attribute is present, participants SHOULD NOT send XR blocks other than the ones indicated by the parameters. This means that inclusion of a "rtcp-xr" attribute without any parameters tells a participant that it SHOULD NOT send any XR blocks at all. The purpose is to conserve bandwidth. This is especially important when collaborative parameters are applied to a large multicast group: the sending of an initiator block could potentially trigger responses from all participants. There are, however, contexts in which it makes sense to send an XR block in the absence of a parameter signaling its use. For instance, an application might be designed so as to send certain report blocks without negotiation, while using SDP signaling to negotiate the use of other blocks.
当存在“rtcp xr”属性时，参与者不应发送除参数指示的xr块以外的xr块。这意味着包含不带任何参数的“rtcp xr”属性会告诉参与者它根本不应该发送任何xr块。目的是节省带宽。当协作参数应用于大型多播组时，这一点尤为重要：发送启动器块可能会触发所有参与者的响应。然而，在某些情况下，在没有参数表示使用XR块的情况下发送XR块是有意义的。例如，应用程序可能被设计成在不协商的情况下发送某些报告块，同时使用SDP信令协商其他块的使用。
In the Offer/Answer context [8], the interpretation of SDP signaling for XR packets depends upon the direction attribute that is signaled: "recvonly", "sendrecv", or "sendonly" [4]. If no direction attribute is supplied, then "sendrecv" is assumed. This section applies only to unicast media streams, except where noted. Discussion of unilateral parameters is followed by discussion of collaborative parameters in this section.
在提供/应答上下文[8]中，对XR数据包的SDP信令的解释取决于所发信号的方向属性：“recvonly”、“sendrecv”或“sendonly”[4]。如果未提供方向属性，则假定为“sendrecv”。本节仅适用于单播媒体流，除非另有说明。在本节中，先讨论单边参数，然后讨论协作参数。
For "sendonly" and "sendrecv" media stream offers that specify unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send the corresponding XR blocks. For "sendrecv" offers, the answerer MAY include the "rtcp-xr" attribute in its response, and specify any unilateral parameters in order to request that the offerer send the corresponding XR blocks. The offerer SHOULD send these blocks.
对于指定单边“rtcp xr”属性参数的“sendonly”和“sendrecv”媒体流产品，应答者应发送相应的xr块。对于“sendrecv”报价，应答方可在其响应中包含“rtcp xr”属性，并指定任何单边参数，以请求报价方发送相应的xr块。报价人应发送这些区块。
For "recvonly" media stream offers, the offerer's use of the "rtcp-xr" attribute in connection with unilateral parameters indicates that the offerer is capable of sending the corresponding XR blocks. If
对于“仅回复”媒体流报价，报价人结合单边参数使用“rtcp xr”属性表示报价人能够发送相应的xr块。如果
the answerer responds with an "rtcp-xr" attribute, the offerer SHOULD send XR blocks for each specified unilateral parameter that was in its offer.
应答者以“rtcp xr”属性响应，报价者应为其报价中的每个指定单边参数发送xr块。
For multicast media streams, the inclusion of an "rtcp-xr" attribute with unilateral parameters means that every media recipient SHOULD send the corresponding XR blocks.
对于多播媒体流，包含带有单边参数的“rtcp xr”属性意味着每个媒体收件人都应发送相应的xr块。
An SDP offer with a collaborative parameter declares the offerer capable of receiving the corresponding initiator and replying with the appropriate responses. For example, an offer that specifies the "rcvr-rtt" parameter means that the offerer is prepared to receive Receiver Reference Time Report Blocks and to send DLRR Report Blocks. An offer of a collaborative parameter means that the answerer MAY send the initiator, and, having received the initiator, the offerer SHOULD send the responses.
带有协作参数的SDP报价声明报价人能够接收相应的发起人并用适当的响应进行回复。例如，指定“rcvr rtt”参数的要约意味着要约人准备接收接收机参考时间报告块并发送DLRR报告块。协作参数的要约意味着应答者可以发送发起者，并且在收到发起者后，发起者应该发送响应。
There are exceptions to the rule that an offerer of a collaborative parameter should send responses. For instance, the collaborative parameter might specify a mode that excludes the offerer; or congestion control or maximum transmission unit considerations might militate against the offerer's response.
合作参数的报价人应发送响应的规则也有例外。例如，协作参数可以指定排除报价人的模式；或者拥塞控制或最大传输单元的考虑可能会影响报价人的响应。
By including a collaborative parameter in its answer, the answerer declares its ability to receive initiators and to send responses. The offerer MAY then send initiators, to which the answerer SHOULD reply with responses. As for the offer of a collaborative parameter, there are exceptions to the rule that the answerer should reply.
通过在应答中包含协作参数，应答者声明其接收发起人和发送响应的能力。然后，发盘人可以发送发起者，发起者应回复发起者。至于提供一个协作参数，对于回答者应该回答的规则有例外。
When making an SDP offer of a collaborative parameter for a multicast media stream, the offerer SHOULD specify which participants are to respond to a received initiator. A participant that is not specified SHOULD NOT send responses. Otherwise, undue bandwidth might be consumed. The offer indicates that each participant that is specified SHOULD respond if it receives an initiator. It also indicates that a specified participant MAY send an initiator block.
当为多播媒体流提供协作参数的SDP报价时，报价人应指定哪些参与者将响应接收到的发起人。未指定的参与者不应发送响应。否则，可能会消耗不适当的带宽。要约表示，如果指定的每个参与者收到发起人，则应作出响应。它还指示指定的参与者可以发送启动器块。
An SDP answer for a multicast media stream SHOULD include all collaborative parameters that are present in the offer and that are supported by the answerer. It SHOULD NOT include any collaborative parameter that is absent from the offer.
多播媒体流的SDP应答应包括报价中存在且应答者支持的所有协作参数。它不应包括报价中缺少的任何协作参数。
If a participant receives an SDP offer and understands the "rtcp-xr" attribute but does not wish to implement XR functionality offered, its answer SHOULD include an "rtcp-xr" attribute without parameters. By doing so, the party declares that, at a minimum, is capable of understanding the signaling.
如果参与者收到SDP报价并理解“rtcp xr”属性，但不希望实现所提供的xr功能，则其回答应包括不带参数的“rtcp xr”属性。通过这样做，该方声明至少能够理解信号。
SDP can be employed outside of the Offer/Answer context, for instance for multimedia sessions that are announced through the Session Announcement Protocol (SAP) [15], or streamed through the Real Time Streaming Protocol (RTSP) [17]. The signaling model is simpler, as the sender does not negotiate parameters, but the functionality expected from specifying the "rtcp-xr" attribute is the same as in Offer/Answer.
SDP可在提供/应答上下文之外使用，例如，通过会话公告协议（SAP）[15]宣布的多媒体会话，或通过实时流协议（RTSP）[17]流式传输的多媒体会话。信令模型更简单，因为发送方不协商参数，但指定“rtcp xr”属性所需的功能与提供/应答中的功能相同。
When a unilateral parameter is specified for the "rtcp-xr" attribute associated with a media stream, the receiver of that stream SHOULD send the corresponding XR block. When a collaborative parameter is specified, only the participants indicated by the mode value in the collaborative parameter are concerned. Each such participant that receives an initiator block SHOULD send the corresponding response block. Each such participant MAY also send initiator blocks.
当为与媒体流关联的“rtcp xr”属性指定单边参数时，该流的接收器应发送相应的xr块。如果指定了协作参数，则仅涉及协作参数中模式值指示的参与者。接收发起程序块的每个这样的参与者都应该发送相应的响应块。每个这样的参与者还可以发送发起程序块。
This document defines a new RTCP packet type, the Extended Report (XR) type, within the existing Internet Assigned Numbers Authority (IANA) registry of RTP RTCP Control Packet Types. This document also defines a new IANA registry: the registry of RTCP XR Block Types. Within this new registry, this document defines an initial set of seven block types and describes how the remaining types are to be allocated.
本文档在RTP RTCP控制数据包类型的现有Internet Assigned Numbers Authority（IANA）注册表中定义了一种新的RTCP数据包类型，即扩展报告（XR）类型。本文档还定义了一个新的IANA注册表：RTCP XR块类型注册表。在这个新的注册表中，本文档定义了一组初始的七种块类型，并描述了如何分配其余的类型。
Further, this document defines a new SDP attribute, "rtcp-xr", within the existing IANA registry of SDP Parameters. It defines a new IANA registry, the registry of RTCP XR SDP Parameters, and an initial set of six parameters, and describes how additional parameters are to be allocated.
此外，本文档在SDP参数的现有IANA注册表中定义了一个新的SDP属性“rtcp xr”。它定义了一个新的IANA注册表、RTCP XR SDP参数注册表和一组初始的六个参数，并描述了如何分配其他参数。
The XR packet type defined by this document is registered with the IANA as packet type 207 in the registry of RTP RTCP Control Packet types (PT).
本文件定义的XR数据包类型在IANA注册为RTP RTCP控制数据包类型（PT）注册表中的数据包类型207。
This document creates an IANA registry called the RTCP XR Block Type Registry to cover the name space of the Extended Report block type (BT) field specified in Section 3. The BT field contains eight bits, allowing 256 values. The RTCP XR Block Type Registry is to be managed by the IANA according to the Specification Required policy of
本文档创建一个名为RTCP XR块类型注册表的IANA注册表，以覆盖第3节中指定的扩展报告块类型（BT）字段的名称空间。BT字段包含八位，允许256个值。RTCP XR块类型注册表将由IANA根据所需策略规范进行管理
RFC 2434 [7]. Future specifications SHOULD attribute block type values in strict numeric order following the values attributed in this document:
RFC 2434[7]。未来的规范应按照本文档中的属性值，以严格的数字顺序对块类型值进行属性化：
BT name
-- ----
1 Loss RLE Report Block
2 Duplicate RLE Report Block
3 Packet Receipt Times Report Block
4 Receiver Reference Time Report Block
5 DLRR Report Block
6 Statistics Summary Report Block
7 VoIP Metrics Report Block
BT name
-- ----
1 Loss RLE Report Block
2 Duplicate RLE Report Block
3 Packet Receipt Times Report Block
4 Receiver Reference Time Report Block
5 DLRR Report Block
6 Statistics Summary Report Block
7 VoIP Metrics Report Block
The BT value 255 is reserved for future extensions.
BT值255保留用于将来的扩展。
Furthermore, future specifications SHOULD avoid the value 0. Doing so facilitates packet validity checking, since an all-zeros field might commonly be found in an ill-formed packet.
此外，未来的规范应避免值0。这样做有助于数据包有效性检查，因为在格式错误的数据包中通常会发现全零字段。
Any registration MUST contain the following information:
任何注册必须包含以下信息：
- Contact information of the one doing the registration, including at least name, address, and email.
- 注册人的联系信息，至少包括姓名、地址和电子邮件。
- The format of the block type being registered, consistent with the extended report block format described in Section 3.
- 正在注册的块类型的格式，与第3节中描述的扩展报告块格式一致。
- A description of what the block type represents and how it shall be interpreted, detailing this information for each of its fields.
- 对块类型表示的内容和解释方式的描述，详细说明其每个字段的信息。
The SDP attribute "rtcp-xr" defined by this document is registered with the IANA registry of SDP Parameters as follows:
本文档定义的SDP属性“rtcp xr”在IANA SDP参数注册表中注册，如下所示：
SDP Attribute ("att-field"):
SDP属性（“att字段”）：
Attribute name: rtcp-xr Long form: RTP Control Protocol Extended Report Parameters Type of name: att-field Type of attribute: session and media level Subject to charset: no Purpose: see Section 5 of this document Reference: this document Values: see this document and registrations below
属性名称：rtcp xr长格式：RTP控制协议扩展报告参数名称类型：att字段属性类型：会话和媒体级别取决于字符集：无用途：参见本文档第5节参考：本文档值：参见下面的本文档和注册
The attribute has an extensible parameter field and therefore a registry for these parameters is required. This document creates an IANA registry called the RTCP XR SDP Parameters Registry. It contains the six parameters defined in Section 5.1: "pkt-loss-rle", "pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and "recv-rtt".
该属性具有可扩展的参数字段，因此需要这些参数的注册表。本文档创建了一个名为RTCP XR SDP参数注册表的IANA注册表。它包含第5.1节中定义的六个参数：“pkt丢失rle”、“pkt重复rle”、“pkt rcpt时间”、“统计摘要”、“voip度量”和“recv rtt”。
Additional parameters are to be added to this registry in accordance with the Specification Required policy of RFC 2434 [7]. Any registration MUST contain the following information:
根据RFC 2434[7]的规范要求政策，将其他参数添加到此注册表中。任何注册必须包含以下信息：
- Contact information of the one doing the registration, including at least name, address, and email.
- 注册人的联系信息，至少包括姓名、地址和电子邮件。
- An Augmented Backus-Naur Form (ABNF) [2] definition of the parameter, in accordance with the "format-ext" definition of Section 5.1.
- 根据第5.1节中的“格式扩展”定义，参数的扩展巴科斯-诺尔格式（ABNF）[2]定义。
- A description of what the parameter represents and how it shall be interpreted, both normally and in Offer/Answer.
- 通常情况下，以及在报价/应答中，对参数表示的内容和解释方式的说明。
This document extends the RTCP reporting mechanism. The security considerations that apply to RTCP reports [9, Appendix B] also apply to XR reports. This section details the additional security considerations that apply to the extensions.
本文件扩展了RTCP报告机制。适用于RTCP报告[9，附录B]的安全注意事项也适用于XR报告。本节详细介绍了应用于扩展的其他安全注意事项。
The extensions introduce heightened confidentiality concerns. Standard RTCP reports contain a limited number of summary statistics. The information contained in XR reports is both more detailed and more extensive (covering a larger number of parameters). The per-packet report blocks and the VoIP Metrics Report Block provide examples.
扩展带来了更高的保密性问题。标准RTCP报告包含数量有限的摘要统计信息。XR报告中包含的信息更详细、更广泛（涵盖更多参数）。每包报告块和VoIP度量报告块提供了示例。
The per-packet information contained in Loss RLE, Duplicate RLE, and Packet Receipt Times Report Blocks facilitates multicast inference of network characteristics (MINC) [11]. Such inference can reveal the gross topology of a multicast distribution tree, as well as parameters, such as the loss rates and delays, along paths between branching points in that tree. Such information might be considered sensitive to autonomous system administrators.
丢失RLE、重复RLE和数据包接收时间报告块中包含的每个数据包信息有助于网络特性的多播推断（MINC）[11]。这种推断可以揭示多播分发树的总体拓扑结构，以及该树中分支点之间路径上的参数，如丢失率和延迟。自治系统管理员可能会认为这些信息很敏感。
The VoIP Metrics Report Block provides information on the quality of ongoing voice calls. Though such information might be carried in an application specific format in standard RTP sessions, making it available in a standard format here makes it more available to potential eavesdroppers.
VoIP度量报告块提供有关正在进行的语音呼叫质量的信息。尽管这些信息可能在标准RTP会话中以特定于应用程序的格式传输，但在这里以标准格式提供这些信息会使潜在窃听者更容易获得这些信息。
No new mechanisms are introduced in this document to ensure confidentiality. Encryption procedures, such as those being suggested for a Secure RTCP (SRTCP) [12] at the time that this document was written, can be used when confidentiality is a concern to end hosts. Given that RTCP traffic can be encrypted by the end hosts, autonomous systems must be prepared for the fact that certain aspects of their network topology can be revealed.
本文件中没有引入新的机制来确保机密性。当终端主机担心机密性时，可以使用加密程序，例如在编写本文档时为安全RTCP（SRTCP）[12]建议的加密程序。鉴于RTCP通信量可由终端主机加密，自治系统必须做好准备，以确保其网络拓扑的某些方面可以被揭示。
Any encryption or filtering of XR report blocks entails a loss of monitoring information to third parties. For example, a network that establishes a tunnel to encrypt VoIP Report Blocks denies that information to the service providers traversed by the tunnel. The service providers cannot then monitor or respond to the quality of the VoIP calls that they carry, potentially creating problems for the network's users. As a default, XR packets should not be encrypted or filtered.
XR报告块的任何加密或过滤都会导致第三方丢失监控信息。例如，建立隧道以加密VoIP报告块的网络拒绝将该信息提供给隧道所穿越的服务提供商。然后，服务提供商无法监控或响应其承载的VoIP呼叫的质量，这可能会给网络用户带来问题。默认情况下，不应加密或过滤XR数据包。
The extensions also make certain denial of service attacks easier. This is because of the potential to create RTCP packets much larger than average with the per packet reporting capabilities of the Loss RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the automatic bandwidth adjustment mechanisms in RTCP, if some session participants are sending large RTCP packets, all participants will see their RTCP reporting intervals lengthened, meaning they will be able to report less frequently. To limit the effects of large packets, even in the absence of denial of service attacks, applications SHOULD place an upper limit on the size of the XR report blocks they employ. The "thinning" techniques described in Section 4.1 permit the packet-by-packet report blocks to adhere to a predefined size limit.
这些扩展还使某些拒绝服务攻击变得更容易。这是因为使用丢失RLE、重复RLE和时间戳报告块的每个数据包报告功能，可能会创建比平均值大得多的RTCP数据包。由于RTCP中的自动带宽调整机制，如果某些会话参与者发送大型RTCP数据包，所有参与者都会看到其RTCP报告间隔延长，这意味着他们能够减少报告频率。为了限制大数据包的影响，即使在没有拒绝服务攻击的情况下，应用程序也应该对其使用的XR报告块的大小设置上限。第4.1节中描述的“细化”技术允许逐包报告块遵守预定义的大小限制。
A. Algorithms
A.算法
This is the algorithm suggested by Section 4.1 for keeping track of the sequence numbers from a given sender. It implements the accounting practice required for the generation of Loss RLE Report Blocks.
这是第4.1节建议的算法，用于跟踪给定发送方的序列号。它实现了生成损失RLE报告块所需的会计实践。
This algorithm keeps track of 16 bit sequence numbers by translating them into a 32 bit sequence number space. The first packet received from a source is considered to have arrived roughly in the middle of that space. Each packet that follows is placed either ahead of or behind the prior one in this 32 bit space, depending upon which choice would place it closer (or, in the event of a tie, which choice would not require a rollover in the 16 bit sequence number).
该算法通过将16位序列号转换为32位序列号空间来跟踪16位序列号。从源接收的第一个分组被认为大致到达该空间的中间。接下来的每个数据包在这个32位空间中被放置在前一个数据包的前面或后面，这取决于哪个选项将使它更靠近（或者，在出现平局的情况下，哪个选项将不需要在16位序列号中滚动）。
// The reference sequence number is an extended sequence number
// that serves as the basis for determining whether a new 16 bit
// sequence number comes earlier or later in the 32 bit sequence
// space.
u_int32 _src_ref_seq;
bool _uninitialized_src_ref_seq;
// The reference sequence number is an extended sequence number
// that serves as the basis for determining whether a new 16 bit
// sequence number comes earlier or later in the 32 bit sequence
// space.
u_int32 _src_ref_seq;
bool _uninitialized_src_ref_seq;
// Place seq into a 32-bit sequence number space based upon a
// heuristic for its most likely location.
u_int32 extend_seq(const u_int16 seq) {
// Place seq into a 32-bit sequence number space based upon a
// heuristic for its most likely location.
u_int32 extend_seq(const u_int16 seq) {
u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b;
if(_uninitialized_src_ref_seq) {
u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b;
if(_uninitialized_src_ref_seq) {
// This is the first sequence number received. Place
// it in the middle of the extended sequence number
// space.
_src_ref_seq = seq | 0x80000000u;
_uninitialized_src_ref_seq = false;
extended_seq = _src_ref_seq;
}
else {
// This is the first sequence number received. Place
// it in the middle of the extended sequence number
// space.
_src_ref_seq = seq | 0x80000000u;
_uninitialized_src_ref_seq = false;
extended_seq = _src_ref_seq;
}
else {
// Prior sequence numbers have been received.
// Propose two candidates for the extended sequence
// number: seq_a is without wraparound, seq_b with
// wraparound.
seq_a = seq | (_src_ref_seq & 0xFFFF0000u);
if(_src_ref_seq < seq_a) {
seq_b = seq_a - 0x00010000u;
diff_a = seq_a - _src_ref_seq;
// Prior sequence numbers have been received.
// Propose two candidates for the extended sequence
// number: seq_a is without wraparound, seq_b with
// wraparound.
seq_a = seq | (_src_ref_seq & 0xFFFF0000u);
if(_src_ref_seq < seq_a) {
seq_b = seq_a - 0x00010000u;
diff_a = seq_a - _src_ref_seq;
diff_b = _src_ref_seq - seq_b;
}
else {
seq_b = seq_a + 0x00010000u;
diff_a = _src_ref_seq - seq_a;
diff_b = seq_b - _src_ref_seq;
}
diff_b = _src_ref_seq - seq_b;
}
else {
seq_b = seq_a + 0x00010000u;
diff_a = _src_ref_seq - seq_a;
diff_b = seq_b - _src_ref_seq;
}
// Choose the closer candidate. If they are equally
// close, the choice is somewhat arbitrary: we choose
// the candidate for which no rollover is necessary.
if(diff_a < diff_b) {
extended_seq = seq_a;
}
else {
extended_seq = seq_b;
}
// Choose the closer candidate. If they are equally
// close, the choice is somewhat arbitrary: we choose
// the candidate for which no rollover is necessary.
if(diff_a < diff_b) {
extended_seq = seq_a;
}
else {
extended_seq = seq_b;
}
// Set the reference sequence number to be this most
// recently-received sequence number.
_src_ref_seq = extended_seq;
}
// Set the reference sequence number to be this most
// recently-received sequence number.
_src_ref_seq = extended_seq;
}
// Return our best guess for a 32-bit sequence number that
// corresponds to the 16-bit number we were given.
return extended_seq;
}
// Return our best guess for a 32-bit sequence number that
// corresponds to the 16-bit number we were given.
return extended_seq;
}
A.2. Example Burst Packet Loss Calculation.
A.2. 突发数据包丢失计算示例。
This is an algorithm for measuring the burst characteristics for the VoIP Metrics Report Block (Section 4.7). The algorithm, which has been verified against a working implementation for correctness, is reproduced from ETSI TS 101 329-5 [3]. The algorithm, as described here, takes precedence over any change that might eventually be made to the algorithm in future ETSI documents.
这是一种用于测量VoIP度量报告块的突发特性的算法（第4.7节）。该算法已根据工作实现进行了正确性验证，其复制自ETSI TS 101 329-5[3]。如本文所述，算法优先于未来ETSI文档中可能最终对算法所做的任何更改。
This algorithm is event driven and hence extremely computationally efficient.
该算法是事件驱动的，因此计算效率极高。
Given the following definition of states:
鉴于以下国家定义：
state 1 = received a packet during a gap state 2 = received a packet during a burst state 3 = lost a packet during a burst state 4 = lost an isolated packet during a gap
状态1=在间隙状态期间接收到数据包状态2=在突发状态期间接收到数据包3=在突发状态期间丢失数据包4=在间隙期间丢失隔离数据包
The "c" variables below correspond to state transition counts, i.e., c14 is the transition from state 1 to state 4. It is possible to infer one of a pair of state transition counts to an accuracy of 1 which is generally sufficient for this application.
下面的“c”变量对应于状态转换计数，即c14是从状态1到状态4的转换。可以将一对状态转移计数中的一个推断为精度为1，这通常足以用于此应用。
"pkt" is the count of packets received since the last packet was declared lost or discarded, and "lost" is the number of packets lost within the current burst. "packet_lost" and "packet_discarded" are Boolean variables that indicate if the event that resulted in this function being invoked was a lost or discarded packet.
“pkt”是自最后一个数据包被声明丢失或丢弃以来接收的数据包计数，“lost”是当前突发中丢失的数据包数。“packet_lost”和“packet_discarded”是布尔变量，用于指示导致调用此函数的事件是丢失的还是丢弃的数据包。
if(packet_lost) {
loss_count++;
}
if(packet_discarded) {
discard_count++;
}
if(!packet_lost && !packet_discarded) {
pkt++;
}
else {
if(pkt >= gmin) {
if(lost == 1) {
c14++;
}
else {
c13++;
}
lost = 1;
c11 += pkt;
}
else {
lost++;
if(pkt == 0) {
c33++;
}
else {
c23++;
c22 += (pkt - 1);
}
}
pkt = 0;
}
if(packet_lost) {
loss_count++;
}
if(packet_discarded) {
discard_count++;
}
if(!packet_lost && !packet_discarded) {
pkt++;
}
else {
if(pkt >= gmin) {
if(lost == 1) {
c14++;
}
else {
c13++;
}
lost = 1;
c11 += pkt;
}
else {
lost++;
if(pkt == 0) {
c33++;
}
else {
c23++;
c22 += (pkt - 1);
}
}
pkt = 0;
}
At each reporting interval the burst and gap metrics can be calculated as follows.
在每个报告间隔，突发和间隙度量可按如下方式计算。
// Calculate additional transition counts.
c31 = c13;
c32 = c23;
ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33;
// Calculate additional transition counts.
c31 = c13;
c32 = c23;
ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33;
// Calculate burst and densities.
p32 = c32 / (c31 + c32 + c33);
if((c22 + c23) < 1) {
p23 = 1;
}
else {
p23 = 1 - c22/(c22 + c23);
}
burst_density = 256 * p23 / (p23 + p32);
gap_density = 256 * c14 / (c11 + c14);
// Calculate burst and densities.
p32 = c32 / (c31 + c32 + c33);
if((c22 + c23) < 1) {
p23 = 1;
}
else {
p23 = 1 - c22/(c22 + c23);
}
burst_density = 256 * p23 / (p23 + p32);
gap_density = 256 * c14 / (c11 + c14);
// Calculate burst and gap durations in ms
m = frameDuration_in_ms * framesPerRTPPkt;
gap_length = (c11 + c14 + c13) * m / c13;
burst_length = ctotal * m / c13 - lgap;
// Calculate burst and gap durations in ms
m = frameDuration_in_ms * framesPerRTPPkt;
gap_length = (c11 + c14 + c13) * m / c13;
burst_length = ctotal * m / c13 - lgap;
/* calculate loss and discard rates */
loss_rate = 256 * loss_count / ctotal;
discard_rate = 256 * discard_count / ctotal;
/* calculate loss and discard rates */
loss_rate = 256 * loss_count / ctotal;
discard_rate = 256 * discard_count / ctotal;
Intellectual Property Notice
知识产权公告
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11 [5]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP 11[5]。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Acknowledgments
致谢
We thank the following people: Colin Perkins, Steve Casner, and Henning Schulzrinne for their considered guidance; Sue Moon for helping foster collaboration between the authors; Mounir Benzaid for drawing our attention to the reporting needs of MLDA; Dorgham Sisalem and Adam Wolisz for encouraging us to incorporate MLDA block types; and Jose Rey for valuable review of the SDP Signaling section.
我们感谢以下人士：科林·帕金斯、史蒂夫·卡斯纳和亨宁·舒尔兹林内，感谢他们深思熟虑的指导；Sue Moon帮助促进了作者之间的合作；Mounir Benzaid提请我们注意MLDA的报告需求；Dorgham Sisalem和Adam Wolisz鼓励我们合并MLDA区块类型；和Jose Rey对SDP信号部分进行了有价值的审查。
Contributors
贡献者
The following people are the authors of this document:
以下人员是本文件的作者：
Kevin Almeroth, UCSB Ramon Caceres, IBM Research Alan Clark, Telchemy Robert G. Cole, JHU Applied Physics Laboratory Nick Duffield, AT&T Labs-Research Timur Friedman, Paris 6 Kaynam Hedayat, Brix Networks Kamil Sarac, UT Dallas Magnus Westerlund, Ericsson
Kevin Almeroth、UCSB Ramon Caceres、IBM研究机构Alan Clark、Telchemy Robert G.Cole、JHU应用物理实验室Nick Duffield、AT&T实验室研究机构Timur Friedman、巴黎6 Kaynam Hedayat、Brix Networks Kamil Sarac、UT Dallas Magnus Westerlund、爱立信
The principal people to contact regarding the individual report blocks described in this document are as follows:
关于本文件中所述的各个报告块，需要联系的主要人员如下：
sec. report block principal contributors
---- ------------ ----------------------
4.1 Loss RLE Report Block Friedman, Caceres, Duffield
4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield
4.3 Packet Receipt Times Report Block Friedman, Caceres, Duffield
4.4 Receiver Reference Time Report Block Friedman
4.5 DLRR Report Block Friedman
4.6 Statistics Summary Report Block Almeroth, Sarac
4.7 VoIP Metrics Report Block Clark, Cole, Hedayat
sec. report block principal contributors
---- ------------ ----------------------
4.1 Loss RLE Report Block Friedman, Caceres, Duffield
4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield
4.3 Packet Receipt Times Report Block Friedman, Caceres, Duffield
4.4 Receiver Reference Time Report Block Friedman
4.5 DLRR Report Block Friedman
4.6 Statistics Summary Report Block Almeroth, Sarac
4.7 VoIP Metrics Report Block Clark, Cole, Hedayat
The principal person to contact regarding the SDP signaling described in this document is Magnus Westerlund.
本文件所述SDP信号的主要联系人是Magnus Westerlund。
References
工具书类
Normative References
规范性引用文件
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[3] ETSI, "Quality of Service (QoS) measurement methodologies", ETSI TS 101 329-5 V1.1.1 (2000-11), November 2000.
[3] ETSI，“服务质量（QoS）测量方法”，ETSI TS 101 329-5 V1.1.1（2000-11），2000年11月。
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[4] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[5] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[5] Hovey，R.和S.Bradner，“参与IETF标准过程的组织”，BCP 11，RFC 2028，1996年10月。
[6] ITU-T, "The E-Model, a computational model for use in transmission planning", Recommendation G.107, January 2003.
[6] ITU-T，“E模型，用于输电规划的计算模型”，建议G.107，2003年1月。
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[7] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[9] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 35502003年7月。
[10] TIA/EIA-810-A Transmission Requirements for Narrowband Voice over IP and Voice over PCM Digital Wireline Telephones, December 2000.
[10] TIA/EIA-810-A窄带IP语音和PCM数字有线电话的传输要求，2000年12月。
Informative References
资料性引用
[11] Adams, A., Bu, T., Caceres, R., Duffield, N.G., Friedman, T., Horowitz, J., Lo Presti, F., Moon, S.B., Paxson, V. and D. Towsley, "The Use of End-to-End Multicast Measurements for Characterizing Internal Network Behavior", IEEE Communications Magazine, May 2000.
[11] Adams，A.，Bu，T.，Caceres，R.，Duffield，N.G.，Friedman，T.，Horowitz，J.，Lo Presti，F.，Moon，S.B.，Paxson，V.和D.Towsley，“端到端多播测量用于描述内部网络行为”，IEEE通信杂志，2000年5月。
[12] Baugher, McGrew, Oran, Blom, Carrara, Naslund and Norrman, "The Secure Real-time Transport Protocol", Work in Progress.
[12] Baugher、McGrew、Oran、Blom、Carrara、Naslund和Norrman，“安全实时传输协议”，正在进行中。
[13] Caceres, R., Duffield, N.G. and T. Friedman, "Impromptu measurement infrastructures using RTP", Proc. IEEE Infocom 2002.
[13] Caceres，R.，Duffield，N.G.和T.Friedman，“使用RTP的即兴测量基础设施”，Proc。IEEE信息通讯2002。
[14] Clark, A.D., "Modeling the Effects of Burst Packet Loss and Recency on Subjective Voice Quality", Proc. IP Telephony Workshop 2001.
[14] Clark，A.D.，“突发数据包丢失和最近性对主观语音质量的影响建模”，Proc。2001年IP电话讲习班。
[15] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[15] Handley，M.，Perkins，C.和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[16] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[16] Reynolds，J.，Ed.，“分配号码：RFC 1700被在线数据库取代”，RFC 3232，2002年1月。
[17] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[17] Schulzrinne，H.，Rao，A.和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[18] Sisalem D. and A. Wolisz, "MLDA: A TCP-friendly Congestion Control Framework for Heterogeneous Multicast Environments", Proc. IWQoS 2000.
[18] Sisalem D.和A.Wolisz，“MLDA：异构多播环境的TCP友好拥塞控制框架”，Proc。IWQoS 2000。
Authors' Addresses
作者地址
Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106 USA
凯文，加利福尼亚大学计算机科学系，圣塔巴巴拉，CA 93106美国
EMail: almeroth@cs.ucsb.edu
EMail: almeroth@cs.ucsb.edu
Ramon Caceres IBM Research 19 Skyline Drive Hawthorne, NY 10532 USA
Ramon Caceres IBM Research 19美国纽约州霍桑市天际大道10532号
EMail: caceres@watson.ibm.com
EMail: caceres@watson.ibm.com
Alan Clark Telchemy Incorporated 3360 Martins Farm Road, Suite 200 Suwanee, GA 30024 USA
Alan Clark Telchemy Incorporated 3360 Martins Farm Road，美国佐治亚州苏瓦尼200号套房，邮编30024
Phone: +1 770 614 6944
Fax: +1 770 614 3951
EMail: alan@telchemy.com
Phone: +1 770 614 6944
Fax: +1 770 614 3951
EMail: alan@telchemy.com
Robert G. Cole Johns Hopkins University Applied Physics Laboratory MP2-S170 11100 Johns Hopkins Road Laurel, MD 20723-6099 USA
罗伯特·G·科尔约翰·霍普金斯大学应用物理实验室MP2-S170 11100美国马里兰州劳雷尔市约翰·霍普金斯路20723-6099
Phone: +1 443 778 6951
EMail: robert.cole@jhuapl.edu
Phone: +1 443 778 6951
EMail: robert.cole@jhuapl.edu
Nick Duffield AT&T Labs-Research 180 Park Avenue, P.O. Box 971 Florham Park, NJ 07932-0971 USA
Nick Duffield AT&T实验室研究美国新泽西州弗洛勒姆公园公园大道180号邮政信箱971 07932-0971
Phone: +1 973 360 8726
Fax: +1 973 360 8050
EMail: duffield@research.att.com
Phone: +1 973 360 8726
Fax: +1 973 360 8050
EMail: duffield@research.att.com
Timur Friedman Universite Pierre et Marie Curie (Paris 6) Laboratoire LiP6-CNRS 8, rue du Capitaine Scott 75015 PARIS France
蒂穆尔·弗里德曼大学皮埃尔和玛丽·居里（巴黎6）实验室LiP6 CNRS 8，斯科特国会街75015法国巴黎
Phone: +33 1 44 27 71 06
Fax: +33 1 44 27 74 95
EMail: timur.friedman@lip6.fr
Phone: +33 1 44 27 71 06
Fax: +33 1 44 27 74 95
EMail: timur.friedman@lip6.fr
Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford, MA 01824 USA
美国马萨诸塞州切姆斯福德密尔路285号Kaynam Hedayat Brix Networks 01824
Phone: +1 978 367 5600
Fax: +1 978 367 5700
EMail: khedayat@brixnet.com
Phone: +1 978 367 5600
Fax: +1 978 367 5700
EMail: khedayat@brixnet.com
Kamil Sarac Department of Computer Science (ES 4.207) Eric Jonsson School of Engineering & Computer Science University of Texas at Dallas Richardson, TX 75083-0688 USA
卡米尔萨拉克计算机科学系（ES 4.207）Eric Jonsson德克萨斯大学工程与计算机科学学院达拉斯TX理查德森75083-068 8美国
Phone: +1 972 883 2337
Fax: +1 972 883 2349
EMail: ksarac@utdallas.edu
Phone: +1 972 883 2337
Fax: +1 972 883 2349
EMail: ksarac@utdallas.edu
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm Sweden
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80瑞典斯德哥尔摩
Phone: +46 8 404 82 87
Fax: +46 8 757 55 50
EMail: magnus.westerlund@ericsson.com
Phone: +46 8 404 82 87
Fax: +46 8 757 55 50
EMail: magnus.westerlund@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。