Network Working Group K. Kobayashi
Request for Comments: 3190 Communication Research Laboratory
Category: Standards Track A. Ogawa
Keio University
S. Casner
Packet Design
C. Bormann
Universitaet Bremen TZI
January 2002
Network Working Group K. Kobayashi
Request for Comments: 3190 Communication Research Laboratory
Category: Standards Track A. Ogawa
Keio University
S. Casner
Packet Design
C. Bormann
Universitaet Bremen TZI
January 2002
RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio
12位DAT音频和20位和24位线性采样音频的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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document specifies a packetization scheme for encapsulating 12-bit nonlinear, 20-bit linear, and 24-bit linear audio data streams using the Real-time Transport Protocol (RTP). This document also specifies the format of a Session Description Protocol (SDP) parameter to indicate when audio data is preemphasized before sampling. The parameter may be used with other audio payload formats, in particular L16 (16-bit linear).
本文件规定了使用实时传输协议（RTP）封装12位非线性、20位线性和24位线性音频数据流的打包方案。本文档还指定了会话描述协议（SDP）参数的格式，以指示音频数据在采样前的预相位化时间。该参数可用于其他音频有效负载格式，特别是L16（16位线性）。
This document describes the sampling of audio data in 12-bit nonlinear, 20-bit linear, and 24-bit linear encodings, and specifies the encapsulation of the audio data into the Real-time Transport Protocol (RTP), version 2 [1,2]. DAT (digital audio tape) and DV (digital video) devices [3,4] use these audio encodings in addition to 16-bit linear encoding. The packetization scheme for 16-bit linear audio (L16) is already specified [2,5]. This document specifies the packetization scheme for the other encodings following that for L16; in particular, when used with the RTP profile [2], these payload formats follow the encoding-independent rules for
本文件描述了12位非线性、20位线性和24位线性编码中音频数据的采样，并规定了音频数据封装到实时传输协议（RTP）版本2[1,2]中。DAT（数字音频磁带）和DV（数字视频）设备[3,4]除了使用16位线性编码外，还使用这些音频编码。已经指定了16位线性音频（L16）的分组方案[2,5]。本文件规定了L16之后的其他编码的打包方案；特别是，当与RTP配置文件[2]一起使用时，这些有效负载格式遵循与编码无关的规则
sample ordering and channel interleaving specified in [2] plus extensions specified here. This document also specifies out-of-band negotiation methods for the extended channel interleaving rules and for use when an analog preemphasis technique is applied to the audio data.
[2]中指定的样本排序和通道交错加上此处指定的扩展。本文件还规定了扩展信道交织规则的带外协商方法，以及对音频数据应用模拟预相位技术时使用的带外协商方法。
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 [6]
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[6]中所述进行解释
Many high-quality digital audio and visual systems, such as DAT and DV, adopt sample-based audio encodings. Different audio formats are used in various situations. To transport the audio data using RTP, an encapsulation needs to be defined for each specific format. Only 16-bit linear audio encapsulation (L16) has thus far been defined. Other encoding formats have already appeared, such as the 12-bit nonlinear, 20-bit linear and 24-bit linear encodings used in the DAT and DV video world. This specification defines the RTP payload encapsulation format in order to use the new encodings in the RTP environment.
许多高质量的数字音频和视频系统，如DAT和DV，都采用基于样本的音频编码。在各种情况下使用不同的音频格式。要使用RTP传输音频数据，需要为每个特定格式定义封装。迄今为止，仅定义了16位线性音频封装（L16）。其他编码格式已经出现，例如在DAT和DV视频世界中使用的12位非线性、20位线性和24位线性编码。本规范定义了RTP有效负载封装格式，以便在RTP环境中使用新编码。
IEC 61119 [3] specifies the 12-bit nonlinear audio format in DAT and DV, called LP (Long Play) audio. It would be easy to convert 12-bit nonlinear audio into 16-bit linear form at the RTP sender and transmit it using the L16 audio format already defined. However, this would consume 33% more network bandwidth than necessary. This payload format is specified as a more efficient alternative.
IEC 61119[3]规定了DAT和DV中的12位非线性音频格式，称为LP（长播放）音频。在RTP发送方将12位非线性音频转换为16位线性形式，并使用已经定义的L16音频格式进行传输是很容易的。然而，这将消耗比需要多33%的网络带宽。此有效负载格式被指定为更有效的替代方案。
The 12-bit nonlinear encoding is the same as for 16-bit linear audio except for the packing of each sampled data element. Each sample of 12-bit nonlinear audio is derived from a single sample of 16-bit linear audio by a nonlinear compression. Table 1 shows the details of the conversion from 16 to 12 bits. The result is a 12-bit signed value ranging from -2048 to 2047 and it is represented in two's complement notation. The 12-bit samples are packed contiguously into payload octets starting with the most significant bit. When the payload contains an odd number of samples, the four LSBs of the last octet are unused. Parameters other than quantization, e.g., sampling frequency and audio channel assignment, are the same as in the L16 payload format. In particular, samples are packed into the packet in time sequence beginning with the oldest sample.
12位非线性编码与16位线性音频相同，只是每个采样数据元素的包装不同。12位非线性音频的每个样本通过非线性压缩从16位线性音频的单个样本中导出。表1显示了从16位到12位的转换细节。结果是一个从-2048到2047的12位有符号值，它用2的补码表示法表示。12位样本从最高有效位开始连续打包到有效负载八位字节中。当有效负载包含奇数个样本时，最后一个八位组的四个LSB未使用。量化以外的参数，例如采样频率和音频信道分配，与L16有效载荷格式中的参数相同。特别是，样本从最早的样本开始按时间顺序打包到数据包中。
------------------------------------------------------------
32,767 (7FFFh) Y = INT(X/64) + (600h) 2,047 (7FFh)
16,384 (4000h) 1,792 (700h)
------------------------------------------------------------
16,383 (3FFFh) Y = INT(X/32) + (500h) 1,791 (6FFh)
8,192 (2000h) 1,536 (600h)
------------------------------------------------------------
8,191 (1FFFh) Y = INT(X/16) + (400h) 1,535 (5FFh)
4,096 (1000h) 1,280 (500h)
------------------------------------------------------------
4,095 (0FFFh) Y = INT(X/8) + (300h) 1,279 (4FFh)
2,048 (0800h) 1,024 (400h)
------------------------------------------------------------
2,047 (07FFh) Y = INT(X/4) + (200h) 1,023 (3FFh)
1,024 (0400h) 768 (300h)
------------------------------------------------------------
1,023 (03FFh) Y = INT(X/2) + (100h) 767 (2FFh)
512 (0200h) 512 (200h)
------------------------------------------------------------
511 (01FFh) Y = X 511 (1FFh)
0 (0000h) 0 (000h)
------------------------------------------------------------
-1 (FFFFh) Y = X -1 (FFFh)
-512 (FE00h) -512 (E00h)
------------------------------------------------------------
-513 (FFFFh) Y = INT((X + 1)/2) - (101h) -513 (DFFh)
-1,024 (FE00h) -768 (D00h)
------------------------------------------------------------
-1,025 (FBFFh) Y = INT((X + 1)/4) - (201h) -769 (CFFh)
-2,048 (F800h) -1,024 (C00h)
------------------------------------------------------------
-2,049 (F7FFh) Y = INT((X + 1)/8) - (301h) -1,025 (BFFh)
-4,096 (F000h) -1,280 (B00h)
------------------------------------------------------------
-4,097 (EFFFh) Y = INT((X + 1)/16) - (401h) -1,281 (AFFh)
-8,192 (E000h) -1,536 (A00h)
------------------------------------------------------------
-8,193 (DFFFh) Y = INT((X + 1)/32) - (501h) -1,537 (9FFh)
-16,384 (C000h) -1,792 (900h)
------------------------------------------------------------
-16,385 (BFFFh) Y = INT((X + 1)/64) - (601h) -1,793 (8FFh)
-32,768 (8000h) -2,048 (800h)
------------------------------------------------------------
------------------------------------------------------------
32,767 (7FFFh) Y = INT(X/64) + (600h) 2,047 (7FFh)
16,384 (4000h) 1,792 (700h)
------------------------------------------------------------
16,383 (3FFFh) Y = INT(X/32) + (500h) 1,791 (6FFh)
8,192 (2000h) 1,536 (600h)
------------------------------------------------------------
8,191 (1FFFh) Y = INT(X/16) + (400h) 1,535 (5FFh)
4,096 (1000h) 1,280 (500h)
------------------------------------------------------------
4,095 (0FFFh) Y = INT(X/8) + (300h) 1,279 (4FFh)
2,048 (0800h) 1,024 (400h)
------------------------------------------------------------
2,047 (07FFh) Y = INT(X/4) + (200h) 1,023 (3FFh)
1,024 (0400h) 768 (300h)
------------------------------------------------------------
1,023 (03FFh) Y = INT(X/2) + (100h) 767 (2FFh)
512 (0200h) 512 (200h)
------------------------------------------------------------
511 (01FFh) Y = X 511 (1FFh)
0 (0000h) 0 (000h)
------------------------------------------------------------
-1 (FFFFh) Y = X -1 (FFFh)
-512 (FE00h) -512 (E00h)
------------------------------------------------------------
-513 (FFFFh) Y = INT((X + 1)/2) - (101h) -513 (DFFh)
-1,024 (FE00h) -768 (D00h)
------------------------------------------------------------
-1,025 (FBFFh) Y = INT((X + 1)/4) - (201h) -769 (CFFh)
-2,048 (F800h) -1,024 (C00h)
------------------------------------------------------------
-2,049 (F7FFh) Y = INT((X + 1)/8) - (301h) -1,025 (BFFh)
-4,096 (F000h) -1,280 (B00h)
------------------------------------------------------------
-4,097 (EFFFh) Y = INT((X + 1)/16) - (401h) -1,281 (AFFh)
-8,192 (E000h) -1,536 (A00h)
------------------------------------------------------------
-8,193 (DFFFh) Y = INT((X + 1)/32) - (501h) -1,537 (9FFh)
-16,384 (C000h) -1,792 (900h)
------------------------------------------------------------
-16,385 (BFFFh) Y = INT((X + 1)/64) - (601h) -1,793 (8FFh)
-32,768 (8000h) -2,048 (800h)
------------------------------------------------------------
Table 1. Conversion from 16-bit linear values (X) to 12-bit nonlinear values (Y) [3]
表1。从16位线性值（X）到12位非线性值（Y）的转换[3]
When conveying encoding information in an SDP [7] session description, the 12-bit nonlinear audio payload format specified here is given the encoding name "DAT12". Thus, the media format representation might be:
在SDP[7]会话描述中传输编码信息时，此处指定的12位非线性音频有效负载格式被赋予编码名称“DAT12”。因此，媒体格式表示可以是：
m=audio 49230 RTP/AVP 97 98
a=rtpmap:97 DAT12/32000/2
a=rtpmap:98 L16/48000/2
m=audio 49230 RTP/AVP 97 98
a=rtpmap:97 DAT12/32000/2
a=rtpmap:98 L16/48000/2
The 20- and 24-bit linear audio encodings are simply an extension of the L16 linear audio encoding [2]. The 20- or 24-bit uncompressed audio data samples are represented as signed values in two's complement notation. The samples are packed contiguously into payload octets starting with the most significant bit. For the 20-bit encoding, when the payload contains an odd number of samples, the four LSBs of the last octet are unused. Samples are packed into the packet in time sequence beginning with the oldest sample.
20位和24位线性音频编码只是L16线性音频编码的扩展[2]。20位或24位未压缩音频数据样本以2的补码表示法表示为有符号值。样本以最高有效位开始连续打包到有效负载八位字节中。对于20位编码，当有效负载包含奇数个样本时，最后八位字节的四个LSB未使用。样本以最早的样本开始的时间顺序打包到数据包中。
When conveying encoding information in an SDP session description, the 20- and 24-bit linear audio payload formats specified here are given the encoding names "L20" and "L24", respectively. An example SDP audio media description would be:
当在SDP会话描述中传送编码信息时，这里指定的20位和24位线性音频有效负载格式分别被赋予编码名称“L20”和“L24”。SDP音频媒体描述示例如下：
m=audio 49230 RTP/AVP 99 100
a=rtpmap:99 L20/48000/2
a=rtpmap:100 L24/48000
m=audio 49230 RTP/AVP 99 100
a=rtpmap:99 L20/48000/2
a=rtpmap:100 L24/48000
In order to improve the higher frequency characteristics of audio signals, analog preemphasis is often applied to the signal before quantization. If analog preemphasis was applied before the payload data was sampled, the type of the preemphasis SHOULD be conveyed with out-of-band signaling. An "emphasis" parameter is defined for this purpose and may be conveyed either as a MIME optional parameter or using the SDP format-specific attribute (a=fmtp line) as below:
为了改善音频信号的高频特性，通常在量化前对信号进行模拟预相位处理。如果在对有效负载数据进行采样之前应用了模拟预相位，则预相位的类型应通过带外信号传输。为此定义了“emphasis”参数，该参数可以作为MIME可选参数或使用SDP格式特定属性（a=fmtp行）传递，如下所示：
a=fmtp:<payload type> emphasis=<emphasis type>
a=fmtp:<payload type> emphasis=<emphasis type>
Only one <emphasis type> value is defined for the parameter at this point:
此时仅为参数定义了一个<emphasis type>值：
50-15 <50/15 microsecond CD-type emphasis>
50-15 <50/15 microsecond CD-type emphasis>
The emphasis attribute MUST NOT be included in the SDP record if preemphasis was not applied. This rule allows the emphasis attribute to be used with other audio formats, in particular L16 [2], while retaining backward compatibility with existing implementations so long as preemphasis is not applied. If an existing application that does not implement preemphasis accepts a session description with an emphasis attribute but ignores that attribute, the only penalty is that the sound will be too "bright" when receiving or "dull" when sending.
如果未应用preemphasis，则SDP记录中不得包含emphasis属性。此规则允许emphasis属性与其他音频格式一起使用，特别是L16[2]，同时只要不应用preemphasis，就可以保持与现有实现的向后兼容性。如果未实现preemphasis的现有应用程序接受带有emphasis属性的会话描述，但忽略该属性，则唯一的惩罚是接收时声音太“亮”，发送时声音太“暗”。
A sample SDP record showing preemphasis applied only to payload type 99 might be as follows:
显示预相位仅适用于有效负载类型99的示例SDP记录可能如下所示：
m=audio 49230 RTP/AVP 99 100
a=rtpmap:99 L20/48000/2
a=fmtp:99 emphasis=50-15
a=rtpmap:100 L24/48000
m=audio 49230 RTP/AVP 99 100
a=rtpmap:99 L20/48000/2
a=fmtp:99 emphasis=50-15
a=rtpmap:100 L24/48000
The DV video specification IEC 61834-4 [4] defines the negative full-scale audio sample value to be an audio error code indicating that no valid audio sample is available for that sample period. Such an error might occur due to a failure while reading audio data from magnetic tape. The audio error code values for each of the DV audio encodings are (in hexadecimal):
DV视频规范IEC 61834-4[4]将负满标度音频采样值定义为音频错误代码，指示该采样周期内没有有效的音频采样可用。这种错误可能是由于从磁带读取音频数据时发生故障而导致的。每个DV音频编码的音频错误代码值为（十六进制）：
12-bit nonlinear: 800h 16-bit linear: 8000h 20-bit linear: 80000h
12位非线性：800h 16位线性：8000h 20位线性：80000h
For the payload formats defined in this document, as well as for the L16 payload format defined in [2], no such error code is defined. That is, all possible sample values are valid. When an RTP sender accepts audio samples from a DV video system and encapsulates those samples according to one of these payload formats, the RTP sender SHOULD perform some error concealment algorithm which may depend upon whether a single sample error or multiple sample errors have occurred. The error concealment algorithm is not specified here and is left to the implementation. The RTP sender MAY treat the error code as if it were a valid audio sample, but this is likely to cause undesirable audio output.
对于本文件中定义的有效载荷格式以及[2]中定义的L16有效载荷格式，未定义此类错误代码。也就是说，所有可能的样本值都是有效的。当RTP发送方从DV视频系统接收音频样本并根据这些有效载荷格式之一封装这些样本时，RTP发送方应执行一些错误隐藏算法，这可能取决于是否发生了单个样本错误或多个样本错误。这里没有指定错误隐藏算法，而是留给实现。RTP发送方可能会将错误代码视为有效的音频样本，但这可能会导致不良的音频输出。
Conversely, an RTP receiver that accepts audio packets in one of these payload formats and delivers the audio samples to a DV video system SHOULD translate the audio samples that would be interpreted as error codes into the next smaller negative audio value. Such audio samples may be present because the audio packets may have come
相反，接收这些有效载荷格式之一的音频分组并将音频样本传送到DV视频系统的RTP接收机应将将被解释为错误码的音频样本转换为下一个较小的负音频值。这样的音频样本可能存在，因为音频分组可能已经到来
from a source other than a DV video system. The DV video specification [4] gives the following translations for the defined audio encodings:
来自DV视频系统以外的源。DV视频规范[4]给出了定义音频编码的以下翻译：
12-bit nonlinear: 800h -> 801h
16-bit linear: 8000h -> 8001h
20-bit linear: 80000h - 8000Fh -> 80010h
12-bit nonlinear: 800h -> 801h
16-bit linear: 8000h -> 8001h
20-bit linear: 80000h - 8000Fh -> 80010h
For the 20-bit linear encoding, note that multiple audio sample values are translated in order to allow a 16-bit system to play 20- bit audio data by ignoring the least significant four bits. Note also that no translation is specified for 24-bit linear audio because that encoding is not included in the DV video specification.
对于20位线性编码，请注意多个音频采样值被转换，以便允许16位系统通过忽略最低有效位的四位来播放20位音频数据。还请注意，没有为24位线性音频指定翻译，因为该编码不包括在DV视频规范中。
When multiple channels of audio, such as in a stereo program, are multiplexed into a single RTP stream, the audio samples from each channel are interleaved according to the rules specified in [2] to be consistent with the L16 payload format. That is, samples from different channels taken at the same sampling instant are packed into consecutive octets. For example, for a two-channel encoding, the sample sequence is (left channel, first sample), (right channel, first sample), (left channel, second sample), (right channel, second sample). Samples for all channels belonging to a single sampling instant MUST be contained in the same packet.
当诸如立体声节目中的多个音频信道被多路复用到单个RTP流中时，来自每个信道的音频样本根据[2]中指定的规则进行交织，以与L16有效负载格式一致。也就是说，在同一采样瞬间采集的来自不同通道的样本被打包成连续的八位组。例如，对于双通道编码，样本序列是（左通道，第一个样本），（右通道，第一个样本），（左通道，第二个样本），（右通道，第二个样本）。属于单个采样瞬间的所有通道的采样必须包含在同一数据包中。
This sample order differs from the packing of samples into blocks in a native DV audio stream. Therefore, applications transmitting DV audio using the payload formats defined in this document MUST reshuffle the samples into the order specified here. This requirement is intended to enable interworking between DV systems and other digital audio systems. Applications choosing to send bundled DV audio/video streams using the native DV block structure may use the payload format defined in [8] instead.
此样本顺序不同于将样本打包到本地DV音频流中的块中。因此，使用本文档中定义的有效负载格式传输DV音频的应用程序必须按照此处指定的顺序重新排列样本。本要求旨在实现DV系统和其他数字音频系统之间的互通。选择使用本机DV块结构发送捆绑DV音频/视频流的应用程序可以使用[8]中定义的有效负载格式。
Most of the existing RTP audio payload formats follow the AIFF-C convention for channel ordering as specified in [2] when sending more than two audio channels within a single RTP stream. However, this convention does not cover some applications. For example, some DV audio formats define a "woofer" channel, but AIFF-C does not include this frequency-dependent channel. Thus, it is necessary to specify the audio channel allocation information explicitly when the contents of the audio stream are beyond the scope of AIFF-C.
当在单个RTP流中发送两个以上的音频通道时，大多数现有RTP音频有效负载格式遵循[2]中规定的AIFF-C通道顺序约定。然而，本公约不包括某些应用。例如，某些DV音频格式定义了一个“低音扬声器”频道，但AIFF-C不包括此频率相关频道。因此，当音频流的内容超出AIFF-C的范围时，有必要明确地指定音频信道分配信息。
For DV audio streams of 4 or more channels, the channel order MUST be specified out-of-band. This applies both to the payload formats defined in this document and to the L16 payload format. A "channel-
对于4个或更多频道的DV音频流，必须在带外指定频道顺序。这既适用于本文档中定义的有效负载格式，也适用于L16有效负载格式。"频道"-
order" parameter is defined here for this purpose and may be conveyed either as a MIME optional parameter or with the SDP a=fmtp attribute using the following syntax:
“顺序”参数在此处定义用于此目的，可以作为MIME可选参数或使用以下语法与SDP a=fmtp属性一起传递：
a=fmtp:<payload type> channel-order=<convention>.<order>
a=fmtp:<payload type> channel-order=<convention>.<order>
The first component of the value, <convention>, specifies the type of channel assignment convention used. This allows for conventions other than AIFF-C and DV to be defined in the future. This document defines only one convention for use in the channel-order parameter:
值的第一个组件<约定>，指定所使用的信道分配约定的类型。这允许将来定义AIFF-C和DV以外的约定。本文档仅定义了一种用于channel order参数的约定：
DV
数码摄像
The second component of the value, <order>, indicates the arrangement of channels within the stream. The DV video specification [4] defines the types of audio channels that may be present and in what order. The symbols used to denote the channel types are reproduced in the Appendix at the end of this document. For the DV convention, the following values, which were formed from the concatenation of the individual channel symbols in the allowed channel orders, are defined for the <order> component:
值的第二个分量，<order>，表示流中通道的排列。DV视频规范[4]定义了可能存在的音频通道的类型以及顺序。本文件末尾的附录中再现了用于表示通道类型的符号。对于DV约定，为<order>组件定义了以下值，这些值由允许的信道顺序中的各个信道符号串联而成：
4 channels: LRLsRs, LRCS, LRCWo 5 channels: LRLsRsC 6 channels: LRLsRsCS, LmixRmixTWoQ1Q2 8 channels: LRCWoLsRsLmixRmix, LRCWoLs1Rs1Ls2Rs2, LRCWoLsRsLcRc
4个通道：LRLsRs、LRCS、LRCWo 5个通道：LRLsRsC 6个通道：LRLsRsCS、LmixRmixTWoQ1Q2 8个通道：LRCWoLsRsLmixRmix、LRCWoLs1Rs1Ls2Rs2、LRCWoLsRsLcRc
The <convention> and <order> symbols are case-insensitive, but are shown here in mixed case to make the individual channel symbols more apparent. These concatenated symbols were deliberately constructed without separators to make clear the fact that the channels MUST NOT be assembled in other, arbitrary orders.
<convention>和<order>符号不区分大小写，但此处以混合大小写显示，以使单个通道符号更明显。这些连接符号是故意构造的，没有分隔符，以明确通道不能以其他任意顺序组装的事实。
For interworking with DV video systems, some of the audio encodings are defined only for a subset of the channel combinations listed above. The DV video specification lists the channel combinations that are allowed for each encoding.
对于与DV视频系统的互通，一些音频编码仅为上面列出的频道组合的子集定义。DV视频规范列出了每个编码允许的频道组合。
The channel-order parameter MUST be consistent with the number of channels specified in the MIME optional parameter "channels" or in the a=rtpmap attribute of SDP. For RTP audio streams of 1, 2 or 3 channels, the AIFF-C channel order is used and is implicit in the number of audio channels specified. To allow backward compatibility, the channel-order parameter MUST NOT be included in this case.
通道顺序参数必须与MIME可选参数“通道”或SDP的a=rtpmap属性中指定的通道数一致。对于1个、2个或3个通道的RTP音频流，使用AIFF-C通道顺序，并隐含在指定的音频通道数中。为了允许向后兼容，在这种情况下不得包括channel order参数。
Note that for the DV convention with 5 channels only one channel order is allowed, but for consistency the channel-order parameter MUST be included nonetheless.
请注意，对于具有5个通道的DV约定，仅允许一个通道顺序，但为了一致性，必须包括通道顺序参数。
An example of an SDP session description using the channel-order parameter is:
使用通道顺序参数的SDP会话描述示例如下：
v=0
o=ikob 2890844526 2890842807 IN IP4 126.16.64.4
s=POI (Audio only)
i=A Seminar on making Presentations on the Internet
u=http://www.koganei.wide.ad.jp/~ikob/POI/index.html
e=ikob@koganei.wide.ad.jp (Katsushi Kobayashi)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
m=audio 49170 RTP/AVP 112 113
a=rtpmap:112 L16/48000/2
a=rtpmap:113 DAT12/32000/4
a=fmtp:113 emphasis=50-15; channel-order=DV.LRCWO
v=0
o=ikob 2890844526 2890842807 IN IP4 126.16.64.4
s=POI (Audio only)
i=A Seminar on making Presentations on the Internet
u=http://www.koganei.wide.ad.jp/~ikob/POI/index.html
e=ikob@koganei.wide.ad.jp (Katsushi Kobayashi)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
m=audio 49170 RTP/AVP 112 113
a=rtpmap:112 L16/48000/2
a=rtpmap:113 DAT12/32000/4
a=fmtp:113 emphasis=50-15; channel-order=DV.LRCWO
This session description shows the audio medium being transmitted in two formats, L16 and DAT12, using payload type numbers 112 and 113, respectively. For the L16 format, the audio data contains 2-channel stereo following the implicit, default AIFF-C convention for left channel first and right channel second. For the DAT12 format, the audio data contains 4 channels following the DV audio convention for the channels left, right, center, and woofer.
此会话描述分别使用有效负载类型编号112和113，以两种格式L16和DAT12显示正在传输的音频媒体。对于L16格式，音频数据包含2声道立体声，遵循左声道第一声道和右声道第二声道的隐式默认AIFF-C约定。对于DAT12格式，音频数据包含4个符合DV音频约定的声道，分别为左声道、右声道、中声道和低音扬声器。
This example also shows how multiple MIME optional parameters ("emphasis" and "channel-order") for these payload formats are mapped to a single a=fmtp attribute as a semicolon separated list of parameter=value pairs.
该示例还显示了如何将这些有效负载格式的多个MIME可选参数（“emphasis”和“channel order”）映射到单个a=fmtp属性，作为参数=值对的分号分隔列表。
The channel-order parameter described here provides a generic out-of-band mechanism to define alternatives to the AIFF-C channel order. However, if multi-channel audio data could be sent following the AIFF-C channel convention after simple processing, such as a data shuffling on the sender side, the alternative channel order SHOULD NOT be defined and instead the AIFF-C order SHOULD be employed to maximize interoperability.
此处描述的信道顺序参数提供了一种通用的带外机制，用于定义AIFF-C信道顺序的替代方案。但是，如果经过简单处理（如发送方端的数据洗牌）后，可以按照AIFF-C通道约定发送多通道音频数据，则不应定义替代通道顺序，而应采用AIFF-C顺序以最大限度地提高互操作性。
Moreover, multiple channels of audio data should only be multiplexed within a single RTP stream when all of the audio channels are intended to be reproduced together, such as the left and right channels in a stereo program. Independent audio channels, such as multiple language translations, SHOULD be sent in separate RTP sessions. This reduces bandwidth requirements by allowing receivers to tune in to only those channels which are desired.
此外，当所有音频通道（例如立体声节目中的左声道和右声道）打算一起再现时，仅应在单个RTP流中多路复用多个音频数据通道。独立的音频通道，如多语言翻译，应在单独的RTP会话中发送。这通过允许接收机仅调谐到所需的信道来降低带宽要求。
This document defines some new RTP payload format names which are also registered as MIME subtypes: DAT12, L20 and L24. The registration forms for these MIME subtypes are provided in the next sections.
本文档定义了一些新的RTP有效负载格式名称，这些名称也注册为MIME子类型：DAT12、L20和L24。这些MIME子类型的注册表格将在下一节中提供。
MIME media type name: audio
MIME媒体类型名称：音频
MIME subtype name: DAT12
MIME子类型名称：DAT12
Required parameters: rate: number of samples per second -- RECOMMENDED values for rate are 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000 samples per second. Other values are permissible.
所需参数：速率：每秒采样数--速率的建议值为每秒8000、11025、16000、22050、24000、32000、44100和48000个样本。其他值是允许的。
Optional parameters: channels: how many audio streams are interleaved -- defaults to 1; stereo would be 2, etc. Interleaving takes place between individual 12-bit samples.
可选参数：通道：交错的音频流数量——默认为1；立体声将是2，等等。交错发生在单个12位采样之间。
emphasis: analog preemphasis applied to the data before quantization. The only emphasis value defined here is emphasis=50-15 to indicate 50/15 microsecond preemphasis. This parameter MUST be omitted if no analog preemphasis was applied.
重点：模拟预相位在量化之前应用于数据。此处定义的唯一强调值为emphasis=50-15，表示50/15微秒的预相位。如果未应用模拟预相位，则必须忽略此参数。
channel-order: specifies the sample interleaving order for multiple-channel audio streams (see RFC 3190 Section 7). Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc. For interoperation with DV video systems, only a subset of these channel combinations is specified for use with 12-bit nonlinear encoding in the DV video specification [4]; that subset is all of the above except DV.LmixRmixTWoQ1Q2. This parameter MUST be omitted when the AIFF-C channel order convention is in use.
通道顺序：指定多通道音频流的示例交错顺序（请参阅RFC 3190第7节）。允许值为DV.LRLsRs、DV.LRCS、DV.LRCWo、DV.LRLsRsC、DV.LRLsRsCS、DV.LMixrimxtWOQ1Q2、DV.LRCWoLsRsLmixRmix、DV.LRCWoLs1Rs1Ls2Rs2、DV.LRCWoLsRsLcRc。对于与DV视频系统的互操作，在DV视频规范[4]中，仅指定了这些信道组合的子集用于12位非线性编码；该子集是除DV.lmixrimxtwoq1q2之外的所有上述内容。当使用AIFF-C通道顺序约定时，必须忽略此参数。
Encoding considerations: DAT12 audio can be transmitted with RTP as specified in RFC 3190.
编码注意事项：按照RFC3190的规定，DAT12音频可以通过RTP传输。
Security considerations: See Section 9.
安全注意事项：见第9节。
Interoperability considerations: NONE
互操作性注意事项：无
Published specification: IEC 61119 Standard [4] and RFC 3190.
出版规范：IEC 61119标准[4]和RFC 3190。
Applications which use this media type: Audio communication.
使用此媒体类型的应用程序：音频通信。
Additional information:
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
Additional information:
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
Person & email address to contact for further information: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
联系人和电子邮件地址以获取更多信息：Katsushi Kobayashi电子邮件：ikob@koganei.wide.ad.jp
Intended usage: COMMON
预期用途：普通
Author/Change controller: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
作者/变更控制员：Katsushi Kobayashi电子邮件：ikob@koganei.wide.ad.jp
MIME media type name: audio
MIME媒体类型名称：音频
MIME subtype name: L20
MIME子类型名称：L20
Required parameters: rate: number of samples per second -- RECOMMENDED values for rate are 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000 samples per second. Other values are permissible.
所需参数：速率：每秒采样数--速率的建议值为每秒8000、11025、16000、22050、24000、32000、44100和48000个样本。其他值是允许的。
Optional parameters: channels: how many audio streams are interleaved -- defaults to 1; stereo would be 2, etc. Interleaving takes place between individual 20-bit samples.
可选参数：通道：交错的音频流数量——默认为1；立体声将是2，等等。交错发生在单个20位采样之间。
emphasis: analog preemphasis applied to the data before quantization. The only emphasis value defined here is emphasis=50-15 to indicate 50/15 microsecond preemphasis. This parameter MUST be omitted if no analog preemphasis was applied.
重点：模拟预相位在量化之前应用于数据。此处定义的唯一强调值为emphasis=50-15，表示50/15微秒的预相位。如果未应用模拟预相位，则必须忽略此参数。
channel-order: specifies the sample interleaving order for multiple-channel audio streams (see RFC 3190 Section 7). Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc. For interoperation with DV video systems, none of these channel
通道顺序：指定多通道音频流的示例交错顺序（请参阅RFC 3190第7节）。允许值为DV.LRLsRs、DV.LRCS、DV.LRCWo、DV.LRLsRsC、DV.LRLsRsCS、DV.LMixrimxtWOQ1Q2、DV.LRCWoLsRsLmixRmix、DV.LRCWoLs1Rs1Ls2Rs2、DV.LRCWoLsRsLcRc。为了与DV视频系统进行互操作，这些通道
combinations is specified for use with 20-bit linear encoding in the DV video specification [4]; only mono and stereo are allowed. This parameter MUST be omitted when the AIFF-C channel order convention is in use.
在DV视频规范[4]中指定了与20位线性编码一起使用的组合；只允许单声道和立体声。当使用AIFF-C通道顺序约定时，必须忽略此参数。
Encoding considerations: L20 audio can be transmitted with RTP as specified in RFC 3190.
编码注意事项：根据RFC3190的规定，L20音频可以通过RTP传输。
Security considerations: See Section 9.
安全注意事项：见第9节。
Interoperability considerations: NONE
互操作性注意事项：无
Published specification: RFC 3190.
已发布规范：RFC3190。
Applications which use this media type: Audio communication.
使用此媒体类型的应用程序：音频通信。
Additional information:
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
Additional information:
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
Person & email address to contact for further information: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
联系人和电子邮件地址以获取更多信息：Katsushi Kobayashi电子邮件：ikob@koganei.wide.ad.jp
Intended usage: COMMON
预期用途：普通
Author/Change controller: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
作者/变更控制员：Katsushi Kobayashi电子邮件：ikob@koganei.wide.ad.jp
MIME media type name: audio
MIME媒体类型名称：音频
MIME subtype name: L24
MIME子类型名称：L24
Required parameters: rate: number of samples per second -- RECOMMENDED values for rate are 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000 samples per second. Other values are permissible.
所需参数：速率：每秒采样数--速率的建议值为每秒8000、11025、16000、22050、24000、32000、44100和48000个样本。其他值是允许的。
Optional parameters: channels: how many audio streams are interleaved -- defaults to 1; stereo would be 2, etc. Interleaving takes place between individual 24-bit samples.
可选参数：通道：交错的音频流数量——默认为1；立体声将是2，等等。交错发生在单个24位采样之间。
emphasis: analog preemphasis applied to the data before quantization. The only emphasis value defined here is emphasis=50-15 to indicate 50/15 microsecond preemphasis. This parameter MUST be omitted if no analog preemphasis was applied.
重点：模拟预相位在量化之前应用于数据。此处定义的唯一强调值为emphasis=50-15，表示50/15微秒的预相位。如果未应用模拟预相位，则必须忽略此参数。
channel-order: specifies the sample interleaving order for multiple-channel audio streams (see Section 7). Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc. This parameter MUST be omitted when the AIFF-C channel order convention is in use.
通道顺序：指定多通道音频流的示例交错顺序（参见第7节）。允许值为DV.LRLsRs、DV.LRCS、DV.LRCWo、DV.LRLsRsC、DV.LRLsRsCS、DV.LMixrimxtWOQ1Q2、DV.LRCWoLsRsLmixRmix、DV.LRCWoLs1Rs1Ls2Rs2、DV.LRCWoLsRsLcRc。当使用AIFF-C通道顺序约定时，必须忽略此参数。
Encoding considerations: L24 audio can be transmitted with RTP as specified in RFC 3190.
编码注意事项：L24音频可以按照RFC3190中的规定使用RTP传输。
Security considerations: See Section 9.
安全注意事项：见第9节。
Interoperability considerations: NONE
互操作性注意事项：无
Published specification: RFC 3190.
已发布规范：RFC3190。
Applications which use this media type: Audio communication.
使用此媒体类型的应用程序：音频通信。
Additional information:
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
Additional information:
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
Person & email address to contact for further information: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
联系人和电子邮件地址以获取更多信息：Katsushi Kobayashi电子邮件：ikob@koganei.wide.ad.jp
Intended usage: COMMON
预期用途：普通
Author/Change controller: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
作者/变更控制员：Katsushi Kobayashi电子邮件：ikob@koganei.wide.ad.jp
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [1], and any appropriate RTP profile [2]. This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used along with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
使用本规范中定义的有效负载格式的RTP数据包受RTP规范[1]和任何适当RTP配置文件[2]中讨论的安全注意事项的约束。这意味着媒体流的机密性是通过加密实现的。由于与此有效负载格式一起使用的数据压缩是端到端应用的，因此可以在压缩之后执行加密，因此两个操作之间没有冲突。
A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. However, this encoding does not exhibit any significant non-uniformity.
使用压缩技术的数据编码存在潜在的拒绝服务威胁，这种压缩技术具有非均匀的接收端计算负载。攻击者可以向流中注入病理数据报，这些数据报解码复杂，并导致接收器过载。然而，这种编码并没有表现出任何显著的非均匀性。
As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [9] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
与任何基于IP的协议一样，在某些情况下，接收机可能仅仅因为接收了太多的数据包而过载，不管是想要的还是不想要的。网络层认证可用于丢弃来自不希望的源的数据包，但认证本身的处理成本可能过高。在多播环境中，可以在IGMP[9]的未来版本和多播路由协议中实现特定源的修剪，以允许接收机选择允许哪些源到达它。
This document defines two new MIME subtype-specific optional parameters "emphasis" and "channel-order", which are specified with the sets of permissible values for those parameters in Sections 5 and 7, respectively. Section 8 includes registrations for three new MIME subtypes that use those optional parameters. These registrations define the subset of the optional parameter values allowed for each subtype. It is expected that the number of additional values that will need to be defined for these optional parameters is small. Therefore, anyone wishing to define new values is required to produce a revision of this document to be vetted through the normal Internet Standards process.
本文档定义了两个新的MIME子类型特定的可选参数“emphasis”和“channel order”，这两个参数分别在第5节和第7节中用这些参数的允许值集指定。第8节包括使用这些可选参数的三个新MIME子类型的注册。这些注册定义了每个子类型允许的可选参数值的子集。预计需要为这些可选参数定义的附加值数量较少。因此，任何希望定义新值的人都需要对本文件进行修订，以通过正常的互联网标准流程进行审查。
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for real-time applications," RFC 1889, January 1996.
[1] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[2] H. Schulzrinne, "RTP profile for audio and video conferences with minimal control", RFC 1890, January 1996.
[2] H.Schulzrinne，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 1890，1996年1月。
[3] IEC 61119, Digital audio tape cassette system (DAT), November 1992.
[3] IEC 61119，数字音频盒式磁带系统（DAT），1992年11月。
[4] IEC 61834, Helical-scan digital video cassette recording system using 6,35 mm magnetic tape for consumer use (525-60, 625-50, 1125-60 and 1250-50 systems), August 1998.
[4] IEC 61834，使用6.35mm磁带的消费者用螺旋扫描数字盒式录像系统（525-60、625-50、1125-60和1250-50系统），1998年8月。
[5] Salsman, J., "The Audio/L16 MIME content type", RFC 2586, May 1999.
[5] Salsman，J.，“音频/L16 MIME内容类型”，RFC2586，1999年5月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[7] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[8] Kobayashi, K., Ogawa, A., Casner, S. and C. Bormann, "RTP Payload Format for DV (IEC 61834) Video", RFC 3189, January 2002.
[8] Kobayashi，K.，Ogawa，A.，Casner，S.和C.Bormann，“DV（IEC 61834）视频的RTP有效载荷格式”，RFC 3189，2002年1月。
[9] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[9] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
Appendix
附录
The DV audio channel symbols are specified in Table 2. These symbols are taken from the notation used in the DV video specification IEC 61834-4 [4], chapter 8.1. For the exact meaning of each symbol, the original DV video specification should be consulted.
表2中规定了DV音频信道符号。这些符号取自DV视频规范IEC 61834-4[4]第8.1章中使用的符号。对于每个符号的确切含义，应参考原始DV视频规范。
L: Left channel of stereo
R: Right channel of stereo
M: Monaural signal
C: Center channel of 3,4,6 or 8 channel audio
S: Surround channel of 4 channel audio
Ls, Ls1, Ls2: Left surround channel
Rs, Rs1, Rs2: Right surround channel
Lc: Left center channel of 8 channel audio
Rc: Right center channel of 8 channel audio
Wo: Woofer channel
Lmix: L + 0.7071C + 0.7071LS
Rmix: R + 0.7071C + 0.7071RS
T: 0.7071C
Q1: 0.7071LS + 0.7071RS
Q2: 0.7071LS - 0.7071RS
L: Left channel of stereo
R: Right channel of stereo
M: Monaural signal
C: Center channel of 3,4,6 or 8 channel audio
S: Surround channel of 4 channel audio
Ls, Ls1, Ls2: Left surround channel
Rs, Rs1, Rs2: Right surround channel
Lc: Left center channel of 8 channel audio
Rc: Right center channel of 8 channel audio
Wo: Woofer channel
Lmix: L + 0.7071C + 0.7071LS
Rmix: R + 0.7071C + 0.7071RS
T: 0.7071C
Q1: 0.7071LS + 0.7071RS
Q2: 0.7071LS - 0.7071RS
Table 2. Channel symbols for audio channels in DV video [4]
表2。DV视频中音频通道的通道符号[4]
Authors' Addresses
作者地址
Katsushi Kobayashi Communication Research Laboratory 4-2-1 Nukii-kita machi, Koganei Tokyo 184-8795 JAPAN
小林善胜通信研究实验室4-2-1日本东京小江内北町4-2-1 184-8795
Phone: +81 42 327 6174
EMail: ikob@koganei.wide.ad.jp
Phone: +81 42 327 6174
EMail: ikob@koganei.wide.ad.jp
Akimichi Ogawa Keio University 5322 Endo, Fujisawa Kanagawa 252 JAPAN
小川秋美庆应大学5322日本藤泽神奈川内都252
EMail: akimichi@sfc.wide.ad.jp
EMail: akimichi@sfc.wide.ad.jp
Stephen L. Casner Packet Design 2465 Latham Street Mountain View, CA 94040 United States
Stephen L.Casner包装设计2465美国加利福尼亚州莱瑟姆街山景城，邮编94040
Phone: +1 650-943-1843
EMail: casner@acm.org
Phone: +1 650-943-1843
EMail: casner@acm.org
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
德国不来梅卡斯滕·鲍曼大学邮政学院330440 D-28334
Phone: +49 421 218 7024
Fax: +49 421 218 7000
EMail: cabo@tzi.org
Phone: +49 421 218 7024
Fax: +49 421 218 7000
EMail: cabo@tzi.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。