Network Working Group J. Lazzaro
Request for Comments: 4571 UC Berkeley
Category: Standards Track July 2006
Network Working Group J. Lazzaro
Request for Comments: 4571 UC Berkeley
Category: Standards Track July 2006
Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport
基于面向连接传输的帧实时传输协议（RTP）和RTP控制协议（RTCP）数据包
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This memo defines a method for framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP). The memo also defines how session descriptions may specify RTP streams that use the framing method.
本备忘录定义了一种将实时传输协议（RTP）和RTP控制协议（RTCP）数据包分帧到面向连接的传输（如TCP）上的方法。备忘录还定义了会话描述如何指定使用帧方法的RTP流。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. The Framing Method ..............................................2
3. Packet Stream Properties ........................................3
4. Session Descriptions for RTP/AVP over TCP .......................3
5. Example .........................................................5
6. Congestion Control ..............................................6
7. Acknowledgements ................................................6
8. Security Considerations .........................................6
9. IANA Considerations .............................................7
10. Normative References ...........................................7
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. The Framing Method ..............................................2
3. Packet Stream Properties ........................................3
4. Session Descriptions for RTP/AVP over TCP .......................3
5. Example .........................................................5
6. Congestion Control ..............................................6
7. Acknowledgements ................................................6
8. Security Considerations .........................................6
9. IANA Considerations .............................................7
10. Normative References ...........................................7
The Audio/Video Profile (AVP, [RFC3550]) for the Real-time Transport Protocol (RTP, [RFC3551]) does not define a method for framing RTP and RTP Control Protocol (RTCP) packets onto connection-oriented transport protocols (such as TCP). However, earlier versions of RTP/AVP did define a framing method, and this method is in use in several implementations.
实时传输协议（RTP，[RFC3551]）的音频/视频配置文件（AVP，[RFC3550]）未定义将RTP和RTP控制协议（RTCP）数据包分帧到面向连接的传输协议（如TCP）上的方法。然而，RTP/AVP的早期版本确实定义了一种成帧方法，并且这种方法已在多个实现中使用。
In this memo, we document the framing method that was defined by earlier versions of RTP/AVP. In addition, we introduce a mechanism for a session description [SDP] to signal the use of the framing method. Note that session description signalling for the framing method is new and was not defined in earlier versions of RTP/AVP.
在本备忘录中，我们记录了RTP/AVP早期版本定义的成帧方法。此外，我们还引入了一种会话描述（SDP）机制来表示使用了成帧方法。注意，成帧方法的会话描述信令是新的，在早期版本的RTP/AVP中没有定义。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Figure 1 defines the framing method.
图1定义了框架方法。
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
---------------------------------------------------------------
| LENGTH | RTP or RTCP packet ... |
---------------------------------------------------------------
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
---------------------------------------------------------------
| LENGTH | RTP or RTCP packet ... |
---------------------------------------------------------------
Figure 1: The bit field definition of the framing method
图1：帧方法的位字段定义
A 16-bit unsigned integer LENGTH field, coded in network byte order (big-endian), begins the frame. If LENGTH is non-zero, an RTP or RTCP packet follows the LENGTH field. The value coded in the LENGTH field MUST equal the number of octets in the RTP or RTCP packet. Zero is a valid value for LENGTH, and it codes the null packet.
以网络字节顺序（big-endian）编码的16位无符号整数长度字段开始帧。如果长度非零，则RTP或RTCP数据包跟随长度字段。长度字段中编码的值必须等于RTP或RTCP数据包中的八位字节数。零是长度的有效值，它对空数据包进行编码。
This framing method does not use frame markers (i.e., an octet of constant value that would precede the LENGTH field). Frame markers are useful for detecting errors in the LENGTH field. In lieu of a frame marker, receivers SHOULD monitor the RTP and RTCP header fields whose values are predictable (for example, the RTP version number). See Appendix A.1 of [RFC3550] for additional guidance.
此成帧方法不使用帧标记（即，长度字段前面的定值八位字节）。帧标记用于检测长度字段中的错误。代替帧标记，接收器应监控其值可预测的RTP和RTCP头字段（例如，RTP版本号）。更多指南见[RFC3550]附录A.1。
In most respects, the framing method does not specify properties above the level of a single packet. In particular, Section 2 does not specify the following:
在大多数方面，成帧方法不指定高于单个数据包级别的属性。具体而言，第2节未规定以下内容：
Bi-directional issues
双向问题
Section 2 defines a framing method for use in one direction on a connection. The relationship between framed packets flowing in a defined direction and in the reverse direction is not specified.
第2节定义了在连接件的一个方向上使用的框架方法。未指定沿定义方向和反向流动的帧数据包之间的关系。
Packet loss and reordering
数据包丢失和重新排序
The reliable nature of a connection does not imply that a framed RTP stream has a contiguous sequence number ordering. For example, if the connection is used to tunnel a UDP stream through a network middlebox that only passes TCP, the sequence numbers in the framed stream reflect any packet loss or reordering on the UDP portion of the end-to-end flow.
连接的可靠性并不意味着帧RTP流具有连续的序列号顺序。例如，如果连接用于通过仅通过TCP的网络中间盒对UDP流进行隧道传输，则帧流中的序列号反映端到端流的UDP部分上的任何数据包丢失或重新排序。
Out-of-band semantics
带外语义
Section 2 does not define the RTP or RTCP semantics for closing a TCP socket, or of any other "out of band" signal for the connection.
第2节未定义用于关闭TCP套接字或连接的任何其他“带外”信号的RTP或RTCP语义。
Memos that normatively include the framing method MAY specify these properties. For example, Section 4 of this memo specifies these properties for RTP/AVP sessions specified in session descriptions.
规范性地包含框架方法的备忘录可以指定这些属性。例如，本备忘录第4节为会话描述中指定的RTP/AVP会话指定了这些属性。
In one respect, the framing protocol does indeed specify a property above the level of a single packet. If a direction of a connection carries RTP packets, the streams carried in this direction MUST support the use of multiple synchronization sources (SSRCs) in those RTP packets. If a direction of a connection carries RTCP packets, the streams carried in this direction MUST support the use of multiple SSRCs in those RTCP packets.
在一个方面，帧协议确实指定了高于单个分组级别的属性。如果连接的一个方向承载RTP数据包，则该方向承载的流必须支持在这些RTP数据包中使用多个同步源（SSRC）。如果连接的一个方向承载RTCP数据包，则该方向承载的流必须支持在这些RTCP数据包中使用多个SSRC。
Session management protocols that use the Session Description Protocol [SDP] in conjunction with the Offer/Answer Protocol [RFC3264] MUST use the methods described in [COMEDIA] to set up RTP/AVP streams over TCP. In this case, the use of Offer/Answer is REQUIRED, as the setup methods described in [COMEDIA] rely on Offer/Answer.
使用会话描述协议[SDP]和提供/应答协议[RFC3264]的会话管理协议必须使用[COMEDIA]中描述的方法通过TCP设置RTP/AVP流。在这种情况下，需要使用提供/回答，因为[喜剧]中描述的设置方法依赖于提供/回答。
In principle, [COMEDIA] is capable of setting up RTP sessions for any RTP profile. In practice, each profile has unique issues that must be considered when applying [COMEDIA] to set up streams for the profile.
原则上，[COMEDIA]能够为任何RTP配置文件设置RTP会话。实际上，在应用[喜剧]为个人资料设置流时，每个个人资料都有独特的问题，必须加以考虑。
In this memo, we restrict our focus to the Audio/Video Profile (AVP, [RFC3551]). Below, we define a token value ("TCP/RTP/AVP") that signals the use of RTP/AVP in a TCP session. We also define the operational procedures that a TCP/RTP/AVP stream MUST follow.
在本备忘录中，我们仅关注音频/视频配置文件（AVP，[RFC3551]）。下面，我们定义一个令牌值（“TCP/RTP/AVP”），它表示在TCP会话中使用RTP/AVP。我们还定义了TCP/RTP/AVP流必须遵循的操作过程。
We expect that other standards-track memos will appear to support the use of the framing method with other RTP profiles. The support memo for a new profile MUST define a token value for the profile, using the style we used for AVP. Thus, for profile xyz, the token value MUST be "TCP/RTP/xyz". The memo SHOULD adopt the operational procedures we define below for AVP, unless these procedures are in some way incompatible with the profile.
我们预计其他标准轨道备忘录将支持在其他RTP配置文件中使用成帧方法。新配置文件的支持备忘录必须使用我们用于AVP的样式为配置文件定义一个标记值。因此，对于概要文件xyz，令牌值必须是“TCP/RTP/xyz”。备忘录应采用我们在下文为AVP定义的操作程序，除非这些程序在某种程度上与概要文件不兼容。
The remainder of this section describes how to setup and use an AVP stream in a TCP session. Figure 2 shows the syntax of a media (m=) line [SDP] of a session description:
本节的其余部分介绍如何在TCP会话中设置和使用AVP流。图2显示了会话描述的媒体（m=）行[SDP]的语法：
"m=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF
"m=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF
Figure 2: Syntax for an SDP media (m=) line (from [SDP])
图2:SDP媒体（m=）行的语法（来自[SDP]）
The <proto> token value "TCP/RTP/AVP" specifies an RTP/AVP [RFC3550] [RFC3551] stream that uses the framing method over TCP.
<proto>标记值“TCP/RTP/AVP”指定在TCP上使用帧方法的RTP/AVP[RFC3550][RFC3551]流。
The <fmt> tokens that follow <proto> MUST be unique unsigned integers in the range 0 to 127. The <fmt> tokens specify an RTP payload type associated with the stream.
<proto>后面的<fmt>标记必须是范围在0到127之间的唯一无符号整数。<fmt>标记指定与流关联的RTP有效负载类型。
In all other respects, the session description syntax for the framing method is identical to [COMEDIA].
在所有其他方面，框架方法的会话描述语法与[COMEDIA]相同。
The TCP <port> on the media line carries RTP packets. If a media stream uses RTCP, a second connection carries RTCP packets. The port for the RTCP connection is chosen using the algorithms defined in [SDP] or by the mechanism defined in [RFC3605].
媒体线路上的TCP<port>承载RTP数据包。如果媒体流使用RTCP，则第二个连接携带RTCP数据包。使用[SDP]中定义的算法或[RFC3605]中定义的机制选择RTCP连接的端口。
The TCP connections MAY carry bi-directional traffic, following the semantics defined in [COMEDIA]. Both directions of a connection MUST carry the same type of packets (RTP or RTCP). The packets MUST exclusively code the RTP or RTCP streams specified on the media line(s) associated with the connection.
TCP连接可以承载双向流量，遵循[COMEDIA]中定义的语义。连接的两个方向必须携带相同类型的数据包（RTP或RTCP）。数据包必须专门编码与连接相关联的媒体线路上指定的RTP或RTCP流。
As noted in [RFC3550], the use of RTP without RTCP is strongly discouraged. However, if a sender does not wish to send RTCP packets in a media session, the sender MUST add the lines "b=RS:0" AND "b=RR:0" to the media description (from [RFC3556]).
如[RFC3550]所述，强烈反对在没有RTCP的情况下使用RTP。但是，如果发送方不希望在媒体会话中发送RTCP数据包，则发送方必须在媒体描述（来自[RFC3556]）中添加行“b=RS:0”和“b=RR:0”。
If the session descriptions of the offer AND the answer both contain the "b=RS:0" AND "b=RR:0" lines, an RTCP TCP flow for the media session MUST NOT be created by either endpoint in the session. In all other cases, endpoints MUST establish two TCP connections for an RTP/AVP stream, one for RTP and one for RTCP.
如果提供和应答的会话描述都包含“b=RS:0”和“b=RR:0”行，则会话中的任一端点都不得创建媒体会话的RTCP TCP流。在所有其他情况下，端点必须为RTP/AVP流建立两个TCP连接，一个用于RTP，一个用于RTCP。
As described in [RFC3264], the use of the "sendonly" or "sendrecv" attribute in an offer (or answer) indicates that the offerer (or answerer) intends to send RTP packets on the RTP TCP connection. The use of the "recvonly" or "sendrecv" attributes in an offer (or answer) indicates that the offerer (or answerer) wishes to receive RTP packets on the RTP TCP connection.
如[RFC3264]所述，在报价（或应答）中使用“sendonly”或“sendrecv”属性表示报价人（或应答人）打算在RTP TCP连接上发送RTP数据包。在报价（或应答）中使用“RecVoOnly”或“sendrecv”属性表示报价人（或应答人）希望在RTP TCP连接上接收RTP数据包。
The session descriptions in Figures 3 and 4 define a TCP RTP/AVP session.
图3和图4中的会话描述定义了一个TCP RTP/AVP会话。
v=0
o=first 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
c=IN IP4 192.0.2.105
m=audio 9 TCP/RTP/AVP 11
a=setup:active
a=connection:new
v=0
o=first 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
c=IN IP4 192.0.2.105
m=audio 9 TCP/RTP/AVP 11
a=setup:active
a=connection:new
Figure 3: TCP session description for the first participant
图3：第一个参与者的TCP会话描述
v=0
o=second 2520644554 2838152170 IN IP4 second.example.net
s=Example
t=0 0
c=IN IP4 192.0.2.94
m=audio 16112 TCP/RTP/AVP 10 11
a=setup:passive
a=connection:new
v=0
o=second 2520644554 2838152170 IN IP4 second.example.net
s=Example
t=0 0
c=IN IP4 192.0.2.94
m=audio 16112 TCP/RTP/AVP 10 11
a=setup:passive
a=connection:new
Figure 4: TCP session description for the second participant
图4：第二个参与者的TCP会话描述
The session descriptions define two parties that participate in a connection-oriented RTP/AVP session. The first party (Figure 3) is capable of receiving stereo L16 streams (static payload type 11).
会话描述定义了参与面向连接的RTP/AVP会话的双方。第一方（图3）能够接收立体声L16流（静态有效负载类型11）。
The second party (Figure 4) is capable of receiving mono (static payload type 10) or stereo L16 streams.
第二方（图4）能够接收单声道（静态有效负载类型10）或立体声L16流。
The "setup" attribute in Figure 3 specifies that the first party is "active" and initiates connections, and the "setup" attribute in Figure 4 specifies that the second party is "passive" and accepts connections [COMEDIA].
图3中的“设置”属性指定第一方为“主动”并启动连接，图4中的“设置”属性指定第二方为“被动”并接受连接[喜剧]。
The first party connects to the network address (192.0.2.94) and port (16112) of the second party. Once the connection is established, it is used bi-directionally: the first party sends framed RTP packets to the second party in one direction of the connection, and the second party sends framed RTP packets to the first party in the other direction of the connection.
第一方连接到第二方的网络地址（192.0.2.94）和端口（16112）。一旦建立了连接，就可以双向使用：第一方在连接的一个方向上向第二方发送带帧的RTP数据包，第二方在连接的另一个方向上向第一方发送带帧的RTP数据包。
The first party also initiates an RTCP TCP connection to port 16113 (16112 + 1, as defined in [SDP]) of the second party. Once the connection is established, the first party sends framed RTCP packets to the second party in one direction of the connection, and the second party sends framed RTCP packets to the first party in the other direction of the connection.
第一方还发起与第二方的端口16113（16112+1，定义见[SDP]）的RTCP TCP连接。一旦建立连接，第一方在连接的一个方向向第二方发送带帧的RTCP数据包，第二方在连接的另一个方向向第一方发送带帧的RTCP数据包。
The RTP congestion control requirements are defined in [RFC3550]. As noted in [RFC3550], all transport protocols used on the Internet need to address congestion control in some way, and RTP is not an exception.
[RFC3550]中定义了RTP拥塞控制要求。如[RFC3550]所述，互联网上使用的所有传输协议都需要以某种方式解决拥塞控制问题，RTP也不例外。
In addition, the congestion control requirements for the Audio/Video Profile are defined in [RFC3551]. The basic congestion control requirement defined in [RFC3551] is that RTP sessions should compete fairly with TCP flows that share the network. As the framing method uses TCP, it competes fairly with other TCP flows by definition.
此外，[RFC3551]中定义了音频/视频配置文件的拥塞控制要求。[RFC3551]中定义的基本拥塞控制要求是RTP会话应与共享网络的TCP流公平竞争。由于framing方法使用TCP，因此它在定义上与其他TCP流公平竞争。
This memo, in part, documents discussions on the AVT mailing list about TCP and RTP. Thanks to all of the participants in these discussions.
本备忘录部分记录了AVT邮件列表中关于TCP和RTP的讨论。感谢所有参与讨论的人。
Implementors should carefully read the Security Considerations sections of the RTP [RFC3550] and RTP/AVP [RFC3551] documents, as most of the issues discussed in these sections directly apply to RTP streams framed over TCP.
实施者应仔细阅读RTP[RFC3550]和RTP/AVP[RFC3551]文档中的安全注意事项部分，因为这些部分中讨论的大多数问题直接适用于通过TCP构建的RTP流。
Session descriptions that specify connection-oriented media sessions (such as the example session shown in Figures 3 and 4 of Section 5) raise unique security concerns for streaming media. The Security Considerations section of [COMEDIA] describes these issues in detail.
指定面向连接的媒体会话的会话描述（如第5节图3和图4中所示的示例会话）为流媒体带来了独特的安全问题。[喜剧]的安全注意事项部分详细描述了这些问题。
Below, we discuss security issues that are unique to the framing method defined in Section 2.
下面，我们将讨论第2节中定义的框架方法特有的安全问题。
Attackers may send framed packets with large LENGTH values to exploit security holes in applications. For example, a C implementation may declare a 1500-byte array as a stack variable, and use LENGTH as the bound on the loop that reads the framed packet into the array. This code would work fine for friendly applications that use Etherframe-sized RTP packets, but may be open to exploit by an attacker. Thus, an implementation needs to handle packets of any length, from a NULL packet (LENGTH == 0) to the maximum-length packet holding 64K octets (LENGTH = 0xFFFF).
攻击者可能发送具有较大长度值的帧数据包，以利用应用程序中的安全漏洞。例如，C实现可以将1500字节的数组声明为堆栈变量，并使用长度作为将带帧数据包读入数组的循环的界限。此代码适用于使用以太帧大小RTP数据包的友好应用程序，但可能会被攻击者利用。因此，实现需要处理任意长度的数据包，从空数据包（长度==0）到包含64K个八位字节（长度=0xFFFF）的最大长度数据包。
[SDP] defines the syntax of session description media lines. We reproduce this definition in Figure 2 of Section 4 of this memo. In Section 4, we define a new token value for the <proto> field of media lines: "TCP/RTP/AVP". Section 4 specifies the semantics associated with the <proto> field token, and Section 5 shows an example of its use in a session description.
[SDP]定义会话描述媒体行的语法。我们在本备忘录第4节的图2中重现了这一定义。在第4节中，我们为媒体行的<proto>字段定义了一个新的令牌值：“TCP/RTP/AVP”。第4节指定了与<proto>字段标记相关联的语义，第5节显示了在会话描述中使用该标记的示例。
[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月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[COMEDIA] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[COMEDIA]Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 41452005年9月。
[SDP] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session Description Protocol", RFC 4566, July 2006.
[SDP]Handley，M.，Jacobson，V.，和C.Perkins。“SDP：会话描述协议”，RFC4566，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月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3605]Huitema，C.，“会话描述协议（SDP）中的实时控制协议（RTCP）属性”，RFC3605，2003年10月。
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[RFC3556]Casner，S.，“RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽修饰符”，RFC 3556，2003年7月。
Author's Address
作者地址
John Lazzaro UC Berkeley CS Division 315 Soda Hall Berkeley CA 94720-1776
约翰·拉扎罗加州大学伯克利分校计算机科学部315苏打厅加利福尼亚州伯克利94720-1776
EMail: lazzaro@cs.berkeley.edu
EMail: lazzaro@cs.berkeley.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。