Network Working Group B. Link
Request for Comments: 4184 T. Hager
Category: Standards Track Dolby Laboratories
J. Flaks
Microsoft Corporation
October 2005
Network Working Group B. Link
Request for Comments: 4184 T. Hager
Category: Standards Track Dolby Laboratories
J. Flaks
Microsoft Corporation
October 2005
RTP Payload Format for AC-3 Audio
AC-3音频的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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes an RTP payload format for transporting audio data using the AC-3 audio compression standard. AC-3 is a high quality, multichannel audio coding system that is used for United States HDTV, DVD, cable television, satellite television and other media. The RTP payload format presented in this document includes support for data fragmentation.
本文档描述了使用AC-3音频压缩标准传输音频数据的RTP有效负载格式。AC-3是一种高质量、多声道音频编码系统，用于美国HDTV、DVD、有线电视、卫星电视和其他媒体。本文档中提供的RTP有效负载格式包括对数据分段的支持。
AC-3 [ATSC] is a high-quality audio codec (audio coding format) designed to encode multiple channels of audio into a low bit-rate format. AC-3 achieves its large compression ratios via encoding a multiplicity of channels as a single entity. Dolby Digital, which is a branded version of AC-3, encodes up to 5.1 channels of audio.
AC-3[ATSC]是一种高质量音频编解码器（音频编码格式），设计用于将多个音频通道编码为低比特率格式。AC-3通过将多个通道编码为单个实体来实现其大压缩比。杜比数码是AC-3的品牌版本，可对多达5.1个声道的音频进行编码。
AC-3 has been adopted as an audio compression scheme for many consumer and professional applications. It is a mandatory audio codec for DVD-video, Advanced Television Standards Committee (ATSC) digital terrestrial television and Digital Living Network Alliance (DLNA) home networking, as well as an optional multichannel audio format for DVD-audio.
AC-3已被许多消费者和专业应用作为音频压缩方案采用。它是DVD视频、高级电视标准委员会（ATSC）数字地面电视和数字生活网络联盟（DLNA）家庭网络的强制性音频编解码器，也是DVD音频的可选多声道音频格式。
There is a need to stream AC-3 data over IP networks. The Internet Real Time Protocol (RTP) provides a mechanism for stream
需要通过IP网络传输AC-3数据。Internet实时协议（RTP）提供了一种流的机制
synchronization and hence serves as the best transport solution for AC-3, which is primarily used in audio-for-video applications. Applications for streaming AC-3 include streaming movies from a home media server to a display, video on demand, and multichannel Internet radio.
同步，因此是AC-3的最佳传输解决方案，AC-3主要用于音频视频应用。流媒体AC-3的应用包括从家庭媒体服务器到显示器的流媒体电影、视频点播和多频道互联网广播。
Section 2 gives a brief overview of the AC-3 algorithm. Section 3 specifies values for fields in the RTP header, while Section 4 specifies the AC-3 payload format. Section 5 discusses media types and SDP usage. Security considerations are covered in Section 6, congestion control in Section 7, and IANA considerations in Section 8. References are given in Sections 9 and 10.
第2节简要概述了AC-3算法。第3节指定RTP标头中字段的值，而第4节指定AC-3有效负载格式。第5节讨论了媒体类型和SDP的使用。第6节介绍了安全注意事项，第7节介绍了拥塞控制，第8节介绍了IANA注意事项。参考资料见第9节和第10节。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
AC-3 can deliver up to 5.1 channels of audio at data rates approximately equal to half of one PCM channel [ATSC], [1994AC3], [1996AC3]. The ".1" refers to a band-limited, optional, low-frequency effects (LFE) channel. AC-3 was designed for signals sampled at rates of 32, 44.1, or 48 kHz. Data rates can vary between 32 kbps and 640 kbps, depending on the number of channels and the desired quality.
AC-3可以以大约等于一个PCM通道[ATSC]、[1994AC3]、[1996AC3]一半的数据速率提供多达5.1个通道的音频。“.1”指带限、可选的低频效应（LFE）信道。AC-3设计用于以32、44.1或48 kHz的频率采样的信号。数据速率可以在32 kbps和640 kbps之间变化，这取决于通道的数量和所需的质量。
AC-3 exploits psycho-acoustic phenomena that cause a significant fraction of the information contained in a typical audio signal to be inaudible. Substantial data reduction occurs via the removal of inaudible information contained in an audio stream. Source coding techniques are further used to reduce the data rate.
AC-3利用了心理声学现象，这种现象会导致典型音频信号中包含的大部分信息听不见。通过去除音频流中包含的不可闻信息，可以实现数据的大幅减少。信源编码技术进一步用于降低数据速率。
Like most perceptual coders, AC-3 operates in the frequency domain. A 512-point TDAC transform is taken with 50% overlap, providing 256 new frequency samples. Frequency samples are then converted to exponents and mantissas. Exponents are differentially encoded. Mantissas are allocated a varying number of bits depending on the audibility of the associated spectral components. Audibility is determined via a masking curve. Bits for mantissas are allocated from a global bit pool.
与大多数感知编码器一样，AC-3在频域中工作。采用512点TDAC变换，重叠50%，提供256个新频率样本。然后将频率样本转换为指数和尾数。指数是差分编码的。尾数根据相关频谱分量的可听性分配不同数量的比特。可听性通过掩蔽曲线确定。尾数的位是从全局位池分配的。
AC-3 bit streams are organized into synchronization frames. Each AC-3 frame contains a Synchronization Information (SI) field, a Bit Stream Information (BSI) field, and 6 audio blocks (ABs) that each represent 256 PCM samples for all channels. The frame ends with an
AC-3比特流被组织成同步帧。每个AC-3帧包含一个同步信息（SI）字段、一个位流信息（BSI）字段和6个音频块（ABs），每个块代表所有通道的256个PCM样本。这个框架以一个字母结尾
optional auxiliary data field (AUX) and an error correction field (CRC). The entire frame represents the time duration of 1536 PCM samples across all coded channels [ATSC]. AC-3 encodes audio sampled at 32 kHz, 44.1 kHz, and 48 kHz. From Annex A, Part 2, of [ATSC], the time duration of an AC-3 frame varies with the sampling rate as follows:
可选辅助数据字段（AUX）和纠错字段（CRC）。整个帧表示所有编码信道上1536个PCM采样的持续时间[ATSC]。AC-3编码以32 kHz、44.1 kHz和48 kHz采样的音频。根据[ATSC]附录A第2部分，AC-3帧的持续时间随采样率变化如下：
Sampling rate Frame duration
_____________________________________
48 kHz 32 ms
44.1 kHz approx. 34.83 ms
32 kHz 48 ms
Sampling rate Frame duration
_____________________________________
48 kHz 32 ms
44.1 kHz approx. 34.83 ms
32 kHz 48 ms
Figure 1 shows the AC-3 frame format.
图1显示了AC-3帧格式。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SI |BSI| AB0 | AB1 | AB2 | AB3 | AB4 | AB5 |AUX|CRC|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SI |BSI| AB0 | AB1 | AB2 | AB3 | AB4 | AB5 |AUX|CRC|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. AC-3 Frame Format
图1。AC-3帧格式
The Synchronization Information field contains information needed to acquire and maintain codec synchronization. The Bit Stream Information field contains parameters that describe the coded audio service [ATSC]. Each audio block contains fields that indicate the use of various coding tools: block switching, dither, coupling, and exponent strategy. They also contain metadata, optionally used to enhance the playback, such as dynamic range control. Finally, the exponents and bit allocation data needed to decode the mantissas into audio data, and the mantissas themselves, are included. The placement of these fields in an AC-3 audio block is shown in Figure 2. The fields shown in this figure are described in detail in [ATSC]. Note that field sizes vary depending on the coded data.
同步信息字段包含获取和维护编解码器同步所需的信息。比特流信息字段包含描述编码音频服务[ATSC]的参数。每个音频块包含指示使用各种编码工具的字段：块切换、抖动、耦合和指数策略。它们还包含元数据（可选地用于增强回放），例如动态范围控制。最后，包括将尾数解码为音频数据所需的指数和位分配数据，以及尾数本身。这些字段在AC-3音频块中的位置如图2所示。本图中显示的字段在[ATSC]中有详细描述。请注意，字段大小因编码数据而异。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block |Dither |Dynamic |Coupling |Coupling |Exponent |
| Switch |Flags |Range Ctrl |Strategy |Coordinates |Strategy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exponents | Bit Allocation | Mantissas |
| | Parameters | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block |Dither |Dynamic |Coupling |Coupling |Exponent |
| Switch |Flags |Range Ctrl |Strategy |Coordinates |Strategy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exponents | Bit Allocation | Mantissas |
| | Parameters | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. AC-3 Audio Block Format
图2。AC-3音频块格式
o Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document. It is specified by the RTP profile under which this payload format is used, or signaled dynamically out-of-band (e.g., using SDP).
o 有效负载类型（PT）：此数据包格式的RTP有效负载类型的分配超出了本文档的范围。它由使用此有效负载格式的RTP配置文件指定，或在带外动态发送信号（例如，使用SDP）。
o Marker (M) bit: The M bit is set to one to indicate that the RTP packet payload contains at least one complete AC-3 frame or contains the final fragment of an AC-3 frame.
o 标记（M）位：将M位设置为1，以指示RTP分组有效载荷包含至少一个完整的AC-3帧或包含AC-3帧的最终片段。
o Extension (X) bit: Defined by the RTP profile used.
o 扩展（X）位：由使用的RTP配置文件定义。
o Timestamp: A 32-bit word that corresponds to the sampling instant for the first AC-3 frame in the RTP packet. Packets containing fragments of the same frame MUST have the same time stamp. The timestamp of the first RTP packet sent SHOULD be selected at random. Thereafter, the timestamp increases linearly with the number of samples included in each frame (i.e., by 1536 for each frame).
o 时间戳：与RTP数据包中第一个AC-3帧的采样瞬间相对应的32位字。包含相同帧片段的数据包必须具有相同的时间戳。应随机选择发送的第一个RTP数据包的时间戳。此后，时间戳随着包括在每个帧中的样本数量线性增加（即，对于每个帧增加1536）。
This payload format is defined for AC-3, as defined in the main part and Annex D of [ATSC]. It is not defined for E-AC-3, as defined in Annex E of [ATSC], and it MUST NOT be used to carry E-AC-3.
根据[ATSC]主要部分和附录D中的定义，该有效载荷格式适用于AC-3。未按照[ATSC]附录E的规定，对E-AC-3进行定义，且不得用于运载E-AC-3。
According to [RFC2736], RTP payload formats should contain an integral number of application data units (ADUs). The AC-3 frame corresponds to an ADU, in the context of this payload format. Each RTP payload MUST start with the two-byte payload header followed by an integral number of complete AC-3 frames or by a single fragment of an AC-3 frame.
根据[RFC2736]，RTP有效负载格式应包含整数个应用数据单元（ADU）。在该有效载荷格式的上下文中，AC-3帧对应于ADU。每个RTP有效负载必须以两字节有效负载头开始，后跟完整AC-3帧的整数或AC-3帧的单个片段。
If an AC-3 frame exceeds the MTU for a network, it SHOULD be fragmented for transmission within an RTP packet. Section 4.2 provides guidelines for creating frame fragments.
如果AC-3帧超过网络的MTU，则应将其分段以在RTP数据包内传输。第4.2节提供了创建帧片段的指南。
There is a two-octet Payload Header at the beginning of each payload.
在每个有效载荷的开头有一个两个八位字节的有效载荷头。
Each AC-3 RTP payload MUST begin with the payload header shown in Figure 3.
每个AC-3 RTP有效载荷必须以图3所示的有效载荷头开始。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | FT| NF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | FT| NF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. AC-3 RTP Payload Header
图3。AC-3 RTP有效载荷头
o MBZ (Must Be Zero): Bits marked MBZ SHALL be set to the value zero and SHALL be ignored by receivers. The bits are reserved for future extensions.
o MBZ（必须为零）：标记为MBZ的位应设置为零，且接收器应忽略。这些位是为将来的扩展保留的。
o FT (Frame Type): This two-bit field indicates the type of frame(s) present in the payload. It takes the following values:
o FT（帧类型）：此两位字段指示有效负载中存在的帧类型。它采用以下值：
0 - One or more complete frames. 1 - Initial fragment of frame which includes the first 5/8ths of the frame. (See Section 4.2.) 2 - Initial fragment of frame, which does not include the first 5/8ths of the frame. 3 - Fragment of frame other than initial fragment. (Note that M bit in RTP header is set for final fragment).
0-一个或多个完整帧。1-帧的初始片段，包括帧的前5/8。（见第4.2节）2-框架的初始碎片，不包括框架的前5/8部分。3-帧的片段，而不是初始片段。（请注意，RTP头中的M位是为最终片段设置的）。
o NF (Number of frames/fragments): An 8-bit field whose meaning depends on the Frame Type (FT) in this payload. For complete frames (FT of 0), it is used to indicate the number of AC-3 frames in the RTP payload. For frame fragments (FT of 1, 2, or 3), it is used to indicate the number fragments (and therefore packets) that make up the current frame. NF MUST be identical for packets containing fragments of the same frame.
o NF（帧/片段数）：一个8位字段，其含义取决于此有效负载中的帧类型（FT）。对于完整帧（0英尺），它用于指示RTP有效负载中AC-3帧的数量。对于帧片段（FT为1、2或3），它用于指示组成当前帧的片段（因此也包括数据包）的数量。对于包含相同帧片段的数据包，NF必须相同。
Figure 4 shows the full AC-3 RTP payload format.
图4显示了完整的AC-3 RTP有效负载格式。
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
| Payload | Frame | Frame | | Frame |
| Header | (1) | (2) | | (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
| Payload | Frame | Frame | | Frame |
| Header | (1) | (2) | | (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
Figure 4. Full AC-3 RTP payload
图4。全AC-3 RTP有效载荷
When receiving AC-3 payloads with FT = 0 and more than a single frame (NF > 1), a receiver needs to use the "frmsizecod" field in the Synchronization Information (syncinfo) block in each AC-3 frame to determine the frame's length. That way a receiver can determine the boundary of the next frame. Note that the frame length may vary from frame to frame.
当接收FT=0且超过单个帧（NF>1）的AC-3有效载荷时，接收机需要使用每个AC-3帧中同步信息（syncinfo）块中的“frmsizecod”字段来确定帧的长度。这样，接收器就可以确定下一帧的边界。请注意，帧长度可能因帧而异。
The size of an AC-3 frame depends on the sample rate of the audio and the data rate used by the encoder (which are indicated in the "Synchronization Information" header in the AC-3 frame). The size of a frame, for a given sample rate and data rate, is specified in Table 5.18 ("Frame Size Code Table") of [ATSC]. This table shows that AC-3 frames range in size from a minimum of 128 bytes to a maximum of 3840 bytes. If the size of an AC-3 frame exceeds the MTU size, the frame SHOULD be fragmented at the RTP level. The fragmentation MAY be performed at any byte boundary in the frame. RTP packets containing fragments of the same AC-3 frame SHALL be sent in consecutive order, from first to last fragment. This enables a receiver to assemble the fragments in correct order.
AC-3帧的大小取决于音频的采样率和编码器使用的数据速率（在AC-3帧的“同步信息”标题中指示）。[ATSC]的表5.18（“帧大小代码表”）规定了给定采样率和数据速率下的帧大小。此表显示AC-3帧的大小范围从最小128字节到最大3840字节。如果AC-3帧的大小超过MTU大小，则应在RTP级别对该帧进行分段。可以在帧中的任何字节边界处执行分段。包含相同AC-3帧片段的RTP数据包应按从第一个片段到最后一个片段的连续顺序发送。这使接收器能够按照正确的顺序组装碎片。
When an AC-3 frame is fragmented, it MAY be fragmented such that at least the first 5/8ths of the frame data is in the first fragment. This provides greater resilience to packet loss. This initial portion of any frame is guaranteed to contain the data necessary to decode the first two blocks of the frame. Any frame fragments other than those containing the first 5/8ths of frame data are only decodable once the complete frame is received. The 5/8ths point of the frame is defined in Table 7.34 ("5/8_frame Size Table") of [ATSC].
当AC-3帧被分段时，它可以被分段，使得帧数据的至少前5/8在第一片段中。这为数据包丢失提供了更大的恢复能力。任何帧的该初始部分保证包含解码帧的前两个块所需的数据。除包含前5/8帧数据的帧片段外，任何帧片段仅在接收到完整帧后才可解码。框架的5/8点在[ATSC]的表7.34（“5/8_框架尺寸表”）中定义。
This registration uses the template defined in [DRAFT-FREED] and follows RFC 3555 [RFC3555].
此注册使用[DRAFT-FREED]中定义的模板，并遵循RFC 3555[RFC3555]。
o Type name: audio
o 类型名称：音频
o Subtype name: ac3
o 子类型名称：ac3
o Required parameters:
o 所需参数：
rate: The RTP timestamp clock rate that is equal to the audio sampling rate. Permitted rates are 32000, 44100, and 48000.
速率：RTP时间戳时钟速率，等于音频采样速率。允许的费率为32000、44100和48000。
o Optional parameters:
o 可选参数：
channels: From a sender, the maximum number of channels present in the AC3 stream. From a receiver, the maximum number of output channels the receiver will deliver. This MUST be a number between 1 and 6. The LFE (".1") channel MUST be counted as one channel. Note that the channel order used in AC-3 differs from the channel order scheme in [RFC3551]. The AC-3 channel order scheme can be found in Table 5.8 of [ATSC].
通道：来自发送方，AC3流中存在的最大通道数。从接收器发送的最大输出通道数。这必须是一个介于1和6之间的数字。LFE（“.1”）通道必须计为一个通道。请注意，AC-3中使用的信道顺序与[RFC3551]中的信道顺序方案不同。AC-3信道订购方案见[ATSC]的表5.8。
ptime: See RFC 2327 [RFC2327].
ptime：见RFC 2327[RFC2327]。
maxptime: See RFC 3267 [RFC3267].
最大时间：参见RFC 3267[RFC3267]。
o Encoding considerations:
o 编码注意事项：
This media type is framed (see section 4.8 in [DRAFT-FREED]) and contains binary data.
该媒体类型为框架（见[DRAFT-FREED]第4.8节），包含二进制数据。
o Security considerations:
o 安全考虑：
See Section 6 of this document.
见本文件第6节。
o Interoperability considerations:
o 互操作性注意事项：
None
没有一个
o Published specification:
o 已发布的规范：
This payload format specification and see [ATSC].
此有效负载格式规范，请参阅[ATSC]。
o Applications that use this media type:
o 使用此媒体类型的应用程序：
Multichannel audio compression of audio and audio for video.
音频和视频音频的多通道音频压缩。
o Additional Information:
o 其他信息：
Magic number(s): The first two octets of an AC-3 frame are always the synchronization word, which has the hex value 0x0B77.
幻数：AC-3帧的前两个八位字节始终是同步字，其十六进制值为0x0B77。
o Person & email address to contact for further information:
o 联系人和电子邮件地址，以获取更多信息：
Brian Link <bdl@dolby.com> IETF AVT working group.
布莱恩·林克<bdl@dolby.com>IETF AVT工作组。
o Intended Usage:
o 预期用途：
COMMON
常见的
o Restrictions on usage:
o 使用限制：
This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[RFC3550]。此时未定义其他帧协议内的传输。
Author/Change controller:
作者/变更控制员：
IETF Audio/Video Transport Working Group delegated from the IESG.
IESG授权的IETF音频/视频传输工作组。
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC2327], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing AC-3, the mapping is as follows:
MIME媒体类型规范中包含的信息具有到会话描述协议（SDP）[RFC2327]中的字段的特定映射，该协议通常用于描述RTP会话。当使用SDP指定使用AC-3的会话时，映射如下：
o The Media type ("audio") goes in SDP "m=" as the media name.
o 媒体类型（“音频”）以SDP“m=”作为媒体名称。
o The Media subtype ("ac3") goes in SDP "a=rtpmap" as the encoding name.
o 媒体子类型（“ac3”）以SDP“a=rtpmap”作为编码名称。
o The required parameter "rate" also goes in "a=rtpmap" as the clock rate, optionally followed by the parameter "channel".
o 所需的参数“rate”也作为时钟速率进入“a=rtpmap”，可选地后跟参数“channel”。
o The optional parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o 可选参数“ptime”和“maxptime”分别位于SDP“a=ptime”和“a=maxptime”属性中。
An example of the SDP data for AC-3:
AC-3的SDP数据示例：
m=audio 49111 RTP/AVP 100
a=rtpmap:100 ac3/48000/6
m=audio 49111 RTP/AVP 100
a=rtpmap:100 ac3/48000/6
Certain considerations are needed when SDP is used to perform offer/answer exchanges [RFC3264].
当使用SDP执行提供/应答交换时，需要考虑某些因素[RFC3264]。
o The "rate" is a symmetric parameter, and the answer MUST use the same value or remove the payload type.
o “速率”是一个对称参数，答案必须使用相同的值或删除有效负载类型。
o The "channels" parameter is declarative and indicates, for recvonly or sendrecv, the desired channel configuration to receive, and for sendonly, the intended channel configuration to transmit. All receivers are capable of receiving any of the defined channel configurations, and the parameter exchange might be used to help optimize the transmission to the number of channels the receiver requests. If the "channels" parameter is omitted, a default maximum value of 6 is implied.
o “channels”参数是声明性的，对于RECVOLY或sendrecv，它指示要接收的所需信道配置，对于sendonly，它指示要发送的预期信道配置。所有接收机都能够接收任何定义的信道配置，并且参数交换可用于帮助优化对接收机请求的信道数量的传输。如果省略“channels”参数，则默认最大值为6。
o The "ptime" and "maxptime" parameters are negotiated as defined for "ptime" in RFC 3264 [RFC3264].
o “ptime”和“maxptime”参数按照RFC 3264[RFC3264]中“ptime”的定义进行协商。
The payload format described in this document is subject to the security considerations defined in the RTP specification [RFC3550] and in any applicable RTP profile (e.g., [RFC3551]). To protect the user's privacy and any copyrighted material, confidentiality protection would have to be applied. To also protect against modification by intermediate entities and ensure the authenticity of the stream, integrity protection and authentication would be required. Confidentiality, integrity protection, and authentication have to be provided by a mechanism external to this payload format, e.g., SRTP [RFC3711].
本文档中描述的有效负载格式受RTP规范[RFC3550]和任何适用RTP配置文件（例如[RFC3551]）中定义的安全注意事项的约束。为了保护用户的隐私和任何受版权保护的材料，必须实施保密保护。为了防止中间实体的修改并确保流的真实性，需要完整性保护和身份验证。保密性、完整性保护和身份验证必须由该有效负载格式之外的机制提供，例如SRTP[RFC3711]。
The AC-3 format is designed so that the validity of data frames can determined by decoders. A decoder that encounters a malformed frame discards the malformed data and conceals the errors in the audio output until a valid frame is detected and decoded. This is expected to prevent crashes and other abnormal decoder behavior in response to errors or attacks.
AC-3格式的设计使得解码器可以确定数据帧的有效性。遇到格式错误的帧的解码器将丢弃格式错误的数据并隐藏音频输出中的错误，直到检测到并解码有效帧。这有望防止崩溃和其他异常解码器行为，以响应错误或攻击。
The general congestion control considerations for transporting RTP data apply to AC-3 audio over RTP as well. See the RTP specification [RFC3550] and any applicable RTP profile (e.g., [RFC3551]).
传输RTP数据的一般拥塞控制注意事项也适用于通过RTP传输AC-3音频。请参阅RTP规范[RFC3550]和任何适用的RTP配置文件（例如[RFC3551]）。
AC-3 encoders may use a range of bit rates to encode audio data, so it is possible to adapt network bandwidth by adjusting the encoder bit rate in real time or by having multiple copies of content encoded at different bit rates. Additionally, packing more frames in each RTP payload can reduce the number of packets sent and hence the overhead from IP/UDP/RTP headers, at the expense of increased delay and reduced robustness against packet losses.
AC-3编码器可以使用一定范围的比特率来编码音频数据，因此可以通过实时调整编码器比特率或通过以不同比特率编码内容的多个副本来调整网络带宽。此外，在每个RTP有效负载中打包更多帧可以减少发送的数据包数量，从而减少来自IP/UDP/RTP报头的开销，但代价是增加延迟并降低对数据包丢失的鲁棒性。
A new media subtype has been assigned for AC-3; see Section 5.1.
为AC-3分配了一个新的媒体子类型；见第5.1节。
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[ATSC] U.S. Advanced Television Systems Committee (ATSC), "ATSC Standard: Digital Audio Compression (AC-3), Revision B," Doc A/52B, June 2005.
[ATSC]美国高级电视系统委员会（ATSC），“ATSC标准：数字音频压缩（AC-3），修订版B”，文件A/52B，2005年6月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327]Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[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月。
[RFC3267] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[RFC3267]Sjoberg，J.，Westerlund，M.，Lakaniemi，A.，和Q.Xie，“自适应多速率（AMR）和自适应多速率宽带（AMR-WB）音频编解码器的实时传输协议（RTP）有效载荷格式和文件存储格式”，RFC 3267，2002年6月。
[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月。
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, December 1999.
[RFC2736]Handley，M.和C.Perkins，“RTP有效载荷格式规范编写者指南”，BCP 36，RFC 2736，1999年12月。
[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月。
[1994AC3] Todd, C., et al., "AC-3: Flexible Perceptual Coding for Audio Transmission and Storage," Preprint 3796, Presented at the 96th Convention of the Audio Engineering Society, May 1994.
[1994AC3]Todd，C.等人，“AC-3：音频传输和存储的灵活感知编码”，预印本3796，在1994年5月举行的音频工程学会第96届大会上发表。
[1996AC3] Fielder, L., et al., "AC-2 and AC-3: Low-Complexity Transform-Based Audio Coding," Collected Papers on Digital Audio Bit-Rate Reduction, pp. 54-72, Audio Engineering Society, September 1996.
[1996AC3]Fielder，L.，等人，“AC-2和AC-3：基于低复杂度变换的音频编码”，数字音频比特率降低论文集，第54-72页，音频工程学会，1996年9月。
[RFC3711] Baugher, M., et al., "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.等人，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[DRAFT-FREED] Freed, N. and Klensin, J., "Media Type Specifications and Registration Procedures", Work in Progress, April 2005.
[DRAFT-FREED]FREED，N.和Klensin，J.，“介质类型规范和注册程序”，正在进行的工作，2005年4月。
Authors' Addresses
作者地址
Brian Link Dolby Laboratories 100 Potrero Ave San Francisco, CA 94103
Brian Link Dolby实验室100波特罗大道旧金山，CA 94103
Phone: +1 415 558 0200
EMail: bdl@dolby.com
Phone: +1 415 558 0200
EMail: bdl@dolby.com
Todd Hager Dolby Laboratories 100 Potrero Ave San Francisco, CA 94103
Todd Hager Dolby实验室100波特罗大道旧金山，CA 94103
Phone: +1 415 558 0136
EMail: thh@dolby.com
Phone: +1 415 558 0136
EMail: thh@dolby.com
Jason Flaks Microsoft Corporation 1 Microsoft Way Redmond, WA 98052
杰森·弗莱克斯微软公司华盛顿州雷德蒙微软路1号，邮编：98052
Phone: +1 425 722 2543
EMail: jasonfl@microsoft.com
Phone: +1 425 722 2543
EMail: jasonfl@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。