Internet Engineering Task Force (IETF) A. Clark
Request for Comments: 6798 Telchemy
Category: Standards Track Q. Wu
ISSN: 2070-1721 Huawei
November 2012
Internet Engineering Task Force (IETF) A. Clark
Request for Comments: 6798 Telchemy
Category: Standards Track Q. Wu
ISSN: 2070-1721 Huawei
November 2012
RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting
用于数据包延迟变化度量报告的RTP控制协议（RTCP）扩展报告（XR）块
Abstract
摘要
This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of packet delay variation metrics for a range of RTP applications.
本文档定义了一个RTP控制协议（RTCP）扩展报告（XR）块，该块允许报告一系列RTP应用程序的数据包延迟变化度量。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6798.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6798.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Packet Delay Variation Metrics Block .......................3
1.2. RTCP and RTCP XR Reports ...................................3
1.3. Performance Metrics Framework ..............................3
1.4. Applicability ..............................................3
2. Terminology .....................................................3
2.1. Requirements Language ......................................3
2.2. Notations ..................................................4
3. Packet Delay Variation Metrics Block ............................4
3.1. Report Block Structure .....................................5
3.2. Definition of Fields in PDV Metrics Block ..................5
3.3. Guidance on Use of PDV Metrics .............................8
3.4. Examples of Use ............................................9
4. SDP Signaling ...................................................9
5. IANA Considerations ............................................10
5.1. New RTCP XR Block Type Value ..............................10
5.2. New RTCP XR SDP Parameter .................................10
5.3. Contact Information for Registrations .....................11
5.4. New Registry of PDV Types .................................11
6. Security Considerations ........................................11
7. Contributors ...................................................12
8. Acknowledgments ................................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................13
1. Introduction ....................................................3
1.1. Packet Delay Variation Metrics Block .......................3
1.2. RTCP and RTCP XR Reports ...................................3
1.3. Performance Metrics Framework ..............................3
1.4. Applicability ..............................................3
2. Terminology .....................................................3
2.1. Requirements Language ......................................3
2.2. Notations ..................................................4
3. Packet Delay Variation Metrics Block ............................4
3.1. Report Block Structure .....................................5
3.2. Definition of Fields in PDV Metrics Block ..................5
3.3. Guidance on Use of PDV Metrics .............................8
3.4. Examples of Use ............................................9
4. SDP Signaling ...................................................9
5. IANA Considerations ............................................10
5.1. New RTCP XR Block Type Value ..............................10
5.2. New RTCP XR SDP Parameter .................................10
5.3. Contact Information for Registrations .....................11
5.4. New Registry of PDV Types .................................11
6. Security Considerations ........................................11
7. Contributors ...................................................12
8. Acknowledgments ................................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................13
This document defines a new block type to augment those defined in [RFC3611], for use in a range of RTP applications.
本文件定义了一种新的块类型，以扩充[RFC3611]中定义的块类型，用于一系列RTP应用。
The new block type provides information on Packet Delay Variation (PDV) using one of several standard metrics, for example, Mean Absolute Packet Delay Variation 2 (MAPDV2) (Clause 6.2.3.2 of [G.1020]) or 2-point PDV (Clause 6.2.4 of [Y.1540]).
新的块类型使用几个标准度量之一提供关于分组延迟变化（PDV）的信息，例如，平均绝对分组延迟变化2（MAPDV2）（G.1020的第6.2.3.2条）或2点PDV（Y.1540的第6.2.4条）。
The metrics belong to the class of transport metrics defined in [MONARCH].
这些指标属于[Monar]中定义的传输指标类别。
The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] defined an extensible structure for reporting using an RTCP Extended Report (XR). This document defines a new Extended Report block for use with [RFC3550] and [RFC3611].
[RFC3550]中定义了使用RTCP进行报告。[RFC3611]定义了使用RTCP扩展报告（XR）进行报告的可扩展结构。本文档定义了一个新的扩展报告块，用于[RFC3550]和[RFC3611]。
The Performance Metrics Framework [RFC6390] provides guidance on the definition and specification of performance metrics. The RTP monitoring architectures [MONARCH] provides guidelines for reporting block format using RTCP XR. The XR block described in this document is in accordance with the guidelines in [RFC6390] and [MONARCH].
性能指标框架[RFC6390]提供了有关性能指标定义和规范的指导。RTP监控体系结构[Monar]提供了使用RTCP XR报告块格式的指南。本文档中描述的XR块符合[RFC6390]和[Monar]中的指南。
These metrics are applicable to a wide range of RTP applications in which the application streams are sensitive to delay variation [RFC5481]. For example, applications could use the measurements of these metrics to help adjust the size of adaptive jitter buffers to improve performance. Network managers can use these metrics to compare actual delay variation to targets (i.e., a numerical objective or Service Level Agreement) to help ensure the quality of real-time application performance.
这些指标适用于广泛的RTP应用，其中应用程序流对延迟变化敏感[RFC5481]。例如，应用程序可以使用这些度量来帮助调整自适应抖动缓冲区的大小以提高性能。网络管理员可以使用这些指标将实际延迟变化与目标（即数字目标或服务级别协议）进行比较，以帮助确保实时应用程序性能的质量。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This report block makes use of binary fractions. The terminology used is
此报告块使用二进制分数。使用的术语是
Numeric formats S X:Y
数字格式S X:Y
where S indicates a two's complement signed representation, X the number of bits prior to the decimal place, and Y the number of bits after the decimal place.
其中S表示2的补码符号表示，X表示小数点前的位数，Y表示小数点后的位数。
Hence, 8:8 represents an unsigned number in the range 0.0 to 255.996 with a granularity of 0.0039. S7:8 represents the range -127.996 to +127.996. 0:16 represents a proper binary fraction with range as follows:
因此，8:8表示0.0到255.996范围内的无符号数，粒度为0.0039。S7:8表示-127.996至+127.996的范围。0:16表示一个适当的二进制分数，其范围如下：
0.0 to 1 - 1/65536 = 0.9999847
0.0 to 1 - 1/65536 = 0.9999847
however, note that use of flag values at the top of the numeric range slightly reduces this upper limit. For example, if the 16-bit values 0xfffe and 0xffff are used as flags for "over-range" and "unavailable" conditions, a 0:16 quantity has a range as follows:
但是，请注意，在数值范围顶部使用标志值会略微降低此上限。例如，如果16位值0xfffe和0xffff用作“超出范围”和“不可用”条件的标志，则0:16数量的范围如下所示：
0.0 to 1 - 3/65536 = 0.9999542
0.0 to 1 - 3/65536 = 0.9999542
Metrics in this block report on packet delay variation in the stream arriving at the RTP system. The measurement of these metrics is made at the receiving end of the RTP stream. Instances of this metric block refer by synchronization source (SSRC) to the separate auxiliary Measurement Information Block [RFC6776], which contains measurement intervals. This metric block relies on the measurement interval given by the value of the "Measurement Duration (Interval)" field in the Measurement Information Block to indicate the span of the report and MUST be sent in the same compound RTCP packet as the Measurement Information Block. If the measurement interval is not received for this metric block, this metric block MUST be discarded.
此块中的度量报告到达RTP系统的流中的数据包延迟变化。这些度量的测量在RTP流的接收端进行。此度量块的实例通过同步源（SSRC）指向单独的辅助测量信息块[RFC6776]，其中包含测量间隔。此度量块依赖于测量信息块中“测量持续时间（间隔）”字段值给出的测量间隔，以指示报告的范围，并且必须在与测量信息块相同的复合RTCP数据包中发送。如果未收到此度量块的测量间隔，则必须丢弃此度量块。
PDV metrics block:
PDV度量块：
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=15 | I |pdvtyp |Rsv| block length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pos PDV Threshold/Peak | Pos PDV Percentile |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neg PDV Threshold/Peak | Neg PDV Percentile |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mean PDV | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=15 | I |pdvtyp |Rsv| block length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pos PDV Threshold/Peak | Pos PDV Percentile |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neg PDV Threshold/Peak | Neg PDV Percentile |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mean PDV | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Report Block Structure
图1：报告块结构
Block type (BT): 8 bits
块类型（BT）：8位
A Packet Delay Variation Metrics Block is identified by the constant 15.
分组延迟变化度量块由常数15标识。
Interval Metric flag (I): 2 bit
间隔度量标志（I）：2位
This field is used to indicate whether the Packet Delay Variation metrics are Sampled, Interval, or Cumulative metrics [MONARCH], that is, whether the reported values apply to the most recent measurement interval duration between successive metrics reports (I=10) (the Interval Duration), or they apply to the accumulation period characteristic of cumulative measurements (I=11) (the Cumulative Duration), or they are a sampled instantaneous value (I=01) (Sampled Value). The value I=00 is reserved and MUST NOT be used. If the value I=00 is received, then the XR block MUST be ignored by the receiver.
该字段用于指示分组延迟变化度量是采样的、间隔的还是累积度量[Monar]，即，报告的值是否应用于连续度量报告之间的最新测量间隔持续时间（I=10）（间隔持续时间），或者它们适用于累积测量的累积周期特征（I=11）（累积持续时间），或者它们是采样瞬时值（I=01）（采样值）。值I=00为保留值，不得使用。如果接收到值I=00，则接收器必须忽略XR块。
Packet Delay Variation Metric Type (pdvtyp): 4 bits
数据包延迟变化度量类型（pdvtyp）：4位
Packet Delay Variation Metric Type is of type enumerated and is interpreted as an unsigned, 4-bit integer. This field is used to identify the Packet Delay Variation Metric Type used in this report block, according to the following code:
数据包延迟变化度量类型为枚举类型，并被解释为无符号4位整数。此字段用于根据以下代码标识此报告块中使用的数据包延迟变化度量类型：
bits 014-011
比特014-011
0: MAPDV2, Clause 6.2.3.2 of [G.1020],
0:MAPDV2，第6.2.3.2条[G.1020]，
1: 2-point PDV, Clause 6.2.4 of [Y.1540].
1:2点PDV，[Y.1540]第6.2.4条。
Rsv: 2 bits
Rsv:2位
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 ignored by the receiver.
此字段保留供将来定义。在没有这种定义的情况下，此字段中的位必须设置为零，并被接收器忽略。
block length: 16 bits
块长度：16位
The length of this report block is in 32-bit words, minus one. For the Packet Delay Variation Metrics Block, the block length is equal to 4.
此报告块的长度为32位字减去1。对于分组延迟变化度量块，块长度等于4。
SSRC of source: 32 bits
源的SSRC：32位
This field is as defined in Section 4.1 of [RFC3611].
该字段的定义见[RFC3611]第4.1节。
Positive PDV Threshold/Peak: 16 bits
正PDV阈值/峰值：16位
This field is associated with the Positive PDV percentile and expressed in milliseconds with numeric format S11:4. The term "Positive" represents that the packets are arriving later than the expected time.
该字段与正PDV百分位数关联，以毫秒为单位，数字格式为S11:4。术语“正”表示分组比预期时间晚到达。
If the measured value is less than -2047.9375 (the value that would be coded as 0x8001), the value 0x8000 SHOULD be reported to indicate an over-range negative measurement. If the measured value is greater than +2047.8125 (the value that would be coded as 0x7FFD), the value 0x7FFE SHOULD be reported to indicate an over-range positive measurement. If the measurement is unavailable, the value 0x7FFF MUST be reported.
如果测量值小于-2047.9375（编码为0x8001的值），则应报告值0x8000以指示超出范围的负测量值。如果测量值大于+2047.8125（将被编码为0x7FFD的值），则应报告值0x7FFE以指示超出范围的正测量。如果测量不可用，则必须报告值0x7FFF。
Positive PDV Percentile: 16 bits
正PDV百分位数：16位
This field indicates the percentages of packets in the RTP stream for which individual packet delays were less than the Positive PDV Threshold. It is expressed in numeric format 8:8 with values from 0 to 100th percentile.
此字段表示RTP流中单个数据包延迟小于正PDV阈值的数据包百分比。它以数字格式8:8表示，数值范围为0到100%。
If the measurement is unavailable, the value 0xFFFF MUST be reported.
如果测量不可用，则必须报告值0xFFFF。
Negative PDV Threshold/Peak: 16 bits
负PDV阈值/峰值：16位
This field is associated with the Negative PDV percentile and expressed in milliseconds with numeric format S11:4. The term "Negative" represents that the packets are arriving earlier than the expected time.
该字段与负PDV百分位数关联，以毫秒为单位，数字格式为S11:4。术语“负”表示分组比预期时间提前到达。
If the measured value is more negative than -2047.9375 (the value that would be coded as 0x8001), the value 0x8000 SHOULD be reported to indicate an over-range negative measurement. If the measured value is more positive than +2047.8125 (the value that would be coded as 0x7FFD), the value 0x7FFE SHOULD be reported to indicate an over-range positive measurement. If the measurement is unavailable, the value 0x7FFF MUST be reported.
如果测量值的负值大于-2047.9375（编码为0x8001的值），则应报告值0x8000，以指示超出范围的负值测量。如果测量值大于+2047.8125（编码为0x7FFD的值），则应报告值0x7FFE，以指示超出范围的正测量。如果测量不可用，则必须报告值0x7FFF。
Negative PDV Percentile: 16 bits
负PDV百分位数：16位
This field indicates the percentages of packets in the RTP stream for which individual packet delays were more than the Negative PDV Threshold. It is expressed in numeric format 8:8 with values from 0 to 100th percentile.
此字段表示RTP流中单个数据包延迟大于负PDV阈值的数据包百分比。它以数字格式8:8表示，数值范围为0到100%。
If the measurement is unavailable, the value 0xFFFF MUST be reported.
如果测量不可用，则必须报告值0xFFFF。
If the PDV Type indicated is 2-point PDV and the Positive and Negative PDV percentiles are set to 100.0, then the Positive and Negative Threshold/Peak PDV values are the peak values measured during the reporting interval (which may be from the start of the call for cumulative reports). In this case, the difference between the Positive and Negative Threshold/Peak values defines the range of 2-point PDV.
如果指示的PDV类型为2点PDV，且正和负PDV百分位数设置为100.0，则正和负阈值/峰值PDV值为报告间隔期间（可能从调用累积报告开始）测量的峰值。在这种情况下，正负阈值/峰值之间的差值定义了两点PDV的范围。
Mean PDV: 16 bits
平均PDV:16位
The mean PDV value of data packets is expressed in milliseconds with Numeric format S11:4 format.
数据包的平均PDV值以毫秒表示，采用数字格式S11:4格式。
For MAPDV2, this value is generated according to Clause 6.2.3.2 of [G.1020]. For interval reports, the MAPDV2 value is reset at the start of the interval.
对于MAPDV2，该值根据[G.1020]第6.2.3.2条生成。对于间隔报告，MAPDV2值在间隔开始时重置。
For 2-point PDV, the value reported is the mean of per-packet 2-point PDV values. This metric indicates the arrival time of the first media packet of the session with respect to the mean of the arrival times of every packet of the session. A single value of the metric (for a single session) may not be useful by itself, but its average over a number of sessions may be useful in diagnosing
对于两点PDV，报告的值是每个数据包两点PDV值的平均值。该度量相对于会话的每个分组的到达时间的平均值指示会话的第一媒体分组的到达时间。度量的单个值（对于单个会话）本身可能没有用处，但其在多个会话上的平均值可能有助于诊断
media delay at session startup. For example, this might occur if media packets are often delayed behind signaling packets due to head-of-line blocking.
会话启动时的媒体延迟。例如，如果由于线路头阻塞，媒体数据包通常延迟在信令数据包之后，则可能发生这种情况。
If the measured value is more negative than -2047.9375 (the value that would be coded as 0x8001), the value 0x8000 SHOULD be reported to indicate an over-range negative measurement. If the measured value is more positive than +2047.8125 (the value that would be coded as 0x7FFD), the value 0x7FFE SHOULD be reported to indicate an over-range positive measurement. If the measurement is unavailable, the value 0x7FFF MUST be reported.
如果测量值的负值大于-2047.9375（编码为0x8001的值），则应报告值0x8000，以指示超出范围的负值测量。如果测量值大于+2047.8125（编码为0x7FFD的值），则应报告值0x7FFE，以指示超出范围的正测量。如果测量不可用，则必须报告值0x7FFF。
Reserved: 16 bits
保留：16位
These bits are reserved for future definition. They MUST be set to zero by the sender and ignored by the receiver.
这些位保留用于将来的定义。发送方必须将它们设置为零，接收方必须忽略它们。
This subsection provides informative guidance on when it might be appropriate to use each of the PDV metric types.
本小节提供了关于何时可能适合使用每种PDV度量类型的信息性指导。
MAPDV2 (Clause 6.2.3.2 of [G.1020]) is the envelope of instantaneous (per-packet) delay when compared to the short-term moving average delay. This metric could be useful in determining residual impairment when an RTP end system uses an adaptive de-jitter buffer that tracks the average delay variation, provided that the averaging behavior of the adaptive algorithm is similar to that of the MAPDV2 algorithm.
MAPDV2（G.1020第6.2.3.2条）是与短期移动平均延迟相比的瞬时（每包）延迟的包络。当RTP终端系统使用跟踪平均延迟变化的自适应去抖动缓冲器时，如果自适应算法的平均行为类似于MAPDV2算法的平均行为，则该度量可用于确定剩余损伤。
2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay variation with respect to a defined reference packet transfer delay. Note that the reference packet is generally selected as the packet with minimum delay based on the most common criterion (see Sections 1 and 5.1 of [RFC5481]). In an RTP context, the two "points" are at the sender (the synchronization source that applies RTP timestamps) and at the receiver. The value of this metric for the packet with index j is identical to the quantity D(i,j) defined in Section 6.4.1 of [RFC3550], and the packet index i should be set equal to the index of the reference packet for the metric in practice. The metric includes the effect of the frequency offsets of clocks in both the sender and receiver end systems, so it is useful mainly in networks where synchronization is distributed. As well as measuring packet delay variation in such networks, it may be used to ensure that synchronization is effective, for example, where the network carries ISDN data traffic over RTP [RFC4040]. The metric is likely to be useful in networks that use fixed de-jitter buffering, because it may be used to determine the length of the required de-jitter buffer, or
2点PDV（Y.1540第6.2.4条）报告相对于定义的参考数据包传输延迟的绝对数据包延迟变化。请注意，参考数据包通常根据最常见的标准（见[RFC5481]第1节和第5.1节）选择为具有最小延迟的数据包。在RTP上下文中，两个“点”分别位于发送方（应用RTP时间戳的同步源）和接收方。索引为j的数据包的该度量值与[RFC3550]第6.4.1节中定义的数量D（i，j）相同，并且数据包索引i应设置为等于实际中该度量的参考数据包的索引。该度量包括发送端和接收端系统中时钟频率偏移的影响，因此它主要在同步分布的网络中有用。除了测量此类网络中的分组延迟变化外，它还可用于确保同步是有效的，例如，当网络通过RTP承载ISDN数据业务时[RFC4040]。该度量可能在使用固定去抖动缓冲的网络中有用，因为它可用于确定所需去抖动缓冲的长度，或
to determine if network performance has deteriorated such that existing de-jitter buffers are too small to accommodate the observed delay variation.
确定网络性能是否已经恶化，以至于现有的去抖动缓冲区太小，无法适应观察到的延迟变化。
(a) To report MAPDV2 [G.1020]:
(a) 报告MAPDV2[G.1020]：
Pos PDV Threshold = 50.0; Pos PDV Percentile = 95.3; Neg PDV
Threshold = 50.0 (note this implies -50 ms); Neg PDV Percentile
= 98.4; PDV type = 0 (MAPDV2)
Pos PDV Threshold = 50.0; Pos PDV Percentile = 95.3; Neg PDV
Threshold = 50.0 (note this implies -50 ms); Neg PDV Percentile
= 98.4; PDV type = 0 (MAPDV2)
causes average MAPDV2 to be reported in the Mean PDV field.
导致在平均PDV字段中报告平均MAPDV2。
Note that implementations either may fix the reported percentile and calculate the associated PDV level or may fix a threshold PDV level and calculate the associated percentile. From a practical implementation perspective, it is simpler to use the second of these approaches (except of course in the extreme case of the 100th percentile).
注意，实施可能会修复报告的百分比并计算相关的PDV水平，或者可能会修复阈值PDV水平并计算相关的百分比。从实际实现的角度来看，使用第二种方法更简单（当然，第100百分位的极端情况除外）。
(b) To report 2-point PDV [Y.1540]:
(b) 报告2点PDV[Y.1540]：
Pos PDV Threshold = 60 (note this implies +60 ms); Pos PDV
Percentile = 96.3; Neg PDV Threshold = 0; Neg PDV Percentile =
0; PDV type = 1 (2-point PDV)
Pos PDV Threshold = 60 (note this implies +60 ms); Pos PDV
Percentile = 96.3; Neg PDV Threshold = 0; Neg PDV Percentile =
0; PDV type = 1 (2-point PDV)
causes 2-point PDV to be reported in the Mean PDV field.
导致在平均PDV字段中报告2点PDV。
2-point PDV, according to [Y.1540] is the difference in delay between the current packet and the referenced packet of the stream. If the sending and receiving clocks are not synchronized, this metric includes the effect of relative timing drift.
根据[Y.1540]，两点PDV是当前数据包和流的参考数据包之间的延迟差。如果发送和接收时钟不同步，则该度量包括相对定时漂移的影响。
[RFC3611] defines the use of the Session Description Protocol (SDP) [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used without prior signaling.
[RFC3611]定义了会话描述协议（SDP）[RFC4566]的使用，用于发送使用XR块的信号。XR块可以在没有事先信令的情况下使用。
This section augments the SDP [RFC4566] attribute "rtcp-xr" defined in [RFC3611] by providing an additional value of "xr-format" to signal the use of the report block defined in this document.
本节增加了[RFC3611]中定义的SDP[RFC4566]属性“rtcp xr”，提供了“xr format”的附加值，以表示使用了本文档中定义的报告块。
xr-format =/ xr-pdv-block
xr format=/xr pdv块
xr-pdv-block = "pkt-dly-var" [ "," pdvtype ] [ "," nspec "," pspec ]
xr pdv block=“pkt dly var”[”，“pdvtype”[”，“nspec”，“pspec]
pdvtype = "pdv=" ( "0" ; MAPDV2 ITU-T G.1020
/ "1" ; 2-point PDV ITU-T Y.1540
/ 1*2DIGIT ) ;Value 2~15 are valid and
;reserved for future use
nspec = ("nthr=" fixpoint) ; negative PDV threshold (ms)
/ ("npc=" fixpoint ) ; negative PDV percentile
pspec = ("pthr=" fixpoint) ; positive PDV threshold (ms)
/ ("ppc=" fixpoint) ; positive PDV percentile
pdvtype = "pdv=" ( "0" ; MAPDV2 ITU-T G.1020
/ "1" ; 2-point PDV ITU-T Y.1540
/ 1*2DIGIT ) ;Value 2~15 are valid and
;reserved for future use
nspec = ("nthr=" fixpoint) ; negative PDV threshold (ms)
/ ("npc=" fixpoint ) ; negative PDV percentile
pspec = ("pthr=" fixpoint) ; positive PDV threshold (ms)
/ ("ppc=" fixpoint) ; positive PDV percentile
fixpoint = 1*DIGIT "." 1*DIGIT ; fixed point decimal
DIGIT = <as defined in Section 3.4 of [RFC5234]>
fixpoint = 1*DIGIT "." 1*DIGIT ; fixed point decimal
DIGIT = <as defined in Section 3.4 of [RFC5234]>
When SDP is used in offer/answer, a system sending SDP may request a specific type of PDV measurement. In addition, they may state a specific percentile or threshold value and expect to receive the corresponding threshold or percentile metric, respectively. The system receiving the SDP SHOULD send the PDV metrics requested, but if the metric is not available, the system receiving the SDP MUST send the metric block with the flag value indicating that the metric is unavailable.
当SDP用于报价/应答时，发送SDP的系统可能会请求特定类型的PDV测量。此外，他们可能会声明特定的百分位或阈值，并期望分别收到相应的阈值或百分位度量。接收SDP的系统应发送所请求的PDV度量，但如果度量不可用，则接收SDP的系统必须发送带有指示度量不可用的标志值的度量块。
New block types for RTCP XR are subject to IANA registration. For general guidelines on IANA considerations for RTCP XR, refer to [RFC3611].
RTCP XR的新块类型需要IANA注册。有关RTCP XR的IANA注意事项的一般指南，请参阅[RFC3611]。
This document assigns the block type value 15 in the IANA "RTCP XR Block Type" registry to the "Packet Delay Variation Metrics Block".
本文档将IANA“RTCP XR block type”注册表中的块类型值15分配给“数据包延迟变化度量块”。
This document also registers a new parameter "pkt-dly-var" in the "RTCP XR SDP Parameters" registry.
本文档还将在“RTCP XR SDP Parameters”注册表中注册一个新参数“pkt dly var”。
The contact information for the registrations is:
注册的联系信息为：
Qin Wu (sunseawq@huawei.com)
秦武(sunseawq@huawei.com)
101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
中国江苏省南京市雨花区软件大道101号210012
This document creates a new registry to be called "RTCP XR PDV block - PDV type" as a sub-registry of the "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry". Policies for this new registry are as follows:
本文档创建了一个名为“RTCP XR PDV块-PDV类型”的新注册表，作为“RTP控制协议扩展报告（RTCP XR）块类型注册表”的子注册表。此新注册表的策略如下：
o The information required to support an assignment is an unambiguous definition of the new metric, covering the base measurements and how they are processed to generate the reported metric. This should include the units of measurement, how values of the metric are reported in the three 16-bit fields "Pos PDV Threshold/Peak", "Neg PDV Threshold/Peak", and "Mean PDV" within the report block, and how the metric uses the two 16-bit fields "Pos PDV Percentile" and "Neg PDV Percentile".
o 支持赋值所需的信息是新度量的明确定义，包括基本度量以及如何处理它们以生成报告的度量。这应包括测量单位、如何在报告块内的三个16位字段“Pos PDV阈值/峰值”、“Neg PDV阈值/峰值”和“平均PDV”中报告度量值，以及度量如何使用两个16位字段“Pos PDV百分位”和“Neg PDV百分位”。
o The review process for the registry is "Specification Required" as described in Section 4.1 of [RFC5226].
o 注册表的审查过程为[RFC5226]第4.1节所述的“所需规范”。
o Entries in the registry are unsigned 4-bit integers. The valid range is 0 to 15 corresponding to the 4-bit field "pdvtyp" in the block. Values are to be recorded in decimal.
o 注册表中的项是无符号4位整数。有效范围为0到15，对应于块中的4位字段“pdvtyp”。数值应以十进制记录。
o Initial assignments are as follows:
o 初步任务如下：
* 0: MAPDV2, Clause 6.2.3.2 of [G.1020],
* 0:MAPDV2，第6.2.3.2条[G.1020]，
* 1: 2-point PDV, Clause 6.2.4 of [Y.1540],
* 1:2点PDV，[Y.1540]第6.2.4条，
* 2-15: Reserved for future use.
* 2-15：保留供将来使用。
It is believed that this proposed RTCP XR block introduces no new security considerations beyond those described in [RFC3611]. This block does not provide per-packet statistics so the risk to confidentiality documented in Section 7, paragraph 3, of [RFC3611] does not apply.
据信，除了[RFC3611]中所述的安全注意事项外，拟议的RTCP XR块未引入任何新的安全注意事项。该块不提供每包统计数据，因此[RFC3611]第7节第3段中记录的保密风险不适用。
Geoff Hunt wrote the initial version of this document.
杰夫·亨特（Geoff Hunt）编写了本文档的初始版本。
The authors gratefully acknowledge reviews and feedback provided by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi Raviraj, Albrecht Schwarz, Tom Taylor, Hideaki Yamada, Jing Zhao, Kevin Gross, Colin Perkins, Charles Eckel, Glen Zorn, Shida Schubert, Benoit Claise, Adrian Farrel, and Pete Resnick.
作者感谢Bruce Adams、Philip Arden、Amit Arora、Bob Biskner、Kevin Connor、Claus Dahm、Randy Ethier、Roni Even、Jim Frauenthal、Albert Higashi、Tom Hock、Shane Holthaus、Paul Jones、Rajesh Kumar、Keith Lantz、Mohamed Mostafa、Amy Pendleton、Colin Perkins、Mike Ramalho、Ravi Raviraj、，阿尔布雷希特·施瓦兹、汤姆·泰勒、山田英代基、赵静、凯文·格罗斯、科林·珀金斯、查尔斯·埃克尔、格伦·佐恩、舒伯特、贝诺特·克莱斯、阿德里安·法雷尔和皮特·雷斯尼克。
[G.1020] ITU-T Rec. G. 1020, "Performance parameter definitions for quality of speech and other voiceband applications utilizing IP networks", July 2006.
[G.1020]ITU-T Rec.G.1020，“利用IP网络的语音质量和其他声带应用的性能参数定义”，2006年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]Friedman，T.，Caceres，R.，和A.Clark，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[RFC4040] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent Call", RFC 4040, April 2005.
[RFC4040]Kreuter，R.，“64 kbit/s透明呼叫的RTP有效负载格式”，RFC 4040，2005年4月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block", RFC 6776, October 2012.
[RFC6776]Clark，A.和Q.Wu，“使用源描述（SDES）项和RTCP扩展报告（XR）块的测量标识和信息报告”，RFC 6776，2012年10月。
[Y.1540] ITU-T Rec. Y.1540, "IP packet transfer and availability performance parameters", November 2007.
[Y.1540]ITU-T Rec.Y.1540，“IP数据包传输和可用性性能参数”，2007年11月。
[MONARCH] Wu, W., Hunt, G., and P. Arden, "Guidelines for Use of the RTP Monitoring Framework", Work in Progress, September 2012.
[Monar]Wu，W.，Hunt，G.，和P.Arden，“RTP监测框架的使用指南”，正在进行的工作，2012年9月。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
[RFC5481]Morton，A.和B.Claise，“数据包延迟变化适用性声明”，RFC 54812009年3月。
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011.
[RFC6390]Clark，A.和B.Claise，“考虑新性能指标开发的指南”，BCP 170，RFC 63902011年10月。
Authors' Addresses
作者地址
Alan Clark Telchemy Incorporated 2905 Premiere Parkway, Suite 280 Duluth, GA 30097 USA
Alan Clark Telchemy Incorporated 2905 Premiere Parkway，美国佐治亚州德卢斯280号套房，邮编30097
EMail: alan.d.clark@telchemy.com
EMail: alan.d.clark@telchemy.com
Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
中国江苏省南京市雨花区华为软件大道101号秦武210012
EMail: sunseawq@huawei.com
EMail: sunseawq@huawei.com