Network Working Group A. Sollaud
Request for Comments: 4749 France Telecom
Category: Standards Track October 2006
Network Working Group A. Sollaud
Request for Comments: 4749 France Telecom
Category: Standards Track October 2006
RTP Payload Format for the G.729.1 Audio Codec
G.729.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) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.729.1 audio codec. A media type registration is included for this payload format.
本文件规定了用于国际电信联盟（ITU-T）G.729.1音频编解码器的实时传输协议（RTP）有效载荷格式。此有效负载格式包括媒体类型注册。
Table of Contents
目录
1. Introduction ....................................................2
2. Background ......................................................2
3. Embedded Bit Rates Considerations ...............................3
4. RTP Header Usage ................................................3
5. Payload Format ..................................................4
5.1. Payload Structure ..........................................4
5.2. Payload Header: MBS Field ..................................4
5.3. Payload Header: FT Field ...................................6
5.4. Audio Data .................................................6
6. Payload Format Parameters .......................................7
6.1. Media Type Registration ....................................7
6.2. Mapping to SDP Parameters ..................................8
6.2.1. Offer-Answer Model Considerations ...................9
6.2.2. Declarative SDP Considerations .....................11
7. Congestion Control .............................................11
8. Security Considerations ........................................11
9. IANA Considerations ............................................12
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
1. Introduction ....................................................2
2. Background ......................................................2
3. Embedded Bit Rates Considerations ...............................3
4. RTP Header Usage ................................................3
5. Payload Format ..................................................4
5.1. Payload Structure ..........................................4
5.2. Payload Header: MBS Field ..................................4
5.3. Payload Header: FT Field ...................................6
5.4. Audio Data .................................................6
6. Payload Format Parameters .......................................7
6.1. Media Type Registration ....................................7
6.2. Mapping to SDP Parameters ..................................8
6.2.1. Offer-Answer Model Considerations ...................9
6.2.2. Declarative SDP Considerations .....................11
7. Congestion Control .............................................11
8. Security Considerations ........................................11
9. IANA Considerations ............................................12
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
The International Telecommunication Union (ITU-T) recommendation G.729.1 [1] is a scalable and wideband extension of the recommendation G.729 [9] audio codec. This document specifies the payload format for packetization of G.729.1 encoded audio signals into the Real-time Transport Protocol (RTP).
国际电信联盟（ITU-T）建议G.729.1[1]是建议G.729[9]音频编解码器的可扩展宽带扩展。本文件规定了将G.729.1编码音频信号打包成实时传输协议（RTP）的有效载荷格式。
The payload format itself is described in Section 5. A media type registration and the details for the use of G.729.1 with SDP are given in Section 6.
有效载荷格式本身在第5节中描述。第6节给出了媒体类型注册和G.729.1与SDP一起使用的详细信息。
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 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
G.729.1 is an 8-32 kbps scalable wideband (50-7000 Hz) speech and audio coding algorithm interoperable with G.729, G.729 Annex A, and G.729 Annex B. It provides a standardized solution for packetized voice applications that allows a smooth transition from narrowband to wideband telephony.
G.729.1是一种8-32 kbps可扩展宽带（50-7000 Hz）语音和音频编码算法，可与G.729、G.729附录A和G.729附录B互操作。它为分组语音应用提供了标准化解决方案，允许从窄带到宽带电话的平滑过渡。
The most important services addressed are IP telephony and videoconferencing, either for enterprise corporate networks or for mass market (like Public Switched Telephone Network (PSTN) emulation over DSL or wireless access). Target devices can be IP phones or other VoIP handsets, home gateways, media gateways, IP Private Branch Exchange (IPBX), trunking equipment, voice messaging servers, etc.
最重要的服务是IP电话和视频会议，无论是针对企业网络还是面向大众市场（如通过DSL或无线接入的公共交换电话网络（PSTN）仿真）。目标设备可以是IP电话或其他VoIP手机、家庭网关、媒体网关、IP专用分支交换机（IPBX）、中继设备、语音消息服务器等。
For all those applications, the scalability feature allows tuning the bit rate versus quality trade-off, possibly in a dynamic way during a session, taking into account service requirements and network transport constraints.
对于所有这些应用程序，可伸缩性功能允许在会话期间以动态方式调整比特率与质量之间的权衡，同时考虑服务需求和网络传输约束。
The G.729.1 coder produces an embedded bitstream structured in 12 layers corresponding to 12 available bit rates between 8 and 32 kbps. The first layer, at 8 kbps, is called the core layer and is bitstream compatible with the ITU-T G.729/G.729A coder. At 12 kbps, a second layer improves the narrowband quality. Upper layers provide wideband audio (50-7000 Hz) between 14 and 32 kbps, with a 2 kbps granularity allowing graceful quality improvements. Only the core layer is mandatory to decode understandable speech; upper layers provide quality enhancement and wideband enlargement.
G.729.1编码器产生12层结构的嵌入式比特流，对应于8到32 kbps之间的12个可用比特率。第一层为8 kbps，称为核心层，与ITU-T G.729/G.729A编码器兼容。在12 kbps时，第二层提高了窄带质量。上层提供14到32 kbps之间的宽带音频（50-7000 Hz），2 kbps的粒度允许优雅的质量改进。只有核心层必须解码可理解的语音；上层提供质量增强和宽带放大。
The codec operates on 20-ms frames, and the default sampling rate is 16 kHz. Input and output at 8 kHz are also supported, at all bit rates.
编解码器在20毫秒帧上运行，默认采样率为16 kHz。在所有比特率下，也支持8 kHz的输入和输出。
The embedded property of G.729.1 streams provides a mechanism to adjust the bandwidth demand. At any time, a sender can change its sending bit rate without external signalling, and the receiver will be able to properly decode the frames. It may help to control congestion, since the bandwidth can be adjusted by selecting another bit rate.
G.729.1流的嵌入式特性提供了一种调整带宽需求的机制。在任何时候，发送方都可以在没有外部信令的情况下更改其发送比特率，并且接收方将能够正确解码帧。它可能有助于控制拥塞，因为可以通过选择另一个比特率来调整带宽。
The ability to adjust the bandwidth may also help when having a fixed bandwidth link dedicated to voice calls, for example in a residential or trunking gateway. In that case, the system can change the bit rates depending on the number of simultaneous calls. This will only impact the sending bandwidth. In order to adjust the receiving bandwidth as well, we introduce an in-band signalling to request the other party to change its own sending bit rate. This in-band request is called MBS, for Maximum Bit rate Supported. It is described in Section 5.2. Note that it is only useful for two-way unicast G.729.1 traffic, because when A sends an in-band MBS to B in order to request that B modify its sending bit rate, it concerns the stream from B to A. If there is no G.729.1 stream in the reverse direction, the MBS will have no effect.
当具有专用于语音呼叫的固定带宽链路时，例如在住宅或中继网关中，调整带宽的能力也可能有所帮助。在这种情况下，系统可以根据同时调用的数量更改比特率。这只会影响发送带宽。为了调整接收带宽，我们引入带内信令来请求另一方改变其自身的发送比特率。对于支持的最大比特率，此带内请求称为MBS。第5.2节对此进行了说明。注意，它仅对双向单播G.729.1通信有用，因为当A向B发送带内MBS以请求B修改其发送比特率时，它涉及从B到A的流。如果反向没有G.729.1流，MBS将无效。
The format of the RTP header is specified in RFC 3550 [3]. This payload format uses the fields of the header in a manner consistent with that specification.
RTP报头的格式在RFC 3550[3]中规定。此有效负载格式以与该规范一致的方式使用报头的字段。
The RTP timestamp clock frequency is the same as the default sampling frequency: 16 kHz.
RTP时间戳时钟频率与默认采样频率相同：16 kHz。
G.729.1 has also the capability to operate with 8 kHz sampled input/ output signals at all bit rates. 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.729.1还具有在所有比特率下使用8 kHz采样输入/输出信号的能力。它不影响比特流，并且解码器不需要关于编码器输入处原始信号的采样率的先验知识。因此，根据设备的实现和音频声学能力，编码器的输入和/或解码器的输出可以配置为8khz；但是，必须始终使用16 kHz RTP时钟频率。
The duration of one frame is 20 ms, corresponding to 320 samples at 16 kHz. Thus the timestamp is increased by 320 for each consecutive frame.
一帧的持续时间为20 ms，对应于16 kHz下的320个样本。因此，对于每个连续帧，时间戳增加320。
The M bit MUST be set to zero in all packets.
在所有数据包中，M位必须设置为零。
The assignment of an RTP payload type for this packet format is outside the scope of the 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 6.2).
此数据包格式的RTP有效负载类型的分配超出了文档的范围，此处将不指定。预计使用此有效负载格式的RTP配置文件将为此编解码器分配有效负载类型，或指定动态绑定有效负载类型（参见第6.2节）。
The complete payload consists of a payload header of 1 octet, followed by zero or more consecutive audio frames at the same bit rate.
完整的有效负载由1个八位字节的有效负载头组成，后跟零个或多个相同比特率的连续音频帧。
The payload header consists of two fields: MBS (see Section 5.2) and FT (see Section 5.3).
有效载荷标题由两个字段组成：MBS（见第5.2节）和FT（见第5.3节）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBS | FT | |
+-+-+-+-+-+-+-+-+ +
: zero or more frames at the same bit rate :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBS | FT | |
+-+-+-+-+-+-+-+-+ +
: zero or more frames at the same bit rate :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBS (4 bits): maximum bit rate supported. Indicates a maximum bit rate to the encoder at the site of the receiver of this payload. The value of the MBS field is set according to the following table:
MBS（4位）：支持的最大比特率。指示此有效负载的接收器站点处编码器的最大比特率。MBS字段的值根据下表设置：
+-------+--------------+
| MBS | max bit rate |
+-------+--------------+
| 0 | 8 kbps |
| 1 | 12 kbps |
| 2 | 14 kbps |
| 3 | 16 kbps |
| 4 | 18 kbps |
| 5 | 20 kbps |
| 6 | 22 kbps |
| 7 | 24 kbps |
| 8 | 26 kbps |
| 9 | 28 kbps |
| 10 | 30 kbps |
| 11 | 32 kbps |
| 12-14 | (reserved) |
| 15 | NO_MBS |
+-------+--------------+
+-------+--------------+
| MBS | max bit rate |
+-------+--------------+
| 0 | 8 kbps |
| 1 | 12 kbps |
| 2 | 14 kbps |
| 3 | 16 kbps |
| 4 | 18 kbps |
| 5 | 20 kbps |
| 6 | 22 kbps |
| 7 | 24 kbps |
| 8 | 26 kbps |
| 9 | 28 kbps |
| 10 | 30 kbps |
| 11 | 32 kbps |
| 12-14 | (reserved) |
| 15 | NO_MBS |
+-------+--------------+
The MBS is used to tell the other party the maximum bit rate one can receive. The encoder MUST NOT exceed the sending rate indicated by the received MBS. Note that, due to the embedded property of the coding scheme, the encoder can send frames at the MBS rate or any lower rate. As long as it does not exceed the MBS, the encoder can change its bit rate at any time without previous notice.
MBS用于告诉另一方可以接收的最大比特率。编码器不得超过接收到的MBS指示的发送速率。注意，由于编码方案的嵌入特性，编码器可以以MBS速率或任何更低的速率发送帧。只要不超过MBS，编码器可以随时更改其比特率，而无需事先通知。
Note that the MBS is a codec bit rate; the actual network bit rate is higher and depends on the overhead of the underlying protocols.
注意，MBS是编解码器比特率；实际网络比特率较高，这取决于底层协议的开销。
The MBS received is valid until the next MBS is received, i.e., a newly received MBS value overrides the previous one.
接收到的MBS在接收到下一个MBS之前有效，即，新接收到的MBS值覆盖上一个MBS值。
If a payload with a reserved MBS value is received, the MBS MUST be ignored.
如果接收到具有保留MBS值的有效负载，则必须忽略MBS。
The MBS field MUST be set to 15 for packets sent to a multicast group and MUST be ignored on packets received from a multicast group.
对于发送到多播组的数据包，必须将MBS字段设置为15，对于从多播组接收的数据包，必须忽略MBS字段。
The MBS field MUST be set to 15 in all packets when the actual MBS value is sent through non-RTP means. This is out of the scope of this specification.
当通过非RTP方式发送实际MBS值时，所有数据包中的MBS字段必须设置为15。这超出了本规范的范围。
See Sections 3 and 7 for more details on the use of MBS for congestion control.
有关使用MBS进行拥塞控制的更多详细信息，请参见第3节和第7节。
FT (4 bits): Frame type of the frame(s) in this packet, as per the following table:
FT（4位）：此数据包中帧的帧类型，如下表所示：
+-------+---------------+------------+
| FT | encoding rate | frame size |
+-------+---------------+------------+
| 0 | 8 kbps | 20 octets |
| 1 | 12 kbps | 30 octets |
| 2 | 14 kbps | 35 octets |
| 3 | 16 kbps | 40 octets |
| 4 | 18 kbps | 45 octets |
| 5 | 20 kbps | 50 octets |
| 6 | 22 kbps | 55 octets |
| 7 | 24 kbps | 60 octets |
| 8 | 26 kbps | 65 octets |
| 9 | 28 kbps | 70 octets |
| 10 | 30 kbps | 75 octets |
| 11 | 32 kbps | 80 octets |
| 12-14 | (reserved) | |
| 15 | NO_DATA | 0 |
+-------+---------------+------------+
+-------+---------------+------------+
| FT | encoding rate | frame size |
+-------+---------------+------------+
| 0 | 8 kbps | 20 octets |
| 1 | 12 kbps | 30 octets |
| 2 | 14 kbps | 35 octets |
| 3 | 16 kbps | 40 octets |
| 4 | 18 kbps | 45 octets |
| 5 | 20 kbps | 50 octets |
| 6 | 22 kbps | 55 octets |
| 7 | 24 kbps | 60 octets |
| 8 | 26 kbps | 65 octets |
| 9 | 28 kbps | 70 octets |
| 10 | 30 kbps | 75 octets |
| 11 | 32 kbps | 80 octets |
| 12-14 | (reserved) | |
| 15 | NO_DATA | 0 |
+-------+---------------+------------+
The FT value 15 (NO_DATA) indicates that there is no audio data in the payload. This MAY be used to update the MBS value when there is no audio frame to transmit. The payload will then be reduced to the payload header.
FT值15（无_数据）表示有效负载中没有音频数据。这可用于在没有要传输的音频帧时更新MBS值。然后，有效负载将减少到有效负载收割台。
If a payload with a reserved FT value is received, the whole payload MUST be ignored.
如果接收到具有保留FT值的有效负载，则必须忽略整个有效负载。
Audio data of a payload contains one or more consecutive audio frames at the same bit rate. The audio frames are packed in order of time, that is, oldest first.
有效载荷的音频数据包含具有相同比特率的一个或多个连续音频帧。音频帧按时间顺序打包，也就是说，最早的帧优先。
The size of one frame is given by the FT field, as per the table in Section 5.3, and the actual number of frames is easy to infer from the size of the audio data part:
根据第5.3节中的表格，一帧的大小由FT字段给出，实际帧数很容易从音频数据部分的大小推断出来：
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.
必须只考虑完整的框架。因此，如果上面的除法还有余数，则必须忽略接收到的有效负载中相应的剩余字节。
Note that if FT=15, there will be no audio frame in the payload.
请注意，如果FT=15，则有效负载中将没有音频帧。
This section defines the parameters that may be used to configure optional features in the G.729.1 RTP transmission.
本节定义了可用于配置G.729.1 RTP传输中可选功能的参数。
The parameters are defined here as part of the media subtype registration for the G.729.1 codec. A mapping of the parameters into the Session Description Protocol (SDP) [5] 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.729.1编解码器的媒体子类型注册的一部分。还为使用SDP的应用程序提供了参数到会话描述协议（SDP）[5]的映射。在不使用MIME或SDP的控制协议中，媒体类型参数必须映射到与该控制协议一起使用的适当格式。
This registration is done using the template defined in RFC 4288 [6] and following RFC 3555 [7].
使用RFC 4288[6]中定义的模板以及RFC 3555[7]中定义的模板完成注册。
Type name: audio
类型名称：音频
Subtype name: G7291
子类型名称：G7291
Required parameters: none
所需参数：无
Optional parameters:
可选参数：
maxbitrate: the absolute maximum codec bit rate for the session, in bits per second. Permissible values are 8000, 12000, 14000, 16000, 18000, 20000, 22000, 24000, 26000, 28000, 30000, and 32000. 32000 is implied if this parameter is omitted. The maxbitrate restricts the range of bit rates which can be used. The bit rates indicated by FT and MBS fields in the RTP packets MUST NOT exceed maxbitrate.
maxbitrate：会话的绝对最大编解码器比特率，以位/秒为单位。允许值为8000、12000、14000、16000、18000、20000、22000、24000、26000、28000、30000和32000。如果省略此参数，则表示32000。maxbitrate限制可使用的比特率范围。RTP数据包中FT和MBS字段指示的比特率不得超过maxbitrate。
mbs: the current maximum codec bit rate supported as a receiver, in bits per second. Permissible values are in the same set as for the maxbitrate parameter, with the constraint that mbs MUST be lower or equal to maxbitrate. If the mbs parameter is omitted, it is set to the maxbitrate value. So if both mbs and maxbitrate are omitted, they are both set to 32000. The mbs parameter corresponds to a MBS value in the RTP packets as per table in Section 5.2 of RFC 4749. Note that this parameter may be dynamically updated by the MBS field of the RTP packets sent; it is not an absolute value for the session.
mbs：接收器支持的当前最大编解码器比特率，单位为比特/秒。允许值与maxbitrate参数的设置相同，但有一个限制，即mbs必须小于或等于maxbitrate。如果省略mbs参数，则将其设置为maxbitrate值。因此，如果同时省略mbs和maxbitrate，则它们都设置为32000。根据RFC 4749第5.2节中的表，mbs参数对应于RTP数据包中的mbs值。注意，该参数可由发送的RTP分组的MBS字段动态更新；它不是会话的绝对值。
ptime: the recommended length of time (in milliseconds) represented by the media in a packet. See Section 6 of RFC 4566 [5].
ptime：由数据包中的媒体表示的建议时间长度（毫秒）。见RF456第5节[见RF66]。
maxptime: the maximum length of time (in milliseconds) that can be encapsulated in a packet. See Section 6 of RFC 4566 [5]
maxptime：可以封装在数据包中的最大时间长度（以毫秒为单位）。参见RFC 4566[5]第6节
Encoding considerations: This media type is framed and contains binary data; see Section 4.8 of RFC 4288 [6].
编码注意事项：此媒体类型为框架，包含二进制数据；参见RFC 4288[6]第4.8节。
Security considerations: See Section 8 of RFC 4749
安全注意事项：见RFC 4749第8节
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 4749
已发布规范：RFC 4749
Applications which 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 [3].
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[3]。
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) [5], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the G.729.1 codec, the mapping is as follows:
媒体类型规范中包含的信息与会话描述协议（SDP）[5]中的字段具有特定映射，该协议通常用于描述RTP会话。当使用SDP指定使用G.729.1编解码器的会话时，映射如下：
o The media type ("audio") goes in SDP "m=" as the media name.
o 媒体类型（“音频”）以SDP“m=”作为媒体名称。
o The media subtype ("G7291") goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for G.729.1.
o 媒体子类型（“G7291”）以SDP“a=rtpmap”作为编码名称。对于G.729.1，“a=rtpmap”中的RTP时钟频率必须为16000。
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”属性中。
o Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the media type string as a semicolon separated list of parameter=value pairs.
o 通过直接从媒体类型字符串中以分号分隔的参数=值对列表形式复制其余参数，将其放入SDP“a=fmtp”属性中。
Some example SDP session descriptions utilizing G.729.1 encodings follow.
下面是使用G.729.1编码的一些示例SDP会话描述。
Example 1: default parameters
示例1：默认参数
m=audio 53146 RTP/AVP 98
a=rtpmap:98 G7291/16000
m=audio 53146 RTP/AVP 98
a=rtpmap:98 G7291/16000
Example 2: recommended packet duration of 40 ms (=2 frames), maximum bit rate is 12 kbps, and initial MBS set to 8 kbps. It could be a loaded PSTN gateway which can operate at 12 kbps but asks to initially reduce the bit rate to 8 kbps.
示例2：建议的数据包持续时间为40ms（=2帧），最大比特率为12kbps，初始MBS设置为8kbps。它可能是一个加载的PSTN网关，可以以12Kbps的速率运行，但要求最初将比特率降低到8Kbps。
m=audio 51258 RTP/AVP 99
a=rtpmap:99 G7291/16000
a=fmtp:99 maxbitrate=12000; mbs=8000
a=ptime:40
m=audio 51258 RTP/AVP 99
a=rtpmap:99 G7291/16000
a=fmtp:99 maxbitrate=12000; mbs=8000
a=ptime:40
The following considerations apply when using SDP offer-answer procedures [8] to negotiate the use of G.729.1 payload in RTP:
使用SDP报价-应答程序[8]协商RTP中G.729.1有效载荷的使用时，应考虑以下因素：
o Since G.729.1 is an extension of G.729, the offerer SHOULD announce G.729 support in its "m=audio" line, with G.729.1 preferred. This will allow interoperability with both G.729.1 and G.729-only capable parties.
o 由于G.729.1是G.729的扩展，报价人应在其“m=audio”行中宣布G.729支持，首选G.729.1。这将允许与G.729.1和只支持G.729的各方进行互操作。
Below is an example of such an offer:
以下是此类报价的一个示例：
m=audio 55954 RTP/AVP 98 18
a=rtpmap:98 G7291/16000
a=rtpmap:18 G729/8000
m=audio 55954 RTP/AVP 98 18
a=rtpmap:98 G7291/16000
a=rtpmap:18 G729/8000
If the answerer supports G.729.1, it will keep the payload type 98 in its answer, and the conversation will be done using G.729.1. Else, if the answerer supports only G.729, it will leave only the payload type 18 in its answer, and the conversation will be done using G.729 (the payload format for G.729 is defined in Section 4.5.6 of RFC 3551 [4]).
如果回答者支持G.729.1，那么它将在回答中保留有效负载类型98，并且对话将使用G.729.1完成。否则，如果应答者仅支持G.729，则其应答中将只保留有效载荷类型18，对话将使用G.729完成（RFC 3551[4]第4.5.6节中定义了G.729的有效载荷格式）。
Note that when used at 8 kbps in G.729-compatible mode, the G.729.1 decoder supports G.729 Annex B. Therefore, Annex B can be advertised (by default, annexb=yes for G729 media type; see Section 4.1.9 of RFC 3555 [7]).
请注意，当在G.729兼容模式下以8 kbps的速度使用时，G.729.1解码器支持G.729附录B。因此，附录B可以发布（默认情况下，附录B=是表示G729媒体类型；请参阅RFC 3555[7]第4.1.9节）。
o The "maxbitrate" parameter is bi-directional. If the offerer sets a maxbitrate value, the answerer MUST reply with a smaller or equal value. The actual maximum bit rate for the session will be the minimum.
o “maxbitrate”参数是双向的。如果提供方设置了maxbitrate值，则应答方必须使用较小或相等的值进行回复。会话的实际最大比特率将是最小的。
o If the received value for "maxbitrate" is between 8000 and 32000 but not in the permissible values set, it SHOULD be read as the closest lower valid value. If the received value is lower than 8000 or greater than 32000, the session MUST be rejected.
o 如果“maxbitrate”的接收值介于8000和32000之间，但不在允许值集内，则应将其读取为最接近的较低有效值。如果收到的值小于8000或大于32000，则必须拒绝会话。
o The "mbs" parameter is not symmetric. Values in the offer and the answer are independent and take into account local constraints. One party MUST NOT start sending frames at a bit rate higher than the "mbs" of the other party. The parameter allows announcing this value, prior to the sending of any packet, to prevent the remote sender from exceeding the MBS at the beginning of the session.
o “mbs”参数不是对称的。报价和答案中的值是独立的，并考虑了本地约束。一方不得以高于另一方“mbs”的比特率开始发送帧。该参数允许在发送任何数据包之前宣布该值，以防止远程发送方在会话开始时超过MBS。
o If the received value for "mbs" is greater or equal to 8000 but not in the permissible values set, it SHOULD be read as the closest lower valid value. If the received value is lower than 8000, the session MUST be rejected.
o 如果“mbs”的接收值大于或等于8000，但不在允许值集内，则应将其读取为最接近的较低有效值。如果收到的值低于8000，则必须拒绝会话。
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 RFC 3264 [8]. The "maxptime" parameter MUST be handled in the same way.
o 参数“ptime”和“maxptime”在大多数情况下不会影响互操作性。RFC 3264[8]中描述了“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 接收方必须忽略报价中的任何未知参数，且不得将其包含在答案中。
Some special rules apply for mono-directional traffic:
一些特殊规则适用于单向交通：
o For sendonly streams, the "mbs" parameter is useless and SHOULD NOT be used.
o 对于仅发送的流，“mbs”参数无效，不应使用。
o For recvonly streams, the "mbs" parameter is the only way to communicate the MBS to the sender, since there is no RTP stream towards it. So to request a bit rate change, the receiver will need to use an out-of-band mechanism, like a SIP RE-INVITE.
o 对于recvonly流，“mbs”参数是将mbs传送给发送方的唯一方式，因为没有RTP流。因此，要请求比特率更改，接收器需要使用带外机制，如SIP重新邀请。
Some special rules apply for multicast:
一些特殊规则适用于多播：
o The "mbs" parameter MUST NOT be used.
o 不得使用“mbs”参数。
o The "maxbitrate" parameter becomes declarative and MUST NOT be negotiated. This parameter is fixed, and a participant MUST use the configuration that is provided for the session.
o “maxbitrate”参数变为声明性参数，不能协商。此参数是固定的，参与者必须使用为会话提供的配置。
For declarative use of SDP such as in SAP [10] and RTSP [11], the following considerations apply:
对于SDP的声明性使用，如在SAP[10]和RTSP[11]中，以下注意事项适用：
o The "mbs" parameter MUST NOT be used.
o 不得使用“mbs”参数。
o The "maxbitrate" parameter is declarative and provides the parameter that SHALL be used when receiving and/or sending the configured stream.
o “maxbitrate”参数是声明性的，并提供在接收和/或发送配置流时应使用的参数。
Congestion control for RTP SHALL be used in accordance with RFC 3550 [3] and any appropriate profile (for example, RFC 3551 [4]). The embedded and variable bit rates capability of G.729.1 provides a mechanism that may help to control congestion; see Section 3 for more details.
RTP的拥塞控制应按照RFC 3550[3]和任何适当的配置文件（例如，RFC 3551[4]）使用。G.729.1的嵌入式和可变比特率功能提供了一种有助于控制拥塞的机制；详见第3节。
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 [3] and any appropriate profile (for example, RFC 3551 [4]).
使用本规范中定义的有效负载格式的RTP数据包受RTP规范[3]和任何适当配置文件（例如，RFC 3551[4]）中讨论的一般安全注意事项的约束。
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 SRTP [12], MAY be used.
由于这种格式传输编码语音/音频，主要的安全问题包括语音/音频本身的机密性、完整性保护和身份验证。有效负载格式本身没有任何内置的安全机制。可以使用任何合适的外部机制，如SRTP[12]。
This payload format and the G.729.1 encoding do not exhibit any significant non-uniformity in the receiver-end computational load and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological datagrams.
该有效载荷格式和G.729.1编码在接收端计算负载中不表现出任何显著的不均匀性，因此不太可能由于接收病理数据报而造成拒绝服务威胁。
IANA has registered audio/G7291 as a media subtype; see Section 6.1.
IANA已将audio/G7291注册为媒体子类型；见第6.1节。
[1] International Telecommunications Union, "G.729 based Embedded Variable bit-rate coder: An 8-32 kbit/s scalable wideband coder bitstream interoperable with G.729", ITU-T Recommendation G.729.1, May 2006.
[1] 国际电信联盟，“基于G.729的嵌入式可变比特率编码器：可与G.729互操作的8-32 kbit/s可伸缩宽带编码器比特流”，ITU-T建议G.729.1，2006年5月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[3] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[4] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[5] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[6] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[6] Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[7] Casner，S.和P.Hoschka，“RTP有效载荷格式的MIME类型注册”，RFC 3555，2003年7月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[9] International Telecommunications Union, "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996.
[9] 国际电信联盟，“使用共轭结构代数码激励线性预测（CS-ACELP）对8kbit/s语音进行编码”，ITU-T建议G.729，1996年3月。
[10] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[10] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[11] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[11] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[12] 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
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。