Network Working Group A. Sollaud
Request for Comments: 5391 France Telecom
Category: Standards Track November 2008
Network Working Group A. Sollaud
Request for Comments: 5391 France Telecom
Category: Standards Track November 2008
RTP Payload Format for ITU-T Recommendation G.711.1
ITU-T建议G.711.1的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) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2008 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication Standardization Sector (ITU-T) G.711.1 audio codec. Two media type registrations are also included.
本文件规定了用于ITU电信标准化部门（ITU-T）G.711.1音频编解码器的实时传输协议（RTP）有效载荷格式。还包括两个媒体类型注册。
Table of Contents
目录
1. Introduction ....................................................2
2. Background ......................................................2
3. RTP Header Usage ................................................3
4. Payload Format ..................................................4
4.1. Payload Header .............................................4
4.2. Audio Data .................................................5
5. Payload Format Parameters .......................................6
5.1. PCMA-WB Media Type Registration ............................7
5.2. PCMU-WB Media Type Registration ............................8
5.3. Mapping to SDP Parameters ..................................9
5.3.1. Offer-Answer Model Considerations ...................9
5.3.2. Declarative SDP Considerations .....................11
6. G.711 Interoperability .........................................11
7. Congestion Control .............................................12
8. Security Considerations ........................................12
9. IANA Considerations ............................................12
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................13
1. Introduction ....................................................2
2. Background ......................................................2
3. RTP Header Usage ................................................3
4. Payload Format ..................................................4
4.1. Payload Header .............................................4
4.2. Audio Data .................................................5
5. Payload Format Parameters .......................................6
5.1. PCMA-WB Media Type Registration ............................7
5.2. PCMU-WB Media Type Registration ............................8
5.3. Mapping to SDP Parameters ..................................9
5.3.1. Offer-Answer Model Considerations ...................9
5.3.2. Declarative SDP Considerations .....................11
6. G.711 Interoperability .........................................11
7. Congestion Control .............................................12
8. Security Considerations ........................................12
9. IANA Considerations ............................................12
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................13
The ITU Telecommunication Standardization Sector (ITU-T) Recommendation G.711.1 [ITU-G.711.1] is an embedded wideband extension of the Recommendation G.711 [ITU-G.711] audio codec. This document specifies a payload format for packetization of G.711.1 encoded audio signals into the Real-time Transport Protocol (RTP).
ITU电信标准化部门（ITU-T）建议G.711.1[ITU-G.711.1]是建议G.711[ITU-G.711]音频编解码器的嵌入式宽带扩展。本文件规定了将G.711.1编码音频信号打包成实时传输协议（RTP）的有效载荷格式。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
G.711.1 is a G.711 embedded wideband speech and audio coding algorithm operating at 64, 80, and 96 kbps. At 64 kbps, G.711.1 is fully interoperable with G.711. Hence, an efficient deployment in existing G.711-based Voice over IP (VoIP) infrastructures is foreseen.
G.711.1是一种G.711嵌入式宽带语音和音频编码算法，以64、80和96 kbps的速率运行。G.711.1以64 kbps的速率与G.711完全互操作。因此，可以预见在现有的基于G.711的IP语音（VoIP）基础设施中进行有效部署。
The codec operates on 5-ms frames, and the default sampling rate is 16 kHz. Input and output at 8 kHz are also supported for narrowband modes.
编解码器在5毫秒帧上运行，默认采样率为16 kHz。窄带模式也支持8 kHz的输入和输出。
The encoder produces an embedded bitstream structured in three layers corresponding to three available bit rates: 64, 80, and 96 kbps. The bitstream can be truncated at the decoder side or by any component of the communication system to adjust, "on the fly", the bit rate to the desired value.
编码器生成一个嵌入的比特流，该比特流分为三层，对应于三个可用比特率：64、80和96 kbps。比特流可以在解码器侧被截断，或者被通信系统的任何组件截断，以“动态”地将比特率调整到所需值。
The following table gives more details on these layers.
下表提供了有关这些层的更多详细信息。
+-------+------------------------+----------+
| Layer | Description | Bit rate |
+-------+------------------------+----------+
| L0 | G.711 compatible | 64 kbps |
| L1 | narrowband enhancement | 16 kbps |
| L2 | wideband enhancement | 16 kbps |
+-------+------------------------+----------+
+-------+------------------------+----------+
| Layer | Description | Bit rate |
+-------+------------------------+----------+
| L0 | G.711 compatible | 64 kbps |
| L1 | narrowband enhancement | 16 kbps |
| L2 | wideband enhancement | 16 kbps |
+-------+------------------------+----------+
Table 1: Layers description
表1：图层说明
The combinations of these three layers results in the definition of four modes, as per the following table.
根据下表，这三层的组合产生了四种模式的定义。
+------+----+----+----+------------+----------+
| Mode | L0 | L1 | L2 | Audio band | Bit rate |
+------+----+----+----+------------+----------+
| R1 | x | | | narrowband | 64 kbps |
| R2a | x | x | | narrowband | 80 kbps |
| R2b | x | | x | wideband | 80 kbps |
| R3 | x | x | x | wideband | 96 kbps |
+------+----+----+----+------------+----------+
+------+----+----+----+------------+----------+
| Mode | L0 | L1 | L2 | Audio band | Bit rate |
+------+----+----+----+------------+----------+
| R1 | x | | | narrowband | 64 kbps |
| R2a | x | x | | narrowband | 80 kbps |
| R2b | x | | x | wideband | 80 kbps |
| R3 | x | x | x | wideband | 96 kbps |
+------+----+----+----+------------+----------+
Table 2: Modes description
表2：模式说明
The format of the RTP header is specified in [RFC3550]. The payload format defined in this document uses the fields of the header in a manner consistent with that specification.
RTP标头的格式在[RFC3550]中指定。本文档中定义的有效负载格式以与该规范一致的方式使用报头的字段。
marker (M): G.711.1 does not define anything specific regarding Discontinuous Transmission (DTX), a.k.a. silence suppression. Codec-independent mechanisms may be used, like the generic comfort-noise payload format defined in [RFC3389].
标记（M）：G.711.1未定义与不连续传输（DTX）有关的任何具体内容，即沉默抑制。可以使用与编解码器无关的机制，如[RFC3389]中定义的通用舒适性噪声有效载荷格式。
For applications that send either no packets or occasional comfort-noise packets during silence, the first packet of a talkspurt -- that is, the first packet after a silence period during which packets have not been transmitted contiguously --
对于在静默期间不发送数据包或偶尔发送舒适噪声数据包的应用程序，TalkSput的第一个数据包——也就是说，在静默期间数据包没有连续发送后的第一个数据包--
SHOULD be distinguished by setting the marker bit in the RTP data header to one. The marker bit in all other packets is zero. The beginning of a talkspurt MAY be used to adjust the playout delay to reflect changing network delays. Applications without silence suppression MUST set the marker bit to zero.
应通过将RTP数据头中的标记位设置为1来区分。所有其他数据包中的标记位均为零。TalkSport的开始可用于调整播放延迟以反映不断变化的网络延迟。无静音抑制的应用程序必须将标记位设置为零。
payload type (PT): 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 under which this payload format is being used will assign a payload type for this codec or specify that the payload type is to be bound dynamically (see Section 5.3).
有效负载类型（PT）：此数据包格式的RTP有效负载类型的分配不在本文档的范围内，此处将不指定。预计使用此有效负载格式的RTP配置文件将为此编解码器分配有效负载类型，或指定动态绑定有效负载类型（参见第5.3节）。
timestamp: The RTP timestamp clock frequency is the same as the default sampling frequency: 16 kHz.
时间戳：RTP时间戳时钟频率与默认采样频率相同：16 kHz。
G.711.1 has also the capability to operate with 8-kHz sampled input/output signals. It does not affect the bitstream, and the decoder does not require a priori knowledge about the sampling rate of the original signal at the input of the encoder. Therefore, depending on the implementation and the audio acoustic capabilities of the devices, the input of the encoder and/or the output of the decoder can be configured at 8 kHz; however, a 16-kHz RTP clock rate MUST always be used.
G.711.1还具有在8-kHz采样输入/输出信号下运行的能力。它不影响比特流，并且解码器不需要关于编码器输入处原始信号的采样率的先验知识。因此，根据设备的实现和音频声学能力，编码器的输入和/或解码器的输出可以配置为8khz；但是，必须始终使用16 kHz RTP时钟频率。
The duration of one frame is 5 ms, corresponding to 80 samples at 16 kHz. Thus, the timestamp is increased by 80 for each consecutive frame.
一帧的持续时间为5ms，对应于16kHz下的80个样本。因此，对于每个连续帧，时间戳增加80。
The complete payload consists of a payload header of 1 octet, followed by one or more consecutive G.711.1 audio frames of the same mode.
完整的有效载荷包括1个八位字节的有效载荷头，后跟一个或多个相同模式的连续G.711.1音频帧。
The mode may change between packets, but not within a packet.
模式可以在分组之间改变，但不能在分组内改变。
The payload header is illustrated below.
有效负载收割台如下图所示。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 0| MI |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 0| MI |
+-+-+-+-+-+-+-+-+
The five most significant bits are reserved for further extension and MUST be set to zero and MUST be ignored by receivers.
五个最高有效位保留用于进一步扩展，必须设置为零，接收机必须忽略。
The Mode Index (MI) field (3 bits) gives the mode of the following frame(s) as per the table:
模式索引（MI）字段（3位）根据表给出以下帧的模式：
+------------+--------------+------------+
| Mode Index | G.711.1 mode | Frame size |
+------------+--------------+------------+
| 1 | R1 | 40 octets |
| 2 | R2a | 50 octets |
| 3 | R2b | 50 octets |
| 4 | R3 | 60 octets |
+------------+--------------+------------+
+------------+--------------+------------+
| Mode Index | G.711.1 mode | Frame size |
+------------+--------------+------------+
| 1 | R1 | 40 octets |
| 2 | R2a | 50 octets |
| 3 | R2b | 50 octets |
| 4 | R3 | 60 octets |
+------------+--------------+------------+
Table 3: Modes in payload header
表3：有效载荷标题中的模式
All other values of MI are reserved for future use and MUST NOT be used.
MI的所有其他值保留供将来使用，不得使用。
Payloads received with an undefined MI value MUST be discarded.
必须丢弃接收到的具有未定义MI值的有效载荷。
If a restricted mode-set has been set up by the signaling (see Section 5), payloads received with an MI value not in this set MUST be discarded.
如果通过信令设置了限制模式集（参见第5节），则必须丢弃接收到的有效载荷，其MI值不在此集中。
After this payload header, the consecutive audio frames are packed in order of time, that is, oldest first. All frames MUST be of the same mode, indicated by the MI field of the payload header.
在该有效负载报头之后，连续音频帧按时间顺序打包，即，最早的第一个。所有帧必须具有相同的模式，由有效负载标头的MI字段指示。
Within a frame, layers are always packed in the same order: L0 then L1 for mode R2a, L0 then L2 for mode R2b, L0 then L1 then L2 for mode R3. This is illustrated below.
在一个帧内，层总是按照相同的顺序打包：L0然后L1用于模式R2a，L0然后L2用于模式R2b，L0然后L1然后L2用于模式R3。这一点如下所示。
+-------------------------------+
R1 | L0 |
+-------------------------------+
+-------------------------------+
R1 | L0 |
+-------------------------------+
+-------------------------------+--------+
R2a | L0 | L1 |
+-------------------------------+--------+
+-------------------------------+--------+
R2a | L0 | L1 |
+-------------------------------+--------+
+-------------------------------+--------+
R2b | L0 | L2 |
+-------------------------------+--------+
+-------------------------------+--------+
R2b | L0 | L2 |
+-------------------------------+--------+
+-------------------------------+--------+--------+
R3 | L0 | L1 | L2 |
+-------------------------------+--------+--------+
+-------------------------------+--------+--------+
R3 | L0 | L1 | L2 |
+-------------------------------+--------+--------+
The size of one frame is given by the mode, as per Table 3, and the actual number of frames is easy to infer from the size of the audio data part:
一帧的大小由模式给出，如表3所示，从音频数据部分的大小很容易推断出实际的帧数：
nb_frames = (size_of_audio_data) / (size_of_one_frame).
nb_frames = (size_of_audio_data) / (size_of_one_frame).
Only full frames must be considered. So if there is a remainder to the division above, the corresponding remaining bytes in the received payload MUST be ignored.
必须只考虑完整的框架。因此，如果上面的除法还有余数，则必须忽略接收到的有效负载中相应的剩余字节。
This section defines the parameters that may be used to configure optional features in the G.711.1 RTP transmission.
本节定义了可用于配置G.711.1 RTP传输中可选功能的参数。
Both A-law and mu-law G.711 are supported in the core layer L0, but there is no interoperability between A-law and mu-law. So two media types with the same parameters will be defined: audio/PCMA-WB for A-law core, and audio/PCMU-WB for mu-law core. This is consistent with the audio/PCMA and audio/PCMU media types separation for G.711 audio.
核心层L0支持A-law和mu-law G.711，但A-law和mu-law之间没有互操作性。因此，将定义两种参数相同的媒体类型：A-law core的audio/PCMA-WB和mu-law core的audio/PCMU-WB。这与G.711 audio的audio/PCMA和audio/PCMU媒体类型分离一致。
The parameters are defined here as part of the media subtype registrations for the G.711.1 codec. A mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] is also provided for those applications that use SDP. In control protocols that do not use MIME or SDP, the media type parameters must be mapped to the appropriate format used with that control protocol.
此处将这些参数定义为G.711.1编解码器的媒体子类型注册的一部分。还为使用SDP的应用程序提供了参数到会话描述协议（SDP）[RFC4566]的映射。在不使用MIME或SDP的控制协议中，媒体类型参数必须映射到与该控制协议一起使用的适当格式。
This registration is done using the template defined in [RFC4288] and following [RFC4855].
此注册使用[RFC4288]中定义的模板和以下[RFC4855]完成。
Type name: audio
类型名称：音频
Subtype name: PCMA-WB
子类型名称：PCMA-WB
Required parameters: none
所需参数：无
Optional parameters:
可选参数：
mode-set: restricts the active codec mode set to a subset of all modes. Possible values are a comma-separated list of modes from the set: 1, 2, 3, 4 (see Mode Index in Table 3 of RFC 5391). The modes are listed in order of preference; first is preferred. If mode-set is specified, frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload. If not present, all codec modes are allowed.
模式集：将活动编解码器模式集限制为所有模式的子集。可能的值是集合中以逗号分隔的模式列表：1、2、3、4（参见RFC 5391表3中的模式索引）。模式按优先顺序列出；首选第一种。如果指定了模式集，则在任何RTP有效负载中都不得发送使用子集之外的模式编码的帧。如果不存在，则允许所有编解码器模式。
ptime: the recommended length of time (in milliseconds) represented by the media in a packet. It should be an integer multiple of 5 ms (the frame size). See Section 6 of RFC 4566.
ptime：由数据包中的媒体表示的建议时间长度（毫秒）。它应该是5毫秒（帧大小）的整数倍。见RFC 4566第6节。
maxptime: the maximum length of time (in milliseconds) that can be encapsulated in a packet. It should be an integer multiple of 5 ms (the frame size). See Section 6 of RFC 4566.
maxptime：可以封装在数据包中的最大时间长度（以毫秒为单位）。它应该是5毫秒（帧大小）的整数倍。见RFC 4566第6节。
Encoding considerations: This media type is framed and contains binary data. See Section 4.8 of RFC 4288.
编码注意事项：此媒体类型是框架式的，包含二进制数据。参见RFC 4288第4.8节。
Security considerations: See Section 8 of RFC 5391.
安全注意事项：见RFC 5391第8节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 5391
已发布规范：RFC 5391
Applications that use this media type: Audio and video conferencing tools.
使用此媒体类型的应用程序：音频和视频会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information: Aurelien Sollaud, aurelien.sollaud@orange-ftgroup.com
联系人和电子邮件地址，以获取更多信息：Aurelian Sollaud，Aurelian。sollaud@orange-ftgroup.com
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输。
Author: Aurelien Sollaud
作者：Aurelian Sollaud
Change controller: IETF Audio/Video Transport working group delegated from the IESG
变更控制员：IESG授权的IETF音频/视频传输工作组
This registration is done using the template defined in [RFC4288] and following [RFC4855].
此注册使用[RFC4288]中定义的模板和以下[RFC4855]完成。
Type name: audio
类型名称：音频
Subtype name: PCMU-WB
子类型名称：PCMU-WB
Required parameters: none
所需参数：无
Optional parameters:
可选参数：
mode-set: restricts the active codec mode-set to a subset of all modes. Possible values are a comma-separated list of modes from the set: 1, 2, 3, 4 (see Mode Index in Table 3 of RFC 5391). The modes are listed in order of preference; first is preferred. If mode-set is specified, frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload. If not present, all codec modes are allowed.
模式集：将活动编解码器模式集限制为所有模式的子集。可能的值是集合中以逗号分隔的模式列表：1、2、3、4（参见RFC 5391表3中的模式索引）。模式按优先顺序列出；首选第一种。如果指定了模式集，则在任何RTP有效负载中都不得发送使用子集之外的模式编码的帧。如果不存在，则允许所有编解码器模式。
ptime: the recommended length of time (in milliseconds) represented by the media in a packet. It should be an integer multiple of 5 ms (the frame size). See Section 6 of RFC 4566.
ptime：由数据包中的媒体表示的建议时间长度（毫秒）。它应该是5毫秒（帧大小）的整数倍。见RFC 4566第6节。
maxptime: the maximum length of time (in milliseconds) that can be encapsulated in a packet. It should be an integer multiple of 5 ms (the frame size). See Section 6 of RFC 4566.
maxptime：可以封装在数据包中的最大时间长度（以毫秒为单位）。它应该是5毫秒（帧大小）的整数倍。见RFC 4566第6节。
Encoding considerations: This media type is framed and contains binary data. See Section 4.8 of RFC 4288.
编码注意事项：此媒体类型是框架式的，包含二进制数据。参见RFC 4288第4.8节。
Security considerations: See Section 8 of RFC 5391.
安全注意事项：见RFC 5391第8节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 5391
已发布规范：RFC 5391
Applications that use this media type: Audio and video conferencing tools.
使用此媒体类型的应用程序：音频和视频会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information: Aurelien Sollaud, aurelien.sollaud@orange-ftgroup.com
联系人和电子邮件地址，以获取更多信息：Aurelian Sollaud，Aurelian。sollaud@orange-ftgroup.com
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输。
Author: Aurelien Sollaud
作者：Aurelian Sollaud
Change controller: IETF Audio/Video Transport working group delegated from the IESG
变更控制员：IESG授权的IETF音频/视频传输工作组
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the G.711.1 codec, the mapping is as follows:
媒体类型规范中包含的信息与会话描述协议（SDP）[RFC4566]中的字段具有特定映射，该协议通常用于描述RTP会话。当使用SDP指定使用G.711.1编解码器的会话时，映射如下：
o The media type ("audio") goes in SDP "m=" as the media name.
o 媒体类型（“音频”）以SDP“m=”作为媒体名称。
o The media subtype ("PCMA-WB" or "PCMU-WB") goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for G.711.1.
o 媒体子类型（“PCMA-WB”或“PCMU-WB”）以SDP“a=rtpmap”作为编码名称。对于G.711.1，“a=rtpmap”中的RTP时钟频率必须为16000。
o The parameter "mode-set" goes in the SDP "a=fmtp" attribute by copying it as a "mode-set=<value>" string.
o 参数“mode set”作为“mode set=<value>”字符串复制到SDP“a=fmtp”属性中。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o 参数“ptime”和“maxptime”分别位于SDP“a=ptime”和“a=maxptime”属性中。
The following considerations apply when using SDP offer-answer procedures [RFC3264] to negotiate the use of G.711.1 payload in RTP:
当使用SDP报价-应答程序[RFC3264]协商RTP中G.711.1有效载荷的使用时，以下注意事项适用：
o Since G.711.1 is an extension of G.711, the offerer SHOULD announce G.711 support in its "m=audio" line, with G.711.1 preferred. This will allow interoperability with both G.711.1 and G.711-only capable parties. This is done by offering the PCMA media subtype in addition to PCMA-WB, and/or PCMU in addition to PCMU-WB.
o 由于G.711.1是G.711的扩展，报价人应在其“m=音频”行中宣布G.711支持，首选G.711.1。这将允许与G.711.1和仅G.711能力方进行互操作。这是通过在PCMA-WB之外提供PCMA媒体子类型和/或在PCMU-WB之外提供PCMU来实现的。
Below is an example part of such an offer, for A-law:
以下是针对A-law的此类报价的示例部分：
m=audio 54874 RTP/AVP 96 8
a=rtpmap:96 PCMA-WB/16000
a=rtpmap:8 PCMA/8000
m=audio 54874 RTP/AVP 96 8
a=rtpmap:96 PCMA-WB/16000
a=rtpmap:8 PCMA/8000
As a reminder, the payload format for G.711 is defined in Section 4.5.14 of [RFC3551].
作为提醒，G.711的有效载荷格式在[RFC3551]的第4.5.14节中定义。
o The "mode-set" parameter is bi-directional; i.e., the restricted mode-set applies to media both to be received and sent by the declaring entity. If a mode-set was supplied in the offer, the answerer MUST return either the same mode-set or a subset of this mode-set. The answerer MAY change the preference order. If no mode-set was supplied in the offer, the anwerer MAY return a mode-set to restrict the possible modes. In any case, the mode-set in the answer then applies for both offerer and answerer. The offerer MUST NOT send frames of a mode that has been removed by the answerer.
o “模式设置”参数是双向的；i、 例如，受限模式集适用于声明实体接收和发送的媒体。如果报价中提供了模式集，应答者必须返回相同的模式集或该模式集的子集。回答者可以更改优先顺序。如果报价中未提供模式集，则报价人可返回模式集以限制可能的模式。在任何情况下，答案中设置的模式适用于报价人和应答人。报价人不得发送已被应答人移除的模式帧。
For multicast sessions, if "mode-set" is supplied in the offer, the answerer SHALL only participate in the session if it supports the offered mode-set.
对于多播会话，如果要约中提供了“模式集”，则应答者仅应在支持所提供模式集的情况下参与会话。
o The parameters "ptime" and "maxptime" will in most cases not affect interoperability. The SDP offer-answer handling of the "ptime" parameter is described in [RFC3264]. The "maxptime" parameter MUST be handled in the same way.
o 参数“ptime”和“maxptime”在大多数情况下不会影响互操作性。[RFC3264]中描述了“ptime”参数的SDP提供应答处理。必须以相同的方式处理“maxptime”参数。
o Any unknown parameter in an offer MUST be ignored by the receiver and MUST NOT be included in the answer.
o 接收方必须忽略报价中的任何未知参数，且不得将其包含在答案中。
Below are some example parts of SDP offer-answer exchanges.
下面是SDP提供答案交换的一些示例部分。
o Example 1
o 例1
Offer: G.711.1 all modes, with G.711 fallback, prefers mu-law
m=audio 54874 RTP/AVP 96 97 0 8
a=rtpmap:96 PCMU-WB/16000
a=rtpmap:97 PCMA-WB/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
Offer: G.711.1 all modes, with G.711 fallback, prefers mu-law
m=audio 54874 RTP/AVP 96 97 0 8
a=rtpmap:96 PCMU-WB/16000
a=rtpmap:97 PCMA-WB/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
Answer: all modes accepted, both mu- and A-law.
m=audio 59452 RTP/AVP 96 97
a=rtpmap:96 PCMU-WB/16000
a=rtpmap:97 PCMA-WB/16000
Answer: all modes accepted, both mu- and A-law.
m=audio 59452 RTP/AVP 96 97
a=rtpmap:96 PCMU-WB/16000
a=rtpmap:97 PCMA-WB/16000
o Example 2
o 例2
Offer: G.711.1 all modes, with G.711 fallback, prefers A-law
m=audio 54874 RTP/AVP 96 97 8 0
a=rtpmap:96 PCMA-WB/16000
a=rtpmap:97 PCMU-WB/16000
Offer: G.711.1 all modes, with G.711 fallback, prefers A-law
m=audio 54874 RTP/AVP 96 97 8 0
a=rtpmap:96 PCMA-WB/16000
a=rtpmap:97 PCMU-WB/16000
Answer: wants only A-law mode R3
m=audio 59452 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4
Answer: wants only A-law mode R3
m=audio 59452 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4
o Example 3
o 例3
Offer: G.711.1 A-law with two modes, R2b and R3, with R3 preferred
m=audio 54874 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4,3
Offer: G.711.1 A-law with two modes, R2b and R3, with R3 preferred
m=audio 54874 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4,3
Answer: accepted
m=audio 59452 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4,3
Answer: accepted
m=audio 59452 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4,3
If the answerer had wanted to restrict to one mode, it would have answered with only one value in the mode-set, for example mode-set=3 for mode R2b.
如果回答者希望限制为一种模式，则在模式集中仅使用一个值进行回答，例如，对于模式R2b，模式集=3。
For declarative use of SDP, nothing specific is defined for this payload format. The configuration given by the SDP MUST be used when sending and/or receiving media in the session.
对于SDP的声明性使用，没有为此有效负载格式定义任何特定内容。在会话中发送和/或接收媒体时，必须使用SDP提供的配置。
The L0 layer of G.711.1 is fully interoperable with G.711, and is embedded in all modes of G.711.1. This provides an easy G.711.1 - G.711 transcoding process.
G.711.1的L0层可与G.711完全互操作，并嵌入到G.711.1的所有模式中。这提供了一个简单的G.711.1-G.711转码过程。
A gateway or any other network device receiving a G.711.1 packet can easily extract a G.711-compatible payload, without the need to decode and re-encode the audio signal. It simply has to take the audio data of the payload, and strip the upper layers (L1 and/or L2), if any.
接收G.711.1数据包的网关或任何其他网络设备可以轻松提取G.711兼容的有效载荷，而无需解码和重新编码音频信号。它只需获取有效负载的音频数据，并剥离上层（L1和/或L2），如果有的话。
If a G.711.1 packet contains several frames, the concatenation of the L0 layers of each frame will form a G.711-compatible payload.
如果G.711.1数据包包含多个帧，则每个帧的L0层的串联将形成G.711兼容的有效载荷。
Congestion control for RTP SHALL be used in accordance with [RFC3550] and any appropriate profile (for example, [RFC3551]).
RTP的拥塞控制应根据[RFC3550]和任何适当的配置文件（例如[RFC3551]）使用。
The embedded nature of G.711.1 audio data can be helpful for congestion control, since a coding mode with a lower bit rate can be selected when needed. This property is usable only when multiple modes have been negotiated (either no "mode-set" parameter in the SDP or a "mode-set" with at least two modes).
G.711.1音频数据的嵌入式特性有助于拥塞控制，因为在需要时可以选择具有较低比特率的编码模式。此属性仅在协商了多个模式时可用（SDP中没有“模式集”参数或“模式集”至少有两个模式）。
The number of frames encapsulated in each RTP payload influences the overall bandwidth of the RTP stream, due to the header overhead. Packing more frames in each RTP payload can reduce the number of packets sent and hence the header overhead, at the expense of increased delay and reduced error robustness.
由于报头开销，封装在每个RTP有效负载中的帧数影响RTP流的总带宽。在每个RTP有效负载中封装更多帧可以减少发送的数据包数量，从而减少报头开销，但代价是增加延迟和降低错误鲁棒性。
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in the RTP specification [RFC3550] and any appropriate profile (for example, [RFC3551]).
使用本规范中定义的有效负载格式的RTP数据包受RTP规范[RFC3550]和任何适当配置文件（例如[RFC3551]）中讨论的一般安全注意事项的约束。
As this format transports encoded speech/audio, the main security issues include confidentiality, integrity protection, and authentication of the speech/audio itself. The payload format itself does not have any built-in security mechanisms. Any suitable external mechanisms, such as the Secure Real-time Transport Protocol (SRTP) [RFC3711], MAY be used.
由于这种格式传输编码语音/音频，主要的安全问题包括语音/音频本身的机密性、完整性保护和身份验证。有效负载格式本身没有任何内置的安全机制。可以使用任何合适的外部机制，例如安全实时传输协议（SRTP）[RFC3711]。
This payload format and the G.711.1 encoding do not exhibit any significant non-uniformity in the receiver-end computational load, and thus they are unlikely to pose a denial-of-service threat due to the receipt of pathological datagrams. In addition, they do not contain any type of active content such as scripts.
这种有效载荷格式和G.711.1编码在接收端计算负载中没有表现出任何显著的不均匀性，因此它们不太可能由于接收病理数据报而造成拒绝服务威胁。此外，它们不包含任何类型的活动内容，如脚本。
Two new media subtypes (audio/PCMA-WB and audio/PCMU-WB) have been registered by IANA. See Sections 5.1 and 5.2.
IANA已经注册了两种新的媒体子类型（audio/PCMA-WB和audio/PCMU-WB）。见第5.1节和第5.2节。
[ITU-G.711.1] International Telecommunications Union, "Wideband embedded extension for G.711 pulse code modulation", ITU-T Recommendation G.711.1, March 2008.
[ITU-G.711.1]国际电信联盟，“G.711脉冲编码调制的宽带嵌入式扩展”，ITU-T建议G.711.1，2008年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月。
[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月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[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月。
[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月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855]Casner，S.，“RTP有效负载格式的媒体类型注册”，RFC 48552007年2月。
[ITU-G.711] International Telecommunications Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988.
[ITU-G.711]国际电信联盟，“语音频率的脉冲编码调制（PCM）”，ITU-T建议G.711，1988年11月。
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, September 2002.
[RFC3389]Zopf，R.，“舒适噪声（CN）的实时传输协议（RTP）有效载荷”，RFC 3389，2002年9月。
[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月。
Author's Address
作者地址
Aurelien Sollaud France Telecom 2 avenue Pierre Marzin Lannion Cedex 22307 France
法国皮埃尔·马津·拉尼翁大道2号奥雷林·索洛德法国电信公司Cedex 22307
Phone: +33 2 96 05 15 06
EMail: aurelien.sollaud@orange-ftgroup.com
Phone: +33 2 96 05 15 06
EMail: aurelien.sollaud@orange-ftgroup.com