Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 5725 D. Hsu
Category: Standards Track M. Lague
ISSN: 2070-1721 Cisco
February 2010
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 5725 D. Hsu
Category: Standards Track M. Lague
ISSN: 2070-1721 Cisco
February 2010
Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)
RTP控制协议（RTCP）扩展报告（XRs）的修复后损失RLE报告块类型
Abstract
摘要
This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss-repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE report in the Session Description Protocol (SDP).
本文档在RTP控制协议（RTCP）扩展报告（XRs）框架内定义了一种新的报告块类型。最初的XR报告块类型之一是丢失运行长度编码（RLE）报告块。此报告传达有关在传输报告之前的RTCP间隔期间发生的单个实时传输协议（RTP）数据包接收和丢失事件的信息。新报告称为修复后丢失RLE报告，其中包含关于在应用所有丢失修复方法后仍然丢失的数据包的信息。通过比较丢失修复完成前后的RTP数据包接收/丢失，可以以聚合方式确定丢失修复方法的有效性。本文档还定义了会话描述协议（SDP）中修复后丢失RLE报告的信令。
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/rfc5725.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5725.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 4
3. Post-Repair Loss RLE Report Block . . . . . . . . . . . . . . . 4
4. Session Description Protocol Signaling . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 4
3. Post-Repair Loss RLE Report Block . . . . . . . . . . . . . . . 4
4. Session Description Protocol Signaling . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
The RTP Control Protocol (RTCP) is the out-of-band control protocol for applications that are using the Real-time Transport Protocol (RTP) for media delivery and communications [RFC3550]. RTCP allows RTP entities to monitor data delivery and provides them minimal control functionality via sender and receiver reports as well as other control packets. [RFC3611] expands the RTCP functionality further by introducing the RTCP Extended Reports (XRs).
RTP控制协议（RTCP）是用于使用实时传输协议（RTP）进行媒体传输和通信的应用程序的带外控制协议[RFC3550]。RTCP允许RTP实体监控数据传输，并通过发送方和接收方报告以及其他控制数据包为其提供最低限度的控制功能。[RFC3611]通过引入RTCP扩展报告（XRs），进一步扩展了RTCP功能。
One of the initial XR report block types defined in [RFC3611] is the Loss Run Length Encoding (RLE) Report Block. This report conveys information regarding the individual RTP packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. However, the Loss RLE in an RTCP XR report is usually collected only on the primary source stream before any loss-repair method is applied. Once one or more loss-repair methods, e.g., Forward Error Correction (FEC) [RFC5109] and/or retransmission [RFC4588], are applied, some or all of the lost packets on the primary source stream may be recovered. However, the pre-repair Loss RLE cannot indicate which source packets were recovered and which are still missing. Thus, the pre-repair Loss RLE cannot specify how well the loss repair performed.
[RFC3611]中定义的初始XR报告块类型之一是丢失行程编码（RLE）报告块。此报告传达有关在传输报告之前的RTCP间隔期间发生的单个RTP数据包接收和丢失事件的信息。但是，RTCP XR报告中的丢失RLE通常仅在应用任何丢失修复方法之前在主源流上收集。一旦应用了一个或多个丢失修复方法，例如前向纠错（FEC）[RFC5109]和/或重传[RFC4588]，则可恢复主源流上的部分或全部丢失分组。然而，修复前丢失RLE不能指示哪些源数据包已恢复，哪些仍然丢失。因此，修复前损失RLE无法指定损失修复的执行情况。
This issue can be addressed by generating an additional report block (within the same or a different RTCP XR report), which reflects the packet receipt/loss events after all loss-repair methods are applied. This report block, which we refer to as the post-repair Loss RLE, indicates the remaining missing, i.e., unrepairable, source packets. When the pre-repair and post-repair Loss RLEs are compared, the RTP sender or another third-party entity can evaluate the effectiveness of the loss-repair methods in an aggregated fashion. To avoid any ambiguity in the evaluation, it is RECOMMENDED that the post-repair Loss RLE be generated for the source packets that have no further chance of being repaired. If the loss-repair method(s) may still recover one or more missing source packets, the post-repair Loss RLE SHOULD NOT be sent until the loss-recovery process has been completed. However, a potential ambiguity may result from sequence-number wrapping in the primary source stream. Thus, the Post-repair Loss RLE reports may not be delayed arbitrarily. In case of an ambiguity in the incoming reports, it is the sender's or the monitoring entity's responsibility to understand which packets the Post-repair Loss RLE report is related to.
可以通过生成附加报告块（在相同或不同的RTCP XR报告中）来解决此问题，该报告块反映应用所有丢失修复方法后的数据包接收/丢失事件。此报告块（我们称之为修复后丢失RLE）指示剩余的丢失源数据包，即不可修复的源数据包。当比较修复前和修复后的损失RLE时，RTP发送方或其他第三方实体可以以聚合方式评估损失修复方法的有效性。为了避免评估中的任何歧义，建议为没有进一步修复机会的源分组生成修复后丢失RLE。如果丢失修复方法仍然可以恢复一个或多个丢失的源数据包，则在丢失恢复过程完成之前，不应发送修复后丢失RLE。然而，在主要源流中的序列号包装可能导致潜在的歧义。因此，维修后损失RLE报告不得任意延迟。如果传入报告中存在歧义，发送方或监控实体有责任了解修复后丢失RLE报告与哪些数据包相关。
Similar to the pre-repair Loss RLE, the post-repair Loss RLE conveys the receipt/loss events at the packet level and considers partially repaired packets as unrepaired. Thus, the methods that can partially recover the missing data SHOULD NOT be evaluated based on the
与修复前丢失RLE类似，修复后丢失RLE在分组级别传递接收/丢失事件，并将部分修复的分组视为未修复的分组。因此，可以部分恢复丢失数据的方法不应基于
information provided by the Post-repair Loss RLE reports since such information may underestimate the effectiveness of such methods.
维修后损失RLE报告提供的信息，因为此类信息可能低估此类方法的有效性。
Note that the idea of using pre-repair and post-repair Loss RLEs can be further extended when multiple sequential loss-repair methods are applied to the primary source stream. Reporting the Loss RLEs before and after each loss-repair method can provide specific information about the individual performances of these methods. However, it can be a difficult task to quantify the specific contribution made by each loss-repair method in hybrid systems, where different methods collectively work together to repair the lost source packets. Thus, in this specification we only consider reporting the Loss RLE after all loss-repair methods have been applied.
注意，当对主要源流应用多个顺序损失修复方法时，可以进一步扩展使用修复前和修复后损失rle的思想。报告每种损失修复方法前后的损失RLE可以提供有关这些方法各自性能的具体信息。然而，量化混合系统中每种丢失修复方法的具体贡献可能是一项困难的任务，在混合系统中，不同的方法共同工作来修复丢失的源数据包。因此，在本规范中，我们只考虑在所有的损失修复方法已经应用之后报告损失RLE。
This document registers a new report block type to cover the post-repair Loss RLE within the framework of RTCP XR. Applications that are employing one or more loss-repair methods MAY use Post-repair Loss RLE reports for every packet they receive or for a set of specific packets they have received. In other words, the coverage of the post-repair Loss RLEs may or may not be contiguous.
本文档注册了一种新的报告块类型，以涵盖RTCP XR框架内的修复后损失RLE。采用一种或多种丢失修复方法的应用程序可以对其接收的每个分组或其接收的一组特定分组使用修复后丢失RLE报告。换句话说，修复后损失RLE的覆盖范围可能是连续的，也可能不是连续的。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The Post-repair Loss RLE Report Block is similar to the existing Loss RLE Report Block defined in [RFC3611]. The report format is shown in Figure 1. Using the same structure for reporting both pre-repair and post-repair Loss RLEs allows the implementations to compare the Loss RLEs very efficiently.
修复后损失RLE报告块类似于[RFC3611]中定义的现有损失RLE报告块。报告格式如图1所示。使用相同的结构来报告修复前和修复后的损失RLE，允许实现非常有效地比较损失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=10 | 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=10 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format for the Post-repair Loss RLE Report Block
图1：修复后损失RLE报告块的格式
o block type (BT): 8 bits A Post-repair Loss RLE Report Block is identified by the constant 10.
o 块类型（BT）：8位修复后损失RLE报告块由常量10标识。
o 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.
o rsvd.：4位此字段保留供将来定义。在没有这种定义的情况下，此字段中的位必须设置为零，并且必须被接收器忽略。
o 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 by this block. A value of 0 indicates that there is no thinning and all packets are reported. The maximum thinning is one packet in every 32,768 (amounting to two packets within each 16-bit sequence space).
o 细化（T）：4位序列号空间上执行的细化量。此块仅报告序列号为0 mod 2^T的数据包。值为0表示没有细化，并且报告所有数据包。最大细化是每32768中有一个分组（相当于每16位序列空间中有两个分组）。
If thinning is desired, it is RECOMMENDED to use the same thinning value in the Pre-repair and Post-repair Loss RLE reports. This will allow easier report processing and correlation. However, based on the specific needs of the application or the monitoring entity, different values of thinning MAY be used for Pre-repair and Post-repair Loss RLE reports.
如果需要细化，建议在维修前和维修后损失RLE报告中使用相同的细化值。这将使报告处理和关联更加容易。然而，根据应用程序或监控实体的特定需求，不同的细化值可用于修复前和修复后损失RLE报告。
o block length: 16 bits The length of this report block, including the header, in 32-bit words minus one.
o 块长度：16位此报告块的长度，包括标题，以32位字减去1表示。
o SSRC of source: 32 bits The SSRC of the RTP data packet source being reported upon by this report block.
o 源SSRC：32位此报告块报告的RTP数据包源的SSRC。
o begin_seq: 16 bits The first sequence number that this block reports on.
o begin_seq:16位此块报告的第一个序列号。
o end_seq: 16 bits The last sequence number that this block reports on plus one.
o end_seq:16位此块报告的最后一个序列号加1。
o chunk i: 16 bits There are three chunk types: run length, bit vector, and terminating null. These are defined in Section 4 of [RFC3611]. 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.
o 块i:16位有三种块类型：运行长度、位向量和终止null。这些在[RFC3611]第4节中定义。如果区块全为零，则它是一个终止的空区块。否则，块的最左边的位确定其类型：0表示游程长度，1表示位向量。
Note that the sequence numbers that are included in the report refer to the primary source stream.
请注意，报告中包含的序列号指的是主源流。
When using Post-repair Loss RLE reports, the amount of bandwidth consumed by the detailed reports should be considered carefully. The bandwidth usage rules, as they are described in [RFC3611], apply to Post-repair Loss RLE reports as well.
使用修复后损失RLE报告时，应仔细考虑详细报告消耗的带宽量。[RFC3611]中描述的带宽使用规则也适用于修复后损失RLE报告。
A new parameter is defined for the Post-repair Loss RLE Report Block to be used with Session Description Protocol (SDP) [RFC4566] using the Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the following syntax within the "rtcp-xr" attribute [RFC3611]:
为修复后丢失RLE报告块定义了一个新参数，该报告块将与会话描述协议（SDP）[RFC4566]一起使用，该协议使用了扩展的Backus Naur表单（ABNF）[RFC5234]。它在“rtcp xr”属性[RFC3611]中具有以下语法：
pkt-loss-rle-post = "post-repair-loss-rle" ["=" max-size]
pkt损耗rle post=“修复后损耗rle”[“=”最大尺寸]
max-size = 1*DIGIT ; maximum block size in octets
max-size = 1*DIGIT ; maximum block size in octets
Refer to Section 5.1 of [RFC3611] for a detailed description and the full syntax of the "rtcp-xr" attribute. The "pkt-loss-rle-post" parameter is compatible with the definition of "format-ext" in the "rtcp-xr" attribute.
有关“rtcp xr”属性的详细说明和完整语法，请参阅[RFC3611]的第5.1节。“pkt loss rle post”参数与“rtcp xr”属性中“格式ext”的定义兼容。
The security considerations of [RFC3611] apply in this document as well. Additional security considerations are briefly mentioned below.
[RFC3611]的安全注意事项也适用于本文件。下文简要介绍了其他安全注意事项。
An attacker who monitors the regular Pre-repair Loss RLE reports sent by a group of receivers in the same multicast distribution network may infer the network characteristics (Multicast Inference of Network Characteristics). However, monitoring the Post-repair Loss RLE reports will not reveal any further information about the network. Without the regular Pre-repair Loss RLE reports, the Post-repair ones will not be any use to attackers. Even when used with the regular Pre-repair Loss RLE reports, the Post-repair Loss RLE reports only reveal the effectiveness of the repair process. However, this does not enable any new attacks, nor does it provide information to an attacker that could not be similarly obtained by watching the RTP packets fly by himself, performing the repair algorithms and computing the desired output.
监视由同一多播分发网络中的一组接收器发送的常规修复前丢失RLE报告的攻击者可以推断网络特征（网络特征的多播推断）。但是，监测修复后损失RLE报告不会透露任何有关网络的进一步信息。如果没有定期的修复前损失RLE报告，修复后的报告对攻击者将没有任何用处。即使与常规的维修前损失RLE报告一起使用，维修后损失RLE报告也只能显示维修过程的有效性。但是，这不会启用任何新的攻击，也不会向攻击者提供通过观察RTP数据包自行飞行、执行修复算法和计算所需输出无法获得的信息。
An attacker may interfere with the repair process for an RTP stream. In that case, if the attacker is able to see the post-repair Loss RLEs, the attacker may infer whether or not the attack is effective. If not, the attacker may continue attacking or alter the attack. In practice, however, this does not pose a security risk.
攻击者可能会干扰RTP流的修复过程。在这种情况下，如果攻击者能够看到修复后的损失RLE，则攻击者可以推断攻击是否有效。否则，攻击者可能会继续攻击或更改攻击。然而，在实践中，这并不构成安全风险。
An attacker may put incorrect information in the regular Pre-repair and Post-repair Loss RLE reports such that it impacts the proactive decisions made by the sender in the repair process or the reactive decisions when responding to the feedback messages coming from the receiver. A sender application should be aware of such risks and should take the necessary precautions to minimize the chances for (or, better, eliminate) such attacks.
攻击者可能会在常规的修复前和修复后损失RLE报告中输入错误信息，从而影响发送方在修复过程中做出的主动决策或响应接收方反馈消息时做出的反应性决策。发送方应用程序应意识到此类风险，并应采取必要的预防措施，以尽量减少（或更好地消除）此类攻击的机会。
Similar to other RTCP XR reports, the Post-repair Loss RLE reports MAY be protected by using the Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) [RFC3711].
与其他RTCP XR报告类似，修复后损失RLE报告可通过使用安全RTP（SRTP）和安全RTP控制协议（SRTCP）[RFC3711]进行保护。
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 10 in the RTCP XR Block Type Registry to "Post-repair Loss RLE Report Block". This document also registers the SDP [RFC4566] parameter "post-repair-loss-rle" for the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry.
本文档将RTCP XR块类型注册表中的块类型值10指定给“修复后损失RLE报告块”。本文档还为rtcp xr SDP参数注册表中的“rtcp xr”属性注册SDP[RFC4566]参数“修复后丢失rle”。
The contact information for the registrations is:
注册的联系信息为：
Ali Begen abegen@cisco.com
阿里出生abegen@cisco.com
170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
The authors would like to thank the members of the VQE Team at Cisco and Colin Perkins for their inputs and suggestions.
作者要感谢Cisco和Colin Perkins的VQE团队成员的投入和建议。
[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月。
[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月。
[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月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，2006年7月。
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
[RFC5109]Li，A.“通用前向纠错的RTP有效载荷格式”，RFC 5109，2007年12月。
Authors' Addresses
作者地址
Ali Begen Cisco 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: abegen@cisco.com
EMail: abegen@cisco.com
Dong Hsu Cisco 1414 Massachusetts Ave. Boxborough, MA 01719 USA
美国马萨诸塞州伯斯堡马萨诸塞大道1414号东旭思科01719
EMail: dohsu@cisco.com
EMail: dohsu@cisco.com
Michael Lague Cisco 1414 Massachusetts Ave. Boxborough, MA 01719 USA
美国马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: mlague@cisco.com
EMail: mlague@cisco.com