Network Working Group M. Handley
Request for Comments: 2736 ACIRI
BCP: 36 C. Perkins
Category: Best Current Practice UCL
December 1999
Network Working Group M. Handley
Request for Comments: 2736 ACIRI
BCP: 36 C. Perkins
Category: Best Current Practice UCL
December 1999
Guidelines for Writers of RTP Payload Format Specifications
RTP有效负载格式规范编写者指南
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development.
本文档提供了通用指南，旨在帮助RTP有效负载格式规范的作者决定好的格式。这些指南试图获取RTP在开发过程中的一些经验。
This document provides general guidelines aimed at assisting the authors of RTP [9] Payload Format specifications in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development.
本文件提供了一般指南，旨在帮助RTP[9]有效负载格式规范的作者决定好的格式。这些指南试图获取RTP在开发过程中的一些经验。
The principles outlined in this document are applicable to almost all data types, but are framed in examples of audio and video codecs for clarity.
本文档中概述的原则几乎适用于所有数据类型，但为了清晰起见，在音频和视频编解码器的示例中进行了阐述。
RTP was designed around the concept of Application Level Framing (ALF), first described by Clark and Tennenhouse [2]. The key argument underlying ALF is that there are many different ways an application might be able to cope with misordered or lost packets. These range from ignoring the loss, to re-sending the missing data (either from a buffer or by regenerating it), and to sending new data which supersedes the missing data. The application only has this choice if the transport protocol is dealing with data in "Application Data Units" (ADUs). An ADU contains data that can be processed out-of-
RTP是围绕应用层框架（ALF）的概念设计的，首先由Clark和Tennenhouse[2]描述。ALF背后的关键论点是，应用程序可能有许多不同的方式来处理顺序错误或丢失的数据包。从忽略丢失到重新发送丢失的数据（从缓冲区或通过重新生成数据），再到发送取代丢失数据的新数据。只有当传输协议处理“应用程序数据单元”（ADU）中的数据时，应用程序才有此选择。ADU包含可从外部处理的数据-
order with respect to other ADUs. Thus the ADU is the minimum unit of error recovery.
关于其他ADU的命令。因此，ADU是错误恢复的最小单位。
The key property of a transport protocol for ADUs is that each ADU contains sufficient information to be processed by the receiver immediately. An example is a video stream, wherein the compressed video data in an ADU must be capable of being decompressed regardless of whether previous ADUs have been received. Additionally the ADU must contain "header" information detailing its position in the video image and the frame from which it came.
ADU传输协议的关键特性是，每个ADU都包含足够的信息，以便接收机立即处理。一个示例是视频流，其中无论是否接收到先前的ADU，ADU中的压缩视频数据必须能够被解压缩。此外，ADU必须包含“标题”信息，详细说明其在视频图像中的位置及其来源的帧。
Although an ADU need not be a packet, there are many applications for which a packet is a natural ADU. Such ALF applications have the great advantage that all packets that are received can be processed by the application immediately.
尽管ADU不需要是数据包，但对于许多应用程序，数据包都是自然的ADU。这样的ALF应用程序具有很大的优势，即应用程序可以立即处理接收到的所有数据包。
RTP was designed around an ALF philosophy. In the context of a stream of RTP data, an RTP packet header provides sufficient information to be able to identify and decode the packet irrespective of whether it was received in order, or whether preceding packets have been lost. However, these arguments only hold good if the RTP payload formats are also designed using an ALF philosophy.
RTP是围绕ALF理念设计的。在RTP数据流的上下文中，RTP分组报头提供足够的信息，以便能够识别和解码分组，而不管分组是否按顺序接收，或者之前的分组是否已丢失。然而，只有当RTP有效负载格式也使用ALF原理设计时，这些参数才有效。
Note that this also implies smart, network aware, end-points. An application using RTP should be aware of the limitations of the underlying network, and should adapt its transmission to match those limitations. Our experience is that a smart end-point implementation can achieve significantly better performance on real IP-based networks than a naive implementation.
请注意，这也意味着智能、网络感知的端点。使用RTP的应用程序应了解底层网络的限制，并应调整其传输以匹配这些限制。我们的经验是，与简单的实现相比，智能端点实现可以在基于IP的真实网络上实现显著更好的性能。
We identify the following channel characteristics that influence the best-effort transport of RTP over UDP/IP in the Internet:
我们确定了影响互联网上UDP/IP上RTP尽力而为传输的以下信道特征：
o Packets may be lost
o 数据包可能丢失
o Packets may be duplicated
o 数据包可以重复
o Packets may be reordered in transit
o 数据包可以在传输过程中重新排序
o Packets will be fragmented if they exceed the MTU of the underlying network
o 如果数据包超过底层网络的MTU，则数据包将被分割
The loss characteristics of a link may vary widely over short time intervals.
链路的损耗特性可能在短时间间隔内变化很大。
Although fragmentation is not a disastrous phenomenon if it is a rare occurrence, relying on IP fragmentation is a bad design strategy as it significantly increases the effective loss rate of a network and decreases goodput. This is because if one fragment is lost, the remaining fragments (which have used up bottleneck bandwidth) will then need to be discarded by the receiver. It also puts additional load on the routers performing fragmentation and on the end-systems re-assembling the fragments.
虽然碎片化在很少发生的情况下并不是灾难性的现象，但依赖IP碎片化是一种糟糕的设计策略，因为它会显著增加网络的有效丢失率并降低吞吐量。这是因为，如果一个片段丢失，那么剩余的片段（已使用瓶颈带宽）将需要被接收器丢弃。它还给执行碎片的路由器和重新组装碎片的终端系统带来额外的负载。
In addition, it is noted that the transit time between two hosts on the Internet will not be constant. This is due to two effects - jitter caused by being queued behind cross-traffic, and routing changes. The former is possible to characterise and compensate for by using a playout buffer, but the latter is impossible to predict and difficult to accommodate gracefully.
此外，需要注意的是，互联网上两台主机之间的传输时间不会恒定。这是由于两个影响-交叉流量后排队引起的抖动和路由更改。前者可以通过使用播放缓冲区来描述和补偿，但后者不可能预测，也难以优雅地适应。
We identify the following requirements of RTP payload format specifications:
我们确定了RTP有效负载格式规范的以下要求：
+ A payload format should be devised so that the stream being transported is still useful even in the presence of a moderate amount of packet loss.
+ 应设计有效负载格式，以便即使在存在适度的分组丢失的情况下，正在传输的流仍然有用。
+ Ideally all the contents of every packet should be possible to be decoded and played out irrespective of whether preceding packets have been lost or arrive late.
+ 理想情况下，每个数据包的所有内容都应该能够被解码和播放，而不管前面的数据包是否丢失或延迟到达。
The first of these requirements is based on the nature of the Internet. Although it may be possible to engineer parts of the Internet to produce low loss rates through careful provisioning or the use of non-best-effort services, as a rule payload formats should not be designed for these special purpose environments. Payload formats should be designed to be used in the public Internet with best effort service, and thus should expect to see moderate loss rates. For example, a 5% loss rate is not uncommon. We note that TCP steady state models [3][4][6] indicate that a 5% loss rate with a 1KByte packet size and 200ms round-trip time will result in TCP achieving a throughput of around 180Kbit/s. Higher loss rates, smaller packet sizes, or a larger RTT are required to constrain TCP to lower data rates. For the most part, it is such TCP traffic that is producing the background loss that many RTP flows must co-exist with. Without explicit congestion notification (ECN) [8], loss must be considered an intrinsic property of best-effort parts of the Internet.
第一个要求是基于互联网的性质。尽管可以通过谨慎的资源调配或使用非尽力而为的服务来设计Internet的某些部分，以产生较低的丢失率，但通常不应为这些特殊用途的环境设计有效负载格式。有效载荷格式应设计为在公共互联网上使用尽力而为的服务，因此应期望看到中等的损失率。例如，5%的损失率并不罕见。我们注意到，TCP稳态模型[3][4][6]表明，在1KB数据包大小和200ms往返时间的情况下，5%的丢失率将使TCP实现约180Kbit/s的吞吐量。需要更高的丢失率、更小的数据包大小或更大的RTT来限制TCP以降低数据速率。在大多数情况下，正是这种TCP流量产生了许多RTP流必须共存的背景损失。如果没有明确的拥塞通知（ECN）[8]，丢失必须被视为互联网尽力而为部分的固有属性。
When payload formats do not assume packet loss will occur, they should state this explicitly up front, and they will be considered special purpose payload formats, unsuitable for use on the public Internet without special support from the network infrastructure.
当有效载荷格式不认为会发生数据包丢失时，它们应提前明确说明这一点，并且它们将被视为专用有效载荷格式，不适合在没有网络基础设施特殊支持的情况下在公共互联网上使用。
The second of these requirements is more explicit about how RTP should cope with loss. If an RTP payload format is properly designed, every packet that is actually received should be useful. Typically this implies the following guidelines are adhered to:
第二个要求更明确地说明RTP应如何应对损失。如果RTP有效负载格式设计得当，那么实际接收到的每个数据包都应该是有用的。这通常意味着遵守以下准则：
+ Packet boundaries should coincide with codec frame boundaries. Thus a packet should normally consist of one or more complete codec frames.
+ 数据包边界应与编解码器帧边界一致。因此，数据包通常应由一个或多个完整的编解码器帧组成。
+ A codec's minimum unit of data should never be packetised so that it crosses a packet boundary unless it is larger than the MTU.
+ 编解码器的最小数据单元不应打包，以使其跨越数据包边界，除非其大于MTU。
+ If a codec's frame size is larger than the MTU, the payload format must not rely on IP fragmentation. Instead it must define its own fragmentation mechanism. Such mechanisms may involve codec-specific information that allows decoding of fragments. Alternatively they might allow codec-independent packet-level forward error correction [5] to be applied that cannot be used with IP-level fragmentation.
+ 如果编解码器的帧大小大于MTU，则有效负载格式不得依赖于IP分段。相反，它必须定义自己的碎片机制。此类机制可能涉及允许片段解码的编解码器特定信息。或者，它们可能允许应用与编解码器无关的数据包级前向纠错[5]，但不能与IP级分段一起使用。
In the abstract, a codec frame (i.e., the ADU or the minimum size unit that has semantic meaning when handed to the codec) can be of arbitrary size. For PCM audio, it is one byte. For GSM audio, a frame corresponds to 20ms of audio. For H.261 video, it is a Group of Blocks (GOB), or one twelfth of a CIF video frame.
在摘要中，编解码器帧（即，ADU或交给编解码器时具有语义意义的最小大小单元）可以具有任意大小。对于PCM音频，它是一个字节。对于GSM音频，帧对应于20ms的音频。对于H.261视频，它是一组块（GOB），或CIF视频帧的十二分之一。
For PCM, it does not matter how audio is packetised, as the ADU size is one byte. For GSM audio, arbitrary packetisation would split a 20ms frame over two packets, which would mean that if one packet were lost, partial frames in packets before and after the loss are meaningless. This means that not only were the bits in the missing packet lost, but also that additional bits in neighboring packets that used bottleneck bandwidth were effectively also lost because the receiver must throw them away. Instead, we would packetise GSM by including several complete GSM frames in a packet; typically four GSM frames are included in current implementations. Thus every packet received can be decoded because even in the presence of loss, no incomplete frames are received.
对于PCM，音频如何打包并不重要，因为ADU大小为一个字节。对于GSM音频，任意分组会将20ms帧分割为两个数据包，这意味着如果一个数据包丢失，丢失前后数据包中的部分帧将毫无意义。这意味着，不仅丢失的数据包中的比特丢失了，而且相邻数据包中使用瓶颈带宽的额外比特也有效地丢失了，因为接收器必须将它们丢弃。相反，我们将通过在一个数据包中包含几个完整的GSM帧来打包GSM；通常，当前实现中包括四个GSM帧。因此，每个接收到的分组都可以被解码，因为即使在丢失的情况下，也不会接收到不完整的帧。
The H.261 specification allows GOBs to be up to 3KBytes long, although most of the time they are smaller than this. It might be thought that we should insert a group of blocks into a packet when it fits, and arbitrarily split the GOB over two or more packets when a
H.261规范允许GOB的长度达到3KB，尽管大多数情况下它们都小于3KB。人们可能认为，我们应该在合适的时候将一组块插入到一个数据包中，并在出现错误时将GOB任意分割为两个或多个数据包
GOB is large. In the first version of the H.261 payload format, this is what was done. However, this still means that there are circumstances where H.261 packets arrive at the receiver and must be discarded because other packets were lost - a loss multiplier effect that we wish to avoid. In fact there are smaller units than GOBs in the H.261 bit-stream called macroblocks, but they are not identifiable without parsing from the start of the GOB. However, if we provide a little additional information at the start of each packet, we can reinstate information that would normally be found by parsing from the start of the GOB, and we can packetise H.261 by splitting the data stream on macroblock boundaries. This is a less obvious packetisation for H.261 than the GOB packetisation, but it does mean that a slightly smarter depacketiser at the receiver can reconstruct a valid H.261 bitstream from a stream of RTP packets that has experienced loss, and not have to discard any of the data that arrived.
采空区很大。在H.261有效载荷格式的第一个版本中，就是这样做的。然而，这仍然意味着，在某些情况下，H.261数据包到达接收器，必须丢弃，因为其他数据包丢失了，这是我们希望避免的丢失倍增效应。事实上，在H.261位流中有比GOB更小的单元，称为宏块，但是如果不从GOB的开始进行解析，它们是无法识别的。然而，如果我们在每个数据包的开头提供一点额外的信息，我们可以恢复通常通过从GOB开头解析找到的信息，并且我们可以通过在宏块边界上分割数据流来打包H.261。对于H.261而言，这是一种不太明显的打包方式，而不是GOB打包方式，但这确实意味着接收器处稍微聪明一点的解打包器可以从经历丢失的RTP数据包流中重建有效的H.261比特流，而不必丢弃任何到达的数据。
An additional guideline concerns codecs that require the decoder state machine to keep step with the encoder state machine. Many audio codecs such as LPC or GSM are of this form. Typically they are loss tolerant, in that after a loss, the predictor coefficients decay, so that after a certain amount of time, the predictor error induced by the loss will disappear. Most codecs designed for telephony services are of this form because they were designed to cope with bit errors without the decoder predictor state permanently remaining incorrect. Just packetising these formats so that packets consist of integer multiples of codec frames may not be optimal, as although the packet received immediately after a packet loss can be decoded, the start of the audio stream produced will be incorrect (and hence distort the signal) because the decoder predictor is now out of step with the encoder. In principle, all of the decoder's internal state could be added using a header attached to the start of every packet, but for lower bit-rate encodings, this state is so substantial that the bit rate is no longer low. However, a compromise can usually be found, where a greatly reduced form of decoder state is sent in every packet, which does not recreate the encoders predictor precisely, but does reduce the magnitude and duration of the distortion produced when the previous packet is lost. Such compressed state is, by definition, very dependent on the codec in question. Thus we recommend:
另外一条准则涉及要求解码器状态机与编码器状态机保持同步的编解码器。许多音频编解码器，如LPC或GSM就是这种形式。通常，它们具有损耗容限，在损耗后，预测系数衰减，因此在一定时间后，由损耗引起的预测误差将消失。大多数为电话服务设计的编解码器都是这种形式的，因为它们被设计用于处理位错误，而解码器预测器状态不会永久保持不正确。仅对这些格式进行打包以使数据包由编解码器帧的整数倍组成可能不是最优的，因为尽管在数据包丢失后立即接收的数据包可以被解码，但产生的音频流的开始将是不正确的（并因此使信号失真），因为解码器预测器现在与编码器不同步。原则上，解码器的所有内部状态都可以使用附加到每个分组开头的报头来添加，但是对于较低比特率编码，该状态非常重要，以至于比特率不再低。然而，通常可以找到折衷方案，其中在每个分组中发送大大减少形式的解码器状态，这不会精确地重新创建编码器预测器，但会减少前一分组丢失时产生的失真的幅度和持续时间。根据定义，这种压缩状态非常依赖于所讨论的编解码器。因此，我们建议：
+ Payload formats for encodings where the decoder contains internal data-driven state that attempts to track encoder state should normally consider including a small additional header that conveys the most critical elements of this state to reduce distortion after packet loss.
+ 编码的有效载荷格式，其中解码器包含试图跟踪编码器状态的内部数据驱动状态，通常应考虑包括一个小的附加报头，该报头传送该状态的最关键元素以减少分组丢失后的失真。
A similar issue arises with codec parameters, and whether or not they should be included in the payload format. An example is with a codec that has a choice of huffman tables for compression. The codec may use either huffman table 1 or table 2 for encoding and the receiver needs to know this information for correct decoding. There are a number of ways in which this kind of information can be conveyed:
编解码器参数以及它们是否应包含在有效负载格式中也会出现类似的问题。一个例子是一个编解码器，它可以选择哈夫曼表进行压缩。编解码器可以使用哈夫曼表1或表2进行编码，并且接收机需要知道该信息以进行正确解码。这类信息可以通过多种方式传达：
o Out of band signalling, prior to media transmission.
o 媒体传输前的带外信令。
o Out of band signalling, but the parameter can be changed mid-session. This requires synchronization of the change in the media stream.
o 带外信令，但参数可以在会话期间更改。这需要同步媒体流中的更改。
o The change is signaled through a change in the RTP payload type field. This requires mapping the parameter space into particular payload type values and signalling this mapping out-of-band prior to media transmission.
o 该更改通过RTP有效负载类型字段中的更改发出信号。这需要将参数空间映射为特定的有效负载类型值，并在媒体传输之前将此映射发送到带外。
o Including the parameter in the payload format. This allows for adapting the parameter in a robust manner, but makes the payload format less efficient.
o 在有效负载格式中包含参数。这允许以健壮的方式调整参数，但会降低有效负载格式的效率。
Which mechanism to use depends on the utility of changing the parameter in mid-session to support application layer adaptation. However, using out-of-band signalling to change a parameter in mid-session is generally to be discouraged due to the problem of synchronizing the parameter change with the media stream.
使用哪种机制取决于在会话中期更改参数以支持应用层自适应的效用。然而，由于参数更改与媒体流同步的问题，通常不鼓励在会话中期使用带外信令来更改参数。
Many RTP payload formats require some additional header information to be carried in addition to that included in the fixed RTP packet header. The recommended way of conveying this information is in the payload section of the packet. The RTP header extension should not be used to convey payload specific information ([9], section 5.3) since this is inefficient in its use of bandwidth; requires the definition of a new RTP profile or profile extension; and makes it difficult to employ FEC schemes such as, for example, [7]. Use of an RTP header extension is only appropriate for cases where the extension in question applies across a wide range of payload types.
许多RTP有效载荷格式要求在固定RTP数据包报头中包含的信息之外，还需要携带一些额外的报头信息。建议在数据包的有效负载部分传输此信息。RTP报头扩展不应用于传送特定于有效载荷的信息（[9]，第5.3节），因为这在带宽使用方面效率低下；需要定义新的RTP配置文件或配置文件扩展；并且使得使用FEC方案变得困难，例如[7]。RTP报头扩展的使用仅适用于所述扩展适用于各种有效负载类型的情况。
Designers of payload formats should also be aware of the needs of RTP header compression [1]. In particular, the compression algorithm functions best when the RTP timestamp increments by a constant value between consecutive packets. Payload formats which rely on sending packets out of order, such that the timestamp increment is not
有效负载格式的设计者还应该了解RTP报头压缩的需求[1]。特别是，当RTP时间戳在连续数据包之间以常量值递增时，压缩算法的功能最佳。依赖于无序发送数据包的有效负载格式，这样时间戳增量就不会增加
constant, are likely to compress less well than those which send packets in order. This has most often been an issue when designing payload formats for FEC information, although some video codecs also rely on out-of-order transmission of packets at the expense of reduced compression. Although in some cases such out-of-order transmission may be the best solution, payload format designers are encourage to look for alternative solutions where possible.
常数，则可能比按顺序发送数据包的压缩效果差。在为FEC信息设计有效载荷格式时，这通常是一个问题，尽管一些视频编解码器也依赖于以降低压缩为代价的无序数据包传输。尽管在某些情况下，这种无序传输可能是最好的解决方案，但鼓励有效负载格式设计师在可能的情况下寻找替代解决方案。
Designing packet formats for RTP is not a trivial task. Typically a detailed knowledge of the codec involved is required to be able to design a format that is resilient to loss, does not introduce loss magnification effects due to inappropriate packetisation, and does not introduce unnecessary distortion after a packet loss. We believe that considerable effort should be put into designing packet formats that are well tailored to the codec in question. Typically this requires a very small amount of processing at the sender and receiver, but the result can be greatly improved quality when operating in typical Internet environments.
为RTP设计数据包格式不是一项简单的任务。通常，需要对所涉及的编解码器有详细的了解，以便能够设计一种格式，该格式具有抗丢失的能力，不会由于不适当的分组而引入丢失放大效应，并且不会在分组丢失后引入不必要的失真。我们认为，在设计适合于所讨论的编解码器的数据包格式时，应该付出相当大的努力。通常，这需要在发送方和接收方进行非常少量的处理，但在典型的Internet环境中操作时，结果可以大大提高质量。
Designers of new codecs for use with RTP should consider making the output of the codec "naturally packetizable". This implies that the codec should be designed to produce a packet stream, rather than a bit-stream; and that that packet stream contains the minimal amount of redundancy necessary to ensure that each packet is independently decodable with minimal loss of decoder predictor tracking. It is recognised that sacrificing some small amount of bandwidth to ensure greater robustness to packet loss is often a worthwhile tradeoff.
与RTP一起使用的新编解码器的设计者应该考虑使编解码器的输出“自然可打包”。这意味着编解码器应设计为产生分组流，而不是比特流；并且该分组流包含确保每个分组独立可解码且解码器预测器跟踪损失最小所需的最小冗余量。人们认识到，牺牲少量带宽以确保对数据包丢失具有更大的鲁棒性通常是一个值得权衡的问题。
It is hoped that, in the long run, new codecs should be produced which can be directly packetised, without the trouble of designing a codec-specific payload format.
人们希望，从长远来看，应该生产出可以直接打包的新编解码器，而无需设计特定于编解码器的有效负载格式。
It is possible to design generic packetisation formats that do not pay attention to the issues described in this document, but such formats are only suitable for special purpose networks where packet loss can be avoided by careful engineering at the network layer, and are not suited to current best-effort networks.
可以设计不注意本文件中所述问题的通用分组格式，但此类格式仅适用于特殊用途网络，通过在网络层仔细设计可以避免分组丢失，并且不适用于当前尽力而为的网络。
The guidelines in this document result in RTP payload formats that are robust in the presence of real world network conditions. Designing payload formats for special purpose networks that assume negligable loss rates will normally result in slightly better compression, but produce formats that are more fragile, thus rendering them easier targets for denial-of-service attacks.
本文档中的指导原则产生了RTP有效负载格式，该格式在现实世界的网络条件下是健壮的。为特殊用途的网络设计负载格式（假定可忽略的丢失率）通常会导致稍微更好的压缩，但会产生更脆弱的格式，从而使它们更容易成为拒绝服务攻击的目标。
Designers of payload formats should pay close attention to possible security issues that might arise from poor implementations of their formats, and should be careful to specify the correct behaviour when anomalous conditions arise. Examples include how to process illegal field values, and conditions when there are mismatches between length fields and actual data. Whilst the correct action will normally be to discard the packet, possible such conditions should be brought to the attention of the implementor to ensure that they are trapped properly.
有效负载格式的设计者应密切关注可能因其格式的糟糕实现而产生的安全问题，并应小心指定异常情况出现时的正确行为。示例包括如何处理非法字段值，以及长度字段与实际数据不匹配时的情况。虽然正确的操作通常是丢弃数据包，但应提请实施者注意可能的此类情况，以确保它们被正确捕获。
The RTP specification covers encryption of the payload. This issue should not normally be dealt with by payload formats themselves. However, certain payload formats spread information about a particular application data unit over a number of packets, or rely on packets which relate to a number of application data units. Care must be taken when changing the encryption of such streams, since such payload formats may constrain the places in a stream where it is possible to change the encryption key without exposing sensitive data.
RTP规范涵盖有效负载的加密。此问题通常不应由有效负载格式本身处理。然而，某些有效载荷格式将关于特定应用数据单元的信息传播到多个分组上，或者依赖于与多个应用数据单元相关的分组。更改此类流的加密时必须小心，因为此类有效负载格式可能会限制流中可以更改加密密钥而不暴露敏感数据的位置。
Designers of payload formats which include FEC should be aware that the automatic addition of FEC in response to packet loss may increase network congestion, leading to a worsening of the problem which the use of FEC was intended to solve. Since this may, at its worst, constitute a denial of service attack, designers of such payload formats should take care that appropriate safeguards are in place to prevent abuse.
包括FEC的有效载荷格式的设计者应当意识到，响应于分组丢失而自动添加FEC可能会增加网络拥塞，从而导致使用FEC旨在解决的问题的恶化。由于这在最坏的情况下可能构成拒绝服务攻击，此类有效负载格式的设计者应注意采取适当的保护措施以防止滥用。
Authors' Addresses
作者地址
Mark Handley AT&T Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA
美国加利福尼亚州伯克利中心大街1947号中心街600室国际计算机科学研究所ICSI互联网研究中心马克·汉德利，邮编94704
EMail: mjh@aciri.org
EMail: mjh@aciri.org
Colin Perkins Dept of Computer Science, University College London, Gower Street, London WC1E 6BT, UK.
科林·珀金斯计算机科学系，伦敦大学学院，伦敦高尔街，WC1E 6BT，英国。
EMail: C.Perkins@cs.ucl.ac.uk
EMail: C.Perkins@cs.ucl.ac.uk
Acknowledgments
致谢
This document is based on experience gained over several years by many people, including Van Jacobson, Steve McCanne, Steve Casner, Henning Schulzrinne, Thierry Turletti, Jonathan Rosenberg and Christian Huitema amongst others.
本文件基于多年来许多人积累的经验，包括Van Jacobson、Steve McCanne、Steve Casner、Henning Schulzrinne、Thierry Turletti、Jonathan Rosenberg和Christian Huitema等。
References
工具书类
[1] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[1] Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[2] D. Clark and D. Tennenhouse, "Architectural Considerations for a New Generation of Network Protocols" Proc ACM Sigcomm 90.
[2] D.Clark和D.Tennenhouse，“新一代网络协议的架构考虑”，Proc ACM Sigcomm 90。
[3] J. Mahdavi and S. Floyd. "TCP-friendly unicast rate-based flow control". Note sent to end2end-interest mailing list, Jan 1997.
[3] 马赫达维和弗洛伊德。“TCP友好的基于速率的单播流量控制”。1997年1月发送至End2 End interest邮件列表的通知。
[4] M. Mathis, J. Semske, J. Mahdavi, and T. Ott. "The macro-scopic behavior of the TCP congestion avoidance algorithm". Computer Communication Review, 27(3), July 1997.
[4] M.Mathis、J.Semske、J.Mahdavi和T.Ott。“TCP拥塞避免算法的宏观行为”。《计算机通信评论》，第27（3）页，1997年7月。
[5] J. Nonnenmacher, E. Biersack, Don Towsley, "Parity-Based Loss Recovery for Reliable Multicast Transmission", Proc ACM Sigcomm
[5] J.Nonnenmacher，E.Biersack，Don Towsley，“用于可靠多播传输的基于奇偶校验的丢失恢复”，Proc ACM Sigcomm
[6] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", Proc. ACM Sigcomm 1998.
[6] J.Padhye，V.Firoiu，D.Towsley，J.Kurose，“TCP吞吐量建模：一个简单模型及其经验验证”，Proc。ACM Sigcomm 1998。
[7] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[7] 帕金斯，C.，库维拉斯，I.，霍德森，O.，哈德曼，V.，汉德利，M.，博洛，J.C.，维加·加西亚，A.和S.福斯·帕里斯，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[8] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[8] Ramakrishnan，K.和S.Floyd，“向IP添加明确拥塞通知（ECN）的提案”，RFC 2481，1999年1月。
[9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "Real-Time Transport Protocol", RFC 1889, January 1996.
[9] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“实时传输协议”，RFC 1889，1996年1月。
Full Copyright Statement
完整版权声明
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编辑功能的资金目前由互联网协会提供。