Network Working Group K. McKay
Request for Comments: 2658 QUALCOMM Incorporated
Category: Standards Track August 1999
Network Working Group K. McKay
Request for Comments: 2658 QUALCOMM Incorporated
Category: Standards Track August 1999
RTP Payload Format for PureVoice(tm) Audio
PureVoice（tm）音频的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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
ABSTRACT
摘要
This document describes the RTP payload format for PureVoice(tm) Audio. The packet format supports variable interleaving to reduce the effect of packet loss on audio quality.
本文档描述了PureVoice（tm）音频的RTP有效负载格式。数据包格式支持可变交织，以减少数据包丢失对音频质量的影响。
1 Introduction
1导言
This document describes how compressed PureVoice audio as produced by the Qualcomm PureVoice CODEC [1] may be formatted for use as an RTP payload type. A method is provided to interleave the output of the compressor to reduce quality degradation due to lost packets. Furthermore, the sender may choose various interleave settings based on the importance of low end-to-end delay versus greater tolerance for lost packets.
本文档描述了如何将高通公司PureVoice编解码器[1]产生的压缩PureVoice音频格式化为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 RFC 2119 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[3]中所述进行解释。
2 Background
2背景
The Electronic Industries Association (EIA) & Telecommunications Industry Association (TIA) standard IS-733 [1] defines an audio compression algorithm for use in CDMA applications. In addition to being the standard CODEC for all wireless CDMA terminals, the Qualcomm PureVoice CODEC (a.k.a. Qcelp) is used in several Internet applications most notably JFax(tm), Apple(r) QuickTime(tm), and Eudora(r).
电子工业协会（EIA）和电信工业协会（TIA）标准IS-733[1]定义了用于CDMA应用的音频压缩算法。除了作为所有无线CDMA终端的标准编解码器外，高通公司的PureVoice编解码器（又称Qcelp）还用于多种互联网应用，最著名的是JFax（tm）、Apple（r）、QuickTime（tm）和Eudora（r）。
The Qcelp CODEC [1] compresses each 20 milliseconds of 8000 Hz, 16- bit sampled input speech into one of four different size output frames: Rate 1 (266 bits), Rate 1/2 (124 bits), Rate 1/4 (54 bits) or Rate 1/8 (20 bits). The CODEC chooses the output frame rate based on analysis of the input speech and the current operating mode (either normal or reduced rate). For typical speech patterns, this results in an average output of 6.8 k bits/sec for normal mode and 4.7 k bits/sec for reduced rate mode.
Qcelp编解码器[1]将每20毫秒8000 Hz、16位采样的输入语音压缩为四种不同大小的输出帧之一：速率1（266位）、速率1/2（124位）、速率1/4（54位）或速率1/8（20位）。编解码器根据对输入语音和当前操作模式（正常或降低速率）的分析来选择输出帧速率。对于典型的语音模式，这会导致正常模式的平均输出为6.8 k位/秒，而低速模式的平均输出为4.7 k位/秒。
3 RTP/Qcelp Packet Format
3 RTP/Qcelp数据包格式
The RTP timestamp is in 1/8000 of a second units. The RTP payload data for the Qcelp CODEC has the following format:
RTP时间戳的单位为1/8000秒。Qcelp编解码器的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 [2] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|RR | LLL | NNN | |
+-+-+-+-+-+-+-+-+ one or more codec data frames |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [2] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|RR | LLL | NNN | |
+-+-+-+-+-+-+-+-+ one or more codec data frames |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RTP header has the expected values as described in [2]. The extension bit is not set and this payload type never sets the marker bit. The codec data frames are aligned on octet boundaries. When interleaving is in use and/or multiple codec data frames are present in a single RTP packet, the timestamp is, as always, that of the oldest data represented in the RTP packet. The other fields have the following meaning:
RTP标头具有[2]中所述的预期值。未设置扩展位，此有效负载类型从不设置标记位。编解码器数据帧在八位字节边界上对齐。当使用交织和/或单个RTP分组中存在多个编解码器数据帧时，时间戳总是RTP分组中表示的最早数据的时间戳。其他字段具有以下含义：
Reserved (RR): 2 bits MUST be set to zero by sender, SHOULD be ignored by receiver.
保留（RR）：发送方必须将2位设置为零，接收方应忽略。
Interleave (LLL): 3 bits MUST have a value between 0 and 5 inclusive. The remaining two values (6 and 7) MUST not be used by senders. If this field is non-zero, interleaving is enabled. All receivers MUST support interleaving. Senders MAY support interleaving. Senders that do not support interleaving MUST set field LLL and NNN to zero.
交织（LLL）：3位的值必须介于0和5之间（包括0和5）。发件人不得使用其余两个值（6和7）。如果此字段非零，则启用交织。所有接收机必须支持交织。发送方可以支持交织。不支持交织的发件人必须将字段LLL和NNN设置为零。
Interleave Index (NNN): 3 bits MUST have a value less than or equal to the value of LLL. Values of NNN greater than the value of LLL are invalid.
交织索引（NNN）：3位的值必须小于或等于LLL的值。大于LLL值的NNN值无效。
On receipt of an RTP packet with an invalid value of the LLL or NNN field, the RTP packet MUST be treated as lost by the receiver for the purpose of generating erasure frames as described in section 4.
在接收到具有LLL或NNN字段无效值的RTP数据包时，接收机必须将RTP数据包视为丢失，以生成第4节中所述的擦除帧。
The output of the Qcelp CODEC must be converted into CODEC data frames for inclusion in the RTP payload as follows:
Qcelp编解码器的输出必须转换为编解码器数据帧，以便包含在RTP有效负载中，如下所示：
a. Octet 0 of the CODEC data frame indicates the rate and total size of the CODEC data frame as indicated in this table:
a. 编解码器数据帧的八位字节0表示编解码器数据帧的速率和总大小，如下表所示：
OCTET 0 RATE TOTAL CODEC data frame size (in octets)
-----------------------------------------------------------
0 Blank 1
1 1/8 4
2 1/4 8
3 1/2 17
4 1 35
5 reserved 8 (SHOULD be treated as a reserved value)
14 Erasure 1 (SHOULD NOT be transmitted by sender)
other n/a reserved
OCTET 0 RATE TOTAL CODEC data frame size (in octets)
-----------------------------------------------------------
0 Blank 1
1 1/8 4
2 1/4 8
3 1/2 17
4 1 35
5 reserved 8 (SHOULD be treated as a reserved value)
14 Erasure 1 (SHOULD NOT be transmitted by sender)
other n/a reserved
Receipt of a CODEC data frame with a reserved value in octet 0 MUST be considered invalid data as described in 3.1.
如3.1所述，接收八位字节0中保留值的编解码器数据帧必须视为无效数据。
b. The bits as numbered in the standard [1] from highest to lowest are packed into octets. The highest numbered bit (265 for Rate 1, 123 for Rate 1/2, 53 for Rate 1/4 and 19 for Rate 1/8) is placed in the most significant bit (Internet bit 0) of octet 1 of the CODEC data frame. The second highest numbered bit (264 for Rate 1, etc.) is placed in the second most significant bit (Internet bit 1) of octet 1 of the data frame. This continues so that bit 258 from the standard Rate 1 frame is placed in the least significant bit of octet 1. Bit 257 from the standard is placed in the most significant bit of octet 2 and so on until bit 0 from the standard Rate 1 frame is placed in Internet bit 1 of octet 34 of the CODEC data frame. The remaining unused bits of the last octet of the CODEC data frame MUST be set to zero.
b. 标准[1]中从高到低编号的位被压缩成八位字节。编号最高的位（265表示速率1，123表示速率1/2，53表示速率1/4，19表示速率1/8）位于编解码器数据帧的八位位组1的最高有效位（因特网位0）中。第二高编号位（速率1的264等）被放置在数据帧的八位组1的第二高有效位（因特网位1）中。这将继续，使得来自标准速率1帧的比特258被置于八位组1的最低有效比特中。来自标准的比特257被放置在八位组2的最高有效比特中，依此类推，直到来自标准速率1帧的比特0被放置在编解码器数据帧的八位组34的因特网比特1中。编解码器数据帧最后八位字节的剩余未使用位必须设置为零。
Here is a detail of how a Rate 1/8 frame is converted into a CODEC data frame: CODEC data frame
下面详细介绍如何将速率为1/8的帧转换为编解码器数据帧：编解码器数据帧
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |1|1|1|1|1|1|1|1|1|1| | | | | | | | | | | | | | |
| 1 (Rate 1/8) |9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|Z|Z|Z|Z|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |1|1|1|1|1|1|1|1|1|1| | | | | | | | | | | | | | |
| 1 (Rate 1/8) |9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|Z|Z|Z|Z|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Octet 0 of the data frame has value 1 (see table above) indicating the total data frame length (including octet 0) is 4 octets. Bits 19 through 0 from the standard Rate 1/8 frame are placed as indicated with bits marked with "Z" being set to zero. The Rate 1, 1/4 and 1/2 standard frames are converted similarly.
数据帧的八位字节0的值为1（见上表），表示数据帧的总长度（包括八位字节0）为4个八位字节。来自标准速率1/8帧的位19到0按照指示放置，标记为“Z”的位设置为零。速率1、1/4和1/2标准帧的转换方式类似。
As indicated in section 3, more than one CODEC data frame MAY be included in a single RTP packet by a sender. Receivers MUST handle bundles of up to 10 CODEC data frames in a single RTP packet.
如第3节所示，发送方可以在单个RTP分组中包括多个编解码器数据帧。接收机必须在单个RTP数据包中处理多达10个编解码器数据帧的捆绑包。
Furthermore, senders have the following additional restrictions:
此外，发件人还有以下附加限制：
o MUST not bundle more CODEC data frames in a single RTP packet than will fit in the MTU of the RTP transport protocol. For the purpose of computing the maximum bundling value, all CODEC data frames should be assumed to have the Rate 1 size.
o 在单个RTP数据包中捆绑的编解码器数据帧不得超过RTP传输协议的MTU所能容纳的数量。为了计算最大捆绑值，应假定所有编解码器数据帧的大小为1。
o MUST never bundle more than 10 CODEC data frames in a single RTP packet.
o 在单个RTP数据包中捆绑的编解码器数据帧不得超过10个。
o Once beginning transmission with a given SSRC and given bundling value, MUST NOT increase the bundling value. If the bundling value needs to be increased, a new SSRC number MUST be used.
o 一旦使用给定SSRC和给定捆绑值开始传输，不得增加捆绑值。如果需要增加捆绑值，则必须使用新的SSRC编号。
o MAY decrease the bundling value only between interleave groups (see section 3.4). If the bundling value is decreased, it MUST NOT be increased (even to the original value), although it may be decreased again at a later time.
o 仅可在交织组之间降低捆绑值（见第3.4节）。如果捆绑值降低，则不得增加捆绑值（即使增加到原始值），尽管以后可能会再次降低捆绑值。
Since no count is transmitted as part of the RTP payload and the CODEC data frames have differing lengths, the only way to determine how many CODEC data frames are present in the RTP packet is to examine octet 0 of each CODEC data frame in sequence until the end of the RTP packet is reached.
由于没有计数作为RTP有效载荷的一部分传输，并且编解码器数据帧具有不同的长度，因此确定RTP分组中存在多少编解码器数据帧的唯一方法是按顺序检查每个编解码器数据帧的八位组0，直到到达RTP分组的末尾。
Interleaving is meaningful only when more than one CODEC data frame is bundled into a single RTP packet.
只有当多个编解码器数据帧捆绑到单个RTP数据包中时，交织才有意义。
All receivers MUST support interleaving. Senders MAY support interleaving.
所有接收机必须支持交织。发送方可以支持交织。
Given a time-ordered sequence of output frames from the Qcelp CODEC numbered 0..n, a bundling value B, and an interleave value L where n = B * (L+1) - 1, the output frames are placed into RTP packets as follows (the values of the fields LLL and NNN are indicated for each RTP packet):
给定来自编号为0..n的Qcelp编解码器的输出帧的时序序列、捆绑值B和交织值L，其中n＝B*（L+1）-1，输出帧被放置到RTP分组中，如下所示（为每个RTP分组指示字段LLL和NNN的值）：
First RTP Packet in Interleave group:
LLL=L, NNN=0
Frame 0, Frame L+1, Frame 2(L+1), Frame 3(L+1), ... for a total of
B frames
First RTP Packet in Interleave group:
LLL=L, NNN=0
Frame 0, Frame L+1, Frame 2(L+1), Frame 3(L+1), ... for a total of
B frames
Second RTP Packet in Interleave group:
LLL=L, NNN=1
Frame 1, Frame 1+L+1, Frame 1+2(L+1), Frame 1+3(L+1), ... for a
total of B frames
Second RTP Packet in Interleave group:
LLL=L, NNN=1
Frame 1, Frame 1+L+1, Frame 1+2(L+1), Frame 1+3(L+1), ... for a
total of B frames
This continues to the last RTP packet in the interleave group:
这将继续到交织组中的最后一个RTP数据包：
L+1 RTP Packet in Interleave group:
LLL=L, NNN=L
Frame L, Frame L+L+1, Frame L+2(L+1), Frame L+3(L+1), ... for a
total of B frames
L+1 RTP Packet in Interleave group:
LLL=L, NNN=L
Frame L, Frame L+L+1, Frame L+2(L+1), Frame L+3(L+1), ... for a
total of B frames
Senders MUST transmit in timestamp-increasing order. Furthermore, within each interleave group, the RTP packets making up the interleave group MUST be transmitted in value-increasing order of the NNN field. While this does not guarantee reduced end-to-end delay on the receiving end, when packets are delivered in order by the underlying transport, delay will be reduced to the minimum possible.
发送方必须以时间戳递增的顺序进行传输。此外，在每个交织组内，组成交织组的RTP分组必须以NNN字段的值递增顺序发送。虽然这不能保证减少接收端的端到端延迟，但当底层传输按顺序传递数据包时，延迟将减少到尽可能小的程度。
Additionally, senders have the following restrictions:
此外，发件人有以下限制：
o Once beginning transmission with a given SSRC and given interleave value, MUST NOT increase the interleave value. If the interleave value needs to be increased, a new SSRC number MUST be used.
o 一旦使用给定SSRC和给定交织值开始传输，不得增加交织值。如果需要增加交织值，则必须使用新的SSRC编号。
o MAY decrease the interleave value only between interleave groups. If the interleave value is decreased, it MUST NOT be increased (even to the original value), although it may be decreased again at a later time.
o 只能在交织组之间减小交织值。如果交织值减小，则不得将其增大（甚至增大到原始值），尽管稍后可能会再次减小。
Given an RTP packet with sequence number S, interleave value (field LLL) L, and interleave index value (field NNN) N, the interleave group consists of RTP packets with sequence numbers from S-N to S-N+L inclusive. In other words, the Interleave group always consists of L+1 RTP packets with sequential sequence numbers. The bundling value for all RTP packets in an interleave group MUST be the same.
给定序列号为S、交织值（字段LLL）L和交织索引值（字段NNN）N的RTP数据包，交织组由序列号为S-N到S-N+L（含）的RTP数据包组成。换句话说，交织组总是由具有序列号的L+1个RTP分组组成。交织组中所有RTP数据包的绑定值必须相同。
The receiver determines the expected bundling value for all RTP packets in an interleave group by the number of CODEC data frames bundled in the first RTP packet of the interleave group received. Note that this may not be the first RTP packet of the interleave group sent if packets are delivered out of order by the underlying transport.
接收机通过在接收到的交织组的第一个RTP分组中捆绑的编解码器数据帧的数量来确定交织组中的所有RTP分组的预期捆绑值。请注意，如果数据包由底层传输无序交付，则这可能不是交织组发送的第一个RTP数据包。
On receipt of an RTP packet in an interleave group with other than the expected bundling value, the receiver MAY discard CODEC data frames off the end of the RTP packet or add erasure CODEC data frames to the end of the packet in order to manufacture a substitute packet with the expected bundling value. The receiver MAY instead choose to discard the whole interleave group and play silence.
在接收到交织组中具有非预期捆绑值的RTP分组时，接收机可以丢弃RTP分组末端的编解码器数据帧，或者向分组末端添加擦除编解码器数据帧，以便制造具有预期捆绑值的替代分组。相反，接收机可以选择丢弃整个交织组并播放静音。
Given an RTP sequence number ordered set of RTP packets in an interleave group numbered 0..L, where L is the interleave value and B is the bundling value, and CODEC data frames within each RTP packet that are numbered in order from first to last with the numbers 1..B, the original, time-ordered sequence of output frames from the CODEC may be reconstructed as follows:
给定编号为0..L的交织组中RTP数据包的RTP序列号有序集，其中L为交织值，B为捆绑值，每个RTP数据包内的编解码器数据帧按从开始到最后的顺序编号，编号为1..B，为原始，可如下重构来自编解码器的输出帧的时序序列：
First L+1 frames: Frame 0 from packet 0 of interleave group Frame 0 from packet 1 of interleave group And so on up to... Frame 0 from packet L of interleave group
前L+1帧：帧0从交织组的数据包0到帧0从交织组的数据包1，依此类推到。。。来自交织组的分组L的帧0
Second L+1 frames: Frame 1 from packet 0 of interleave group Frame 1 from packet 1 of interleave group And so on up to... Frame 1 from packet L of interleave group
第二个L+1帧：帧1来自交织组的数据包0帧1来自交织组的数据包1，依此类推到。。。来自交织组的分组L的帧1
And so on up to...
等等，直到。。。
Bth L+1 frames: Frame B from packet 0 of interleave group Frame B from packet 1 of interleave group And so on up to... Frame B from packet L of interleave group
Bth L+1帧：帧B从交织组的数据包0开始帧B从交织组的数据包1开始帧B，依此类推直到。。。来自交织组的分组L的帧B
Assume that the receiver has begun playing frames from an interleave group. The time has come to play frame x from packet n of the interleave group. Further assume that packet n of the interleave group has not been received. As described in section 4, an erasure frame will be sent to the Qcelp CODEC.
假设接收器已开始播放交织组中的帧。从交织组的分组n播放帧x的时间到了。进一步假设交织组的分组n尚未被接收。如第4节所述，擦除帧将被发送到Qcelp编解码器。
Now, assume that packet n of the interleave group arrives before frame x+1 of that packet is needed. Receivers SHOULD use frame x+1 of the newly received packet n rather than substituting an erasure frame. In other words, just because packet n wasn't available the first time it was needed to reconstruct the interleaved audio, the receiver SHOULD NOT assume it's not available when it's subsequently needed for interleaved audio reconstruction.
现在，假设交织组的分组n在需要该分组的帧x+1之前到达。接收机应使用新接收的分组n的帧x+1，而不是替换擦除帧。换句话说，仅仅因为分组n在第一次需要重建交织音频时不可用，接收机就不应该假设它在随后需要重建交织音频时不可用。
4 Handling lost RTP packets
4处理丢失的RTP数据包
The Qcelp CODEC supports the notion of erasure frames. These are frames that for whatever reason are not available. When reconstructing interleaved audio or playing back non-interleaved audio, erasure frames MUST be fed to the Qcelp CODEC for all of the missing packets.
Qcelp编解码器支持擦除帧的概念。这些帧由于任何原因都不可用。重建交织音频或播放非交织音频时，必须将所有丢失数据包的擦除帧馈送至Qcelp编解码器。
Receivers MUST use the timestamp clock to determine how many CODEC data frames are missing. Each CODEC data frame advances the timestamp clock EXACTLY 160 counts.
接收器必须使用时间戳时钟来确定缺少多少编解码器数据帧。每个编解码器数据帧将时间戳时钟精确提前160个计数。
Since the bundling value may vary (it can only decrease), the timestamp clock is the only reliable way to calculate exactly how many CODEC data frames are missing when a packet is dropped.
由于捆绑值可能会变化（它只能减小），因此时间戳时钟是唯一可靠的方法，可以准确计算丢包时丢失多少编解码器数据帧。
Specifically when reconstructing interleaved audio, a missing RTP packet in the interleave group should be treated as containing B erasure CODEC data frames where B is the bundling value for that interleave group.
具体地说，当重建交织音频时，交织组中丢失的RTP分组应被视为包含B擦除编解码器数据帧，其中B是该交织组的捆绑值。
5 Discussion
5讨论
The Qcelp CODEC interpolates the missing audio content when given an erasure frame. However, the best quality is perceived by the listener when erasure frames are not consecutive. This makes interleaving desirable as it increases audio quality when dropped packets are more likely.
当给定擦除帧时，Qcelp编解码器插入丢失的音频内容。然而，当擦除帧不是连续的时，听者会感觉到最好的质量。这使得交错成为可取的，因为当丢弃的数据包更有可能时，交错可以提高音频质量。
On the other hand, interleaving can greatly increase the end-to-end delay. Where an interactive session is desired, an interleave (field LLL) value of 0 or 1 and a bundling factor of 4 or less is recommended.
另一方面，交织可以大大增加端到端延迟。如果需要交互式会话，建议交错（字段LLL）值为0或1，捆绑因子为4或更小。
When end-to-end delay is not a concern, a bundling value of at least 4 and an interleave (field LLL) value of 4 or 5 is recommended subject to MTU limitations.
当不考虑端到端延迟时，根据MTU限制，建议捆绑值至少为4，交织（字段LLL）值为4或5。
The restrictions on senders set forth in sections 3.3 and 3.4 guarantee that after receipt of the first payload packet from the sender, the receiver can allocate a well-known amount of buffer space that will be sufficient for all future reception from the same SSRC value. Less buffer space may be required at some point in the future if the sender decreases the bundling value or interleave, but never more buffer space. This prevents the possibility of the receiver needing to allocate more buffer space (with the possible result that none is available) should the bundling value or interleave value be increased by the sender. Also, were the interleave or bundling value to increase, the receiver could be forced to pause playback while it receives the additional packets necessary for playback at an increased bundling value or increased interleave.
第3.3节和第3.4节中规定的对发送方的限制保证，在从发送方接收到第一个有效负载数据包后，接收方可以分配一个众所周知的缓冲空间量，该缓冲空间量足以满足将来从相同SSRC值接收到的所有数据。如果发送方减少捆绑值或交织，则在将来某个时候可能需要更少的缓冲区空间，但决不需要更多的缓冲区空间。这防止了在发送方增加捆绑值或交织值的情况下，接收方需要分配更多缓冲区空间的可能性（可能导致没有可用的缓冲区空间）。此外，如果交织值或捆绑值增加，则当接收机以增加的捆绑值或增加的交织值接收回放所需的附加分组时，可以强制接收机暂停回放。
6 Security Considerations
6安全考虑
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [2], and any appropriate profile (for example [4]). This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
使用本规范中定义的有效负载格式的RTP数据包受RTP规范[2]和任何适当配置文件（例如[4]）中讨论的安全注意事项的约束。这意味着媒体流的机密性是通过加密实现的。由于与此有效负载格式一起使用的数据压缩是端到端应用的，因此可以在压缩之后执行加密，因此两个操作之间没有冲突。
A potential denial-of-service threat exists for data encodings 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 be overloaded. However, this encoding does not exhibit any significant non-uniformity.
使用压缩技术的数据编码存在潜在的拒绝服务威胁，这种压缩技术具有非均匀的接收端计算负载。攻击者可以向流中注入病理数据报，这些数据报解码复杂，并导致接收器过载。然而，这种编码并没有表现出任何显著的非均匀性。
As with any IP-based protocol, in some circumstances, a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [5] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
与任何基于IP的协议一样，在某些情况下，接收机可能仅仅因为接收了太多的数据包而过载，不管是想要的还是不想要的。网络层认证可用于丢弃来自不希望的源的数据包，但认证本身的处理成本可能过高。在多播环境中，可以在IGMP[5]的未来版本和多播路由协议中实现特定源的修剪，以允许接收机选择允许哪些源到达它。
7 References
7参考文献
[1] TIA/EIA/IS-733. TR45: High Rate Speech Service Option for Wideband Spread Spectrum Communications Systems. Available from Global Engineering +1 800 854 7179 or +1 303 792 2181. May also be ordered online at http://www.eia.org/eng/.
[1] TIA/EIA/IS-733。TR45：宽带扩频通信系统的高速语音服务选项。可从全球工程+1800 854 7179或+1 303 792 2181获得。也可通过以下网址在线订购：http://www.eia.org/eng/.
[2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[2] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[4] Schulzrinne，H.，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 1890，1996年1月。
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[5] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
8 Author's Address
8作者地址
Kyle J. McKay QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 USA
美国加利福尼亚州圣地亚哥莫尔豪斯大道5775号凯尔·J·麦凯高通公司，邮编92121-1714
Phone: +1 858 587 1121
EMail: kylem@qualcomm.com
Phone: +1 858 587 1121
EMail: kylem@qualcomm.com
9 Full Copyright Statement
9完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。
K. McKay Standards Track [Page 10]
K.麦凯标准轨道[第10页]