Internet Engineering Task Force (IETF) R. Huang
Request for Comments: 7509 Huawei
Category: Standards Track V. Singh
ISSN: 2070-1721 Aalto University
May 2015
Internet Engineering Task Force (IETF) R. Huang
Request for Comments: 7509 Huawei
Category: Standards Track V. Singh
ISSN: 2070-1721 Aalto University
May 2015
RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics
修复后损失计数指标的RTP控制协议（RTCP）扩展报告（XR）
Abstract
摘要
This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows reporting of a post-repair loss count metric for a range of RTP applications. In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count when needed, so that the RTP sender or a third-party entity is able to evaluate the effectiveness of the repair methods used by the system.
本文档定义了一个RTP控制协议（RTCP）扩展报告（XR）块，该块允许报告一系列RTP应用程序的修复后损失计数指标。此外，此报告块中还引入了另一个度量，即修复损失计数，用于在需要时计算修复前损失计数，以便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/rfc7509.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7509.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Post-Repair Loss Count Metrics Report Block .....................3
3.1. Report Block Structure .....................................4
3.2. Example Usage ..............................................5
4. SDP Signaling ...................................................6
4.1. SDP rtcp-xr-attrib Attribute Extension .....................6
4.2. Offer/Answer Usage .........................................7
5. Security Considerations .........................................7
6. IANA Considerations .............................................7
6.1. New RTCP XR Block Type Value ...............................7
6.2. New RTCP XR SDP Parameter ..................................7
6.3. Contact Information for Registrations ......................7
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................9
Appendix A. Metrics Represented Using the Template from RFC 6390 ..10
Acknowledgments ...................................................11
Authors' Addresses ................................................11
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Post-Repair Loss Count Metrics Report Block .....................3
3.1. Report Block Structure .....................................4
3.2. Example Usage ..............................................5
4. SDP Signaling ...................................................6
4.1. SDP rtcp-xr-attrib Attribute Extension .....................6
4.2. Offer/Answer Usage .........................................7
5. Security Considerations .........................................7
6. IANA Considerations .............................................7
6.1. New RTCP XR Block Type Value ...............................7
6.2. New RTCP XR SDP Parameter ..................................7
6.3. Contact Information for Registrations ......................7
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................9
Appendix A. Metrics Represented Using the Template from RFC 6390 ..10
Acknowledgments ...................................................11
Authors' Addresses ................................................11
RTCP Sender Reports (SRs) / Receiver Reports (RRs) [RFC3550] contain some rough statistics about the data received from the particular source indicated in that block. One of them is the cumulative number of packets lost, which is called the pre-repair loss metric in this document. This metric conveys information regarding the total number of RTP data packets that have been lost since the beginning of the RTP session.
RTCP发送方报告（SRs）/接收方报告（RRs）[RFC3550]包含从该方框中指定的特定来源接收的数据的一些粗略统计信息。其中之一是数据包丢失的累积数量，在本文档中称为修复前丢失度量。此度量传递有关自RTP会话开始以来已丢失的RTP数据包总数的信息。
However, this metric is measured on the media stream before any loss-repair mechanism, e.g., retransmission [RFC4588] or Forward Error Correction (FEC) [RFC5109], is applied. Using a repair mechanism usually results in recovering some or all of the lost packets. The recovery process does not reduce the values reported by the two loss metrics in RTCP RR [RFC3550] -- namely, the fraction lost and the cumulative loss. Hence, the sending endpoint cannot infer the performance of the repair mechanism based on the aforementioned metrics in [RFC3550].
然而，在应用任何丢失修复机制（例如，重传[RFC4588]或前向纠错（FEC）[RFC5109]）之前，在媒体流上测量该度量。使用修复机制通常会恢复部分或全部丢失的数据包。恢复过程不会减少RTCP RR[RFC3550]中两个损失指标报告的值，即损失分数和累积损失。因此，发送端点无法根据[RFC3550]中的上述指标推断修复机制的性能。
Consequently, [RFC5725] specifies a post-repair loss Run-Length Encoding (RLE) XR report block to address this issue. The sending endpoint is able to infer which packets were repaired from the RLE report block, but the reporting overhead for the packet-by-packet report block is higher compared to other report blocks.
因此，[RFC5725]指定修复后丢失游程长度编码（RLE）XR报告块来解决此问题。发送端点能够从RLE报告块推断哪些数据包被修复，但是与其他报告块相比，逐数据包报告块的报告开销更高。
When applications use multiple XR blocks, the endpoints may require more concise reporting to save bandwidth. This document defines a new XR block type to augment those defined in [RFC3611] and complement the report block defined in [RFC5725] for use in a range of RTP applications. This new block type reports the post-repair loss count metric, which records the number of primary source RTP packets that are still lost after applying one or more loss-repair mechanisms. In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count during this range, so that the RTP sender or a third-party entity is able to evaluate the effectiveness of the repair methods used by the system. The metrics defined in this document are packet level rather than slice/picture level; this means the partial recovery of a packet will not be regarded as a repaired packet.
当应用程序使用多个XR块时，端点可能需要更简洁的报告以节省带宽。本文档定义了一种新的XR块类型，以扩充[RFC3611]中定义的XR块类型，并补充[RFC5725]中定义的报告块，以便在一系列RTP应用程序中使用。此新块类型报告修复后丢失计数度量，该度量记录应用一个或多个丢失修复机制后仍丢失的主要源RTP数据包的数量。此外，此报告块中还引入了另一个度量，即修复损失计数，用于计算此范围内的修复前损失计数，以便RTP发送方或第三方实体能够评估系统使用的修复方法的有效性。本文件中定义的度量是数据包级别，而不是切片/图片级别；这意味着数据包的部分恢复将不会被视为已修复的数据包。
The metrics defined in this document belong to the class of transport-related metrics defined in [RFC6792] and are specified in accordance with the guidelines in [RFC6390] and [RFC6792]. These metrics are applicable to any RTP application, especially those that use loss-repair mechanisms.
本文件中定义的指标属于[RFC6792]中定义的运输相关指标类别，并根据[RFC6390]和[RFC6792]中的指南规定。这些指标适用于任何RTP应用程序，特别是那些使用丢失修复机制的应用程序。
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
primary source RTP packet: The original RTP packet sent from the RTP sender for the first time. A lost primary source RTP packet may be repaired by some other RTP packets used in repair mechanisms like FEC or retransmission.
主源RTP数据包：第一次从RTP发送方发送的原始RTP数据包。丢失的主要源RTP分组可以由在诸如FEC或重传之类的修复机制中使用的一些其他RTP分组来修复。
This block reports the number of packets lost after applying repair mechanisms (e.g., FEC). It complements the RTCP XR metrics defined in [RFC5725]. As noted in [RFC5725], ambiguity may occur when comparing this metric with a pre-repair loss metric reported in an RTCP SR/RR, i.e., some packets were not repaired in the current RTCP interval, but they may be repaired later. Therefore, this block uses a begin sequence number and an end sequence number to explicitly indicate the actual sequence number range reported by this RTCP XR. Accordingly, only packets that have no further chance of being repaired and that have been repaired are included in this report block.
此块报告应用修复机制（例如，FEC）后丢失的数据包数。它补充了[RFC5725]中定义的RTCP XR指标。如[RFC5725]中所述，当将该度量与RTCP SR/RR中报告的修复前丢失度量进行比较时，可能会出现歧义，即，某些数据包在当前RTCP间隔内未修复，但可以稍后修复。因此，此块使用开始序列号和结束序列号明确指示此RTCP XR报告的实际序列号范围。因此，该报告块中仅包括没有进一步被修复机会且已被修复的数据包。
The Post-Repair Loss Count Metrics Report Block has the following format:
修复后损失计数度量报告块的格式如下：
0 1 2 3 4
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=33 | Reserved | Block length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Post-repair loss count | Repaired loss count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=33 | Reserved | Block length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Post-repair loss count | Repaired loss count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Block Type (BT): 8 bits
块类型（BT）：8位
A Post-Repair Loss Count Metrics Report Block is identified by the constant 33.
修复后损失计数度量报告块由常量33标识。
Reserved: 8 bits
保留：8位
These bits are reserved for future use. They MUST be set to zero by senders and ignored by receivers (see Section 4.2 of [RFC6709]).
这些位留作将来使用。发送方必须将其设置为零，接收方必须忽略（见[RFC6709]第4.2节）。
Block length: 16 bits
块长度：16位
This field is in accordance with the definition in [RFC3611]. In this report block, it MUST be set to 4. The block MUST be discarded if the block length is set to a different value.
该字段符合[RFC3611]中的定义。在此报告块中，必须将其设置为4。如果块长度设置为不同的值，则必须丢弃该块。
SSRC of source: 32 bits
源的SSRC：32位
As defined in Section 4.1 of [RFC3611].
如[RFC3611]第4.1节所定义。
begin_seq: 16 bits
开始顺序：16位
The first sequence number that this block reports on. It can remain fixed when calculating metrics over several RTCP reporting intervals.
此块报告的第一个序列号。在多个RTCP报告间隔内计算指标时，它可以保持固定。
end_seq: 16 bits
结束顺序：16位
The last sequence number that this block reports on plus one.
此块报告的最后一个序列号加1。
Post-repair loss count: 16 bits
修复后损失计数：16位
Total number of packets finally lost after applying one or more loss-repair methods, e.g., FEC and/or retransmission, during the actual sequence number range indicated by begin_seq and end_seq. This metric MUST NOT count the lost packets for which repair might still be possible. Note that this metric MUST measure only primary source RTP packets.
在begin_seq和end_seq指示的实际序列号范围内，应用一种或多种丢失修复方法（例如FEC和/或重传）后最终丢失的数据包总数。此指标不得计算仍有可能修复的丢失数据包。请注意，此度量必须仅测量主源RTP数据包。
Repaired loss count: 16 bits
修复的丢失计数：16位
Total number of packets fully repaired after applying one or more loss-repair methods, e.g., FEC and/or retransmission, during the actual sequence number range indicated by begin_seq and end_seq. Note that this metric MUST measure only primary source RTP packets.
在begin_seq和end_seq指示的实际序列号范围内，应用一种或多种丢失修复方法（例如FEC和/或重传）后完全修复的数据包总数。请注意，此度量必须仅测量主源RTP数据包。
The metrics defined in this report block are all measured at the RTP receiver. However, the receiving endpoint can report the metrics in two different ways:
此报告块中定义的度量都是在RTP接收器处测量的。但是，接收端点可以通过两种不同的方式报告度量：
1) Cumulative report
1) 累积报告
In this case, implementations may set begin_seq to the first packet in the RTP session, and it will remain fixed across all reports. Hence, the "Post-repair loss count" and "Repaired loss count", respectively, will correspond to "Cumulative post-repair loss count" and "Cumulative repaired loss count" in this case. These cumulative metrics when combined with the cumulative loss metrics reported in an RTCP RR (pre-repair) assist in calculating the "Still-to-be-repaired lost packets":
在这种情况下，实现可以将begin_seq设置为RTP会话中的第一个数据包，并且它将在所有报告中保持固定。因此，在这种情况下，“修理后损失计数”和“修理后损失计数”分别对应于“修理后累积损失计数”和“修理后累积损失计数”。这些累积度量与RTCP RR（预修复）中报告的累积丢失度量相结合，有助于计算“仍需修复的丢失数据包”：
Still-to-be-repaired lost packets = Cumulative number of packets lost - Cumulative post-repair loss count - Cumulative repaired loss count
仍需修复的丢失数据包=累计丢失数据包数-累计修复后丢失计数-累计修复丢失计数
2) Interval report
2) 间隔报告
Some implementations may align the begin_seq and end_seq number with the highest sequence numbers of consecutive RTCP RRs (RTCP interval). This is NOT RECOMMENDED as packets that are not yet repaired in this current RTCP interval and may be repaired in the subsequent intervals will not be reported. An interval report is illustrated in the following example:
一些实现可能会将开始顺序号和结束顺序号与连续RTCP RRs（RTCP间隔）的最高序列号对齐。不建议这样做，因为在当前RTCP间隔内尚未修复且可能在后续间隔内修复的数据包将不会被报告。间隔报告如以下示例所示：
Interval A: The extended highest sequence number received in RTCP RR is 20. Begin_seq is 10 and end_seq is 20.
间隔A：RTCP RR中接收到的扩展最高序列号为20。开始顺序为10，结束顺序为20。
Interval B: The extended highest sequence number received in RTCP RR is 30. Begin_seq is 20 and end_seq is 30.
间隔B：RTCP RR中接收到的扩展最高序列号为30。开始顺序为20，结束顺序为30。
If packets 17 and 19 are lost and not yet repaired in interval A and subsequently repaired in interval B, they will not be reported because their sequence numbers do not belong in interval B. Therefore, if implementations want these packets to be reported as repaired, they MUST NOT align the begin_seq and end_seq to the RTCP intervals.
如果数据包17和19丢失，且在间隔A中尚未修复，随后在间隔B中修复，则不会报告它们，因为它们的序列号不属于间隔B。因此，如果实现希望将这些数据包报告为已修复，则它们不得将开始顺序和结束顺序与RTCP间隔对齐。
Alternatively, implementations may choose the begin_seq and end_seq numbers that cover several RTCP intervals. Additionally, the reported range of sequence numbers may overlap with the previous report blocks, so that the packets that were not yet repaired in one interval, but were subsequently repaired or deemed unrepairable, were reported in subsequent intervals.
或者，实施可以选择覆盖多个RTCP间隔的开始顺序和结束顺序编号。此外，所报告的序列号范围可与先前的报告块重叠，以便在一个间隔中尚未修复但随后被修复或被认为不可修复的分组在随后的间隔中被报告。
In this case, the "Cumulative number of packets lost" cannot be easily compared with the post-repair metrics. However, the sending endpoint can calculate the efficiency of the error resilience algorithm using the post-repair and repaired loss count, respectively.
在这种情况下，“累计丢失的数据包数”不能轻易与修复后指标进行比较。然而，发送端点可以分别使用修复后和修复损失计数计算错误恢复算法的效率。
[RFC3611] defines the use of SDP (Session Description Protocol) for signaling the use of RTCP XR blocks. However, XR blocks MAY be used without prior signaling (see Section 5 of [RFC3611]).
[RFC3611]定义了SDP（会话描述协议）的使用，用于发送使用RTCP XR块的信号。但是，可以在没有事先信令的情况下使用XR块（参见[RFC3611]第5节）。
This session augments the SDP attribute "rtcp-xr" defined in Section 5.1 of [RFC3611] by providing an additional value of "xr-format" to signal the use of the report block defined in this document. The ABNF [RFC5234] syntax is as follows.
此会话通过提供附加值“xr format”来表示使用本文档中定义的报告块，从而增强[RFC3611]第5.1节中定义的SDP属性“rtcp xr”。ABNF[RFC5234]语法如下所示。
xr-format =/ xr-prlr-block
xr format=/xr prlr块
xr-prlr-block = "post-repair-loss-count"
xr prlr block=“维修后损失计数”
When SDP is used in offer/answer context, the SDP Offer/Answer usage defined in [RFC3611] for the unilateral "rtcp-xr" attribute parameters applies. For detailed usage of Offer/Answer for unilateral parameters, refer to Section 5.2 of [RFC3611].
在提供/应答上下文中使用SDP时，[RFC3611]中为单边“rtcp xr”属性参数定义的SDP提供/应答用法适用。有关单边参数的报价/应答的详细用法，请参阅[RFC3611]第5.2节。
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段中记录的保密风险不适用。
An attacker may put incorrect information in the Post-Repair Loss Count reports, which will affect the performance of loss-repair mechanisms. Implementers should consider the guidance in [RFC7202] for using appropriate security mechanisms, i.e., where security is a concern, the implementation should apply encryption and authentication to the report block. For example, this can be achieved by using the AVPF profile together with the Secure RTP profile as defined in [RFC3711]; an appropriate combination of the two profiles (an "SAVPF") is specified in [RFC5124]. However, other mechanisms also exist (documented in [RFC7201]) and might be more suitable.
攻击者可能在修复后损失计数报告中输入错误信息，这将影响损失修复机制的性能。实现者应该考虑[RCF7202]中使用适当的安全机制的指导，即，在安全性方面，实现应该对报告块应用加密和认证。例如，这可以通过将AVPF配置文件与[RFC3711]中定义的安全RTP配置文件一起使用来实现；[RFC5124]中规定了两个配置文件的适当组合（“SAVPF”）。但是，也存在其他机制（见[RFC7201]），可能更合适。
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 33 in the IANA "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry" to the "Post-Repair Loss Count Metrics Report Block".
本文档将IANA“RTP控制协议扩展报告（RTCP XR）块类型注册表”中的块类型值33分配给“修复后损失计数度量报告块”。
This document also registers a new parameter "post-repair-loss-count" in the "RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry".
本文档还将在“RTP控制协议扩展报告（RTCP XR）会话描述协议（SDP）参数注册表”中注册一个新参数“修复后损失计数”。
The contact information for the registrations is:
RAI Area Directors <rai-ads@ietf.org>
The contact information for the registrations is:
RAI Area Directors <rai-ads@ietf.org>
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<http://www.rfc-editor.org/info/rfc3550>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <http://www.rfc-editor.org/info/rfc3611>.
[RFC3611]Friedman，T.，Ed.，Caceres，R.，Ed.，和A.Clark，Ed.，“RTP控制协议扩展报告（RTCP XR）”，RFC 3611，DOI 10.17487/RFC36112003年11月<http://www.rfc-editor.org/info/rfc3611>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 3711，DOI 10.17487/RFC3711，2004年3月<http://www.rfc-editor.org/info/rfc3711>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124]Ott，J.和E.Carrara，“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”，RFC 5124DOI 10.17487/RFC5124，2008年2月<http://www.rfc-editor.org/info/rfc5124>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February 2010, <http://www.rfc-editor.org/info/rfc5725>.
[RFC5725]Begen，A.，Hsu，D.，和M.Lague，“RTP控制协议（RTCP）扩展报告（XRs）的修复后损失RLE报告块类型”，RFC 5725，DOI 10.17487/RFC5725，2010年2月<http://www.rfc-editor.org/info/rfc5725>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <http://www.rfc-editor.org/info/rfc4588>.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，DOI 10.17487/RFC4588，2006年7月<http://www.rfc-editor.org/info/rfc4588>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5109]Li，A.，Ed.“通用前向纠错的RTP有效载荷格式”，RFC 5109，DOI 10.17487/RFC5109，2007年12月<http://www.rfc-editor.org/info/rfc5109>.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <http://www.rfc-editor.org/info/rfc6390>.
[RFC6390]Clark，A.和B.Claise，“考虑新绩效指标开发的指南”，BCP 170，RFC 6390，DOI 10.17487/RFC6390，2011年10月<http://www.rfc-editor.org/info/rfc6390>.
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>.
[RFC6709]Carpenter，B.，Aboba，B.，Ed.，和S.Cheshire，“协议扩展的设计考虑”，RFC 6709，DOI 10.17487/RFC6709，2012年9月<http://www.rfc-editor.org/info/rfc6709>.
[RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use of the RTP Monitoring Framework", RFC 6792, DOI 10.17487/RFC6792, November 2012, <http://www.rfc-editor.org/info/rfc6792>.
[RFC6792]Wu，Q.，Ed.，Hunt，G.，和P.Arden，“RTP监测框架的使用指南”，RFC 6792，DOI 10.17487/RFC6792，2012年11月<http://www.rfc-editor.org/info/rfc6792>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201]Westerlund，M.和C.Perkins，“保护RTP会话的选项”，RFC 7201，DOI 10.17487/RFC7201，2014年4月<http://www.rfc-editor.org/info/rfc7201>.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <http://www.rfc-editor.org/info/rfc7202>.
[RFC7202]Perkins，C.和M.Westerlund，“保护RTP框架：为什么RTP不要求单一媒体安全解决方案”，RFC 7202，DOI 10.17487/RFC7202，2014年4月<http://www.rfc-editor.org/info/rfc7202>.
a. Post-Repair RTP Packet Loss Count Metric
a. 修复后RTP数据包丢失计数度量
* Metric Name: Post-Repair RTP Packet Loss Count Metric.
* 度量名称：修复后RTP数据包丢失计数度量。
* Metric Description: Total number of RTP packets still lost after loss-repair methods are applied.
* 度量说明：应用丢失修复方法后仍丢失的RTP数据包总数。
* Method of Measurement or Calculation: See the "Post-repair loss count" definition in Section 3.1. It is directly measured and must be measured for the primary source RTP packets with no further chance of repair.
* 测量或计算方法：参见第3.1节中的“维修后损失计数”定义。它是直接测量的，并且必须针对主要源RTP数据包进行测量，没有进一步的修复机会。
* Units of Measurement: This metric is expressed as a 16-bit unsigned integer value giving the number of RTP packets.
* 度量单位：此度量表示为16位无符号整数值，给出RTP数据包的数量。
* Measurement Point(s) with Potential Measurement Domain: It is measured at the receiving end of the RTP stream.
* 具有潜在测量域的测量点：在RTP流的接收端测量。
* Measurement Timing: This metric relies on the sequence number interval to determine measurement timing. See the Cumulative and Interval reports defined in Section 3.2.
* 测量时间：该度量依赖于序列号间隔来确定测量时间。参见第3.2节中定义的累积和间隔报告。
* Use and Applications: These metrics are applicable to any RTP application, especially those that use loss-repair mechanisms. See Section 1 for details.
* 使用和应用：这些指标适用于任何RTP应用程序，特别是那些使用损失修复机制的应用程序。详情见第1节。
* Reporting Model: See RFC 3611.
* 报告模式：见RFC 3611。
b. Repaired RTP Packet Loss Count Metric
b. 修复的RTP数据包丢失计数度量
* Metric Name: Repaired RTP Packet Count Metric.
* 度量名称：修复的RTP数据包计数度量。
* Metric Description: The number of RTP packets lost but repaired after applying loss-repair methods.
* 度量说明：应用丢失修复方法后丢失但修复的RTP数据包数。
* Method of Measurement or Calculation: See the "Repaired loss count" in Section 3.1. It is directly measured and must be measured for the primary source RTP packets with no further chance of repair.
* 测量或计算方法：见第3.1节中的“修复损失计数”。它是直接测量的，并且必须针对主要源RTP数据包进行测量，没有进一步的修复机会。
* Units of Measurement: This metric is expressed as a 16-bit unsigned integer value giving the number of RTP packets.
* 度量单位：此度量表示为16位无符号整数值，给出RTP数据包的数量。
* Measurement Point(s) with Potential Measurement Domain: It is measured at the receiving end of the RTP stream.
* 具有潜在测量域的测量点：在RTP流的接收端测量。
* Measurement Timing: This metric relies on the sequence number interval to determine measurement timing. See the Cumulative and Interval reports defined in Section 3.2.
* 测量时间：该度量依赖于序列号间隔来确定测量时间。参见第3.2节中定义的累积和间隔报告。
* Use and Applications: These metrics are applicable to any RTP application, especially those that use loss-repair mechanisms. See Section 1 for details.
* 使用和应用：这些指标适用于任何RTP应用程序，特别是那些使用损失修复机制的应用程序。详情见第1节。
* Reporting Model: See RFC 3611.
* 报告模式：见RFC 3611。
Acknowledgments
致谢
The authors would like to thank Roni Even, Colin Perkins, and Qin Wu for giving valuable comments and suggestions.
作者要感谢Roni Even、Colin Perkins和秦武提供了宝贵的意见和建议。
Authors' Addresses
作者地址
Rachel Huang Huawei 101 Software Avenue, Yuhua District Nanjing 210012 China
中国南京市雨花区华为软件大道101号，邮编：210012
EMail: rachel.huang@huawei.com
EMail: rachel.huang@huawei.com
Varun Singh Aalto University School of Electrical Engineering Otakaari 5 A Espoo, FIN 02150 Finland
瓦伦·辛格·阿尔托大学电气工程学院奥塔卡里5 A埃斯波，芬兰02150
EMail: varun@comnet.tkk.fi
URI: http://www.netlab.tkk.fi/~varun/
EMail: varun@comnet.tkk.fi
URI: http://www.netlab.tkk.fi/~varun/