Network Working Group S. Casner
Request for Comments: 2508 Cisco Systems
Category: Standards Track V. Jacobson
Cisco Systems
February 1999
Network Working Group S. Casner
Request for Comments: 2508 Cisco Systems
Category: Standards Track V. Jacobson
Cisco Systems
February 1999
Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
压缩低速串行链路的IP/UDP/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 a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In many cases, all three headers can be compressed to 2-4 bytes.
本文档描述了一种压缩IP/UDP/RTP数据报报头以减少低速串行链路开销的方法。在许多情况下，所有三个头都可以压缩到2-4字节。
Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s).
征求意见，并将其发送至工作组邮件列表-conf@es.net和/或作者。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
Since the Real-time Transport Protocol was published as an RFC [1], there has been growing interest in using RTP as one step to achieve interoperability among different implementations of network audio/video applications. However, there is also concern that the 12-byte RTP header is too large an overhead for 20-byte payloads when operating over low speed lines such as dial-up modems at 14.4 or 28.8 kb/s. (Some existing applications operating in this environment use an application-specific protocol with a header of a few bytes that has reduced functionality relative to RTP.)
自从实时传输协议以RFC[1]的形式发布以来，人们对使用RTP作为实现网络音频/视频应用程序不同实现之间互操作性的一个步骤越来越感兴趣。然而，也有人担心，当以14.4或28.8 kb/s的速度在拨号调制解调器等低速线路上运行时，12字节RTP报头对于20字节的有效负载来说开销太大。（在此环境中运行的某些现有应用程序使用特定于应用程序的协议，该协议的标头为几个字节，与RTP相比功能有所降低。）
Header size may be reduced through compression techniques as has been done with great success for TCP [2]. In this case, compression might be applied to the RTP header alone, on an end-to-end basis, or to the combination of IP, UDP and RTP headers on a link-by-link basis. Compressing the 40 bytes of combined headers together provides substantially more gain than compressing 12 bytes of RTP header alone because the resulting size is approximately the same (2-4 bytes) in either case. Compressing on a link-by-link basis also provides better performance because the delay and loss rate are lower. Therefore, the method defined here is for combined compression of IP, UDP and RTP headers on a link-by-link basis.
头大小可以通过压缩技术来减小，这在TCP方面已经取得了巨大的成功[2]。在这种情况下，压缩可以在端到端的基础上单独应用于RTP报头，或者在逐个链路的基础上应用于IP、UDP和RTP报头的组合。将40个字节的组合报头压缩在一起比单独压缩12个字节的RTP报头提供更多的收益，因为在这两种情况下产生的大小大致相同（2-4个字节）。由于延迟和丢失率较低，因此逐链路压缩也提供了更好的性能。因此，这里定义的方法用于逐个链路地组合压缩IP、UDP和RTP报头。
This document defines a compression scheme that may be used with IPv4, IPv6 or packets encapsulated with more than one IP header, though the initial focus is on IPv4. The IP/UDP/RTP compression defined here is intended to fit within the more general compression framework specified in [3] for use with both IPv6 and IPv4. That framework defines TCP and non-TCP as two classes of transport above IP. This specification creates IP/UDP/RTP as a third class extracted from the non-TCP class.
本文档定义了一种可用于IPv4、IPv6或使用多个IP头封装的数据包的压缩方案，尽管最初的重点是IPv4。此处定义的IP/UDP/RTP压缩旨在适用于[3]中指定的更通用的压缩框架，用于IPv6和IPv4。该框架将TCP和非TCP定义为IP之上的两类传输。本规范将IP/UDP/RTP创建为从非TCP类提取的第三个类。
The goal of this compression scheme is to reduce the IP/UDP/RTP headers to two bytes for most packets in the case where no UDP checksums are being sent, or four bytes with checksums. It is motivated primarily by the specific problem of sending audio and video over 14.4 and 28.8 dialup modems. These links tend to provide full-duplex communication, so the protocol takes advantage of that fact, though the protocol may also be used with reduced performance on simplex links. This compression scheme performs best on local links with low round-trip-time.
此压缩方案的目标是在没有发送UDP校验和的情况下，将大多数数据包的IP/UDP/RTP报头减少到两个字节，或者将校验和减少到四个字节。其主要原因是通过14.4和28.8拨号调制解调器发送音频和视频的具体问题。这些链路倾向于提供全双工通信，因此该协议利用了这一事实，尽管在单工链路上使用该协议也可能降低性能。这种压缩方案在低往返时间的本地链路上表现最好。
This specification does not address segmentation and preemption of large packets to reduce the delay across the slow link experienced by small real-time packets, except to identify in Section 4 some interactions between segmentation and compression that may occur. Segmentation schemes may be defined separately and used in conjunction with the compression defined here.
本规范不涉及大数据包的分段和抢占，以减少小实时数据包在慢速链路上经历的延迟，除非在第4节中确定可能发生的分段和压缩之间的一些交互。分割方案可以单独定义，并与此处定义的压缩结合使用。
It should be noted that implementation simplicity is an important factor to consider in evaluating a compression scheme. Communications servers may need to support compression over perhaps as many as 100 dial-up modem lines using a single processor. Therefore, it may be appropriate to make some simplifications in the design at the expense of generality, or to produce a flexible design that is general but can be subsetted for simplicity. Higher compression gain might be achieved by communicating more complex
应该注意的是，实现简单性是评估压缩方案时考虑的重要因素。通信服务器可能需要使用单个处理器支持多达100条拨号调制解调器线路的压缩。因此，以牺牲通用性为代价对设计进行一些简化可能是合适的，或者产生一个通用但为了简单而可以细分的灵活设计。通过更复杂的通信可以实现更高的压缩增益
models for the changing header fields from the compressor to the decompressor, but that complexity is deemed unnecessary. The next sections discuss some of the tradeoffs listed here.
用于将标题字段从压缩器更改为解压缩器的模型，但这种复杂性被认为是不必要的。下一节将讨论此处列出的一些权衡。
In the absence of other constraints, a compression scheme that worked over simplex links would be preferred over one that did not. However, operation over a simplex link requires periodic refreshes with an uncompressed packet header to restore compression state in case of error. If an explicit error signal can be returned instead, the delay to recovery may be shortened substantially. The overhead in the no-error case is also reduced. To gain these performance improvements, this specification includes an explicit error indication sent on the reverse path.
在没有其他约束的情况下，在单工链路上工作的压缩方案将优于不工作的压缩方案。但是，单工链路上的操作需要使用未压缩的数据包头定期刷新，以在出现错误时恢复压缩状态。如果可以返回显式错误信号，则恢复延迟可以大大缩短。无错误情况下的开销也会减少。为了获得这些性能改进，本规范包括在反向路径上发送的显式错误指示。
On a simplex link, it would be possible to use a periodic refresh instead. Whenever the decompressor detected an error in a particular packet stream, it would simply discard all packets in that stream until an uncompressed header was received for that stream, and then resume decompression. The penalty would be the potentially large number of packets discarded. The periodic refresh method described in Section 3.3 of [3] applies to IP/UDP/RTP compression on simplex links or links with high delay as well as to other non-TCP packet streams.
在单工链路上，可以使用定期刷新。每当解压器在特定数据包流中检测到错误时，它将简单地丢弃该数据流中的所有数据包，直到收到该数据流的未压缩报头，然后恢复解压。惩罚是可能丢弃大量数据包。[3]第3.3节中描述的定期刷新方法适用于单工链路或高延迟链路上的IP/UDP/RTP压缩以及其他非TCP数据包流。
Delay induced by the time required to send a large packet over the slow link is not a problem for one-way audio, for example, because the receiver can adapt to the variance in delay. However, for interactive conversations, minimizing the end-to-end delay is critical. Segmentation of large, non-real-time packets to allow small real-time packets to be transmitted between segments can reduce the delay.
例如，通过慢速链路发送大数据包所需的时间引起的延迟对于单向音频来说不是问题，因为接收机可以适应延迟的变化。然而，对于交互式对话，最小化端到端延迟至关重要。对大型非实时数据包进行分段，以允许在段之间传输小型实时数据包，可以减少延迟。
This specification deals only with compression and assumes segmentation, if included, will be handled as a separate layer. It would be inappropriate to integrate segmentation and compression in such a way that the compression could not be used by itself in situations where segmentation was deemed unnecessary or impractical. Similarly, one would like to avoid any requirements for a reservation protocol. The compression scheme can be applied locally on the two ends of a link independent of any other mechanisms except for the requirements that the link layer provide some packet type codes, a packet length indication, and good error detection.
本规范仅涉及压缩，并假设分段（如果包括）将作为单独的层处理。以这样一种方式整合分割和压缩是不合适的，即在分割被认为是不必要或不可行的情况下，压缩本身无法使用。同样，人们希望避免对保留协议的任何要求。除了要求链路层提供一些分组类型码、分组长度指示和良好的错误检测之外，压缩方案可以独立于任何其他机制在链路的两端局部应用。
Conversely, separately compressing the IP/UDP and RTP layers loses too much of the compression gain that is possible by treating them together. Crossing these protocol layer boundaries is appropriate because the same function is being applied across all layers.
相反，单独压缩IP/UDP和RTP层会损失太多的压缩增益，而将它们一起处理可能会损失太多的压缩增益。跨越这些协议层边界是合适的，因为在所有层上应用相同的功能。
The compression algorithm defined in this document draws heavily upon the design of TCP/IP header compression as described in RFC 1144 [2]. Readers are referred to that RFC for more information on the underlying motivations and general principles of header compression.
本文档中定义的压缩算法在很大程度上借鉴了RFC 1144[2]中描述的TCP/IP报头压缩设计。读者可以参考RFC，了解更多有关头压缩的基本动机和一般原则的信息。
In TCP header compression, the first factor-of-two reduction in data rate comes from the observation that half of the bytes in the IP and TCP headers remain constant over the life of the connection. After sending the uncompressed header once, these fields may be elided from the compressed headers that follow. The remaining compression comes from differential coding on the changing fields to reduce their size, and from eliminating the changing fields entirely for common cases by calculating the changes from the length of the packet. This length is indicated by the link-level protocol.
在TCP报头压缩中，数据速率降低两个因素中的第一个因素是观察到IP和TCP报头中的一半字节在连接的生命周期内保持不变。在发送一次未压缩的报头后，这些字段可能会从随后的压缩报头中删除。剩余的压缩来自对变化字段进行差分编码以减小其大小，以及通过计算数据包长度的变化来完全消除常见情况下的变化字段。该长度由链路级协议指示。
For RTP header compression, some of the same techniques may be applied. However, the big gain comes from the observation that although several fields change in every packet, the difference from packet to packet is often constant and therefore the second-order difference is zero. By maintaining both the uncompressed header and the first-order differences in the session state shared between the compressor and decompressor, all that must be communicated is an indication that the second-order difference was zero. In that case, the decompressor can reconstruct the original header without any loss of information simply by adding the first-order differences to the saved uncompressed header as each compressed packet is received.
对于RTP报头压缩，可以应用一些相同的技术。然而，最大的收获来自于这样的观察：尽管每个数据包中有几个字段发生变化，但数据包之间的差异通常是恒定的，因此二阶差异为零。通过在压缩器和解压缩器之间共享的会话状态中保持未压缩的报头和一阶差，必须传达的只是二阶差为零的指示。在这种情况下，解压器仅通过在接收到每个压缩分组时向保存的未压缩报头添加一阶差分，就可以在不丢失任何信息的情况下重构原始报头。
Just as TCP/IP header compression maintains shared state for multiple simultaneous TCP connections, this IP/UDP/RTP compression SHOULD maintain state for multiple session contexts. A session context is defined by the combination of the IP source and destination addresses, the UDP source and destination ports, and the RTP SSRC field. A compressor implementation might use a hash function on these fields to index a table of stored session contexts. The compressed packet carries a small integer, called the session context identifier or CID, to indicate in which session context that packet should be interpreted. The decompressor can use the CID to index its table of stored session contexts directly.
正如TCP/IP报头压缩为多个同时TCP连接维护共享状态一样，此IP/UDP/RTP压缩应为多个会话上下文维护状态。会话上下文由IP源和目标地址、UDP源和目标端口以及RTP SSRC字段的组合定义。压缩器实现可以在这些字段上使用哈希函数来索引存储会话上下文的表。压缩数据包携带一个小整数，称为会话上下文标识符或CID，以指示应在哪个会话上下文中解释该数据包。解压器可以使用CID直接索引其存储的会话上下文表。
Because the RTP compression is lossless, it may be applied to any UDP traffic that benefits from it. Most likely, the only packets that will benefit are RTP packets, but it is acceptable to use heuristics to determine whether or not the packet is an RTP packet because no harm is done if the heuristic gives the wrong answer. This does require executing the compression algorithm for all UDP packets, or at least those with even port numbers (see section 3.4).
因为RTP压缩是无损的，所以它可以应用于任何受益于它的UDP通信。最有可能受益的数据包是RTP数据包，但使用启发式方法确定数据包是否为RTP数据包是可以接受的，因为如果启发式方法给出错误的答案，则不会造成伤害。这确实需要对所有UDP数据包执行压缩算法，或者至少对端口号为偶数的数据包执行压缩算法（请参见第3.4节）。
Most compressor implementations will need to maintain a "negative cache" of packet streams that have failed to compress as RTP packets for some number of attempts in order to avoid further attempts. Failing to compress means that some fields in the potential RTP header that are expected to remain constant most of the time, such as the payload type field, keep changing. Even if the other such fields remain constant, a packet stream with a constantly changing SSRC field SHOULD be entered in the negative cache to avoid consuming all of the available session contexts. The negative cache is indexed by the source and destination IP address and UDP port pairs but not the RTP SSRC field since the latter may be changing. When RTP compression fails, the IP and UDP headers MAY still be compressed.
大多数压缩器实现将需要维护一个包流的“负缓存”，该包流在一些尝试次数内未能压缩为RTP包，以避免进一步的尝试。未能压缩意味着潜在RTP报头中的某些字段（如有效负载类型字段）在大部分时间内保持不变，但这些字段会不断更改。即使其他此类字段保持不变，也应在负缓存中输入具有不断变化的SSRC字段的数据包流，以避免消耗所有可用会话上下文。负缓存由源和目标IP地址和UDP端口对索引，但不由RTP SSRC字段索引，因为后者可能正在更改。当RTP压缩失败时，IP和UDP报头仍可能被压缩。
Fragmented IP Packets that are not initial fragments and packets that are not long enough to contain a complete UDP header MUST NOT be sent as FULL_HEADER packets. Furthermore, packets that do not additionally contain at least 12 bytes of UDP data MUST NOT be used to establish RTP context. If such a packet is sent as a FULL_HEADER packet, it MAY be followed by COMPRESSED_UDP packets but MUST NOT be followed by COMPRESSED_RTP packets.
非初始片段的分段IP数据包和长度不足以包含完整UDP报头的数据包不得作为完整的_报头数据包发送。此外，不包含至少12字节UDP数据的数据包不得用于建立RTP上下文。如果此类数据包作为完整的_报头数据包发送，则其后面可以是压缩的_UDP数据包，但后面不能是压缩的_RTP数据包。
In the IPv4 header, only the total length, packet ID, and header check-sum fields will normally change. The total length is redundant with the length provided by the link layer, and since this compression scheme must depend upon the link layer to provide good error detection (e.g., PPP's CRC [4]), the header checksum may also be elided. This leaves only the packet ID, which, assuming no IP fragmentation, would not need to be communicated. However, in order to maintain lossless compression, changes in the packet ID will be transmitted. The packet ID usually increments by one or a small number for each packet. (Some systems increment the ID with the bytes swapped, which results in slightly less compression.) In the IPv6 base header, there is no packet ID nor header checksum and only the payload length field changes.
在IPv4报头中，通常只更改总长度、数据包ID和报头校验和字段。总长度与链路层提供的长度是冗余的，并且由于此压缩方案必须依赖于链路层以提供良好的错误检测（例如，PPP的CRC[4]），因此也可以省略报头校验和。这只留下数据包ID，假设没有IP碎片，则不需要进行通信。然而，为了保持无损压缩，将传输分组ID中的变化。对于每个数据包，数据包ID通常增加一个或一个小数字。（一些系统在交换字节时增加ID，这会导致压缩稍微减少。）在IPv6基本报头中，没有数据包ID或报头校验和，只有有效负载长度字段更改。
In the UDP header, the length field is redundant with the IP total length field and the length indicated by the link layer. The UDP check-sum field will be a constant zero if the source elects not to generate UDP checksums. Otherwise, the checksum must be communicated intact in order to preserve the lossless compression. Maintaining end-to-end error detection for applications that require it is an important principle.
在UDP报头中，长度字段与IP总长度字段和链路层指示的长度冗余。如果源选择不生成UDP校验和，则UDP校验和字段将为常量零。否则，为了保持无损压缩，校验和必须完整地通信。为需要端到端错误检测的应用程序维护端到端错误检测是一项重要原则。
In the RTP header, the SSRC identifier is constant in a given context since that is part of what identifies the particular context. For most packets, only the sequence number and the timestamp will change from packet to packet. If packets are not lost or misordered upstream from the compressor, the sequence number will increment by one for each packet. For audio packets of constant duration, the timestamp will increment by the number of sample periods conveyed in each packet. For video, the timestamp will change on the first packet of each frame, but then stay constant for any additional packets in the frame. If each video frame occupies only one packet, but the video frames are generated at a constant rate, then again the change in the timestamp from frame to frame is constant. Note that in each of these cases the second-order difference of the sequence number and timestamp fields is zero, so the next packet header can be constructed from the previous packet header by adding the first-order differences for these fields that are stored in the session context along with the previous uncompressed header. When the second-order difference is not zero, the magnitude of the change is usually much smaller than the full number of bits in the field, so the size can be reduced by encoding the new first-order difference and transmitting it rather than the absolute value.
在RTP报头中，SSRC标识符在给定上下文中是常量，因为这是标识特定上下文的一部分。对于大多数数据包，只有序列号和时间戳会随着数据包的变化而变化。如果数据包没有从压缩器上游丢失或顺序错误，则序列号将为每个数据包增加一个。对于持续时间恒定的音频数据包，时间戳将增加每个数据包中传输的采样周期数。对于视频，时间戳将在每个帧的第一个数据包上改变，但对于帧中的任何附加数据包，时间戳将保持不变。如果每个视频帧仅占用一个数据包，但视频帧以恒定速率生成，则帧与帧之间的时间戳变化也是恒定的。注意，在这些情况中的每一种情况下，序列号和时间戳字段的二阶差为零，因此可以通过将存储在会话上下文中的这些字段的一阶差与先前未压缩的报头相加，从先前的分组报头构造下一个分组报头。当二阶差不是零时，变化的幅度通常比字段中的完整位数小得多，因此可以通过编码新的一阶差并传输它而不是绝对值来减小大小。
The M bit will be set on the first packet of an audio talkspurt and the last packet of a video frame. If it were treated as a constant field such that each change required sending the full RTP header, this would reduce the compression significantly. Therefore, one bit in the compressed header will carry the M bit explicitly.
M位将设置在音频TalkSput的第一个数据包和视频帧的最后一个数据包上。如果将其视为一个常量字段，以便每次更改都需要发送完整的RTP报头，则会显著降低压缩。因此，压缩头中的一位将显式地携带M位。
If the packets are flowing through an RTP mixer, most commonly for audio, then the CSRC list and CC count will also change. However, the CSRC list will typically remain constant during a talkspurt or longer, so it need be sent only when it changes.
如果数据包通过RTP混音器（最常见的是音频混音器），则CSC列表和CC计数也将发生变化。然而，中国证监会名单通常会在一段或更长时间内保持不变，因此只有在发生变化时才需要发送。
The compression protocol must maintain a collection of shared information in a consistent state between the compressor and decompressor. There is a separate session context for each IP/UDP/RTP packet stream, as defined by a particular combination of the IP source and destination addresses, UDP source and destination
压缩协议必须在压缩器和解压缩器之间保持一致状态的共享信息集合。每个IP/UDP/RTP数据包流都有一个单独的会话上下文，由IP源地址和目标地址、UDP源地址和目标地址的特定组合定义
ports, and the RTP SSRC field. The number of session contexts to be maintained MAY be negotiated between the compressor and decompressor. Each context is identified by an 8- or 16-bit identifier, depending upon the number of contexts negotiated, so the maximum number is 65536. Both uncompressed and compressed packets MUST carry the context ID and a 4-bit sequence number used to detect packet loss between the compressor and decompressor. Each context has its own separate sequence number space so that a single packet loss need only invalidate one context.
端口和RTP SSRC字段。要维护的会话上下文的数量可以在压缩器和解压缩器之间协商。每个上下文由8位或16位标识符标识，具体取决于协商的上下文数量，因此最大数量为65536。未压缩和压缩的数据包都必须携带上下文ID和用于检测压缩器和解压缩器之间的数据包丢失的4位序列号。每个上下文都有自己独立的序列号空间，因此单个数据包丢失只需使一个上下文失效。
The shared information in each context consists of the following items:
每个上下文中的共享信息由以下项目组成：
o The full IP, UDP and RTP headers, possibly including a CSRC list, for the last packet sent by the compressor or reconstructed by the decompressor.
o 压缩器发送或解压器重构的最后一个数据包的完整IP、UDP和RTP报头，可能包括CSC列表。
o The first-order difference for the IPv4 ID field, initialized to 1 whenever an uncompressed IP header for this context is received and updated each time a delta IPv4 ID field is received in a compressed packet.
o IPv4 ID字段的一阶差，每当接收到此上下文的未压缩IP报头时初始化为1，并在每次压缩数据包中接收到增量IPv4 ID字段时更新。
o The first-order difference for the RTP timestamp field, initialized to 0 whenever an uncompressed packet for this context is received and updated each time a delta RTP timestamp field is received in a compressed packet.
o RTP时间戳字段的一阶差，每当接收到此上下文的未压缩数据包时初始化为0，并在压缩数据包中每次接收增量RTP时间戳字段时更新。
o The last value of the 4-bit sequence number, which is used to detect packet loss between the compressor and decompressor.
o 4位序列号的最后一个值，用于检测压缩器和解压缩器之间的数据包丢失。
o The current generation number for non-differential coding of UDP packets with IPv6 (see [3]). For IPv4, the generation number may be set to zero if the COMPRESSED_NON_TCP packet type, defined below, is never used.
o 使用IPv6对UDP数据包进行非差分编码的当前代数（请参见[3]）。对于IPv4，如果从未使用下面定义的压缩非TCP数据包类型，则生成号可能设置为零。
o A context-specific delta encoding table (see section 3.3.4) may optionally be negotiated for each context.
o 可以选择为每个上下文协商特定于上下文的增量编码表（见第3.3.4节）。
In order to communicate packets in the various uncompressed and compressed forms, this protocol depends upon the link layer being able to provide an indication of four new packet formats in addition to the normal IPv4 and IPv6 packet formats:
为了以各种未压缩和压缩形式传输数据包，此协议取决于链路层是否能够提供除正常IPv4和IPv6数据包格式之外的四种新数据包格式的指示：
FULL_HEADER - communicates the uncompressed IP header plus any following headers and data to establish the uncompressed header state in the decompressor for a particular context. The FULL-HEADER packet also carries the 8- or 16-bit session context identifier and the 4-bit sequence number to establish
FULL_HEADER-将未压缩的IP标头加上任何以下标头和数据进行通信，以在特定上下文的解压器中建立未压缩标头状态。全报头数据包还携带8位或16位会话上下文标识符和要建立的4位序列号
synchronization between the compressor and decompressor. The format is shown in section 3.3.1.
压缩机和减压器之间的同步。格式见第3.3.1节。
COMPRESSED_UDP - communicates the IP and UDP headers compressed to 6 or fewer bytes (often 2 if UDP checksums are disabled), followed by any subsequent headers (possibly RTP) in uncompressed form, plus data. This packet type is used when there are differences in the usually constant fields of the (potential) RTP header. The RTP header includes a potentially changed value of the SSRC field, so this packet may redefine the session context. The format is shown in section 3.3.3.
COMPRESSED_UDP-将IP和UDP报头压缩到6个或更少字节（如果禁用UDP校验和，则通常为2个字节），然后以未压缩形式发送任何后续报头（可能是RTP）以及数据。当（潜在）RTP报头的通常常量字段存在差异时，使用此数据包类型。RTP报头包含可能更改的SSRC字段值，因此此数据包可能会重新定义会话上下文。格式见第3.3.3节。
COMPRESSED_RTP - indicates that the RTP header is compressed along with the IP and UDP headers. The size of this header may still be just two bytes, or more if differences must be communicated. This packet type is used when the second-order difference (at least in the usually constant fields) is zero. It includes delta encodings for those fields that have changed by other than the expected amount to establish the first-order differences after an uncompressed RTP header is sent and whenever they change. The format is shown in section 3.3.2.
COMPRESSED_RTP-表示RTP标头与IP和UDP标头一起被压缩。此标头的大小可能仍然只有两个字节，如果必须传递差异，则大小可能会更大。当二阶差（至少在通常恒定的字段中）为零时，使用此数据包类型。它包括那些字段的增量编码，这些字段在发送未压缩的RTP报头后以及在发生更改时发生了更改，以建立一阶差异。格式见第3.3.2节。
CONTEXT_STATE - indicates a special packet sent from the decompressor to the compressor to communicate a list of context IDs for which synchronization has or may have been lost. This packet is only sent across the point-to-point link so it requires no IP header. The format is shown in section 3.3.5.
CONTEXT_STATE-表示从解压器发送到压缩器的特殊数据包，用于传递已丢失或可能已丢失同步的上下文ID列表。此数据包仅通过点到点链路发送，因此不需要IP报头。格式见第3.3.5节。
When this compression scheme is used with IPv6 as part of the general header compression framework specified in [3], another packet type MAY be used:
当此压缩方案作为[3]中指定的通用报头压缩框架的一部分与IPv6一起使用时，可以使用另一种数据包类型：
COMPRESSED_NON_TCP - communicates the compressed IP and UDP headers as defined in [3] without differential encoding. If it were used for IPv4, it would require one or two bytes more than the COMPRESSED_UDP form listed above in order to carry the IPv4 ID field. For IPv6, there is no ID field and this non-differential compression is more resilient to packet loss.
COMPRESSED_NON_TCP-按照[3]中的定义，在不使用差分编码的情况下通信压缩的IP和UDP报头。如果它用于IPv4，则需要比上面列出的压缩的UDP表单多一个或两个字节才能携带IPv4 ID字段。对于IPv6，没有ID字段，这种非差分压缩对数据包丢失更具弹性。
Assignments of numeric codes for these packet formats in the Point-to-Point Protocol [4] are to be made by the Internet Assigned Numbers Authority.
在点到点协议[4]中，这些数据包格式的数字代码的分配由互联网分配号码管理局进行。
The definition of the FULL_HEADER packet given here is intended to be the consistent with the definition given in [3]. Full details on design choices are given there.
此处给出的完整_头数据包的定义旨在与[3]中给出的定义一致。关于设计选择的全部细节在这里给出。
The format of the FULL_HEADER packet is the same as that of the original packet. In the IPv4 case, this is usually an IP header, followed by a UDP header and UDP payload that may be an RTP header and its payload. However, the FULL_HEADER packet may also carry IP encapsulated packets, in which case there would be two IP headers followed by UDP and possibly RTP. Or in the case of IPv6, the packet may be built of some combination of IPv6 and IPv4 headers. Each successive header is indicated by the type field of the previous header, as usual.
完整_头数据包的格式与原始数据包的格式相同。在IPv4情况下，这通常是一个IP报头，然后是UDP报头和UDP有效负载，可能是RTP报头及其有效负载。然而，完整的_报头数据包也可能携带IP封装的数据包，在这种情况下，将有两个IP报头后跟UDP，可能还有RTP。或者在IPv6的情况下，数据包可以由IPv6和IPv4报头的某种组合构建。与往常一样，每个连续的标头由前一个标头的类型字段指示。
The FULL_HEADER packet differs from the corresponding normal IPv4 or IPv6 packet in that it must also carry the compression context ID and the 4-bit sequence number. In order to avoid expanding the size of the header, these values are inserted into length fields in the IP and UDP headers since the actual length may be inferred from the length provided by the link layer. Two 16-bit length fields are needed; these are taken from the first two available headers in the packet. That is, for an IPv4/UDP packet, the first length field is the total length field of the IPv4 header, and the second is the length field of the UDP header. For an IPv4 encapsulated packet, the first length field would come from the total length field of the first IP header, and the second length field would come from the total length field of the second IP header.
完整_头数据包与相应的正常IPv4或IPv6数据包的不同之处在于，它还必须携带压缩上下文ID和4位序列号。为了避免扩展报头的大小，这些值被插入到IP和UDP报头的长度字段中，因为实际长度可以从链路层提供的长度推断出来。需要两个16位长度字段；这些数据来自数据包中的前两个可用头。也就是说，对于IPv4/UDP数据包，第一个长度字段是IPv4报头的总长度字段，第二个是UDP报头的长度字段。对于IPv4封装的数据包，第一个长度字段将来自第一个IP报头的总长度字段，第二个长度字段将来自第二个IP报头的总长度字段。
As specified in Sections 5.3.2 of [3], the position of the context ID (CID) and 4-bit sequence number varies depending upon whether 8- or 16-bit context IDs have been selected, as shown in the following diagram (16 bits wide, with the most-significant bit is to the left):
如[3]第5.3.2节所述，上下文ID（CID）和4位序列号的位置取决于选择的是8位还是16位上下文ID，如下图所示（16位宽，最高有效位在左侧）：
For 8-bit context ID:
对于8位上下文ID：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Generation| CID | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Generation| CID | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | seq | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | seq | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For 16-bit context ID:
对于16位上下文ID：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Generation| 0 | seq | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Generation| 0 | seq | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first bit in the first length field indicates the length of the CID. The length of the CID MUST either be constant for all contexts or two additional distinct packet types MUST be provided to separately indicate COMPRESSED_UDP and COMPRESSED_RTP packet formats with 8- and 16-bit CIDs. The second bit in the first length field is 1 to indicate that the 4-bit sequence number is present, as is always the case for this IP/UDP/RTP compression scheme.
第一个长度字段中的第一位表示CID的长度。对于所有上下文，CID的长度必须是恒定的，或者必须提供两种额外的不同数据包类型，以分别指示具有8位和16位CID的压缩_UDP和压缩_RTP数据包格式。第一个长度字段中的第二位是1，表示存在4位序列号，这与此IP/UDP/RTP压缩方案的情况相同。
The generation field is used with IPv6 for COMPRESSED_NON_TCP packets as described in [3]. For IPv4-only implementations that do not use COMPRESSED_NON_TCP packets, the compressor SHOULD set the generation value to zero. For consistent operation between IPv4 and IPv6, the generation value is stored in the context when it is received by the decompressor, and the most recent value is returned in the CONTEXT_STATE packet.
生成字段与IPv6一起用于压缩的\u非\u TCP数据包，如[3]所述。对于不使用压缩的非TCP数据包的仅IPv4实现，压缩器应将生成值设置为零。对于IPv4和IPv6之间的一致操作，当解压器接收到生成值时，生成值将存储在上下文中，最新的值将在上下文状态数据包中返回。
When a FULL_HEADER packet is received, the complete set of headers is stored into the context selected by the context ID. The 4-bit sequence number is also stored in the context, thereby resynchronizing the decompressor to the compressor.
当接收到完整的头数据包时，完整的头数据集存储在由上下文ID选择的上下文中。4位序列号也存储在上下文中，从而将解压器与压缩器重新同步。
When COMPRESSED_NON_TCP packets are used, the 4-bit sequence number is inserted into the "Data Field" of that packet and the D bit is set as described in Section 6 of [3]. When a COMPRESSED_NON_TCP packet is received, the generation number is compared to the value stored in the context. If they are not the same, the context is not up to date and MUST be refreshed by a FULL_HEADER packet. If the generation does match, then the compressed IP and UDP header information, the 4-bit sequence number, and the (potential) RTP header are all stored into the saved context.
当使用压缩的非TCP数据包时，将4位序列号插入该数据包的“数据字段”，并按照[3]第6节所述设置D位。当接收到压缩的\u非\u TCP数据包时，将生成编号与存储在上下文中的值进行比较。如果它们不相同，则上下文不是最新的，必须通过完整的_头数据包刷新。如果生成不匹配，则压缩的IP和UDP头信息、4位序列号和（可能的）RTP头都存储到保存的上下文中。
The amount of memory required to store the context will vary depending upon how many encapsulating headers are included in the FULL_HEADER packet. The compressor and decompressor MAY negotiate a maximum header size.
存储上下文所需的内存量将根据完整_头数据包中包含的封装头数量而有所不同。压缩机和减压器可协商最大割台尺寸。
When the second-order difference of the RTP header from packet to packet is zero, the decompressor can reconstruct a packet simply by adding the stored first-order differences to the stored uncompressed header representing the previous packet. All that need be communicated is the session context identifier and a small sequence number (not related to the RTP sequence number) to maintain synchronization and detect packet loss between the compressor and decompressor.
当分组之间的RTP报头的二阶差为零时，解压器可以简单地通过将存储的一阶差添加到表示先前分组的存储的未压缩报头来重构分组。需要传达的只是会话上下文标识符和一个小序列号（与RTP序列号无关），以保持同步并检测压缩器和解压缩器之间的数据包丢失。
If the second-order difference of the RTP header is not zero for some fields, the new first-order difference for just those fields is communicated using a compact encoding. The new first-order difference values are added to the corresponding fields in the uncompressed header in the decompressor's session context, and are also stored explicitly in the context to be added to the corresponding fields again on each subsequent packet in which the second-order difference is zero. Each time the first-order difference changes, it is transmitted and stored in the context.
如果某些字段的RTP报头的二阶差不是零，则仅这些字段的新一阶差使用压缩编码进行通信。新的一阶差值被添加到解压器会话上下文中未压缩报头中的相应字段中，并且还显式存储在上下文中，以便在二阶差值为零的每个后续数据包上再次添加到相应字段。每次一阶差分发生变化时，它都会被传输并存储在上下文中。
In practice, the only fields for which it is useful to store the first-order difference are the IPv4 ID field and the RTP timestamp. For the RTP sequence number field, the usual increment is 1. If the sequence number changes by other than 1, the difference must be communicated but does not set the expected difference for the next packet. Instead, the expected first-order difference remains fixed at 1 so that the difference need not be explicitly communicated on the next packet assuming it is in order.
实际上，存储一阶差有用的唯一字段是IPv4 ID字段和RTP时间戳。对于RTP序列号字段，通常的增量为1。如果序列号的变化不是1，则必须传递差异，但不设置下一个数据包的预期差异。相反，预期的一阶差保持固定在1，以便在假定下一个分组是有序的情况下，不需要在下一个分组上显式地传递该差。
For the RTP timestamp, when a FULL_HEADER, COMPRESSED_NON_TCP or COMPRESSED_UDP packet is sent to refresh the RTP state, the stored first-order difference is initialized to zero. If the timestamp is the same on the next packet (e.g., same video frame), then the second-order difference is zero. Otherwise, the difference between the timestamps of the two packets is transmitted as the new first-order difference to be added to the timestamp in the uncompressed header stored in the decompressor's context and also stored as the first-order difference in that context. Each time the first-order difference changes on subsequent packets, that difference is again transmitted and used to update the context.
对于RTP时间戳，当发送完整的\u头、压缩的\u非\u TCP或压缩的\u UDP数据包以刷新RTP状态时，存储的一阶差初始化为零。如果时间戳在下一个分组上相同（例如，相同的视频帧），则二阶差为零。否则，两个分组的时间戳之间的差作为要添加到解压器上下文中存储的未压缩报头中的时间戳的新的一阶差被发送，并且还作为该上下文中的一阶差被存储。每次后续数据包上的一阶差变化时，该差再次被传输并用于更新上下文。
Similarly, since the IPv4 ID field frequently increments by one, the first-order difference for that field is initialized to one when the state is refreshed by a FULL_HEADER packet, or when a COMPRESSED_NON_TCP packet is sent since it carries the ID field in uncompressed form. Thereafter, whenever the first-order difference changes, it is transmitted and stored in the context.
类似地，由于IPv4 ID字段经常递增1，当状态由完整的\u头数据包刷新时，或者当发送压缩的\u非\u TCP数据包时，该字段的一阶差初始化为1，因为它以未压缩的形式携带ID字段。此后，每当一阶差分改变时，它被传输并存储在上下文中。
A bit mask will be used to indicate which fields have changed by other than the expected difference. In addition to the small link sequence number, the list of items to be conditionally communicated in the compressed IP/UDP/RTP header is as follows:
位掩码将用于指示哪些字段的更改超出了预期的差异。除了小链路序列号外，在压缩IP/UDP/RTP报头中有条件地通信的项目列表如下：
I = IPv4 packet ID (always 0 if no IPv4 header) U = UDP checksum M = RTP marker bit S = RTP sequence number T = RTP timestamp L = RTP CSRC count and list
I=IPv4数据包ID（如果没有IPv4标头，则始终为0）U=UDP校验和M=RTP标记位S=RTP序列号T=RTP时间戳L=RTP CSC计数和列表
If 4 bits are needed for the link sequence number to get a reasonable probability of loss detection, there are too few bits remaining to assign one bit to each of these items and still fit them all into a single byte to go along with the context ID.
如果链路序列号需要4位以获得合理的丢失检测概率，则剩余的位太少，无法将一位分配给这些项中的每一项，并且仍然将它们全部放入一个字节中，以便与上下文ID一起使用。
It is not necessary to explicitly carry the U bit to indicate the presence of the UDP checksum because a source will typically include check-sums on all packets of a session or none of them. When the session state is initialized with an uncompressed header, if there is a nonzero checksum present, an unencoded 16-bit checksum will be inserted into the compressed header in all subsequent packets until this setting is changed by sending another uncompressed packet.
不需要显式地携带U位来指示UDP校验和的存在，因为源通常会在会话的所有数据包上包含校验和，或者不包含任何数据包。当使用未压缩的报头初始化会话状态时，如果存在非零校验和，则未编码的16位校验和将插入所有后续数据包中的压缩报头，直到通过发送另一个未压缩数据包更改此设置为止。
Of the remaining items, the L bit for the CSRC count and list may be the one least frequently used. Rather than dedicating a bit in the mask to indicate CSRC change, an unusual combination of the other bits may be used instead. This bit combination is denoted MSTI. If all four of the bits for the IP packet ID, RTP marker bit, RTP sequence number and RTP timestamp are set, this is a special case indicating an extended form of the compressed RTP header will follow. That header will include an additional byte containing the real values of the four bits plus the CC count. The CSRC list, of length indicated by the CC count, will be included just as it appears in the uncompressed RTP header.
在其余项目中，中国证监会计数和列表的L位可能是使用频率最低的一个。可以使用其他位的不寻常组合，而不是在掩码中指定一位来指示CSC变化。该位组合表示为MSTI。如果设置了IP分组ID、RTP标记位、RTP序列号和RTP时间戳的所有四个位，则这是一种特殊情况，表明压缩RTP报头的扩展形式将随之出现。该报头将包含一个额外的字节，其中包含四位的实际值加上CC计数。由CC计数指示长度的CSC列表将包括在未压缩RTP标题中。
The other fields of the RTP header (version, P bit, X bit, payload type and SSRC identifier) are assumed to remain relatively constant. In particular, the SSRC identifier is defined to be constant for a given context because it is one of the factors selecting the context. If any of the other fields change, the uncompressed RTP header MUST sent as described in Section 3.3.3.
RTP报头的其他字段（版本、P位、X位、有效负载类型和SSRC标识符）假定保持相对恒定。特别是，SSRC标识符被定义为给定上下文的常量，因为它是选择上下文的因素之一。如果任何其他字段发生变化，则必须按照第3.3.3节所述发送未压缩RTP报头。
The following diagram shows the compressed IP/UDP/RTP header with dotted lines indicating fields that are conditionally present. The most significant bit is numbered 0. Multi-byte fields are sent in network byte order (most significant byte first). The delta fields are often a single byte as shown but may be two or three bytes depending upon the delta value as explained in Section 3.3.4.
下图显示了压缩的IP/UDP/RTP报头，虚线表示有条件存在的字段。最高有效位编号为0。多字节字段按网络字节顺序发送（最高有效字节优先）。增量字段通常为单字节，如图所示，但可能为两个或三个字节，具体取决于第3.3.4节中解释的增量值。
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+---+---+---+---+---+---+---+---+
| M | S | T | I | link sequence |
+---+---+---+---+---+---+---+---+
: :
+ UDP checksum + (if nonzero in context)
: :
+...............................+
: :
+ "RANDOM" fields + (if encapsulated)
: :
+...............................+
: M'| S'| T'| I'| CC : (if MSTI = 1111)
+...............................+
: delta IPv4 ID : (if I or I' = 1)
+...............................+
: delta RTP sequence : (if S or S' = 1)
+...............................+
: delta RTP timestamp : (if T or T' = 1)
+...............................+
: :
: CSRC list : (if MSTI = 1111
: : and CC nonzero)
: :
+...............................+
: :
: RTP header extension : (if X set in context)
: :
: :
+-------------------------------+
| |
| RTP data |
/ /
/ /
| |
+-------------------------------+
: padding : (if P set in context)
+...............................+
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+---+---+---+---+---+---+---+---+
| M | S | T | I | link sequence |
+---+---+---+---+---+---+---+---+
: :
+ UDP checksum + (if nonzero in context)
: :
+...............................+
: :
+ "RANDOM" fields + (if encapsulated)
: :
+...............................+
: M'| S'| T'| I'| CC : (if MSTI = 1111)
+...............................+
: delta IPv4 ID : (if I or I' = 1)
+...............................+
: delta RTP sequence : (if S or S' = 1)
+...............................+
: delta RTP timestamp : (if T or T' = 1)
+...............................+
: :
: CSRC list : (if MSTI = 1111
: : and CC nonzero)
: :
+...............................+
: :
: RTP header extension : (if X set in context)
: :
: :
+-------------------------------+
| |
| RTP data |
/ /
/ /
| |
+-------------------------------+
: padding : (if P set in context)
+...............................+
When more than one IPv4 header is present in the context as initialized by the FULL_HEADER packet, then the IP ID fields of encapsulating headers MUST be sent as absolute values as described in
当上下文中存在多个由完整_头数据包初始化的IPv4头时，封装头的IP ID字段必须作为绝对值发送，如中所述
[3]. These fields are identified as "RANDOM" fields. They are inserted into the COMPRESSED_RTP packet in the same order as they appear in the original headers, immediately following the UDP checksum if present or the MSTI byte if not, as shown in the diagram. Only if an IPv4 packet immediately precedes the UDP header will the IP ID of that header be sent differentially, i.e., potentially with no bits if the second difference is zero, or as a delta IPv4 ID field if not. If there is not an IPv4 header immediately preceding the UDP header, then the I bit MUST be 0 and no delta IPv4 ID field will be present.
[3]. 这些字段被标识为“随机”字段。如图所示，它们以与原始头中出现的顺序相同的顺序插入到压缩的_RTP数据包中，紧跟在UDP校验和（如果存在）或MSTI字节（如果不存在）之后。只有当IPv4数据包紧跟在UDP报头之前时，该报头的IP ID才会有差异地发送，即，如果第二个差异为零，则可能没有比特，如果不是，则作为增量IPv4 ID字段发送。如果UDP报头前面没有IPv4报头，则I位必须为0，并且不存在增量IPv4 ID字段。
If there is a change in any of the fields of the RTP header that are normally constant (such as the payload type field), then an uncompressed RTP header MUST be sent. If the IP and UDP headers do not also require updating, this RTP header MAY be carried in a COMPRESSED_UDP packet rather than a FULL_HEADER packet. The COMPRESSED_UDP packet has the same format as the COMPRESSED_RTP packet except that the M, S and T bits are always 0 and the corresponding delta fields are never included:
如果RTP报头的任何字段（如有效负载类型字段）发生了变化，则必须发送未压缩的RTP报头。如果IP和UDP报头也不需要更新，则此RTP报头可以在压缩的_UDP数据包而不是完整的_报头数据包中携带。压缩的_UDP数据包的格式与压缩的_RTP数据包的格式相同，只是M、S和T位始终为0，并且不包括相应的增量字段：
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | I | link sequence |
+---+---+---+---+---+---+---+---+
: :
+ UDP checksum + (if nonzero in context)
: :
+...............................+
: :
+ "RANDOM" fields + (if encapsulated)
: :
+...............................+
: delta IPv4 ID : (if I = 1)
+-------------------------------+
| UDP data |
: (uncompressed RTP header) :
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | I | link sequence |
+---+---+---+---+---+---+---+---+
: :
+ UDP checksum + (if nonzero in context)
: :
+...............................+
: :
+ "RANDOM" fields + (if encapsulated)
: :
+...............................+
: delta IPv4 ID : (if I = 1)
+-------------------------------+
| UDP data |
: (uncompressed RTP header) :
Note that this constitutes a form of IP/UDP header compression different from COMPRESSED_NON_TCP packet type defined in [3]. The motivation is to allow reaching the target of two bytes when UDP checksums are disabled, as IPv4 allows. The protocol in [3] does not use differential coding for UDP packets, so in the IPv4 case, two
注意，这构成了一种不同于[3]中定义的压缩的非TCP数据包类型的IP/UDP报头压缩形式。其动机是允许在禁用UDP校验和时达到两个字节的目标，就像IPv4允许的那样。[3]中的协议不对UDP数据包使用差分编码，因此在IPv4情况下，两个
bytes of IP ID, and two bytes of UDP checksum if nonzero, would always be transmitted in addition to two bytes of compression prefix. For IPv6, the COMPRESSED_NON_TCP packet type MAY be used instead.
除了两个字节的压缩前缀外，还将始终传输两个字节的IP ID和两个字节的UDP校验和（如果不为零）。对于IPv6，可以使用压缩的非TCP数据包类型。
The delta fields in the COMPRESSED_RTP and COMPRESSED_UDP packets are encoded with a variable-length mapping for compactness of the more commonly-used values. A default encoding is specified below, but it is RECOMMENDED that implementations use a table-driven delta encoder and decoder to allow negotiation of a table specific for each session if appropriate, possibly even an optimal Huffman encoding. Encodings based on sequential interpretation of the bit stream, of which this default table and Huffman encoding are examples, allow a reasonable table size and may result in an execution speed faster than a non-table-driven implementation with explicit tests for ranges of values.
压缩的_RTP和压缩的_UDP数据包中的增量字段使用可变长度映射进行编码，以实现更常用值的紧凑性。下面指定了默认编码，但建议实现使用表驱动的增量编码器和解码器，以便在适当的情况下允许协商特定于每个会话的表，甚至可能是最佳的哈夫曼编码。基于比特流的顺序解释的编码（此默认表和哈夫曼编码为示例）允许合理的表大小，并且可能导致执行速度快于具有显式值范围测试的非表驱动实现。
The default delta encoding is specified in the following table. This encoding was designed to efficiently encode the small changes that may occur in the IP ID and in RTP sequence number when packets are lost upstream from the compressor, yet still handling most audio and video deltas in two bytes. The column on the left is the decimal value to be encoded, and the column on the right is the resulting sequence of bytes shown in hexadecimal and in the order in which they are transmitted (network byte order). The first and last values in each contiguous range are shown, with ellipses in between:
下表中指定了默认增量编码。当数据包从压缩器上游丢失时，该编码被设计为有效地编码IP ID和RTP序列号中可能发生的微小变化，但仍然以两个字节处理大多数音频和视频增量。左边的一列是要编码的十进制值，右边的一列是以十六进制显示的字节结果序列以及它们的传输顺序（网络字节顺序）。显示每个连续范围中的第一个和最后一个值，中间有省略号：
Decimal Hex
十进制十六进制
-16384 C0 00 00
: :
-129 C0 3F 7F
-128 80 00
: :
-1 80 7F
0 00
: :
127 7F
128 80 80
: :
16383 BF FF
16384 C0 40 00
: :
4194303 FF FF FF
-16384 C0 00 00
: :
-129 C0 3F 7F
-128 80 00
: :
-1 80 7F
0 00
: :
127 7F
128 80 80
: :
16383 BF FF
16384 C0 40 00
: :
4194303 FF FF FF
For positive values, a change of zero through 127 is represented directly in one byte. If the most significant two bits of the byte are 10 or 11, this signals an extension to a two- or three-byte
对于正值，零到127的变化直接用一个字节表示。如果字节的最高有效位为10或11，则表示扩展为2或3字节
value, respectively. The least significant six bits of the first byte are combined, in decreasing order of significance, with the next one or two bytes to form a 14- or 22-bit value.
值，分别为。第一个字节的最低有效六位按重要性降序与下一个或两个字节组合，形成14位或22位值。
Negative deltas may occur when packets are misordered or in the intentionally out-of-order RTP timestamps on MPEG video [5]. These events are less likely, so a smaller range of negative values is encoded using otherwise redundant portions of the positive part of the table.
当数据包顺序错误或在MPEG视频上的RTP时间戳故意乱序时，可能会出现负增量[5]。这些事件不太可能发生，因此使用表中其他冗余部分对较小范围的负值进行编码。
A change in the RTP timestamp value less than -16384 or greater than 4194303 forces the RTP header to be sent uncompressed using a FULL_HEADER, COMPRESSED_NON_TCP or COMPRESSED_UDP packet type. The IP ID and RTP sequence number fields are only 16 bits, so negative deltas for those fields SHOULD be masked to 16 bits and then encoded (as large positive 16-bit numbers).
RTP时间戳值的更改小于-16384或大于4194303将强制使用完整的\u头、压缩的\u非\u TCP或压缩的\u UDP数据包类型以未压缩的方式发送RTP头。IP ID和RTP序列号字段只有16位，因此这些字段的负增量应屏蔽为16位，然后进行编码（作为大的正16位数字）。
Whenever the 4-bit sequence number for a particular context increments by other than 1, except when set by a FULL_HEADER or COMPRESSED_NON_TCP packet, the decompressor MUST invalidate that context and send a CONTEXT_STATE packet back to the compressor indicating that the context has been invalidated. All packets for the invalid context MUST be discarded until a FULL_HEADER or COMPRESSED_NON_TCP packet is received for that context to re-establish consistent state (unless the "twice" algorithm is used as described later in this section). Since multiple compressed packets may arrive in the interim, the decompressor SHOULD NOT retransmit the CONTEXT_STATE packet for every compressed packet received, but instead SHOULD limit the rate of retransmission to avoid flooding the reverse channel.
每当特定上下文的4位序列号增加1以外的值时（由完整的\u头或压缩的\u非\u TCP数据包设置时除外），解压器必须使该上下文无效，并将一个上下文状态数据包发送回压缩器，指示该上下文已无效。必须丢弃无效上下文的所有数据包，直到接收到该上下文的完整\u头或压缩\u非\u TCP数据包以重新建立一致状态（除非如本节后面所述使用“两次”算法）。由于多个压缩包可能会在这段时间内到达，因此解压器不应该为接收到的每个压缩包重新传输上下文状态包，而是应该限制重新传输的速率，以避免淹没反向信道。
When an error occurs on the link, the link layer will usually discard the packet that was damaged (if any), but may provide an indication of the error. Some time may elapse before another packet is delivered for the same context, and then that packet would have to be discarded by the decompressor when it is observed to be out of sequence, resulting in at least two packets lost. To allow faster recovery if the link does provide an explicit error indication, the decompressor MAY optionally send an advisory CONTEXT_STATE packet listing the last valid sequence number and generation number for one or more recently active contexts (not necessarily all). For a given context, if the compressor has sent no compressed packet with a higher sequence number, and if the generation number matches the current generation, no corrective action is required. Otherwise, the compressor MAY choose to mark the context invalid so that the next packet is sent in FULL_HEADER or COMPRESSED_NON_TCP mode (FULL_HEADER
当链路上发生错误时，链路层通常会丢弃损坏的数据包（如果有），但可能会提供错误指示。在为同一上下文传递另一个包之前可能会经过一段时间，然后，当发现该包的顺序不正确时，解压缩程序必须丢弃该包，从而导致至少两个包丢失。为了在链路确实提供显式错误指示的情况下允许更快的恢复，解压器可以选择性地发送咨询上下文状态包，其中列出一个或多个最近活动上下文（不一定全部）的最后有效序列号和生成号。对于给定的上下文，如果压缩器未发送具有更高序列号的压缩数据包，并且如果生成号与当前生成匹配，则无需采取纠正措施。否则，压缩器可能会选择将上下文标记为无效，以便下一个数据包以完整\u头或压缩\u非\u TCP模式（完整\u头）发送
is required if the generation doesn't match). However, note that if the link round-trip-time is large compared to the inter-packet spacing, there may be several packets from multiple contexts in flight across the link, increasing the probability that the sequence numbers will already have advanced when the CONTEXT_STATE packet is received by the compressor. The result could be that some contexts are invalidated unnecessarily, causing extra bandwidth to be consumed.
如果生成不匹配，则需要）。然而，注意，如果链路往返时间与分组间间隔相比较大，则可能有来自多个上下文的多个分组在链路上飞行，这增加了当压缩器接收到上下文状态分组时序列号已经提前的概率。结果可能是一些上下文不必要地无效，导致额外的带宽被消耗。
The format of the CONTEXT_STATE packet is shown in the following diagrams. The first byte is a type code to allow the CONTEXT_STATE packet type to be shared by multiple compression schemes within the general compression framework specified in [3]. The contents of the remainder of the packet depends upon the compression scheme. For the IP/UDP/RTP compression scheme specified here, the remainder of the CONTEXT_STATE packet is structured as a list of blocks to allow the state for multiple contexts to be indicated, preceded by a one-byte count of the number of blocks.
上下文状态数据包的格式如下图所示。第一个字节是一种类型代码，允许[3]中规定的通用压缩框架内的多个压缩方案共享上下文状态数据包类型。数据包其余部分的内容取决于压缩方案。对于此处指定的IP/UDP/RTP压缩方案，CONTEXT_STATE数据包的其余部分被构造为块列表，以允许指示多个上下文的状态，前面是块数的一个字节计数。
Two type code values are used for the IP/UDP/RTP compression scheme. The value 1 indicates that 8-bit session context IDs are being used:
IP/UDP/RTP压缩方案使用两个类型代码值。值1表示正在使用8位会话上下文ID：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 = IP/UDP/RTP with 8-bit CID |
+---+---+---+---+---+---+---+---+
| context count |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| session context ID |
+---+---+---+---+---+---+---+---+
| I | 0 | 0 | 0 | sequence |
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
...
+---+---+---+---+---+---+---+---+
| session context ID |
+---+---+---+---+---+---+---+---+
| I | 0 | 0 | 0 | sequence |
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 = IP/UDP/RTP with 8-bit CID |
+---+---+---+---+---+---+---+---+
| context count |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| session context ID |
+---+---+---+---+---+---+---+---+
| I | 0 | 0 | 0 | sequence |
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
...
+---+---+---+---+---+---+---+---+
| session context ID |
+---+---+---+---+---+---+---+---+
| I | 0 | 0 | 0 | sequence |
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
The value 2 indicates that 16-bit session context IDs are being used. The session context ID is sent in network byte order (most significant byte first):
值2表示正在使用16位会话上下文ID。会话上下文ID按网络字节顺序发送（最高有效字节优先）：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 2 = IP/UDP/RTP with 16-bit CID|
+---+---+---+---+---+---+---+---+
| context count |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| |
+ session context ID +
| |
+---+---+---+---+---+---+---+---+
| I | 0 | 0 | 0 | sequence |
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
...
+---+---+---+---+---+---+---+---+
| |
+ session context ID +
| |
+---+---+---+---+---+---+---+---+
| I | 0 | 0 | 0 | sequence |
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 2 = IP/UDP/RTP with 16-bit CID|
+---+---+---+---+---+---+---+---+
| context count |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| |
+ session context ID +
| |
+---+---+---+---+---+---+---+---+
| I | 0 | 0 | 0 | sequence |
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
...
+---+---+---+---+---+---+---+---+
| |
+ session context ID +
| |
+---+---+---+---+---+---+---+---+
| I | 0 | 0 | 0 | sequence |
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
The bit labeled "I" is set to one for contexts that have been marked invalid and require a FULL_HEADER of COMPRESSED_NON_TCP packet to be transmitted. If the I bit is zero, the context state is advisory. The I bit is set to zero to indicate advisory context state that MAY be sent following a link error indication.
标记为“I”的位被设置为1，用于标记为无效的上下文，并且需要传输压缩的\u非\u TCP数据包的完整\u头。如果I位为零，则上下文状态为advisory。I位设置为零，以指示在链路错误指示之后可能发送的通知上下文状态。
Since the CONTEXT_STATE packet itself may be lost, retransmission of one or more blocks is allowed. It is expected that retransmission will be triggered only by receipt of another packet, but if the line is near idle, retransmission MAY be triggered by a relatively long timer (on the order of 1 second).
由于上下文状态包本身可能丢失，因此允许重新传输一个或多个块。预计只有在接收到另一个数据包时才会触发重传，但如果线路接近空闲，则可通过相对较长的计时器（大约1秒）触发重传。
If a CONTEXT_STATE block for a given context is retransmitted, it may cross paths with the FULL_HEADER or COMPRESSED_NON_TCP packet intended to refresh that context. In that case, the compressor MAY choose to ignore the error indication.
如果重新传输给定上下文的上下文\状态块，它可能会与用于刷新该上下文的完整\头或压缩\非\ TCP数据包交叉。在这种情况下，压缩机可选择忽略错误指示。
In the case where UDP checksums are being transmitted, the decompressor MAY attempt to use the "twice" algorithm described in section 10.1 of [3]. In this algorithm, the delta is applied more than once on the assumption that the delta may have been the same on the missing packet(s) and the one subsequently received. Success is
在传输UDP校验和的情况下，解压器可尝试使用[3]第10.1节所述的“两次”算法。在该算法中，基于丢失的分组和随后接收的分组上的增量可能相同的假设，多次应用增量。成功是
indicated by a checksum match. For the scheme defined here, the difference in the 4- bit sequence number tells number of times the delta must be applied. Note, however, that there is a nontrivial risk of an incorrect positive indication. It may be advisable to request a FULL_HEADER or COMPRESSED_NON_TCP packet even if the "twice" algorithm succeeds.
由校验和匹配指示。对于这里定义的方案，4位序列号中的差异表示必须应用增量的次数。然而，请注意，存在不正确阳性指示的非平凡风险。即使“两次”算法成功，也可以请求完整的\u头或压缩的\u非\u TCP数据包。
Some errors may not be detected, for example if 16 packets are lost in a row and the link level does not provide an error indication. In that case, the decompressor will generate packets that are not valid. If UDP checksums are being transmitted, the receiver will probably detect the invalid packets and discard them, but the receiver does not have any means to signal the decompressor. Therefore, it is RECOMMENDED that the decompressor verify the UDP checksum periodically, perhaps one out of 16 packets. If an error is detected, the decompressor would invalidate the context and signal the compressor with a CONTEXT_STATE packet.
某些错误可能无法检测到，例如，如果一行中有16个数据包丢失，并且链路级别没有提供错误指示。在这种情况下，解压缩程序将生成无效的数据包。如果正在传输UDP校验和，接收器可能会检测到无效数据包并丢弃它们，但接收器没有任何方法向解压缩器发送信号。因此，建议解压缩程序定期验证UDP校验和，可能是16个数据包中的一个。如果检测到错误，解压器将使上下文无效，并向压缩器发送一个context_状态数据包。
By relying on the RTP convention that data is carried on an even port number and the corresponding RTCP packets are carried on the next higher (odd) port number, one could tailor separate compression schemes to be applied to RTP and RTCP packets. For RTCP, the compression could apply not only to the header but also the "data", that is, the contents of the different packet types. The numbers in Sender Report (SR) and Receiver Report (RR) RTCP packets would not compress well, but the text information in the Source Description (SDES) packets could be compressed down to a bit mask indicating each item that was present but compressed out (for timing purposes on the SDES NOTE item and to allow the end system to measure the average RTCP packet size for the interval calculation).
通过依靠RTP约定，即数据在偶数端口号上传输，而相应的RTCP数据包在下一个更高（奇数）端口号上传输，可以定制适用于RTP和RTCP数据包的单独压缩方案。对于RTCP，压缩不仅可以应用于报头，还可以应用于“数据”，即不同数据包类型的内容。发送方报告（SR）和接收方报告（RR）RTCP数据包中的数字不会得到很好的压缩，但源描述（SDES）数据包中的文本信息可以压缩到一个位掩码，表示存在但被压缩掉的每个项（用于SDES注释项上的计时目的，并允许终端系统测量用于间隔计算的平均RTCP数据包大小）。
However, in the compression scheme defined here, no compression will be done on the RTCP headers and "data" for several reasons (though compression SHOULD still be applied to the IP and UDP headers). Since the RTP protocol specification suggests that the RTCP packet interval be scaled so that the aggregate RTCP bandwidth used by all participants in a session will be no more than 5% of the session bandwidth, there is not much to be gained from RTCP compression. Compressing out the SDES items would require a significant increase in the shared state that must be stored for each context ID. And, in order to allow compression when SDES information for several sources was sent through an RTP "mixer", it would be necessary to maintain a separate RTCP session context for each SSRC identifier. In a session with more than 255 participants, this would cause perfect thrashing of the context cache even when only one participant was sending data.
但是，在此处定义的压缩方案中，由于多种原因，不会对RTCP头和“数据”进行压缩（尽管压缩仍应应用于IP和UDP头）。由于RTP协议规范建议调整RTCP数据包间隔，以便会话中所有参与者使用的RTCP总带宽不超过会话带宽的5%，因此RTCP压缩不会带来太多好处。压缩SDES项目将需要显著增加必须为每个上下文ID存储的共享状态。并且，为了在通过RTP“混合器”发送多个源的SDES信息时允许压缩，有必要为每个SSRC标识符维护单独的RTCP会话上下文。在一个参与者超过255人的会话中，即使只有一个参与者在发送数据，这也会导致上下文缓存的彻底抖动。
Even though RTCP is not compressed, the fraction of the total bandwidth occupied by RTCP packets on the compressed link remains no more than 5% in most cases, assuming that the RTCP packets are sent as COMPRESSED_UDP packets. Given that the uncompressed RTCP traffic consumes no more than 5% of the total session bandwidth, then for a typical RTCP packet length of 90 bytes, the portion of the compressed bandwidth used by RTCP will be no more than 5% if the size of the payload in RTP data packets is at least 108 bytes. If the size of the RTP data payload is smaller, the fraction will increase, but is still less than 7% for a payload size of 37 bytes. For large data payloads, the compressed RTCP fraction is less than the uncompressed RTCP fraction (for example, 4% at 1000 bytes).
即使RTCP未被压缩，但在大多数情况下，假设RTCP数据包作为压缩的UDP数据包发送，压缩链路上RTCP数据包占用的总带宽份额仍不超过5%。假设未压缩的RTCP流量消耗的会话带宽不超过总带宽的5%，那么对于90字节的典型RTCP数据包长度，如果RTP数据包中的有效负载大小至少为108字节，则RTCP使用的压缩带宽部分将不超过5%。如果RTP数据有效负载的大小较小，则分数将增加，但对于37字节的有效负载大小，分数仍然小于7%。对于大数据有效负载，压缩的RTCP分数小于未压缩的RTCP分数（例如，1000字节时为4%）。
As described earlier, the COMPRESSED_UDP packet MAY be used to compress UDP packets that don't carry RTP. Whatever data follows the UDP header is unlikely to have some constant values in the bits that correspond to usually constant fields in the RTP header. In particular, the SSRC field would likely change. Therefore, it is necessary to keep track of the non-RTP UDP packet streams to avoid using up all the context slots as the "SSRC field" changes (since that field is part of what identifies a particular RTP context). Those streams may each be given a context, but the encoder would set a flag in the context to indicate that the changing SSRC field should be ignored and COMPRESSED_UDP packets should always be sent instead of COMPRESSED_RTP packets.
如前所述，压缩的UDP分组可用于压缩不携带RTP的UDP分组。UDP报头后面的任何数据都不可能在与RTP报头中通常为常量的字段相对应的位中具有某些常量值。特别是，SSRC字段可能会发生变化。因此，有必要跟踪非RTP UDP数据包流，以避免在“SSRC字段”更改时耗尽所有上下文插槽（因为该字段是标识特定RTP上下文的一部分）。这些流可能每个都有一个上下文，但编码器将在上下文中设置一个标志，以指示应忽略不断变化的SSRC字段，并且应始终发送压缩的_UDP数据包，而不是压缩的_RTP数据包。
A segmentation scheme may be used in conjunction with RTP header compression to allow small, real-time packets to interrupt large, presumably non-real-time packets in order to reduce delay. It is assumed that the large packets bypass the compressor and decompressor since the interleaving would modify the sequencing of packets at the decompressor and cause the appearance of errors. Header compression should be less important for large packets since the overhead ratio is smaller.
分段方案可与RTP报头压缩结合使用，以允许小的实时分组中断大的，可能是非实时分组以减少延迟。假设大数据包绕过压缩器和解压缩器，因为交织将修改解压缩器中数据包的顺序，并导致出现错误。对于大数据包，报头压缩应该不那么重要，因为开销比较小。
If some packets from an RTP session context are selected for segmentation (perhaps based on size) and some are not, there is a possibility of re-ordering. This would reduce the compression efficiency because the large packets would appear as lost packets in the sequence space. However, this should not cause more serious problems because the RTP sequence numbers should be reconstructed correctly and will allow the application to correct the ordering.
如果从RTP会话上下文中选择了一些数据包进行分段（可能基于大小），而没有选择，则可能会重新排序。这将降低压缩效率，因为大数据包将在序列空间中显示为丢失的数据包。但是，这不应导致更严重的问题，因为RTP序列号应正确重建，并允许应用程序更正顺序。
Link errors detected by the segmentation scheme using its own sequencing information MAY be indicated to the compressor with an advisory CONTEXT_STATE message just as for link errors detected by the link layer itself.
分段方案使用其自身的序列信息检测到的链路错误可以与链路层本身检测到的链路错误一样，用咨询上下文_状态消息指示给压缩器。
The context ID byte is placed first in the COMPRESSED_RTP header so that this byte MAY be shared with the segmentation layer if such sharing is feasible and has been negotiated. Since the compressor may assign context ID values arbitrarily, the value can be set to match the context identifier from the segmentation layer.
上下文ID字节首先放在压缩的\u RTP报头中，这样，如果这种共享是可行的，并且已经协商，则可以与分段层共享该字节。由于压缩器可以任意分配上下文ID值，因此可以将该值设置为与来自分段层的上下文标识符匹配。
The use of IP/UDP/RTP compression over a particular link is a function of the link-layer protocol. It is expected that such negotiation will be defined separately for PPP [4], for example. The following items MAY be negotiated:
在特定链路上使用IP/UDP/RTP压缩是链路层协议的一项功能。例如，预计PPP[4]将单独定义此类协商。可就下列项目进行谈判：
o The size of the context ID. o The maximum size of the stack of headers in the context. o A context-specific table for decoding of delta values.
o 上下文ID的大小。o上下文中头堆栈的最大大小。o用于解码增量值的上下文特定表。
Several people have contributed to the design of this compression scheme and related problems. Scott Petrack initiated discussion of RTP header compression in the AVT working group at Los Angeles in March, 1996. Carsten Bormann has developed an overall architecture for compression in combination with traffic control across a low-speed link, and made several specific contributions to the scheme described here. David Oran independently developed a note based on similar ideas, and suggested the use of PPP Multilink protocol for segmentation. Mikael Degermark has contributed advice on integration of this compression scheme with the IPv6 compression framework.
一些人对这种压缩方案的设计和相关问题做出了贡献。Scott Petrack于1996年3月在洛杉矶的AVT工作组中发起了RTP报头压缩的讨论。卡斯滕·鲍曼（Carsten Bormann）已经开发了一个整体架构，将压缩与低速链路上的流量控制相结合，并对本文描述的方案做出了一些具体贡献。David Oran基于类似的想法独立开发了一个注释，并建议使用PPP多链路协议进行分段。Mikael Degermark就将此压缩方案与IPv6压缩框架集成提供了建议。
7. References:
7. 参考资料：
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for real-time applications", RFC 1889, January 1996.
[1] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[2] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links", RFC 1144, February 1990.
[2] Jacobson，V.，“低速串行链路的TCP/IP压缩”，RFC 1144，1990年2月。
[3] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for IPv6", RFC 2507, February 1999.
[3] Degermark，M.，Nordgren，B.和S.Pink，“IPv6的头压缩”，RFC 2507，1999年2月。
[4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[4] 辛普森，W.，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[5] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[5] Hoffman，D.，Fernando，G.，Goyal，V.和M.Civanlar，“MPEG1/MPEG2视频的RTP有效载荷格式”，RFC 2250，1998年1月。
Because encryption eliminates the redundancy that this compression scheme tries to exploit, there is some inducement to forego encryption in order to achieve operation over a low-bandwidth link. However, for those cases where encryption of data and not headers is satisfactory, RTP does specify an alternative encryption method in which only the RTP payload is encrypted and the headers are left in the clear. That would allow compression to still be applied.
由于加密消除了此压缩方案试图利用的冗余，因此有一些诱因导致放弃加密以实现在低带宽链路上的操作。然而，对于数据加密而非报头加密令人满意的情况，RTP确实指定了一种替代加密方法，其中仅对RTP有效负载进行加密，报头保留在空白处。这将允许仍然应用压缩。
A malfunctioning or malicious compressor could cause the decompressor to reconstitute packets that do not match the original packets but still have valid IP, UDP and RTP headers and possibly even valid UDP check-sums. Such corruption may be detected with end-to-end authentication and integrity mechanisms which will not be affected by the compression. Constant portions of authentication headers will be compressed as described in [3].
发生故障或恶意压缩程序可能会导致解压缩程序重新生成与原始数据包不匹配但仍具有有效IP、UDP和RTP头，甚至可能具有有效UDP校验和的数据包。这种损坏可以通过端到端身份验证和完整性机制进行检测，而不会受到压缩的影响。身份验证头的常量部分将按[3]中所述进行压缩。
No authentication is performed on the CONTEXT_STATE control packet sent by this protocol. An attacker with access to the link between the decompressor and compressor could inject false CONTEXT_STATE packets and cause compression efficiency to be reduced, probably resulting in congestion on the link. However, an attacker with access to the link could also disrupt the traffic in many other ways.
不在此协议发送的上下文状态控制数据包上执行身份验证。访问解压器和压缩器之间链路的攻击者可能会注入错误的上下文状态数据包，并导致压缩效率降低，可能导致链路拥塞。但是，具有链接访问权限的攻击者还可以通过许多其他方式中断通信。
A potential denial-of-service threat exists when using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decompress and cause the receiver to be overloaded and degrading processing of other streams. However, this compression
使用具有非均匀接收端计算负载的压缩技术时，存在潜在的拒绝服务威胁。攻击者可以向流中注入病理数据报，这些数据报很难解压，并导致接收器过载和降低对其他流的处理。然而，这种压缩
does not exhibit any significant non-uniformity.
不表现出任何显著的不均匀性。
A security review of this protocol found no additional security considerations.
对该协议的安全审查未发现其他安全注意事项。
Stephen L. Casner Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 United States
Stephen L.Casner Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
EMail: casner@cisco.com
EMail: casner@cisco.com
Van Jacobson Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 United States
Van Jacobson Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
EMail: van@cisco.com
EMail: van@cisco.com
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。