Network Working Group J.-H. Chen
Request for Comments: 4298 W. Lee
Category: Standards Track J. Thyssen
Broadcom Corporation
December 2005
Network Working Group J.-H. Chen
Request for Comments: 4298 W. Lee
Category: Standards Track J. Thyssen
Broadcom Corporation
December 2005
RTP Payload Format for BroadVoice Speech Codecs
BroadVoice语音编解码器的RTP有效负载格式
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs. The narrowband codec, called BroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification. The document also provides specifications for the use of BroadVoice with MIME and the Session Description Protocol (SDP).
本文档描述了BroadVoice（R）窄带和宽带语音编解码器的RTP有效负载格式。CableLabs已选择称为BroadVoice16或BV16的窄带编解码器作为PacketCable 1.5中的强制性编解码器，并具有CableLabs规范。本文档还提供了BroadVoice与MIME以及会话描述协议（SDP）的使用规范。
Table of Contents
目录
1. Introduction ....................................................2
2. Background ......................................................2
3. RTP Payload Format for BroadVoice16 Narrowband Codec ............3
3.1. BroadVoice16 Bit Stream Definition .........................4
3.2. Multiple BroadVoice16 Frames in an RTP Packet ..............5
4. RTP Payload Format for BroadVoice32 Wideband Codec ..............6
4.1. BroadVoice32 Bit Stream Definition .........................6
4.2. Multiple BroadVoice32 Frames in an RTP Packet ..............8
5. IANA Considerations .............................................8
5.1. MIME Registration of BroadVoice16 for RTP ..................9
5.2. MIME Registration of BroadVoice32 for RTP ..................9
6. Mapping to SDP Parameters ......................................10
6.1. Offer-Answer Model Considerations .........................11
7. Security Considerations ........................................11
8. Congestion Control .............................................11
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
1. Introduction ....................................................2
2. Background ......................................................2
3. RTP Payload Format for BroadVoice16 Narrowband Codec ............3
3.1. BroadVoice16 Bit Stream Definition .........................4
3.2. Multiple BroadVoice16 Frames in an RTP Packet ..............5
4. RTP Payload Format for BroadVoice32 Wideband Codec ..............6
4.1. BroadVoice32 Bit Stream Definition .........................6
4.2. Multiple BroadVoice32 Frames in an RTP Packet ..............8
5. IANA Considerations .............................................8
5.1. MIME Registration of BroadVoice16 for RTP ..................9
5.2. MIME Registration of BroadVoice32 for RTP ..................9
6. Mapping to SDP Parameters ......................................10
6.1. Offer-Answer Model Considerations .........................11
7. Security Considerations ........................................11
8. Congestion Control .............................................11
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
This document specifies the payload format for sending BroadVoice encoded speech or audio signals using the Real-time Transport Protocol (RTP) [1]. The sender may send one or more BroadVoice codec data frames per packet, depending on the application scenario, based on network conditions, bandwidth availability, delay requirements, and packet-loss tolerance.
本文件规定了使用实时传输协议（RTP）[1]发送BroadVoice编码语音或音频信号的有效载荷格式。发送方可以基于网络条件、带宽可用性、延迟要求和分组丢失容限，根据应用场景，为每个分组发送一个或多个BroadVoice编解码器数据帧。
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]中所述进行解释。
BroadVoice is a speech codec family developed for VoIP (Voice over Internet Protocol) applications, including Voice over Cable, Voice over DSL, and IP phone applications. BroadVoice achieves high speech quality with a low coding delay and relatively low codec complexity.
BroadVoice是为VoIP（互联网协议语音）应用开发的语音编解码器系列，包括有线语音、DSL语音和IP电话应用。BroadVoice以较低的编码延迟和相对较低的编解码器复杂度实现了较高的语音质量。
The BroadVoice codec family contains two codec versions. The narrowband version of BroadVoice, called BroadVoice16 [3], or BV16 for short, encodes 8 kHz-sampled narrowband speech at a bit rate of 16 kilobits/second, or 16 kbit/s. The wideband version of BroadVoice, called BroadVoice32, or BV32, encodes 16 kHz-sampled wideband speech at a bit rate of 32 kbit/s. The BV16 and BV32 use
BroadVoice编解码器系列包含两个编解码器版本。BroadVoice的窄带版本，简称为BroadVoice16[3]，或BV16，以16千比特/秒或16千比特/秒的比特率对8千赫采样的窄带语音进行编码。宽带版本的BroadVoice称为BroadVoice32或BV32，以32 kbit/s的比特率对16 kHz采样的宽带语音进行编码。BV16和BV32使用
very similar (but not identical) coding algorithms; they share most of their algorithm modules.
非常相似（但不完全相同）的编码算法；他们共享大部分算法模块。
To minimize the delay in real-time two-way communications, both the BV16 and BV32 encode speech with a very small frame size of 5 ms without using any look ahead. By using a packet size as small as 5 ms if necessary, this allows VoIP systems based on BroadVoice to have a very low end-to-end system delay.
为了最大限度地减少实时双向通信中的延迟，BV16和BV32都以5ms的非常小的帧大小对语音进行编码，而不使用任何前瞻。如果需要，通过使用小到5毫秒的数据包大小，这使得基于BroadVoice的VoIP系统具有非常低的端到端系统延迟。
BroadVoice also has relatively low codec complexity when compared with ITU-T standard speech codecs based on CELP (Coded Excited Linear Prediction), such as G.728, G.729, G.723.1, and G.722.2. Full-duplex implementations of the BV16 and BV32 take around 12 and 17 MIPS, respectively, on general-purpose 16-bit fixed-point digital signal processors (DSPs). The total memory footprints of the BV16 and BV32, including program size, data tables, and data RAM, are around 12 kwords each, or 24 kbytes.
与基于CELP（编码激励线性预测）的ITU-T标准语音编解码器（如G.728、G.729、G.723.1和G.722.2）相比，BroadVoice的编解码器复杂度也相对较低。在通用16位定点数字信号处理器（DSP）上，BV16和BV32的全双工实现分别需要约12和17 MIPS。BV16和BV32的总内存占用（包括程序大小、数据表和数据RAM）约为12 kwords，即24 KB。
The PacketCable(TM) project of Cable Television Laboratories, Inc. (CableLabs(R)) has chosen the BV16 codec for use in VoIP telephone services provided by cable operators. More specifically, the BV16 codec was selected as one of the mandatory audio codecs in the PacketCable(TM) 1.5 Audio/Video Codecs Specification [8] and has been implemented by multiple vendors. The wideband version (BV32) has been developed by Broadcom but has not yet appeared in a public specification; since it is technically very similar to BV16, its payload format is also defined in this document.
有线电视实验室有限公司（CableLabs（R））的PacketCable（TM）项目选择BV16编解码器用于有线运营商提供的VoIP电话服务。更具体地说，BV16编解码器被选为PacketCable（TM）1.5音频/视频编解码器规范[8]中的强制性音频编解码器之一，并已由多家供应商实施。宽带版本（BV32）由Broadcom开发，但尚未出现在公开规范中；由于它在技术上与BV16非常相似，因此其有效载荷格式也在本文档中定义。
The BroadVoice16 uses 5 ms frames and a sampling frequency of 8 kHz, so the RTP timestamp MUST be in units of 1/8000 of a second. The RTP timestamp indicates the sampling instant of the oldest audio sample represented by the frame(s) present in the payload. The RTP payload for the BroadVoice16 has the format shown in the figure below. No additional header specific to this payload format is required.
BroadVoice16使用5 ms帧和8 kHz的采样频率，因此RTP时间戳必须以1/8000秒为单位。RTP时间戳指示由有效负载中存在的帧表示的最早音频样本的采样时刻。BroadVoice16的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 [1] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| one or more frames of BroadVoice16 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [1] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| one or more frames of BroadVoice16 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If BroadVoice16 is used for applications with silence compression, the first BroadVoice16 packet after a silence period during which packets have not been transmitted contiguously SHOULD have the marker bit in the RTP data header set to one. The marker bit in all other packets is zero. Applications without silence suppression MUST set the marker bit to zero.
如果BroadVoice16用于静默压缩应用，则在静默期之后的第一个BroadVoice16数据包（在此期间数据包未连续传输）应将RTP数据报头中的标记位设置为1。所有其他数据包中的标记位均为零。无静音抑制的应用程序必须将标记位设置为零。
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.
此新数据包格式的RTP有效负载类型的分配超出了本文档的范围，此处将不进行指定。预计特定类别应用的RTP配置文件将为此编码分配有效负载类型，或者如果未分配有效负载类型，则应选择动态范围内的有效负载类型。
The BroadVoice16 encoder operates on speech frames of 5 ms corresponding to 40 samples at a sampling rate of 8000 samples per second. For every 5 ms frame, the encoder encodes the 40 consecutive audio samples into 80 bits, or 10 octets. Thus, the 80-bit bit stream produced by the BroadVoice16 for each 5 ms frame is octet-aligned, and no padding bits are required. The bit allocation for the encoded parameters of the BroadVoice16 codec is listed in the following table.
BroadVoice16编码器以每秒8000个样本的采样率在对应于40个样本的5ms语音帧上运行。对于每5毫秒帧，编码器将40个连续音频样本编码为80位或10个八位字节。因此，BroadVoice16为每个5ms帧生成的80位比特流是八位组对齐的，不需要填充比特。下表列出了BroadVoice16编解码器编码参数的位分配。
Encoded Parameter Codeword Number of bits per frame
------------------------------------------------------------
Line Spectrum Pairs L0,L1 7+7=14
Pitch Lag PL 7
Pitch Gain PG 5
Log-Gain LG 4
Excitation Vectors V0,...,V9 5*10=50
------------------------------------------------------------
Total: 80 bits
Encoded Parameter Codeword Number of bits per frame
------------------------------------------------------------
Line Spectrum Pairs L0,L1 7+7=14
Pitch Lag PL 7
Pitch Gain PG 5
Log-Gain LG 4
Excitation Vectors V0,...,V9 5*10=50
------------------------------------------------------------
Total: 80 bits
The mapping of the encoded parameters in an 80-bit BroadVoice16 data frame is defined in the following figure. This figure shows the bit packing in "network byte order", also known as big-endian order. The bits of each 32-bit word are numbered 0 to 31, with the most significant bit on the left and numbered 0. The octets (bytes) of each word are transmitted with the most significant octet first. The bits of the data field for each encoded parameter are numbered in the same order, with the most significant bit on the left.
下图定义了80位BroadVoice16数据帧中编码参数的映射。该图显示了“网络字节顺序”（也称为大端顺序）中的位压缩。每个32位字的位编号为0到31，最高有效位在左边，编号为0。每个字的八位字节（字节）首先以最重要的八位字节进行传输。每个编码参数的数据字段位按相同顺序编号，最高有效位在左侧。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L0 | L1 | PL | PG | LG | V0|
| | | | | | |
|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V0 | V1 | V2 | V3 | V4 | V5 | V6 |
| | | | | | | |
|2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| V7 | V8 | V9 |
|6| | | |
|4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L0 | L1 | PL | PG | LG | V0|
| | | | | | |
|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V0 | V1 | V2 | V3 | V4 | V5 | V6 |
| | | | | | | |
|2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| V7 | V8 | V9 |
|6| | | |
|4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: BroadVoice16 bit packing
图1:BroadVoice16位封装
More than one BroadVoice16 frame MAY be included in a single RTP packet by a sender. Senders have the following additional restrictions:
发送方可以在单个RTP分组中包括多个BroadVoice16帧。发件人具有以下附加限制：
o SHOULD NOT include more BroadVoice16 frames in a single RTP packet than will fit in the MTU of the RTP.
o 单个RTP数据包中包含的BroadVoice16帧不应超过RTP的MTU所能容纳的数量。
o MUST NOT split a BroadVoice16 frame between RTP packets.
o 不得在RTP数据包之间拆分BroadVoice16帧。
o BroadVoice16 frames in an RTP packet MUST be consecutive.
o RTP数据包中的BroadVoice16帧必须是连续的。
Since multiple BroadVoice16 frames in an RTP packet MUST be consecutive, and since BroadVoice16 has a fixed frame size of 5 ms, recovering the timestamps of all frames within a packet is easy. The oldest frame within an RTP packet has the same timestamp as the RTP packet, as mentioned above. To obtain the timestamp of the frame that is N frames later than the oldest frame in the packet, one simply adds 5*N ms worth of time units to the timestamp of the RTP packet.
由于RTP数据包中的多个BroadVoice16帧必须是连续的，并且BroadVoice16具有5 ms的固定帧大小，因此恢复数据包中所有帧的时间戳很容易。如上所述，RTP数据包中最早的帧与RTP数据包具有相同的时间戳。为了获得比分组中最早的帧晚N帧的帧的时间戳，只需向RTP分组的时间戳添加5×nms的时间单位。
It is RECOMMENDED that the number of frames contained within an RTP packet be consistent with the application. For example, in a telephony application where delay is important, the fewer frames per packet, the lower the delay; whereas, for a delay insensitive streaming or messaging application, many 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 only way to determine the number of BroadVoice16 frames is to count the total number of octets within the RTP payload, and divide the octet count by 10.
描述RTP分组中包含的帧数的信息不作为RTP有效载荷的一部分传输。确定BroadVoice16帧数的唯一方法是计算RTP有效负载内的八位字节总数，并将八位字节数除以10。
The BroadVoice32 uses 5 ms frames and a sampling frequency of 16 kHz, so the RTP timestamp MUST be in units of 1/16000 of a second. The RTP timestamp indicates the sampling instant of the oldest audio sample represented by the frame(s) present in the payload. The RTP payload for the BroadVoice32 has the format shown in the figure below. No additional header specific to this payload format is required.
BroadVoice32使用5 ms帧和16 kHz的采样频率，因此RTP时间戳必须以1/16000秒为单位。RTP时间戳指示由有效负载中存在的帧表示的最早音频样本的采样时刻。BroadVoice32的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 [1] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| one or more frames of BroadVoice32 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [1] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| one or more frames of BroadVoice32 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If BroadVoice32 is used for applications with silence compression, the first BroadVoice32 packet after a silence period during which packets have not been transmitted contiguously SHOULD have the marker bit in the RTP data header set to one. The marker bit in all other packets is zero. Applications without silence suppression MUST set the marker bit to zero.
如果BroadVoice32用于静默压缩应用，则在静默期之后的第一个BroadVoice32数据包（在此期间数据包未连续传输）应将RTP数据报头中的标记位设置为1。所有其他数据包中的标记位均为零。无静音抑制的应用程序必须将标记位设置为零。
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.
此新数据包格式的RTP有效负载类型的分配超出了本文档的范围，此处将不进行指定。预计特定类别应用的RTP配置文件将为此编码分配有效负载类型，或者如果未分配有效负载类型，则应选择动态范围内的有效负载类型。
The BroadVoice32 encoder operates on speech frames of 5 ms corresponding to 80 samples at a sampling rate of 16000 samples per second. For every 5 ms frame, the encoder encodes the 80 consecutive audio samples into 160 bits, or 20 octets. Thus, the 160-bit bit stream produced by the BroadVoice32 for each 5 ms frame is octet-aligned, and no padding bits are required. The bit allocation for
BroadVoice32编码器以每秒16000个样本的采样率在对应于80个样本的5ms语音帧上运行。对于每5毫秒帧，编码器将80个连续音频样本编码为160位或20个八位字节。因此，BroadVoice32为每个5ms帧生成的160位比特流是八位组对齐的，并且不需要填充比特。的位分配
the encoded parameters of the BroadVoice32 codec is listed in the
following table.
Number of bits
Encoded Parameter Codeword per frame
---------------------------------------------------------------
Line Spectrum Pairs L0,L1,L2 7+5+5=17
Pitch Lag PL 8
Pitch Gain PG 5
Log-Gains (1st & 2nd subframes) LG0,LG1 5+5=10
Excitation Vectors (1st subframe) VA0,...,VA9 6*10=60
Excitation Vectors (2nd subframe) VB0,...,VB9 6*10=60
---------------------------------------------------------------
Total: 160 bits
the encoded parameters of the BroadVoice32 codec is listed in the
following table.
Number of bits
Encoded Parameter Codeword per frame
---------------------------------------------------------------
Line Spectrum Pairs L0,L1,L2 7+5+5=17
Pitch Lag PL 8
Pitch Gain PG 5
Log-Gains (1st & 2nd subframes) LG0,LG1 5+5=10
Excitation Vectors (1st subframe) VA0,...,VA9 6*10=60
Excitation Vectors (2nd subframe) VB0,...,VB9 6*10=60
---------------------------------------------------------------
Total: 160 bits
The mapping of the encoded parameters in a 160-bit BroadVoice32 data frame is defined in the following figure. This figure shows the bit packing in "network byte order", also known as big-endian order. The bits of each 32-bit word are numbered 0 to 31, with the most significant bit on the left and numbered 0. The octets (bytes) of each word are transmitted with the most significant octet first. The bits of the data field for each encoded parameter are numbered in the same order, with the most significant bit on the left.
下图定义了160位BroadVoice32数据帧中编码参数的映射。该图显示了“网络字节顺序”中的位压缩，也称为big-endian顺序。每个32位字的位编号为0到31，最高有效位在左边，编号为0。每个字的八位字节（字节）首先以最重要的八位字节进行传输。每个编码参数的数据字段位按相同顺序编号，最高有效位在左侧。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L0 | L1 | L2 | PL | PG |LG0|
| | | | | | |
|0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7|0 1 2 3 4|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LG0 | LG1 | VA0 | VA1 | VA2 | VA3 |
| | | | | | |
|2 3 4|0 1 2 3 4|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VA4 | VA5 | VA6 | VA7 | VA8 |VA9|
| | | | | | |
|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VA9 | VB0 | VB1 | VB2 | VB3 | VB4 |
| | | | | | |
|2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VB4| VB5 | VB6 | VB7 | VB8 | VB9 |
| | | | | | |
|4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L0 | L1 | L2 | PL | PG |LG0|
| | | | | | |
|0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7|0 1 2 3 4|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LG0 | LG1 | VA0 | VA1 | VA2 | VA3 |
| | | | | | |
|2 3 4|0 1 2 3 4|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VA4 | VA5 | VA6 | VA7 | VA8 |VA9|
| | | | | | |
|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VA9 | VB0 | VB1 | VB2 | VB3 | VB4 |
| | | | | | |
|2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VB4| VB5 | VB6 | VB7 | VB8 | VB9 |
| | | | | | |
|4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: BroadVoice32 bit packing
图2:BroadVoice32位打包
More than one BroadVoice32 frame MAY be included in a single RTP packet by a sender. Senders have the following additional restrictions:
发送方可以在单个RTP分组中包括多个BroadVoice32帧。发件人具有以下附加限制：
o SHOULD NOT include more BroadVoice32 frames in a single RTP packet than will fit in the MTU of the RTP.
o 单个RTP数据包中包含的BroadVoice32帧不应超过RTP的MTU中所能容纳的数量。
o MUST NOT split a BroadVoice32 frame between RTP packets.
o 不能在RTP数据包之间拆分BroadVoice32帧。
o BroadVoice32 frames in an RTP packet MUST be consecutive.
o RTP数据包中的BroadVoice32帧必须是连续的。
Since multiple BroadVoice32 frames in an RTP packet MUST be consecutive, and since BroadVoice32 has a fixed frame size of 5 ms, recovering the timestamps of all frames within a packet is easy. The oldest frame within an RTP packet has the same timestamp as the RTP packet, as mentioned above. To obtain the timestamp of the frame that is N frames later than the oldest frame in the packet, one simply adds 5*N ms worth of time units to the timestamp of the RTP packet.
由于RTP数据包中的多个BroadVoice32帧必须是连续的，并且BroadVoice32具有5 ms的固定帧大小，因此恢复数据包中所有帧的时间戳很容易。如上所述，RTP数据包中最早的帧与RTP数据包具有相同的时间戳。为了获得比分组中最早的帧晚N帧的帧的时间戳，只需向RTP分组的时间戳添加5×nms的时间单位。
It is RECOMMENDED that the number of frames contained within an RTP packet be consistent with the application. For example, in a telephony application where delay is important, the fewer frames per packet, the lower the delay; whereas, for a delay insensitive streaming or messaging application, many 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 only way to determine the number of BroadVoice32 frames is to count the total number of octets within the RTP payload, and divide the octet count by 20.
描述RTP分组中包含的帧数的信息不作为RTP有效载荷的一部分传输。确定BroadVoice32帧数的唯一方法是计算RTP有效负载内的八位字节总数，并将八位字节数除以20。
Two new MIME sub-types, as described in this section, have been registered.
如本节所述，已注册了两个新的MIME子类型。
The MIME names for the BV16 and BV32 codecs have been allocated from the IETF tree since these two codecs are expected to be widely used for Voice-over-IP applications, especially in Voice over Cable applications.
BV16和BV32编解码器的MIME名称已从IETF树中分配，因为这两个编解码器预计将广泛用于IP语音应用，尤其是电缆语音应用。
MIME media type name: audio
MIME媒体类型名称：音频
MIME media subtype name: BV16
MIME媒体子类型名称：BV16
Required parameter: none
必需参数：无
Optional parameters: ptime: Defined as usual for RTP audio (see RFC 2327 [4]).
可选参数：ptime：定义为RTP音频的常规参数（参见RFC 2327[4]）。
maxptime: See RFC 3267 [7] for its definition. The maxptime SHOULD be a multiple of the duration of a single codec data frame (5 ms).
maxptime：有关其定义，请参见RFC 3267[7]。maxptime应该是单个编解码器数据帧持续时间（5毫秒）的倍数。
Encoding considerations: This type is defined for transferring BV16-encoded data via RTP using the payload format specified in Section 3 of RFC 4298. Audio data is binary data and must be encoded for non-binary transport; the Base64 encoding is suitable for Email.
编码注意事项：此类型定义用于使用RFC 4298第3节中指定的有效负载格式通过RTP传输BV16编码数据。音频数据是二进制数据，必须为非二进制传输进行编码；Base64编码适用于电子邮件。
Security considerations: See Section 7 "Security Considerations" of RFC 4298.
安全注意事项：参见RFC 4298第7节“安全注意事项”。
Public specification: The BroadVoice16 codec has been specified in [3].
公共规范：BroadVoice16编解码器已在[3]中指定。
Intended usage: COMMON. It is expected that many VoIP applications, especially Voice over Cable applications, will use this type.
预期用途：普通。预计许多VoIP应用程序，特别是有线语音应用程序，将使用这种类型。
Person & email address to contact for further information: Juin-Hwey (Raymond) Chen rchen@broadcom.com
联系人和电子邮件地址，以获取更多信息：Juin Hwey（Raymond）Chenrchen@broadcom.com
Author/Change controller:
Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com
Change Controller: IETF Audio/Video Transport Working Group
delegated from the IESG
Author/Change controller:
Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com
Change Controller: IETF Audio/Video Transport Working Group
delegated from the IESG
MIME media type name: audio
MIME媒体类型名称：音频
MIME media subtype name: BV32
MIME媒体子类型名称：BV32
Required parameter: none
必需参数：无
Optional parameters: ptime: Defined as usual for RTP audio (see RFC 2327 [4]).
可选参数：ptime：定义为RTP音频的常规参数（参见RFC 2327[4]）。
maxptime: See RFC 3267 [7] for its definition. The maxptime SHOULD be a multiple of the duration of a single codec data frame (5 ms).
maxptime：有关其定义，请参见RFC 3267[7]。maxptime应该是单个编解码器数据帧持续时间（5毫秒）的倍数。
Encoding considerations: This type is defined for transferring BV32-encoded data via RTP using the payload format specified in Section 4 of RFC 4298. Audio data is binary data and must be encoded for non-binary transport; the Base64 encoding is suitable for Email.
编码注意事项：此类型定义用于使用RFC 4298第4节中指定的有效负载格式通过RTP传输BV32编码数据。音频数据是二进制数据，必须为非二进制传输进行编码；Base64编码适用于电子邮件。
Security considerations: See Section 7 "Security Considerations" of RFC 4298.
安全注意事项：参见RFC 4298第7节“安全注意事项”。
Intended usage: COMMON. It is expected that many VoIP applications, especially Voice over Cable applications, will use this type.
预期用途：普通。预计许多VoIP应用程序，特别是有线语音应用程序，将使用这种类型。
Person & email address to contact for further information: Juin-Hwey (Raymond) Chen rchen@broadcom.com
联系人和电子邮件地址，以获取更多信息：Juin Hwey（Raymond）Chenrchen@broadcom.com
Author/Change controller:
Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com
Change Controller: IETF Audio/Video Transport Working Group
delegated from the IESG
Author/Change controller:
Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com
Change Controller: IETF Audio/Video Transport Working Group
delegated from the IESG
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [4], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the BroadVoice16 or BroadVoice32 codec, the mapping is as follows:
MIME媒体类型规范中包含的信息与会话描述协议（SDP）[4]中的字段具有特定映射，该协议通常用于描述RTP会话。使用SDP指定使用BroadVoice16或BroadVoice32编解码器的会话时，映射如下：
- The MIME type ("audio") goes in SDP "m=" as the media name.
- MIME类型（“音频”）以SDP“m=”作为媒体名称。
- The MIME subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 8000 for BV16 and 16000 for BV32.
- MIME子类型（有效负载格式名称）以SDP“a=rtpmap”作为编码名称。“a=rtpmap”中的RTP时钟频率对于BV16必须为8000，对于BV32必须为16000。
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
- 参数“ptime”和“maxptime”分别位于SDP“a=ptime”和“a=maxptime”属性中。
An example of the media representation in SDP for describing BV16 might be:
SDP中用于描述BV16的媒体表示的示例可能是：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 BV16/8000
m=audio 49120 RTP/AVP 97
a=rtpmap:97 BV16/8000
An example of the media representation in SDP for describing BV32 might be:
SDP中用于描述BV32的媒体表示的示例可能是：
m=audio 49122 RTP/AVP 99
a=rtpmap:99 BV32/16000
m=audio 49122 RTP/AVP 99
a=rtpmap:99 BV32/16000
No special considerations are needed for using the SDP Offer/Answer model [5] with the BV16 and BV32 RTP payload formats.
使用带有BV16和BV32 RTP有效负载格式的SDP提供/应答模型[5]时，无需特别考虑。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [1] and any appropriate profile (for example, [6]). This implies that confidentiality of the media streams is achieved by encryption.
使用本规范中定义的有效负载格式的RTP数据包受RTP规范[1]和任何适当配置文件（例如[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 that 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.
使用具有非均匀接收端计算负载的压缩技术进行数据编码存在潜在的拒绝服务威胁。攻击者可以向流中注入难以解码的病理数据报，并导致接收器过载。然而，本文件中涵盖的编码并未表现出任何显著的不一致性。
The general congestion control considerations for transporting RTP data apply to BV16 and BV32 audio over RTP as well (see RTP [1]) and any applicable RTP profile like AVP [6]. BV16 and BV32 do not have any built-in mechanism for reducing the bandwidth. Packing more frames in each RTP payload can reduce the number of packets sent, and hence the overhead from IP/UDP/RTP headers, at the expense of increased delay and reduced error robustness against packet losses.
传输RTP数据的一般拥塞控制注意事项也适用于通过RTP传输的BV16和BV32音频（见RTP[1]）以及任何适用的RTP配置文件，如AVP[6]。BV16和BV32没有任何用于减少带宽的内置机制。在每个RTP有效负载中打包更多帧可以减少发送的数据包数量，从而减少IP/UDP/RTP报头的开销，但代价是增加延迟并降低对数据包丢失的错误鲁棒性。
The authors would like to thank Magnus Westerlund, Colin Perkins, Allison Mankin, and Jean-Francois Mule for their review of this document.
作者要感谢Magnus Westerlund、Colin Perkins、Allison Mankin和Jean-Francois Mule对本文件的审查。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[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] Cable Television Laboratories, Inc., BroadVoice(TM)16 Speech Codec Specification, Revision 1.2, October 30, 2003.
[3] 有线电视实验室有限公司，《BroadVoice（TM）16语音编解码器规范》，第1.2版，2003年10月30日。
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[4] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[6] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[7] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[7] Sjoberg，J.，Westerlund，M.，Lakaniemi，A.，和Q.Xie，“自适应多速率（AMR）和自适应多速率宽带（AMR-WB）音频编解码器的实时传输协议（RTP）有效载荷格式和文件存储格式”，RFC 3267，2002年6月。
[8] Cable Television Laboratories, Inc., PacketCable(TM) 1.5
Audio/Video Codecs Specification, PKT-SP-CODEC1.5-I01-050128,
January 28, 2005.
http://www.cablelabs.com/specifications/archives/
[8] Cable Television Laboratories, Inc., PacketCable(TM) 1.5
Audio/Video Codecs Specification, PKT-SP-CODEC1.5-I01-050128,
January 28, 2005.
http://www.cablelabs.com/specifications/archives/
Authors' Addresses
作者地址
Juin-Hwey (Raymond) Chen Broadcom Corporation Room A3020 16215 Alton Parkway Irvine, CA 92618 USA
Juin Hwey（Raymond）Chen Broadcom公司美国加利福尼亚州埃尔文市阿尔顿公园路A3020 16215室，邮编92618
Phone: +1 949 926 6288
EMail: rchen@broadcom.com
Phone: +1 949 926 6288
EMail: rchen@broadcom.com
Winnie Lee Broadcom Corporation Room A2012E 200-13711 International Place Richmond, British Columbia V6V 2Z8 Canada
加拿大不列颠哥伦比亚省里士满国际广场A2012E 200-13711室Winnie Lee Broadcom Corporation V6V 2Z8
Phone: +1 604 233 8605
EMail: wlee@broadcom.com
Phone: +1 604 233 8605
EMail: wlee@broadcom.com
Jes Thyssen Broadcom Corporation Room A3018 16215 Alton Parkway Irvine, CA 92618 USA
Jes Thyssen Broadcom Corporation美国加利福尼亚州埃尔文市阿尔顿大道A3018 16215室，邮编92618
Phone: +1 949 926 5768
EMail: jthyssen@broadcom.com
Phone: +1 949 926 5768
EMail: jthyssen@broadcom.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。