Network Working Group A. Duric
Request for Comments: 3952 Telio
Category: Experimental S. Andersen
Aalborg University
December 2004
Network Working Group A. Duric
Request for Comments: 3952 Telio
Category: Experimental S. Andersen
Aalborg University
December 2004
Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech
internet低速率编解码器（iLBC）语音的实时传输协议（RTP）有效负载格式
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME and Session Description Protocol (SDP).
本文档描述了全球IP声音（GIPS）开发的互联网低比特率编解码器（iLBC）语音的实时传输协议（RTP）有效负载格式。此外，在文档中还包含了将iLBC与MIME和会话描述协议（SDP）结合使用的必要细节。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background. . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. RTP Payload Format. . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Bitstream definition . . . . . . . . . . . . . . . . . . . 3
3.2. Multiple iLBC frames in a RTP packet . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. MIME registration of iLBC. . . . . . . . . . . . . . . . . 8
5. Mapping to SDP Parameters . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background. . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. RTP Payload Format. . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Bitstream definition . . . . . . . . . . . . . . . . . . . 3
3.2. Multiple iLBC frames in a RTP packet . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. MIME registration of iLBC. . . . . . . . . . . . . . . . . 8
5. Mapping to SDP Parameters . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
This document describes how compressed iLBC speech, as produced by the iLBC codec [1], may be formatted for use as an RTP payload type. Methods are provided to packetize the codec data frames into RTP packets. The sender may send one or more codec data frames per packet depending on the application scenario or based on the transport network condition, bandwidth restriction, delay requirements and packet-loss tolerance.
本文档描述了如何对iLBC编解码器[1]生成的压缩iLBC语音进行格式化，以用作RTP有效负载类型。提供了将编解码器数据帧打包成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 BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
Global IP Sound (GIPS) has developed a speech compression algorithm for use in IP based communications [1]. The iLBC codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets.
全球IP声音（GIPS）开发了一种语音压缩算法，用于基于IP的通信[1]。iLBC编解码器能够在丢失帧的情况下实现优美的语音质量下降，这与丢失或延迟的IP数据包有关。
This codec is suitable for real time communications such as, telephony and videoconferencing, streaming audio, archival and messaging.
此编解码器适用于实时通信，如电话和视频会议、流式音频、存档和消息传递。
The iLBC codec [1] is an algorithm that compresses each basic frame (20 ms or 30 ms) of 8000 Hz, 16-bit sampled input speech, into output frames with rate of 400 bits for 30 ms basic frame size and 304 bits for 20 ms basic frame size.
iLBC编解码器[1]是一种算法，它将8000 Hz、16位采样输入语音的每个基本帧（20毫秒或30毫秒）压缩为输出帧，30毫秒基本帧大小的速率为400位，20毫秒基本帧大小的速率为304位。
The codec supports two basic frame lengths: 30 ms at 13.33 kbit/s and 20 ms at 15.2 kbit/s, using a block independent linear-predictive coding (LPC) algorithm. When the codec operates at block lengths of 20 ms, it produces 304 bits per block which MUST be packetized in 38 bytes. Similarly, for block lengths of 30 ms it produces 400 bits per block which MUST be packetized in 50 bytes. This algorithm results in a speech coding system with a controlled response to packet losses similar to what is known from pulse code modulation (PCM) with a packet loss concealment (PLC), such as ITU-T G711 standard [7], which operates at a fixed bit rate of 64 kbit/s. At the same time, this algorithm enables fixed bit rate coding with a quality-versus-bit rate tradeoff close to what is known from code-excited linear prediction (CELP).
该编解码器支持两种基本帧长度：使用块独立线性预测编码（LPC）算法，以13.33 kbit/s的速度30 ms，以15.2 kbit/s的速度20 ms。当编解码器以20ms的块长度运行时，它每块产生304位，必须用38字节进行打包。类似地，对于30ms的块长度，每个块产生400位，必须在50字节中打包。该算法产生了一个语音编码系统，该系统对丢包有受控响应，类似于已知的具有丢包隐藏（PLC）的脉冲编码调制（PCM），如ITU-T G711标准[7]，该标准以64 kbit/s的固定比特率运行。同时，该算法实现了固定比特率编码，其质量与比特率之间的折衷接近于代码激励线性预测（CELP）中已知的折衷。
The iLBC codec uses 20 or 30 ms frames and a sampling rate clock of 8 kHz, so the RTP timestamp MUST be in units of 1/8000 of a second. The RTP payload for iLBC has the format shown in the figure bellow. No addition header specific to this payload format is required.
iLBC编解码器使用20或30毫秒帧和8 kHz的采样率时钟，因此RTP时间戳必须以1/8000秒为单位。iLBC的RTP有效负载的格式如下图所示。不需要特定于此有效负载格式的附加标头。
This format is intended for the situations where the sender and the receiver send one or more codec data frames per packet. The RTP packet looks as follows:
此格式适用于发送方和接收方每个数据包发送一个或多个编解码器数据帧的情况。RTP数据包如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header [3] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ one or more frames of iLBC [1] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header [3] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ one or more frames of iLBC [1] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1, Packet format diagram
图1，数据包格式图
The RTP header of the packetized encoded iLBC speech has the expected values as described in [3]. The usage of M bit SHOULD be as specified in the applicable RTP profile, for example, RFC 3551 [4] specifies that if the sender does not suppress silence (i.e., sends a frame on every frame interval), the M bit will always be zero. When more then one codec data frame is present in a single RTP packet, the timestamp is, as always, the oldest data frame represented in the RTP packet.
分组编码的iLBC语音的RTP报头具有[3]中所述的预期值。M位的使用应符合适用RTP配置文件的规定，例如，RFC 3551[4]规定，如果发送方不抑制静默（即，在每个帧间隔发送一帧），M位将始终为零。当单个RTP数据包中存在多个编解码器数据帧时，时间戳始终是RTP数据包中表示的最早的数据帧。
The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or if that is not done, then a payload type in the dynamic range shall be chosen by the sender.
此新数据包格式的RTP有效负载类型的分配超出了本文档的范围，此处将不进行指定。预计特定类别应用的RTP配置文件将为此编码分配有效负载类型，或者如果未分配有效负载类型，则发送方应选择动态范围内的有效负载类型。
The total number of bits used to describe one frame of 20 ms speech is 304, which fits in 38 bytes and results in a bit rate of 15.20 kbit/s. For the case with a frame length of 30 ms speech the total number of bits used is 400, which fits in 50 bytes and results in a bit rate of 13.33 kbit/s. In the bitstream definition, the bits are distributed into three classes according to their bit error or loss sensitivity. The most sensitive bits (class 1) are placed first in
用于描述20毫秒语音的一帧的总位数为304，适合38字节，比特率为15.20 kbit/s。对于帧长为30ms语音的情况，使用的总比特数为400，适合于50字节，比特率为13.33kbit/s。在比特流定义中，根据比特的误码或丢失敏感性将比特分为三类。最敏感位（1类）放在第一位
the bitstream for each frame. The less sensitive bits (class 2) are placed after the class 1 bits. The least sensitive bits (class 3) are placed at the end of the bitstream for each frame.
每个帧的位流。敏感度较低的位（类别2）放在类别1位之后。对于每个帧，最不敏感的位（类别3）被放置在比特流的末尾。
Looking at the 20/30 ms frame length cases for each class: The class 1 bits occupy a total of 6/8 bytes (48/64 bits), the class 2 bits occupy 8/12 bytes (64/96 bits), and the class 3 bits occupy 24/30 bytes (191/239 bits). This distribution of the bits enables the use of uneven level protection (ULP). The detailed bit allocation is shown in the table below. When a quantization index is distributed between more classes the more significant bits belong to the lowest class.
查看每个类的20/30ms帧长度情况：类1位总共占用6/8字节（48/64位），类2位占用8/12字节（64/96位），类3位占用24/30字节（191/239位）。位的这种分布允许使用不均匀级别保护（ULP）。详细的位分配如下表所示。当量化索引分布在更多类别之间时，更重要的比特属于最低类别。
Bitstream structure:
比特流结构：
------------------------------------------------------------------+
Parameter | Bits Class <1,2,3> |
| 20 ms frame | 30 ms frame |
----------------------------------+---------------+---------------+
Split 1 | 6 <6,0,0> | 6 <6,0,0> |
LSF 1 Split 2 | 7 <7,0,0> | 7 <7,0,0> |
LSF Split 3 | 7 <7,0,0> | 7 <7,0,0> |
------------------+---------------+---------------+
Split 1 | NA (Not Appl.)| 6 <6,0,0> |
LSF 2 Split 2 | NA | 7 <7,0,0> |
Split 3 | NA | 7 <7,0,0> |
------------------+---------------+---------------+
Sum | 20 <20,0,0> | 40 <40,0,0> |
----------------------------------+---------------+---------------+
Block Class. | 2 <2,0,0> | 3 <3,0,0> |
----------------------------------+---------------+---------------+
Position 22 sample segment | 1 <1,0,0> | 1 <1,0,0> |
----------------------------------+---------------+---------------+
Scale Factor State Coder | 6 <6,0,0> | 6 <6,0,0> |
----------------------------------+---------------+---------------+
Sample 0 | 3 <0,1,2> | 3 <0,1,2> |
Quantized Sample 1 | 3 <0,1,2> | 3 <0,1,2> |
Residual : | : : | : : |
State : | : : | : : |
Samples : | : : | : : |
Sample 56 | 3 <0,1,2> | 3 <0,1,2> |
Sample 57 | NA | 3 <0,1,2> |
------------------+---------------+---------------+
Sum | 171 <0,57,114>| 174 <0,58,116>|
----------------------------------+---------------+---------------+
Stage 1 | 7 <6,0,1> | 7 <4,2,1> |
CB for 22/23 Stage 2 | 7 <0,0,7> | 7 <0,0,7> |
sample block Stage 3 | 7 <0,0,7> | 7 <0,0,7> |
------------------+---------------+---------------+
Sum | 21 <6,0,15> | 21 <4,2,15> |
----------------------------------+---------------+---------------+
Stage 1 | 5 <2,0,3> | 5 <1,1,3> |
Gain for 22/23 Stage 2 | 4 <1,1,2> | 4 <1,1,2> |
sample block Stage 3 | 3 <0,0,3> | 3 <0,0,3> |
------------------+---------------+---------------+
Sum | 12 <3,1,8> | 12 <2,2,8> |
----------------------------------+---------------+---------------+
Stage 1 | 8 <7,0,1> | 8 <6,1,1> |
sub-block 1 Stage 2 | 7 <0,0,7> | 7 <0,0,7> |
Stage 3 | 7 <0,0,7> | 7 <0,0,7> |
------------------+---------------+---------------+
------------------------------------------------------------------+
Parameter | Bits Class <1,2,3> |
| 20 ms frame | 30 ms frame |
----------------------------------+---------------+---------------+
Split 1 | 6 <6,0,0> | 6 <6,0,0> |
LSF 1 Split 2 | 7 <7,0,0> | 7 <7,0,0> |
LSF Split 3 | 7 <7,0,0> | 7 <7,0,0> |
------------------+---------------+---------------+
Split 1 | NA (Not Appl.)| 6 <6,0,0> |
LSF 2 Split 2 | NA | 7 <7,0,0> |
Split 3 | NA | 7 <7,0,0> |
------------------+---------------+---------------+
Sum | 20 <20,0,0> | 40 <40,0,0> |
----------------------------------+---------------+---------------+
Block Class. | 2 <2,0,0> | 3 <3,0,0> |
----------------------------------+---------------+---------------+
Position 22 sample segment | 1 <1,0,0> | 1 <1,0,0> |
----------------------------------+---------------+---------------+
Scale Factor State Coder | 6 <6,0,0> | 6 <6,0,0> |
----------------------------------+---------------+---------------+
Sample 0 | 3 <0,1,2> | 3 <0,1,2> |
Quantized Sample 1 | 3 <0,1,2> | 3 <0,1,2> |
Residual : | : : | : : |
State : | : : | : : |
Samples : | : : | : : |
Sample 56 | 3 <0,1,2> | 3 <0,1,2> |
Sample 57 | NA | 3 <0,1,2> |
------------------+---------------+---------------+
Sum | 171 <0,57,114>| 174 <0,58,116>|
----------------------------------+---------------+---------------+
Stage 1 | 7 <6,0,1> | 7 <4,2,1> |
CB for 22/23 Stage 2 | 7 <0,0,7> | 7 <0,0,7> |
sample block Stage 3 | 7 <0,0,7> | 7 <0,0,7> |
------------------+---------------+---------------+
Sum | 21 <6,0,15> | 21 <4,2,15> |
----------------------------------+---------------+---------------+
Stage 1 | 5 <2,0,3> | 5 <1,1,3> |
Gain for 22/23 Stage 2 | 4 <1,1,2> | 4 <1,1,2> |
sample block Stage 3 | 3 <0,0,3> | 3 <0,0,3> |
------------------+---------------+---------------+
Sum | 12 <3,1,8> | 12 <2,2,8> |
----------------------------------+---------------+---------------+
Stage 1 | 8 <7,0,1> | 8 <6,1,1> |
sub-block 1 Stage 2 | 7 <0,0,7> | 7 <0,0,7> |
Stage 3 | 7 <0,0,7> | 7 <0,0,7> |
------------------+---------------+---------------+
Stage 1 | 8 <0,0,8> | 8 <0,7,1> |
sub-block 2 Stage 2 | 8 <0,0,8> | 8 <0,0,8> |
Indices Stage 3 | 8 <0,0,8> | 8 <0,0,8> |
for CB ------------------+---------------+---------------+
sub-blocks Stage 1 | NA | 8 <0,7,1> |
sub-block 3 Stage 2 | NA | 8 <0,0,8> |
Stage 3 | NA | 8 <0,0,8> |
------------------+---------------+---------------+
Stage 1 | NA | 8 <0,7,1> |
sub-block 4 Stage 2 | NA | 8 <0,0,8> |
Stage 3 | NA | 8 <0,0,8> |
------------------+---------------+---------------+
Sum | 46 <7,0,39> | 94 <6,22,66> |
----------------------------------+---------------+---------------+
Stage 1 | 5 <1,2,2> | 5 <1,2,2> |
sub-block 1 Stage 2 | 4 <1,1,2> | 4 <1,2,1> |
Stage 3 | 3 <0,0,3> | 3 <0,0,3> |
------------------+---------------+---------------+
Stage 1 | 5 <1,1,3> | 5 <0,2,3> |
sub-block 2 Stage 2 | 4 <0,2,2> | 4 <0,2,2> |
Stage 3 | 3 <0,0,3> | 3 <0,0,3> |
Gains for ------------------+---------------+---------------+
sub-blocks Stage 1 | NA | 5 <0,1,4> |
sub-block 3 Stage 2 | NA | 4 <0,1,3> |
Stage 3 | NA | 3 <0,0,3> |
------------------+---------------+---------------+
Stage 1 | NA | 5 <0,1,4> |
sub-block 4 Stage 2 | NA | 4 <0,1,3> |
Stage 3 | NA | 3 <0,0,3> |
------------------+---------------+---------------+
Sum | 24 <3,6,15> | 48 <2,12,34> |
-------------------------------------------------------------------
Empty frame indicator | 1 <0,0,1> | 1 <0,0,1> |
-------------------------------------------------------------------
SUM 304 <48,64,192> 400 <64,96,240>
Stage 1 | 8 <0,0,8> | 8 <0,7,1> |
sub-block 2 Stage 2 | 8 <0,0,8> | 8 <0,0,8> |
Indices Stage 3 | 8 <0,0,8> | 8 <0,0,8> |
for CB ------------------+---------------+---------------+
sub-blocks Stage 1 | NA | 8 <0,7,1> |
sub-block 3 Stage 2 | NA | 8 <0,0,8> |
Stage 3 | NA | 8 <0,0,8> |
------------------+---------------+---------------+
Stage 1 | NA | 8 <0,7,1> |
sub-block 4 Stage 2 | NA | 8 <0,0,8> |
Stage 3 | NA | 8 <0,0,8> |
------------------+---------------+---------------+
Sum | 46 <7,0,39> | 94 <6,22,66> |
----------------------------------+---------------+---------------+
Stage 1 | 5 <1,2,2> | 5 <1,2,2> |
sub-block 1 Stage 2 | 4 <1,1,2> | 4 <1,2,1> |
Stage 3 | 3 <0,0,3> | 3 <0,0,3> |
------------------+---------------+---------------+
Stage 1 | 5 <1,1,3> | 5 <0,2,3> |
sub-block 2 Stage 2 | 4 <0,2,2> | 4 <0,2,2> |
Stage 3 | 3 <0,0,3> | 3 <0,0,3> |
Gains for ------------------+---------------+---------------+
sub-blocks Stage 1 | NA | 5 <0,1,4> |
sub-block 3 Stage 2 | NA | 4 <0,1,3> |
Stage 3 | NA | 3 <0,0,3> |
------------------+---------------+---------------+
Stage 1 | NA | 5 <0,1,4> |
sub-block 4 Stage 2 | NA | 4 <0,1,3> |
Stage 3 | NA | 3 <0,0,3> |
------------------+---------------+---------------+
Sum | 24 <3,6,15> | 48 <2,12,34> |
-------------------------------------------------------------------
Empty frame indicator | 1 <0,0,1> | 1 <0,0,1> |
-------------------------------------------------------------------
SUM 304 <48,64,192> 400 <64,96,240>
Table 3.1 The bitstream definition for iLBC.
表3.1 iLBC的比特流定义。
When packetized into the payload, all the class 1 bits MUST be sorted in order (from top and down) as they were specified in the table. Additionally, all the class 2 bits MUST be sorted (from top and down) and all the class 3 bits MUST be sorted in the same sequential order.
当打包到有效负载中时，必须按照表中指定的顺序（从上到下）对所有1类位进行排序。此外，所有2类位必须进行排序（从上到下），所有3类位必须按照相同的顺序进行排序。
More than one iLBC frame may be included in a single RTP packet by a sender.
发送方可以在单个RTP分组中包括多个iLBC帧。
It is important to observe that senders have the following additional restrictions:
请务必注意，发件人有以下附加限制：
o SHOULD NOT include more iLBC frames in a single RTP packet than will fit in the MTU of the RTP transport protocol.
o 单个RTP数据包中包含的iLBC帧不应超过RTP传输协议MTU中的iLBC帧。
o Frames MUST NOT be split between RTP packets.
o 帧不能在RTP数据包之间分割。
o Frames of the different modes (20 ms and 30 ms) MUST NOT be included within the same packet.
o 不同模式（20 ms和30 ms）的帧不得包含在同一数据包中。
It is RECOMMENDED that the number of frames contained within an RTP packet are consistent with the application. For example, in telephony and other real time applications where delay is important, the delay is lower depending on the amount of frames per packet (i.e., fewer frames per packet, the lower the delay). Whereas for bandwidth constrained links or delay insensitive streaming messaging application, one or more frames per packet would be acceptable.
建议RTP数据包中包含的帧数与应用程序一致。例如，在延迟很重要的电话和其他实时应用中，延迟较低，这取决于每个分组的帧数（即，每个分组的帧数越少，延迟越低）。然而，对于带宽受限的链路或延迟不敏感的流式消息传递应用程序，每个数据包一个或多个帧是可以接受的。
Information describing the number of frames contained in an RTP packet is not transmitted as part of the RTP payload. The way to determine the number of iLBC frames is to count the total number of octets within the RTP packet, and divide the octet count by the number of expected octets per frame (32/50 per frame).
描述RTP分组中包含的帧数的信息不作为RTP有效载荷的一部分传输。确定iLBC帧数的方法是计算RTP数据包内的八位字节总数，并将八位字节数除以每帧的预期八位字节数（每帧32/50）。
One new MIME sub-type as described in this section has been registered.
已注册一个新的MIME子类型，如本节所述。
The storage mode is used for storing speech frames (e.g., as a file or email attachment).
存储模式用于存储语音帧（例如，作为文件或电子邮件附件）。
+------------------+
| Header |
+------------------+
| Speech frame 1 |
+------------------+
: :
+------------------+
| Speech frame n |
+------------------+
+------------------+
| Header |
+------------------+
| Speech frame 1 |
+------------------+
: :
+------------------+
| Speech frame n |
+------------------+
Figure 2, Storage format diagram
图2，存储格式图
The file begins with a header that includes only a magic number to identify that it is an iLBC file.
该文件以仅包含一个幻数的头开始，以标识它是iLBC文件。
The magic number for iLBC file MUST correspond to the ASCII character string:
iLBC文件的幻数必须对应于ASCII字符串：
o for 30 ms frame size mode:"#!iLBC30\n", or "0x23 0x21 0x69 0x4C 0x42 0x43 0x33 0x30 0x0A" in hexadecimal form,
o 对于30毫秒帧大小模式，十六进制格式为“#！iLBC30\n”或“0x23 0x21 0x69 0x4C 0x42 0x43 0x33 0x30 0x0A”，
o for 20 ms frame size mode:"#!iLBC20\n", or "0x23 0x21 0x69 0x4C 0x42 0x43 0x32 0x30 0x0A" in hexadecimal form.
o 对于20毫秒帧大小模式，十六进制格式为“#！iLBC20\n”或“0x23 0x21 0x69 0x4C 0x42 0x43 0x32 0x30 0x0A”。
After the header, follow the speech frames in consecutive order.
在标题之后，按连续顺序跟随语音帧。
Speech frames lost in transmission MUST be stored as "empty frames", as defined in [1].
传输中丢失的语音帧必须存储为[1]中定义的“空帧”。
MIME media type name: audio
MIME媒体类型名称：音频
MIME subtype: iLBC
MIME子类型：iLBC
Optional parameters:
可选参数：
All of the parameters does apply for RTP transfer only.
所有参数仅适用于RTP传输。
maxptime:The maximum amount of media which can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the frame size. This attribute is probably only meaningful for audio data, but may be used with other media types if it makes sense. It is a media attribute, and is not dependent on charset. Note that this attribute was introduced after RFC 2327, and non updated implementations will ignore this attribute.
maxptime：每个数据包中可封装的最大媒体量，以毫秒表示。时间应计算为数据包中存在的媒体代表的时间之和。时间应该是帧大小的倍数。此属性可能仅对音频数据有意义，但如果有意义，可以与其他媒体类型一起使用。它是媒体属性，不依赖于字符集。请注意，此属性是在RFC2327之后引入的，未更新的实现将忽略此属性。
mode: The iLBC operating frame mode (20 or 30 ms) that will be encapsulated in each packet. Values can be 0, 20 and 30 (where 0 is reserved, 20 stands for preferred 20 ms frame size and 30 stands for preferred 30 ms frame size).
模式：将封装在每个数据包中的iLBC操作帧模式（20或30毫秒）。值可以是0、20和30（其中0是保留的，20表示首选20毫秒帧大小，30表示首选30毫秒帧大小）。
ptime: Defined as usual for RTP audio (see [5]).
ptime：定义为RTP音频的常规时间（见[5]）。
Encoding considerations: This type is defined for transfer via both RTP (RFC 3550) and stored-file methods as described in Section 4.1, of RFC
编码注意事项：此类型定义为通过RTP（RFC 3550）和存储文件方法进行传输，如RFC第4.1节所述
3952. Audio data is binary data, and must be encoded for non-binary transport; the Base64 encoding is suitable for email.
3952音频数据是二进制数据，必须进行编码以进行非二进制传输；Base64编码适用于电子邮件。
Security considerations: See Section 6 of RFC 3952.
安全注意事项：见RFC 3952第6节。
Public specification: Please refer to RFC 3951 [1].
公共规范：请参考RFC 3951[1]。
Additional information: The following applies to stored-file transfer methods:
其他信息：以下内容适用于存储的文件传输方法：
Magic number: ASCII character string for: o 30 ms frame size mode "#!iLBC30\n" (or 0x23 0x21 0x69 0x4C 0x42 0x43 0x33 0x30 0x0A in hexadecimal) o 20 ms frame size mode "#!iLBC20\n" (or 0x23 0x21 0x69 0x4C 0x42 0x43 0x32 0x30 0x0A in hexadecimal)
幻数：ASCII字符串，用于：o 30毫秒帧大小模式“#！iLBC30\n”（或十六进制格式的0x23 0x21 0x69 0x4C 0x42 0x43 0x33 0x30 0x0A）o 20毫秒帧大小模式“#！iLBC20\n”（或十六进制格式的0x23 0x21 0x69 0x4C 0x42 0x43 0x32 0x30 0x0A）
File extensions: lbc, LBC Macintosh file type code: none Object identifier or OID: none
文件扩展名：lbc、lbc Macintosh文件类型代码：无对象标识符或OID:无
Person & email address to contact for further information: alan.duric@telio.no
联系人和电子邮件地址，以获取更多信息：alan。duric@telio.no
Intended usage: COMMON. It is expected that many VoIP applications will use this type.
预期用途：普通。预计许多VoIP应用程序将使用这种类型。
Author/Change controller: alan.duric@telio.no IETF Audio/Video transport working group
作者/变更控制员：艾伦。duric@telio.noIETF音频/视频传输工作组
The information carried in the MIME 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 iLBC codec, the mapping is as follows:
MIME媒体类型规范中包含的信息与会话描述协议（SDP）[5]中的字段具有特定映射，该协议通常用于描述RTP会话。使用SDP指定使用iLBC编解码器的会话时，映射如下：
o The MIME type ("audio") goes in SDP "m=" as the media name.
o MIME类型（“音频”）以SDP“m=”作为媒体名称。
o The MIME subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name.
o MIME子类型（有效负载格式名称）以SDP“a=rtpmap”作为编码名称。
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 The parameter "mode" goes in the SDP "a=fmtp" attribute by copying it directly from the MIME media type string as "mode=value".
o 参数“mode”直接从MIME媒体类型字符串复制为“mode=value”，从而进入SDP“a=fmtp”属性。
When conveying information by SDP, the encoding name SHALL be "iLBC" (the same as the MIME subtype).
通过SDP传输信息时，编码名称应为“iLBC”（与MIME子类型相同）。
An example of the media representation in SDP for describing iLBC might be:
SDP中用于描述iLBC的媒体表示的一个示例可能是：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=audio 49120 RTP/AVP 97
a=rtpmap:97 iLBC/8000
If 20 ms frame size mode is used, remote iLBC encoder SHALL receive "mode" parameter in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon separated with parameter=value, where parameter is "mode", and values can be 0 and 20 (where 0 is reserved and 20 stands for preferred 20 ms frame size). An example of the media representation in SDP for describing iLBC when 20 ms frame size mode is used might be:
如果使用20毫秒帧大小模式，远程iLBC编码器应通过直接从MIME媒体类型字符串中复制“mode”参数，将其作为分号与parameter=value分隔，从而接收SDP“a=fmtp”属性中的“mode”参数，其中参数为“mode”，值可以为0和20（其中0为保留值，20为首选20毫秒帧大小）。当使用20ms帧大小模式时，SDP中用于描述iLBC的媒体表示的示例可能是：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
m=audio 49120 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
It is important to emphasize the bi-directional character of the "mode" parameter - both sides of a bi-directional session MUST use the same "mode" value.
强调“mode”参数的双向性很重要-双向会话的双方必须使用相同的“mode”值。
The offer contains the preferred mode of the offerer. The answerer may agree to that mode by including the same mode in the answer, or may include a different mode. The resulting mode used by both parties SHALL be the lower of the bandwidth modes in the offer and answer.
报价包含报价人的首选模式。回答者可以通过在回答中包含相同的模式来同意该模式，也可以包含不同的模式。双方使用的结果模式应为报价和应答中的较低带宽模式。
That is, an offer of "mode=20" receiving an answer of "mode=30" will result in "mode=30" being used by both participants. Similarly, an offer of "mode=30" and an answer of "mode=20" will result in "mode=30" being used by both participants.
也就是说，“mode=20”的报价收到“mode=30”的答复将导致两个参与者都使用“mode=30”。同样，提供“mode=30”和回答“mode=20”将导致两个参与者都使用“mode=30”。
This is important when one end point utilizes a bandwidth constrained link (e.g., 28.8k modem link or slower), where only the lower frame size will work.
当一个端点使用带宽受限的链路（例如，28.8k调制解调器链路或更慢的链路）时，这一点很重要，因为只有较低的帧大小才能工作。
Parameter ptime can not be used for the purpose of specifying iLBC operating mode, due to fact that for the certain values it will be impossible to distinguish which mode is about to be used (e.g., when ptime=60, it would be impossible to distinguish if packet is carrying 2 frames of 30 ms or 3 frames of 20 ms, etc.).
参数ptime不能用于指定iLBC操作模式，因为对于某些值，将无法区分将要使用的模式（例如，当ptime=60时，将无法区分数据包是承载2帧30毫秒还是3帧20毫秒，等等）。
Note that the payload format (encoding) names are commonly shown in upper case. MIME subtypes are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in MIME types and in the default mapping to the SDP a=fmtp attribute
请注意，有效负载格式（编码）名称通常以大写形式显示。MIME子类型通常以小写形式显示。这些名称在两个位置都不区分大小写。类似地，参数名在MIME类型和SDP a=fmtp属性的默认映射中都不区分大小写
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in [3] and any appropriate profile (e.g., [4]).
使用本规范中定义的有效负载格式的RTP数据包受[3]中讨论的一般安全注意事项和任何适当的配置文件（例如[4]）的约束。
As this format transports encoded speech, the main security issues include confidentiality and authentication of the speech itself. The payload format itself does not have any built-in security mechanisms. Confidentiality of the media streams is achieved by encryption, therefore external mechanisms, such as SRTP [6], MAY be used for that purpose. The data compression used with this payload format is applied end-to-end; hence encryption may be performed after compression with no conflict between the two operations.
由于这种格式传输编码语音，主要的安全问题包括语音本身的保密性和身份验证。有效负载格式本身没有任何内置的安全机制。媒体流的机密性是通过加密实现的，因此外部机制，例如SRTP[6]，可用于该目的。与此有效负载格式一起使用的数据压缩是端到端应用的；因此，可以在压缩之后执行加密，两个操作之间没有冲突。
A potential denial-of-service threat exists for data encoding using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to become overloaded. However, the encodings covered in this document do not exhibit any significant non-uniformity.
使用具有非均匀接收端计算负载的压缩技术进行数据编码存在潜在的拒绝服务威胁。攻击者可以向流中注入病理数据报，这些数据报解码复杂，并导致接收器过载。然而，本文件中涵盖的编码并未表现出任何显著的不一致性。
[1] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)", RFC 3951, December 2004.
[1] Andersen，S.，Duric，A.，Astrom，H.，Hagen，R.，Kleijn，W.，和J.Linden，“互联网低比特率编解码器（iLBC）”，RFC 39512004年12月。
[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. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol", RFC 3711, March 2004.
[6] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议”，RFC 3711，2004年3月。
[7] ITU-T Recommendation G.711, available online from the ITU bookstore at http://www.itu.int.
[7] ITU-T建议G.711，可从ITU书店在线获取，网址为http://www.itu.int.
Henry Sinnreich, Patrik Faltstrom, Alan Johnston and Jean-Francois Mule for great support of the iLBC initiative and for valuable feedback and comments.
Henry Sinnreich、Patrik Faltstrom、Alan Johnston和Jean-Francois Mule感谢对iLBC倡议的大力支持以及宝贵的反馈和评论。
Authors' Addresses
作者地址
Alan Duric Telio AS Stoperigt. 2 Oslo, N-0250 Norway
阿兰·杜里奇·泰利奥饰演斯托佩里格特。挪威奥斯陆，N-0250
Phone: +47 21673505
EMail: alan.duric@telio.no
Phone: +47 21673505
EMail: alan.duric@telio.no
Soren Vang Andersen Department of Communication Technology Aalborg University Fredrik Bajers Vej 7A 9200 Aalborg Denmark
索伦·万安徒生通讯技术系奥尔堡大学弗雷德里克·巴杰斯Vej 7A 9200丹麦奥尔堡
Phone: ++45 9 6358627
EMail: sva@kom.auc.dk
Phone: ++45 9 6358627
EMail: sva@kom.auc.dk
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见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编辑功能的资金目前由互联网协会提供。