Network Working Group R. Even
Request for Comments: 4587 Polycom
Obsoletes: 2032 August 2006
Category: Standards Track
Network Working Group R. Even
Request for Comments: 4587 Polycom
Obsoletes: 2032 August 2006
Category: Standards Track
RTP Payload Format for H.261 Video Streams
H.261视频流的RTP有效负载格式
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 describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP.
本备忘录描述了一种使用实时传输协议RTP将H.261视频流打包以进行传输的方案，该协议具有任何承载RTP的底层协议。
The memo also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.261 video codec. A media type registration is included for this payload format.
备忘录还描述了支持H.261视频编解码器所需的会话描述协议（SDP）参数的语法和语义。此有效负载格式包括媒体类型注册。
This specification obsoletes RFC 2032.
本规范淘汰了RFC 2032。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Structure of the Packet Stream ..................................3
3.1. Overview of the ITU-T Recommendation H.261 .................3
3.2. Considerations for Packetization ...........................4
4. Specification of the Packetization Scheme .......................5
4.1. Usage of RTP ...............................................5
4.2. Recommendations for Operation with Hardware Codecs .........8
5. Packet Loss Issues ..............................................9
6. IANA Considerations ............................................10
6.1. Media Type Registrations ..................................10
6.1.1. Registration of MIME Media Type video/H261 .........10
6.2. SDP Parameters ............................................12
6.2.1. Usage with the SDP Offer Answer Model ..............12
7. Backward Compatibility to RFC 2032 .............................13
7.1. Optional H.261-Specific Control Packets ...................13
7.2. New SDP Optional Parameters ...............................13
8. Security Considerations ........................................14
9. Acknowledgements ...............................................14
10. Changes from RFC 2032 .........................................14
11. References ....................................................15
11.1. Normative References .....................................15
11.2. Informative References ...................................15
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Structure of the Packet Stream ..................................3
3.1. Overview of the ITU-T Recommendation H.261 .................3
3.2. Considerations for Packetization ...........................4
4. Specification of the Packetization Scheme .......................5
4.1. Usage of RTP ...............................................5
4.2. Recommendations for Operation with Hardware Codecs .........8
5. Packet Loss Issues ..............................................9
6. IANA Considerations ............................................10
6.1. Media Type Registrations ..................................10
6.1.1. Registration of MIME Media Type video/H261 .........10
6.2. SDP Parameters ............................................12
6.2.1. Usage with the SDP Offer Answer Model ..............12
7. Backward Compatibility to RFC 2032 .............................13
7.1. Optional H.261-Specific Control Packets ...................13
7.2. New SDP Optional Parameters ...............................13
8. Security Considerations ........................................14
9. Acknowledgements ...............................................14
10. Changes from RFC 2032 .........................................14
11. References ....................................................15
11.1. Normative References .....................................15
11.2. Informative References ...................................15
ITU-T Recommendation H.261 [H261] specifies the encoding used by ITU-T-compliant video-conference codecs. Although this encoding was originally specified for fixed-data rate Integrated Services Digital Network (ISDN) circuits, experiments [INRIA], [MICE] have shown that they can also be used over packet-switched networks, such as the Internet.
ITU-T建议H.261[H261]规定了符合ITU-T标准的视频会议编解码器使用的编码。虽然这种编码最初指定用于固定数据速率综合业务数字网（ISDN）电路，但实验[INRIA]，[MICE]表明，它们也可以用于分组交换网络，如互联网。
The purpose of this memo is to specify the RTP payload format for encapsulating H.261 video streams in RTP [RFC3550].
本备忘录的目的是指定RTP有效负载格式，用于将H.261视频流封装在RTP[RFC3550]中。
This document obsoletes RFC 2032 and updates the "video/h261" media type that was registered in RFC 3555.
本文档淘汰RFC 2032，并更新在RFC 3555中注册的“视频/h261”媒体类型。
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] and indicate requirement levels for compliant RTP implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释，并指出符合RTP实施的要求级别。
The H.261 coding is organized as a hierarchy of groupings. The video stream is composed of a sequence of images, or frames, which are themselves organized as a set of Groups of Blocks (GOB). Note that H.261 "pictures" are referred to as "frames" in this document. Each GOB holds a set of 3 lines of 11 macro blocks (MB). Each MB carries information on a group of 16x16 pixels: luminance information is specified for 4 blocks of 8x8 pixels, whereas chrominance information is given by two "red" and "blue" color difference components at a resolution of only 8x8 pixels. These components and the codes representing their sampled values are as defined in ITU-R Recommendation 601 [BT601].
H.261编码被组织为分组的层次结构。视频流由一系列图像或帧组成，这些图像或帧本身被组织为一组块（GOB）。请注意，H.261“图片”在本文件中称为“框架”。每个GOB包含一组3行11个宏块（MB）。每个MB携带一组16x16像素的信息：亮度信息是为4个8x8像素块指定的，而色度信息是由两个“红色”和“蓝色”色差分量以仅8x8像素的分辨率提供的。这些组件和代表其采样值的代码如ITU-R建议601[BT601]所定义。
This grouping is used to specify information at each level of the hierarchy:
此分组用于指定层次结构每个级别的信息：
- At the frame level, one specifies information such as the delay from the previous frame, the image format, and various indicators.
- 在帧级别，可以指定信息，例如来自前一帧的延迟、图像格式和各种指示符。
- At the GOB level, one specifies the GOB number and the default quantifier that will be used for the MBs.
- 在GOB级别，指定将用于MBs的GOB编号和默认量词。
- At the MB level, one specifies which blocks are present and which did not change, and, optionally, a quantifier and motion vectors.
- 在MB级别，可以指定哪些块存在，哪些块没有更改，还可以指定量词和运动向量。
Blocks that have changed are encoded by computing the discrete cosine transform (DCT) of their coefficients, which are then quantized and Huffman encoded (Variable Length Codes).
已改变的块通过计算其系数的离散余弦变换（DCT）进行编码，然后对其进行量化和哈夫曼编码（可变长度码）。
The H.261 Huffman encoding includes a special "GOB start" pattern, which is a word of 16 bits, 0000 0000 0000 0001. This pattern is included at the beginning of each GOB header (and also at the beginning of each frame header) to mark the separation between two GOBs and is in fact used as an indicator that the current GOB is terminated. The encoding also includes a stuffing pattern, composed of seven zero bits followed by four bits with a value of one; that stuffing pattern can only be entered between the encoding of MBs, or just before the GOB separator.
H.261哈夫曼编码包括一个特殊的“GOB-start”模式，它是一个16位的字，0000 0001。该模式包括在每个采空区标头的开头（以及每个帧标头的开头），以标记两个采空区之间的间隔，并且实际上用作当前采空区终止的指示器。编码还包括填充模式，填充模式由七个零位后跟四个值为1的位组成；填充模式只能在MBs编码之间输入，或在GOB分隔符之前输入。
H.261 codecs designed for operation over ISDN circuits produce a bit stream composed of several levels of encoding specified by H.261 and companion recommendations. The bits resulting from the Huffman encoding are arranged in 512-bit frames, containing 2 bits of synchronization, 492 bits of data and 18 bits of error correcting code. The 512-bit frames are then interlaced with an audio stream and transmitted over px 64 kbps circuits according to specification H.221 [H221].
为在ISDN电路上运行而设计的H.261编解码器产生由H.261和配套建议规定的几种编码级别组成的比特流。哈夫曼编码产生的比特被安排在512比特帧中，包括2比特的同步、492比特的数据和18比特的纠错码。然后，根据规范H.221[H221]，512位帧与音频流交错，并通过px 64 kbps电路传输。
For transmitting over the Internet, we will directly consider the output of the Huffman encoding. All the bits produced by the Huffman encoding stage will be included in the packet. We will not carry the 512-bit frames, as protection against bit errors can be obtained by other means. Similarly, we will not attempt to multiplex audio and video signals in the same packets, as UDP and RTP provide a much more suitable way to achieve multiplexing.
为了在因特网上传输，我们将直接考虑赫夫曼编码的输出。哈夫曼编码阶段产生的所有比特都将包含在数据包中。我们将不携带512位帧，因为可以通过其他方式获得针对位错误的保护。类似地，我们不会尝试在相同的数据包中多路复用音频和视频信号，因为UDP和RTP提供了一种更合适的方式来实现多路复用。
Directly transmitting the result of the Huffman encoding over an unreliable stream of UDP datagrams would, however, have poor error resistance characteristics. The result of the hierarchical structure of the H.261 bit stream is that one needs to receive the information present in the frame header to decode the GOBs, as well as the information present in the GOB header to decode the MBs. Without precautions, this would mean that one has to receive all the packets that carry an image in order to decode its components properly.
然而，通过不可靠的UDP数据报流直接传输哈夫曼编码的结果将具有较差的抗错误特性。H.261比特流的层次结构的结果是，需要接收帧报头中存在的信息以解码GOBs，以及GOB报头中存在的信息以解码MBs。如果不采取预防措施，这将意味着必须接收所有携带图像的数据包才能正确解码其组件。
If each image could be carried in a single packet, this requirement would not create a problem. However, a video image or even one GOB by itself can sometimes be too large to fit in a single packet.
如果每个图像都可以放在一个包中，这个要求就不会产生问题。然而，一个视频图像或甚至一个GOB本身有时可能太大，无法装入单个数据包。
Therefore, the MB is taken as the unit of fragmentation. Packets must start and end on an MB boundary; that is, an MB cannot be split across multiple packets. Multiple MBs may be carried in a single packet when they will fit within the maximal packet size allowed. This practice is recommended to reduce the packet send rate and packet overhead.
因此，MB被视为碎片单元。数据包必须在MB边界上开始和结束；也就是说，一个MB不能被分割成多个数据包。当多个mb适合于允许的最大分组大小时，可以在单个分组中携带多个mb。建议采用这种做法以降低数据包发送速率和数据包开销。
To allow each packet to be processed independently for efficient resynchronization in the presence of packet losses, some state information from the frame header and GOB header is carried with each packet to allow the MBs in that packet to be decoded. This state information includes the GOB number in effect at the start of the packet, the macroblock address predictor (i.e., the last macroblock address (MBA) encoded in the previous packet), the quantizer value in effect prior to the start of this packet (GQUANT, MQUANT, or zero in the case of a beginning of GOB) and the reference motion vector data (MVD) for computing the true MVDs contained within this packet. The bit stream cannot be fragmented between a GOB header and MB 1 of that GOB.
为了允许在存在分组丢失的情况下独立地处理每个分组以进行有效的重新同步，来自帧报头和GOB报头的一些状态信息与每个分组一起携带以允许解码该分组中的MBs。该状态信息包括在分组开始时有效的GOB编号、宏块地址预测器（即，在前一分组中编码的最后一个宏块地址（MBA））、在该分组开始之前有效的量化器值（GQUANT、MQUANT或在GOB开始的情况下为零）以及用于计算该分组中包含的真实MVD的参考运动矢量数据（MVD）。位流不能在GOB标头和该GOB的MB 1之间分段。
Moreover, since the compressed MB may not fill an integer number of octets, the data header contains two 3-bit integers, SBIT and EBIT, to indicate the number of unused bits in the first and last octets of the H.261 data, respectively.
此外，由于压缩的MB可能不会填充整数个八位字节，因此数据头包含两个3位整数SBIT和EBIT，以分别指示H.261数据的第一个八位字节和最后一个八位字节中未使用的位数。
Each RTP packet starts with a fixed RTP header, as explained in RFC 3550 [RFC3550]. The following fields of the RTP fixed header used for H.261 video streams are further emphasized here:
每个RTP数据包都以一个固定的RTP报头开始，如RFC 3550[RFC3550]中所述。这里进一步强调用于H.261视频流的RTP固定报头的以下字段：
- Payload type. The assignment of an RTP payload type for this packet format is outside the scope of this document and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or, if that is not done, then a payload type in the dynamic range shall be chosen.
- 有效载荷类型。此数据包格式的RTP有效负载类型的分配超出了本文档的范围，此处将不进行指定。预计特定类别应用的RTP配置文件将为此编码分配有效负载类型，或者，如果未分配有效负载类型，则应选择动态范围内的有效负载类型。
- The RTP timestamp encodes the sampling instant of the first video image contained in the RTP data packet. If a video image occupies more than one packet, the timestamp SHALL be the same on all of those packets. Packets from different video images MUST have a different timestamp so that frames may be distinguished by the timestamp. For H.261 video streams, the RTP timestamp is based on a 90-kHz clock. This clock rate is a multiple of the natural H.261 frame rate (i.e., 30000/1001 or approximately 29.97 Hz). That way,
- RTP时间戳对包含在RTP数据分组中的第一视频图像的采样瞬间进行编码。如果视频图像占用多个数据包，则所有这些数据包上的时间戳应相同。来自不同视频图像的数据包必须具有不同的时间戳，以便可以通过时间戳区分帧。对于H.261视频流，RTP时间戳基于90 kHz时钟。该时钟频率是自然H.261帧速率（即30000/1001或约29.97 Hz）的倍数。这样,，
for each frame time, the clock is just incremented by the multiple, and this removes inaccuracy in calculating the timestamp. Furthermore, the initial value of the timestamp MUST be random (unpredictable) to make known-plaintext attacks on encryption more difficult; see RTP [RFC3550]. Note that if multiple frames are encoded in a packet (e.g., when there are very few changes between two images), it is necessary to calculate display times for the frames after the first, using the timing information in the H.261 frame header. This is required because the RTP timestamp only gives the display time of the first frame in the packet.
对于每个帧时间，时钟只是增加倍数，这消除了计算时间戳的不精确性。此外，时间戳的初始值必须是随机的（不可预测的），以使对加密的已知明文攻击更加困难；见RTP[RFC3550]。注意，如果在分组中编码多个帧（例如，当两个图像之间的变化很少时），则需要使用H.261帧报头中的定时信息来计算第一帧之后的帧的显示时间。这是必需的，因为RTP时间戳仅给出数据包中第一帧的显示时间。
- The marker bit of the RTP header MUST be set to one in the last packet of a video frame; otherwise, it MUST be zero. Thus, it is not necessary to wait for a following packet (which contains the start code that terminates the current frame) to detect that a new frame should be displayed.
- RTP报头的标记位必须在视频帧的最后一个分组中设置为1；否则，它必须为零。因此，不必等待后续分组（其包含终止当前帧的开始代码）来检测应显示新帧。
The H.261 data SHALL follow the RTP header, as in the following:
H.261数据应遵循RTP标题，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. RTP header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.261 header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.261 stream ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. RTP header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.261 header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.261 stream ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The H.261 header is defined as follows:
H.261标题定义如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SBIT |EBIT |I|V| GOBN | MBAP | QUANT | HMVD | VMVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SBIT |EBIT |I|V| GOBN | MBAP | QUANT | HMVD | VMVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the H.261 header have the following meanings:
H.261标题中的字段具有以下含义：
Start bit position (SBIT): 3 bits
起始位位置（SBIT）：3位
Number of most significant bits that should be ignored in the first data octet.
第一个数据八位组中应忽略的最高有效位数。
End bit position (EBIT): 3 bits
结束位位置（息税前利润）：3位
Number of least significant bits that should be ignored in the last data octet.
最后一个数据八位字节中应忽略的最低有效位数。
INTRA-frame encoded data (I): 1 bit
帧内编码数据（I）：1位
Set to 1 if this stream contains only INTRA-frame coded blocks. Set to 0 if this stream may or may not contain INTRA-frame coded blocks. The meaning of this bit should not be changed during the course of the RTP session.
如果此流仅包含帧内编码块，则设置为1。如果此流可能包含也可能不包含帧内编码块，则设置为0。在RTP会话过程中，此位的含义不应更改。
Motion Vector flag (V): 1 bit
运动矢量标志（V）：1位
Set to 0 if motion vectors are not used in this stream. Set to 1 if motion vectors may or may not be used in this stream. The meaning of this bit should not be changed during the course of the session.
如果此流中未使用运动矢量，则设置为0。如果此流中可能使用或不使用运动矢量，则设置为1。在会话过程中，此位的含义不应更改。
GOB number (GOBN): 4 bits
采空区编号（GOBN）：4位
Encodes the GOB number in effect at the start of the packet. Set to 0 if the packet begins with a GOB header.
对数据包开始时生效的GOB编号进行编码。如果数据包以GOB头开头，则设置为0。
Macroblock address predictor (MBAP): 5 bits
宏块地址预测器（MBAP）：5位
Encodes the macroblock address predictor (i.e., the last MBA encoded in the previous packet). This predictor ranges from 0 - 32 (to predict the valid MBAs 1 - 33), but because the bit stream cannot be fragmented between a GOB header and MB 1, the predictor at the start of the packet shall not be 0. Therefore, the range is 1 - 32, which is biased by -1 to fit in 5 bits. For example, if MBAP is 0, the value of the MBA predictor is 1. Set to 0 if the packet begins with a GOB header.
对宏块地址预测器进行编码（即，前一个数据包中编码的最后一个MBA）。该预测器的范围为0-32（用于预测有效的mba 1-33），但由于位流不能在GOB报头和MB 1之间分段，因此数据包开始处的预测器不应为0。因此，范围为1-32，偏置-1以适合5位。例如，如果MBAP为0，则MBA预测值为1。如果数据包以GOB头开头，则设置为0。
Quantizer (QUANT): 5 bits
量化器（量化）：5位
Quantizer value (MQUANT or GQUANT) in effect prior to the start of this packet. Set to 0 if the packet begins with a GOB header.
量化器值（MQUANT或GQUANT）在此数据包开始之前生效。如果数据包以GOB头开头，则设置为0。
Horizontal motion vector data (HMVD): 5 bits
水平运动矢量数据（HMVD）：5位
Reference horizontal motion vector data (MVD). Set to 0 if V flag is 0 or if the packet begins with a GOB header, or when the MTYPE of the last MB encoded in the previous packet was not motion compensation (MC). HMVD is encoded as a 2s complement number, and '10000' corresponding to the value -16 is forbidden (motion vector fields range from +/-15).
参考水平运动矢量数据（MVD）。如果V标志为0，或者数据包以GOB头开始，或者前一个数据包中编码的最后一个MB的MTYPE不是运动补偿（MC），则设置为0。HMVD编码为2s补码，禁止使用与值-16对应的“10000”（运动矢量场范围为+/-15）。
Vertical motion vector data (VMVD): 5 bits
垂直运动矢量数据（VMVD）：5位
Reference vertical motion vector data (MVD). Set to 0 if V flag is 0 or if the packet begins with a GOB header, or when the MTYPE of the last MB encoded in the previous packet was not MC. VMVD is encoded as a 2s complement number, and '10000' corresponding to the value -16 SHALL not be used (motion vector fields range from +/-15).
参考垂直运动矢量数据（MVD）。如果V标志为0，或者数据包以GOB头开始，或者前一个数据包中编码的最后一个MB的MTYPE不是MC，则设置为0。VMVD编码为2s补码，不应使用与值-16对应的“10000”（运动矢量场范围为+/-15）。
Note that the I and V flags are hint flags; i.e., they can be inferred from the bit stream. They are included to allow decoders to make optimizations that would not be possible if these hints were not provided before the bit stream was decoded. Therefore, these bits cannot change for the duration of the stream. A conforming implementation can always set V=1 and I=0.
注意，I和V标志是提示标志；i、 例如，它们可以从比特流中推断出来。包括它们是为了允许解码器进行优化，如果在解码比特流之前未提供这些提示，则无法进行优化。因此，这些位在流的持续时间内不能改变。一致性实现始终可以设置V=1和I=0。
The H.261 stream SHALL be used without BCH error correction and without error correction framing.
H.261流应在无BCH错误校正和无错误校正帧的情况下使用。
Packetizers for hardware codecs can trivially figure out GOB boundaries, using the GOB-start pattern included in the H.261 data. (Note that software encoders already know the boundaries.) The cheapest packetization implementation is to packetize at the GOB level all the GOBs that fit in a packet. But when a GOB is too large, the packetizer has to parse it to do MB fragmentation. (Note that only the Huffman encoding must be parsed and that it is not necessary to decompress the stream fully, so this requires relatively little processing; examples of implementations can be found in some public H.261 codecs, such as IVS [IVS] and VIC [VIC].) It is recommended that MB level fragmentation be used when feasible in order to obtain more efficient packetization. Using this fragmentation scheme reduces the output packet rate and therefore reduces the overhead.
硬件编解码器的打包器可以使用H.261数据中包含的GOB开始模式轻松地计算出GOB边界。（请注意，软件编码器已经知道边界。）最便宜的打包实现是在GOB级别打包适合一个包的所有GOB。但是当一个GOB太大时，打包程序必须解析它以进行MB碎片化。（注意，只有哈夫曼编码必须被解析，并且没有必要完全解压缩流，因此这需要相对较少的处理；在一些公共H.261编解码器中可以找到实现示例，例如IVS[IVS]和VIC[VIC]。）建议在可行的情况下使用MB级别的分段，以获得更有效的打包。使用此分段方案可降低输出数据包速率，从而降低开销。
At the receiver, the data stream can be depacketized and directed to a hardware codec's input. If the hardware decoder operates at a fixed bit rate, synchronization may be maintained by inserting the stuffing pattern between MBs (i.e., between packets) when the packet arrival rate is slower than the bit rate.
在接收器处，数据流可以被解除分组并定向到硬件编解码器的输入端。如果硬件解码器以固定比特率操作，则当分组到达速率低于比特率时，可以通过在MBs之间（即，分组之间）插入填充图案来维持同步。
On the Internet, most packet losses are due to network congestion rather than to transmission errors. Using UDP, no mechanism is available at the sender to know whether a packet has been successfully received. It is up to the application (i.e., coder and decoder) to handle the packet loss. Each RTP packet includes a sequence number field that can be used to detect packet loss.
在互联网上，大多数数据包丢失是由于网络拥塞而不是传输错误造成的。使用UDP，发送方没有机制可以知道是否成功接收到数据包。由应用程序（即编码器和解码器）处理数据包丢失。每个RTP数据包包括一个序列号字段，可用于检测数据包丢失。
H.261 uses the temporal redundancy of video to perform compression. This differential coding (or INTER-frame coding) is sensitive to packet loss. After a packet loss, parts of the image may remain corrupt until all corresponding MBs have been encoded in INTRA-frame mode (i.e., encoded independently of past frames). There are several ways to mitigate packet loss:
H.261使用视频的时间冗余来执行压缩。这种差分编码（或帧间编码）对分组丢失很敏感。在分组丢失之后，图像的部分可保持损坏，直到所有对应mb已以帧内模式编码（即，独立于过去帧编码）。有几种方法可以减轻数据包丢失：
(1) One way is to use only INTRA-frame encoding and MB-level conditional replenishment. That is, only MBs that change (beyond some threshold) are transmitted.
(1) 一种方法是只使用帧内编码和MB级条件补充。也就是说，仅传输变化（超过某个阈值）的MBs。
(2) Another way is to adjust the INTRA-frame encoding refreshment rate according to the packet loss observed by the receivers. The H.261 recommendation specifies that an MB be INTRA-frame encoded at least every 132 times it is transmitted. However, the INTRA-frame refreshment rate can be raised in order to speed the recovery when the measured loss rate is significant.
(2) 另一种方法是根据接收机观察到的分组丢失来调整帧内编码刷新率。H.261建议规定，至少每隔132次对MB进行帧内编码。然而，当测量到的丢失率显著时，可以提高帧内刷新率以加快恢复。
(3) The fastest way to repair a corrupted image is to request an INTRA-frame coded image refreshment after a packet loss is detected. One means to accomplish this is for the decoder to send to the coder a list of packets lost. The coder can decide to encode every MB of every GOB of the following video frame in INTRA-frame mode (i.e., full INTRA-frame encoded). If the coder can deduce from the packet sequence numbers which MBs were affected by the loss, it can save bandwidth by sending only those MBs in INTRA-frame mode. This mode is particularly efficient in point-to-point connection or when the number of decoders is low.
(3) 修复损坏图像的最快方法是在检测到数据包丢失后请求帧内编码图像刷新。实现这一点的一种方法是解码器向编码器发送丢失的数据包列表。编码器可以决定以帧内模式（即，全帧内编码）对以下视频帧的每个GOB的每MB进行编码。如果编码器可以从分组序列号推断出哪些MBs受到丢失的影响，那么它可以通过在帧内模式下仅发送那些MBs来节省带宽。该模式在点对点连接或解码器数量较低时特别有效。
The H.261-specific control packets FIR and NACK, as described in RFC 2032, SHALL NOT be used to request image refreshment. Old implementations are encouraged to use the methods described in this section. Image refreshment may be needed due to packet loss or due to application requirements. An example of application requirement may be the change of the speaker in a voice-activated multipoint video switching conference. There are two methods that can be used for requesting image refreshment. The first method is by using the Extended RTP Profile for RTCP-based Feedback and sending RTCP generic
RFC 2032中所述的H.261特定控制数据包FIR和NACK不得用于请求图像刷新。鼓励旧的实现使用本节中描述的方法。由于数据包丢失或应用要求，可能需要图像刷新。应用要求的一个例子可以是在语音激活的多点视频交换会议中改变扬声器。有两种方法可用于请求图像刷新。第一种方法是使用扩展RTP配置文件进行基于RTCP的反馈，并发送RTCP generic
control packets, as described in RFC 4585 [RFC4585]. The second method is by using application protocol-specific commands, such as H.245 [ITU.H245] FastUpdateRequest.
控制数据包，如RFC 4585[RFC4585]中所述。第二种方法是使用特定于应用程序协议的命令，如H.245[ITU.H245]FastUpdateRequest。
This section updates the H.261 media type described in RFC 3555 [RFC3555].
本节更新RFC 3555[RFC3555]中描述的H.261介质类型。
This section specifies optional parameters that MAY be used to select optional features of the payload format. The parameters are specified here as part of the MIME subtype registration for the ITU-T H.261 codec. A mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] is also provided for those applications that use SDP. Multiple parameters SHOULD be expressed as a media type string, in the form of a semicolon-separated list of parameters.
本节指定可用于选择有效负载格式可选特性的可选参数。此处指定的参数是ITU-T H.261编解码器MIME子类型注册的一部分。还为使用SDP的应用程序提供了参数到会话描述协议（SDP）[RFC4566]的映射。多个参数应以分号分隔的参数列表形式表示为媒体类型字符串。
This section describes the media types and names associated with this payload format. The section updates the previous registered version in RFC 3555 [RFC3555]. This registration uses the template defined in RFC 4288 [RFC4288]
本节介绍与此有效负载格式关联的媒体类型和名称。本节更新了RFC 3555[RFC3555]中先前注册的版本。此注册使用RFC 4288[RFC4288]中定义的模板
MIME media type name: video
MIME媒体类型名称：视频
MIME subtype name: H261
MIME子类型名称：H261
Required parameters: None
所需参数：无
Optional parameters:
可选参数：
CIF. This parameter has the format of parameter=value. It describes the maximum supported frame rate for CIF resolution. Permissible values are integer values 1 to 4, and it means that the maximum rate is 29.97/specified value.
到岸价此参数的格式为parameter=value。它描述了CIF分辨率支持的最大帧速率。允许值为整数值1至4，表示最大速率为29.97/规定值。
QCIF. This parameter has the format of parameter=value. It describes the maximum supported frame rate for QCIF resolution. Permissible values are integer values 1 to 4, and it means that the maximum rate is 29.97/specified value.
QCIF。此参数的格式为parameter=value。它描述了QCIF分辨率支持的最大帧速率。允许值为整数值1至4，表示最大速率为29.97/规定值。
D. Specifies support for still image graphics according to H.261, annex D. If supported, the parameter value SHALL be "1". If not supported, the parameter SHOULD NOT be used or SHALL have the value "0".
D.根据H.261附录D规定了对静态图像图形的支持。如果支持，参数值应为“1”。如果不受支持，则不应使用该参数或其值应为“0”。
Encoding considerations:
编码注意事项：
This media type is framed and binary, see Section 4.8 in [RFC4288].
此媒体类型为帧和二进制，请参阅[RFC4288]中的第4.8节。
Security considerations: See Section 8
安全注意事项：见第8节
Interoperability considerations:
互操作性注意事项：
These are receiver options; current implementations will not send any optional parameters in their SDP. They will ignore the optional parameters and will encode the H.261 stream without annex D. Most decoders support at least QCIF resolutions, and they are expected to be available in almost every H.261-based video application.
这些是接收器选项；当前实现不会在其SDP中发送任何可选参数。它们将忽略可选参数，并在没有附件D的情况下对H.261流进行编码。大多数解码器至少支持QCIF分辨率，预计它们将在几乎所有基于H.261的视频应用中可用。
Published specification: RFC 4587
已发布规范：RFC 4587
Applications that use this media type:
使用此媒体类型的应用程序：
Audio and video streaming and conferencing applications.
音频和视频流以及会议应用程序。
Additional information: None
其他信息：无
Person and email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Roni Even: roni.even@polycom.co.il
罗尼：罗尼。even@polycom.co.il
Intended usage: COMMON
预期用途：普通
Restrictions on usage:
使用限制：
This media type depends on RTP framing and thus is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[RFC3550]。此时未定义其他帧协议内的传输。
Author: Roni Even
作者：Roni Even
Change controller:
更改控制器：
IETF Audio/Video Transport working group, delegated from the IESG.
IETF音频/视频传输工作组，由IESG授权。
The MIME media type video/H261 string is mapped to fields in the Session Description Protocol (SDP) as follows:
MIME媒体类型video/H261字符串映射到会话描述协议（SDP）中的字段，如下所示：
o The media name in the "m=" line of SDP MUST be video.
o SDP的“m=”行中的媒体名称必须是视频。
o The encoding name in the "a=rtpmap" line of SDP MUST be H261 (the MIME subtype).
o SDP的“a=rtpmap”行中的编码名称必须是H261（MIME子类型）。
o The clock rate in the "a=rtpmap" line MUST be 90000.
o “a=rtpmap”行中的时钟频率必须为90000。
o The optional parameters "CIF", "QCIF", and "D", if any, SHALL be included in the "a=fmtp" line of SDP. These parameters are expressed as a MIME media type string, in the form of as a semicolon-separated list of parameters
o 可选参数“CIF”、“QCIF”和“D”（如有）应包含在SDP的“a=fmtp”行中。这些参数表示为MIME媒体类型字符串，形式为以分号分隔的参数列表
When H.261 is offered over RTP using SDP in an Offer/Answer model [RFC3264] the following considerations are necessary.
当在提供/应答模型[RFC3264]中使用SDP通过RTP提供H.261时，需要考虑以下事项。
Codec options: (D) This option MUST NOT appear unless the sender of this SDP message is able to decode this option. This option SHALL be considered a receiver's capability even when it is sent in a "sendonly" offer.
编解码器选项：（D）除非此SDP邮件的发件人能够解码此选项，否则不得显示此选项。即使在“仅发送”报价中发送此选项，也应将其视为接收方的能力。
Picture sizes and MPI:
图片大小和MPI：
Supported picture sizes and their corresponding minimum picture interval (MPI) information for H.261 can be combined. All picture sizes may be advertised to the other party, or only a subset of it. Using the recvonly or sendrev direction attribute, a terminal SHOULD announce those picture sizes (with their MPIs) that it is willing to receive. For example, CIF=2 means that receiver can receive a CIF picture and that the frame rate SHALL be less then 15 frames per second.
可以组合H.261支持的图片大小及其对应的最小图片间隔（MPI）信息。所有图片尺寸可向另一方发布，或仅向其子集发布。使用RECVOLY或sendrev direction属性，终端应宣布其愿意接收的图片大小（及其MPI）。例如，CIF=2意味着接收器可以接收CIF图片，并且帧速率应小于每秒15帧。
When the direction attribute is sendonly, the parameters describe the capabilities of the stream that the sender can produce.
当direction属性为sendonly时，参数描述发送方可以生成的流的功能。
Implementations following this specification SHALL specify at least one supported picture size.
遵循本规范的实施应规定至少一种支持的图片大小。
If the receiver does not specify the picture size/MPI parameter, then it is safe to assume that it is an implementation that follows RFC 2032. In that case, it is RECOMMENDED to assume that such a receiver is able to support reception of QCIF resolution with MPI=1.
如果接收器未指定picture size/MPI参数，则可以安全地假定它是遵循RFC 2032的实现。在这种情况下，建议假设此类接收器能够支持接收MPI=1的QCIF分辨率。
Parameters offered first are the most preferred picture mode to be received.
首先提供的参数是要接收的最首选图片模式。
An example of media representation in SDP is as follows CIF at 15 frames per second, QCIF at 30 frames per second and annex D
SDP中的媒体表示示例如下：CIF每秒15帧、QCIF每秒30帧和附录D
m=video 49170/2 RTP/AVP 31
a=rtpmap:31 H261/90000
a=fmtp:31 CIF=2;QCIF=1;D=1
m=video 49170/2 RTP/AVP 31
a=rtpmap:31 H261/90000
a=fmtp:31 CIF=2;QCIF=1;D=1
This means that the sender of this message can decode an H.261 bit stream with the following options and parameters: preferred resolution is CIF (its MPI is 2), but if that is not possible, then QCIF size is also supported. Still image using annex D MAY be used.
这意味着此消息的发送方可以使用以下选项和参数解码H.261位流：首选分辨率为CIF（其MPI为2），但如果不可能，则还支持QCIF大小。可以使用使用附件D的静止图像。
The current document replaces RFC 2032. This section will address the major backward compatibility issues.
当前文档将取代RFC 2032。本节将讨论主要的向后兼容性问题。
RFC 2032 defined two H.261-specific RTCP control packets, "Full INTRA-frame Request" and "Negative Acknowledgement". Support of these control packets was optional. The H.261-specific control packets differ from normal RTCP packets in that they are not transmitted to the normal RTCP destination transport address for the RTP session (which is often a multicast address). Instead, these control packets are sent directly via unicast from the decoder to the encoder. The destination port for these control packets is the same port that the encoder uses as a source port for transmitting RTP (data) packets. Therefore, these packets may be considered "reverse" control packets. This memo suggests generic methods to address the same requirement. The authors of the documents are not aware of products that support these control packets. Since these are optional features, new implementations SHALL ignore them, and they SHALL NOT be used by new implementations.
RFC 2032定义了两个特定于H.261的RTCP控制数据包，“完整帧内请求”和“否定确认”。对这些控制数据包的支持是可选的。特定于H.261的控制数据包与正常RTCP数据包的不同之处在于，它们不会被传输到RTP会话的正常RTCP目标传输地址（通常是多播地址）。相反，这些控制包直接通过单播从解码器发送到编码器。这些控制包的目标端口与编码器用作传输RTP（数据）包的源端口的端口相同。因此，这些分组可被视为“反向”控制分组。本备忘录提出了解决相同要求的通用方法。文档的作者不知道支持这些控制数据包的产品。由于这些是可选特性，新实现应忽略它们，新实现不应使用它们。
The document adds new optional parameters to the H261 payload type. Since these are optional parameters, we expect that old implementations ignore these parameters, whereas new implementations that receive the H261 payload type capabilities with no parameters will assume that it is an old implementation and will send H.261 at QCIF resolution and 30 frames per second.
本文档向H261有效负载类型添加了新的可选参数。由于这些是可选参数，我们希望旧的实现忽略这些参数，而接收H261有效负载类型功能（无参数）的新实现将假定它是旧的实现，并将以QCIF分辨率和每秒30帧发送H.261。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and in any appropriate RTP profile (e.g., [RFC3551]). This implies that confidentiality of the media streams is achieved by encryption. SRTP [RFC3711] may be used to provide both encryption and integrity protection of RTP flow. Because the data compression used with this payload format is applied end to end, encryption will be performed after compression, so there is no conflict between the two operations.
使用本规范中定义的有效负载格式的RTP数据包受RTP规范[RFC3550]和任何适当RTP配置文件（例如[RFC3551]）中讨论的安全注意事项的约束。这意味着媒体流的机密性是通过加密实现的。SRTP[RFC3711]可用于提供RTP流的加密和完整性保护。由于与此有效负载格式一起使用的数据压缩是端到端应用的，因此在压缩后将执行加密，因此两个操作之间没有冲突。
A potential denial-of-service threat exists for data encoding using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream that are complex to decode and cause the receiver to be overloaded. The usage of authentication of at least the RTP packet is RECOMMENDED. H.261 is vulnerable to such attacks because it is possible for an attacker to generate RTP packets containing frames that affect the decoding process of future frames. Therefore, the usage of data origin authentication and data integrity protection of at least the RTP packet is RECOMMENDED; for example, with SRTP.
使用具有非均匀接收端计算负载的压缩技术进行数据编码存在潜在的拒绝服务威胁。攻击者可以向流中注入难以解码的病理数据报，并导致接收器过载。建议至少使用RTP数据包的身份验证。H.261容易受到此类攻击，因为攻击者可能生成包含影响未来帧解码过程的帧的RTP数据包。因此，建议使用至少RTP分组的数据源认证和数据完整性保护；例如，使用SRTP。
Note that the appropriate mechanism to ensure confidentiality and integrity of RTP packets and their payloads is very dependent on the application and on the transport and signaling protocols employed. Thus, although SRTP is given as an example above, other possible choices exist.
请注意，确保RTP数据包及其有效负载的机密性和完整性的适当机制非常依赖于应用程序以及所采用的传输和信令协议。因此，尽管上面给出了SRTP作为示例，但存在其他可能的选择。
This is to acknowledge the authors of RFC 2032, Thierry Turletti and Christian Huitema. Special thanks for the work done by Petri Koskelainen from Nokia and Nermeen Ismail from Cisco, who helped with drafting the text for the new MIME types.
这是为了感谢RFC 2032的作者Thierry Turletti和Christian Huitema。特别感谢诺基亚的Petri Koskelainen和思科的Nermeen Ismail所做的工作，他们帮助起草了新MIME类型的文本。
The changes from the RFC 2032 are:
RFC 2032的变化如下：
1. The H.261 MIME type is now in the payload specification.
1. H.261 MIME类型现在在有效负载规范中。
2. Added optional parameters to the H.261 MIME type
2. 在H.261 MIME类型中添加了可选参数
3. Deprecated the H.261 specific control packets
3. 不推荐使用H.261特定的控制数据包
4. Editorial changes to be in line with RFC editing procedures
4. 编辑变更应符合RFC编辑程序
[H261] International Telecommunications Union, "Video codec for audiovisual services at px 64 kbit/s", ITU Recommendation H.261, March 1993.
[H261]国际电信联盟，“用于px 64 kbit/s视听服务的视频编解码器”，国际电联建议H.261，1993年3月。
[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月。
[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月。
[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月。
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[RFC3555]Casner，S.和P.Hoschka，“RTP有效载荷格式的MIME类型注册”，RFC 35552003年7月。
[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月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[ITU.H245] International Telecommunications Union, "CONTROL PROTOCOL FOR MULTIMEDIA COMMUNICATION", ITU Recommendation H.245, 2003.
[ITU.H245]国际电信联盟，“多媒体通信控制协议”，ITU建议H.245，2003年。
[INRIA] Turletti, T., "H.261 software codec for videoconferencing over the Internet", INRIA Research Report 1834, January 1993.
[INRIA]Turletti，T.，“互联网视频会议用H.261软件编解码器”，INRIA研究报告1834，1993年1月。
[IVS] Turletti, T., "INRIA Videoconferencing tool (IVS)", available by anonymous ftp from zenon.inria.fr in the "rodeo/ivs/last_version" directory. See also URL <http://www.inria.fr/rodeo/ivs.html>.
[IVS]Turletti，T.，“INRIA视频会议工具（IVS）”，可通过匿名ftp从zenon.INRIA.fr的“rodeo/IVS/last_version”目录中获得。另请参见URL<http://www.inria.fr/rodeo/ivs.html>.
[BT601] International Telecommunications Union, "Studio encoding parameters of digital television for standard 4:3 and wide-screen 16:9 aspect ratios", ITU-R Recommendation BT.601-5, October 1995.
[BT601]国际电信联盟，“标准4:3和宽屏幕16:9纵横比的数字电视演播室编码参数”，ITU-R建议BT.601-5，1995年10月。
[MICE] Sasse, MA., Bilting, U., Schultz, CD., and T. Turletti, "Remote Seminars through MultiMedia Conferencing: Experiences from the MICE project", Proc. INET'94/JENC5, Prague pp. 251/1-251/8, June 1994.
[MICE]马萨诸塞州萨塞、美国比尔廷、Schultz、CD.和T.Turletti，“通过多媒体会议的远程研讨会：MICE项目的经验”，Proc。内特'94/JENC5，布拉格，第251/1-251/8页，1994年6月。
[VIC] MacCanne, S., "VIC Videoconferencing tool, available by anonymous ftp from ee.lbl.gov in the "conferencing/vic" directory".
[VIC]MacCanne，S.，“VIC视频会议工具，可通过匿名ftp从ee.lbl.gov的“conferencing/VIC”目录中获得”。
[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月。
[H221] International Telecommunications Union, "Frame structure for a 64 to 1920 kbit/s channel in audiovisual teleservices", ITU Recommendation H.221, May 1999.
[H221]国际电信联盟，“视听电信服务中64至1920 kbit/s信道的帧结构”，ITU建议H.221，1999年5月。
Author's Address
作者地址
Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel
Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130以色列
EMail: roni.even@polycom.co.il
EMail: roni.even@polycom.co.il
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）提供。