Network Working Group T. Koren
Request for Comments: 3545 Cisco Systems
Category: Standards Track S. Casner
Packet Design
J. Geevarghese
Motorola India Electronics Ltd.
B. Thompson
P. Ruddy
Cisco Systems
July 2003
Network Working Group T. Koren
Request for Comments: 3545 Cisco Systems
Category: Standards Track S. Casner
Packet Design
J. Geevarghese
Motorola India Electronics Ltd.
B. Thompson
P. Ruddy
Cisco Systems
July 2003
Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering
针对高延迟、丢包和重排序链路的增强压缩RTP（CRTP）
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays.
本文档描述了一种用于具有丢包和长延迟的点到点链路的报头压缩方案。它基于压缩实时传输协议（CRTP），即RFC2508中描述的IP/UDP/RTP报头压缩。CRTP在这样的链路上表现不佳：数据包丢失会导致上下文损坏，并且由于长延迟，在修复上下文之前会丢弃更多的数据包。为了纠正CRTP在这些链路上的行为，这里指定了对协议的一些扩展。这些扩展旨在通过更改压缩器在解压器处更新上下文的方式来减少上下文损坏：重复更新并包括对完整和差异上下文参数的更新。通过这些扩展，CRTP在丢包、重排序和长延迟的链路上表现良好。
Table of Contents
目录
1. Introduction ................................................. 2
1.1. CRTP Operation ......................................... 4
1.2. How do contexts get corrupted? ......................... 4
1.3. Preventing context corruption .......................... 5
1.4. Specification of Requirements .......................... 5
2. Enhanced CRTP ................................................ 5
2.1. Extended COMPRESSED_UDP packet ......................... 6
2.2. CRTP Headers Checksum .................................. 11
2.3. Achieving robust operation ............................. 13
2.3.1. Examples ....................................... 15
3. Negotiating usage of enhanced-CRTP ........................... 18
4. Security Considerations ...................................... 18
5. Acknowledgements ............................................. 19
6. References ................................................... 19
6.1. Normative References ................................... 19
6.2. Informative References ................................. 20
7. Intellectual Property Rights Notice .......................... 20
8. Authors' Addresses ........................................... 21
9. Full Copyright Statement ..................................... 22
1. Introduction ................................................. 2
1.1. CRTP Operation ......................................... 4
1.2. How do contexts get corrupted? ......................... 4
1.3. Preventing context corruption .......................... 5
1.4. Specification of Requirements .......................... 5
2. Enhanced CRTP ................................................ 5
2.1. Extended COMPRESSED_UDP packet ......................... 6
2.2. CRTP Headers Checksum .................................. 11
2.3. Achieving robust operation ............................. 13
2.3.1. Examples ....................................... 15
3. Negotiating usage of enhanced-CRTP ........................... 18
4. Security Considerations ...................................... 18
5. Acknowledgements ............................................. 19
6. References ................................................... 19
6.1. Normative References ................................... 19
6.2. Informative References ................................. 20
7. Intellectual Property Rights Notice .......................... 20
8. Authors' Addresses ........................................... 21
9. Full Copyright Statement ..................................... 22
RTP header compression (CRTP) as described in RFC 2508 was designed to reduce the header overhead of IP/UDP/RTP datagrams by compressing the three headers. The IP/UDP/RTP headers are compressed to 2-4 bytes most of the time.
RFC2508中描述的RTP报头压缩（CRTP）旨在通过压缩三个报头来减少IP/UDP/RTP数据报的报头开销。IP/UDP/RTP报头大部分时间压缩为2-4字节。
CRTP was designed for reliable point to point links with short delays. It does not perform well over links with high rate of packet loss, packet reordering and long delays.
CRTP设计用于具有短延迟的可靠点对点链路。它在数据包丢失率高、数据包重新排序和长延迟的链路上性能不佳。
An example of such a link is a PPP session that is tunneled using an IP level tunneling protocol such as L2TP. Packets within the tunnel are carried by an IP network and hence may get lost and reordered. The longer the tunnel, the longer the round trip time.
这种链路的一个示例是使用诸如L2TP之类的IP级隧道协议进行隧道传输的PPP会话。隧道内的数据包由IP网络承载，因此可能丢失并重新排序。隧道越长，往返时间越长。
Another example is an IP network that uses layer 2 technologies such as ATM and Frame Relay for the access portion of the network. Layer 2 transport networks such as ATM and Frame Relay behave like point to point serial links in that they do not reorder packets. In addition, Frame Relay and ATM virtual circuits used as IP access technologies often have a low bit rate associated with them. These virtual circuits differ from low speed serial links in that they may span a larger physical distance than a point to point serial link. Speed of light delays within the layer 2 transport network will result in higher round trip delays between the endpoints of the circuit. In
另一个例子是IP网络，它使用第2层技术，例如ATM和帧中继，用于网络的接入部分。第2层传输网络（如ATM和帧中继）的行为类似于点对点串行链路，因为它们不会对数据包重新排序。此外，用作IP接入技术的帧中继和ATM虚拟电路通常具有低比特率。这些虚拟电路与低速串行链路的不同之处在于，它们可能跨越比点对点串行链路更大的物理距离。第2层传输网络内的光速延迟将导致电路端点之间更高的往返延迟。在里面
addition, congestion within the layer 2 transport network may result in an effective drop rate for the virtual circuit which is significantly higher than error rates typically experienced on point to point serial links.
此外，第2层传输网络内的拥塞可能导致虚拟电路的有效丢弃率显著高于点对点串行链路上通常经历的错误率。
It may be desirable to extend existing CRTP implementations for use also over IP tunnels and other virtual circuits, where packet losses, reordering, and long delays are common characteristics. To address these scenarios, this document defines modifications and extensions to CRTP to increase robustness to both packet loss and misordering between the compressor and the decompressor. This is achieved by repeating updates and allowing the sending of absolute (uncompressed) values in addition to delta values for selected context parameters. Although these new mechanisms impose some additional overhead, the overall compression is still substantial. The enhanced CRTP, as defined in this document, is thus suitable for many applications in the scenarios discussed above, e.g., tunneling and other virtual circuits.
可能需要扩展现有CRTP实现，以便也在IP隧道和其他虚拟电路上使用，其中丢包、重新排序和长延迟是常见的特征。为了解决这些情况，本文档定义了对CRTP的修改和扩展，以增强对压缩器和解压缩器之间的数据包丢失和错误排序的鲁棒性。这是通过重复更新并允许发送绝对（未压缩）值以及选定上下文参数的增量值来实现的。尽管这些新机制会带来一些额外的开销，但总体压缩仍然很大。因此，本文件中定义的增强型CRTP适用于上述场景中的许多应用，例如隧道和其他虚拟电路。
RFC 3095 defines another RTP header compression scheme called Robust Header Compression [ROHC]. ROHC was developed with wireless links as the main target, and introduced new compression mechanisms with the primary objective to achieve the combination of robustness against packet loss and maximal compression efficiency. ROHC is expected to be the preferred compression mechanism over links where compression efficiency is important. However, ROHC was designed with the same link assumptions as CRTP, e.g., that the compression scheme should not have to tolerate misordering of compressed packets between the compressor and decompressor, which may occur when packets are carried in an IP tunnel across multiple hops.
RFC3095定义了另一种RTP报头压缩方案，称为鲁棒报头压缩[ROHC]。ROHC是以无线链路为主要目标开发的，并引入了新的压缩机制，其主要目标是实现对数据包丢失的鲁棒性和最大压缩效率的结合。在压缩效率非常重要的链路上，ROHC有望成为首选的压缩机制。然而，ROHC的设计采用了与CRTP相同的链路假设，例如，压缩方案不应容忍压缩包在压缩器和解压缩器之间的错序，这可能发生在包在IP隧道中跨多个跃点传输时。
At some time in the future, enhancements may be defined for ROHC to allow it to perform well in the presence of misordering of compressed packets. The result might be more efficient than the compression protocol specified in this document. However, there are many environments for which the enhanced CRTP defined here may be the preferred choice. In particular, for those environments where CRTP is already implemented, the additional effort required to implement the extensions defined here is expected to be small. There are also cases where the implementation simplicity of this enhanced CRTP relative to ROHC is more important than the performance advantages of ROHC.
在将来的某个时候，可能会为ROHC定义增强功能，以允许它在出现压缩数据包的错误排序时表现良好。结果可能比本文档中指定的压缩协议更有效。但是，在许多环境中，此处定义的增强型CRTP可能是首选。特别是，对于那些已经实现了CRTP的环境，实现这里定义的扩展所需的额外工作量预计很小。在某些情况下，这种增强型CRTP相对于ROHC的实现简单性比ROHC的性能优势更为重要。
During compression of an RTP stream, a session context is defined. For each context, the session state is established and shared between the compressor and the decompressor. Once the context state is established, compressed packets may be sent.
在RTP流的压缩过程中，定义了会话上下文。对于每个上下文，会话状态在压缩器和解压缩器之间建立和共享。一旦建立了上下文状态，就可以发送压缩包。
The context state consists of the full IP/UDP/RTP headers, a few first order differential values, a link sequence number, a generation number and a delta encoding table.
上下文状态由完整的IP/UDP/RTP头、几个一阶差分值、链接序列号、生成号和增量编码表组成。
The headers part of the context is set by the FULL_HEADER packet that always starts a compression session. The first order differential values (delta values) are set by sending COMPRESSED_RTP packets that include updates to the delta values.
上下文的头部分由始终启动压缩会话的完整_头数据包设置。通过发送包含增量值更新的压缩RTP数据包来设置一阶差分值（增量值）。
The context state must be synchronized between compressor and decompressor for successful decompression to take place. If the context gets out of sync, the decompressor is not able to restore the compressed headers accurately. The decompressor invalidates the context and sends a CONTEXT_STATE packet to the compressor indicating that the context has been corrupted. To resume compression, the compressor must re-establish the context.
为了成功进行解压缩，必须在压缩器和解压缩器之间同步上下文状态。如果上下文不同步，则解压缩程序无法准确恢复压缩的头。解压器使上下文无效，并向压缩器发送一个context_STATE数据包，指示上下文已损坏。要恢复压缩，压缩器必须重新建立上下文。
During the time the context is corrupted, the decompressor discards all the packets received for that context. Since the context repair mechanism in CRTP involves feedback from the decompressor, context repair takes at least as much time as the round trip time of the link. If the round trip time of the link is long, and especially if the link bandwidth is high, many packets will be discarded before the context is repaired. On such links it is desirable to minimize context invalidation.
在上下文损坏期间，解压缩程序将丢弃为该上下文接收的所有数据包。由于CRTP中的上下文修复机制涉及来自解压器的反馈，因此上下文修复所花费的时间至少与链路的往返时间相同。如果链路的往返时间长，尤其是链路带宽高，在修复上下文之前，许多数据包将被丢弃。在这样的链接上，希望最小化上下文失效。
As long as the fields in the combined IP/UDP/RTP headers change as expected for the sequence of packets in a session, those headers can be compressed, and the decompressor can fully restore the compressed headers using the context state. When the headers don't change as expected it's necessary to update some of the full or the delta values of the context. For example, the RTP timestamp is expected to increment by delta RTP timestamp (dT). If silence suppression is used, packets are not sent during silence periods. Then when voice activity resumes, packets are sent again, but the RTP timestamp is incremented by a large value and not by dT. In this case an update must be sent.
只要组合IP/UDP/RTP报头中的字段按照会话中数据包序列的预期变化，这些报头就可以被压缩，解压器可以使用上下文状态完全恢复压缩的报头。当标题没有按预期更改时，有必要更新上下文的一些完整值或增量值。例如，RTP时间戳预计将以增量RTP时间戳（dT）递增。如果使用静默抑制，则在静默期间不发送数据包。然后，当语音活动恢复时，再次发送数据包，但RTP时间戳的增量较大，而不是dT。在这种情况下，必须发送更新。
If a packet that includes an update to some context state values is lost, the state at the decompressor is not updated. The shared state is now different at the compressor and decompressor. When the next packet arrives at the decompressor, the decompressor will fail to restore the compressed headers accurately since the context state at the decompressor is different than the state at the compressor.
如果包含对某些上下文状态值的更新的数据包丢失，则不更新解压缩程序的状态。现在，压缩机和解压缩器的共享状态不同。当下一个数据包到达解压器时，解压器将无法准确恢复压缩的头，因为解压器的上下文状态与压缩器的状态不同。
Note that the decompressor fails not when a packet is lost, but when the next compressed packet arrives. If the next packet happens to include the same context update as in the lost packet, the context at the decompressor may be updated successfully and decompression may continue uninterrupted. If the lost packet included an update to a delta field such as the delta RTP timestamp (dT), the next packet can't compensate for the loss since the update of a delta value is relative to the previous packet which was lost. But if the update is for an absolute value such as the full RTP timestamp or the RTP payload type, this update can be repeated in the next packet independently of the lost packet. Hence it is useful to be able to update the absolute values of the context.
请注意，解压器不是在数据包丢失时失败，而是在下一个压缩数据包到达时失败。如果下一个分组碰巧包括与丢失分组中相同的上下文更新，则解压器处的上下文可以成功更新，并且解压可以不间断地继续。如果丢失的数据包包含对增量字段（如增量RTP时间戳（dT））的更新，则下一个数据包无法补偿丢失，因为增量值的更新与丢失的前一个数据包相关。但是，如果更新是针对绝对值，例如完整RTP时间戳或RTP有效负载类型，则可以在下一个数据包中重复该更新，而不依赖于丢失的数据包。因此，能够更新上下文的绝对值非常有用。
The next chapter describes several extensions to CRTP that add the capability to selectively update absolute values of the context, rather than sending a FULL_HEADER packet, in addition to the existing updates of the delta values. This enhanced version of CRTP is intended to minimize context invalidation and thus improve the performance over lossy links with a long round trip time.
下一章描述了CRTP的几个扩展，除了增量值的现有更新外，还添加了选择性更新上下文绝对值的功能，而不是发送完整的_头数据包。CRTP的这一增强版本旨在最大限度地减少上下文失效，从而提高长往返时间有损链路的性能。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This chapter specifies the changes in this enhanced version of CRTP. They are:
本章详细说明了此增强版CRTP中的更改。他们是：
- Extensions to the COMPRESSED_UDP packet to allow updating the differential RTP values in the decompressor context and to selectively update the absolute IPv4 ID and the following RTP values: sequence number, timestamp, payload type, CSRC count and CSRC list. This allows context sync to be maintained even with some packet loss.
- 对压缩的_UDP数据包进行扩展，以允许更新解压器上下文中的差异RTP值，并有选择地更新绝对IPv4 ID和以下RTP值：序列号、时间戳、负载类型、CSC计数和CSC列表。这使得即使在某些数据包丢失的情况下也可以保持上下文同步。
- A "headers checksum" to be inserted by the compressor and removed by the decompressor when the UDP checksum is not present so that validation of the decompressed headers is still possible. This allows the decompressor to verify that context sync has not been lost after a packet loss.
- 当UDP校验和不存在时，由压缩器插入并由解压缩器删除的“标头校验和”，以便仍然可以验证解压缩的标头。这允许解压器验证在数据包丢失后上下文同步没有丢失。
An algorithm is then described to use these changes with repeated updates to achieve robust operation over links with packet loss and long delay.
然后描述了一种算法，该算法使用这些变化和重复更新来实现在具有分组丢失和长延迟的链路上的鲁棒操作。
It is possible to accommodate some packet loss between the compressor and decompressor using the "twice" algorithm in RFC 2508 so long as the context remains in sync. In that algorithm, the delta values are added to the previous context twice (or more) to effect the change that would have occurred if the missing packets had arrived. The result is verified with the UDP checksum. Keeping the context in sync requires reliably communicating both the absolute value and the delta value whenever the delta value changes. For many environments, sufficient reliability can be achieved by repeating the update with each of several successive packets.
只要上下文保持同步，就可以使用RFC 2508中的“两次”算法来适应压缩器和解压缩器之间的一些数据包丢失。在该算法中，增量值被添加到前一个上下文中两次（或更多次），以影响丢失的数据包到达时可能发生的更改。使用UDP校验和验证结果。保持上下文同步需要在增量值更改时可靠地传递绝对值和增量值。对于许多环境，通过对多个连续数据包中的每个数据包重复更新，可以实现足够的可靠性。
The COMPRESSED_UDP packet satisfies the need to communicate the absolute values of the differential RTP fields, but it is specified in RFC 2508 to reset the delta RTP timestamp. That limitation can be removed with the following simple change: RFC 2508 describes the format of COMPRESSED_UDP as being the same as COMPRESSED_RTP except that the M, S and T bits are always 0 and the corresponding delta fields are never included. This enhanced version of CRTP changes that specification to say that the T bit MAY be nonzero to indicate that the delta RTP timestamp is included explicitly rather than being reset to zero.
压缩的_UDP分组满足传递差分RTP字段的绝对值的需要，但是在RFC 2508中指定它来重置delta RTP时间戳。通过以下简单的更改可以消除该限制：RFC 2508将压缩的_UDP的格式描述为与压缩的_RTP相同，只是M、S和T位始终为0，并且从不包括相应的增量字段。CRTP的这个增强版本改变了该规范，即T位可能是非零的，以指示显式地包括了增量RTP时间戳，而不是重置为零。
A second change adds another byte of flag bits to the COMPRESSED_UDP packet to allow only selected individual uncompressed fields of the RTP header to be included in the packet rather than carrying the full RTP header as part of the UDP data. The additional flags do increase computational complexity somewhat, but the corresponding increase in bit efficiency is important when the differential field updates are communicated multiple times in successive COMPRESSED_UDP packets. With this change, there are flag bits to indicate inclusion of both delta values and absolute values, so the flag nomenclature is changed. The original S, T, I bits which indicate the inclusion of deltas are renamed dS, dT, dI, and the inclusion of absolute values is indicated by S, T, I. The M bit is absolute as before. A new
第二个更改将另一字节的标志位添加到压缩的UDP数据包中，以允许数据包中仅包含RTP报头的选定单个未压缩字段，而不是作为UDP数据的一部分承载完整的RTP报头。附加标志确实在一定程度上增加了计算复杂度，但当差分字段更新在连续的压缩UDP数据包中进行多次通信时，比特效率的相应增加很重要。通过此更改，有标志位指示包含增量值和绝对值，因此标志术语发生了更改。表示包含delta的原始S、T、I位重命名为dS、dT、dI，绝对值的包含由S、T、I表示。M位与之前一样是绝对的。一个新的
flag P indicates inclusion of the absolute RTP payload type value and another flag C indicates the inclusion of the CSRC count. When C=1, an additional byte is added following the two flag bytes to include the absolute value of the four-bit CC field in the RTP header.
标志P表示包含绝对RTP有效负载类型值，另一标志C表示包含CSC计数。当C=1时，在两个标志字节之后添加一个附加字节，以包括RTP报头中四位CC字段的绝对值。
The last of the three changes to the COMPRESSED_UDP packet deals with updating the IPv4 ID field. For this field, the COMPRESSED_UDP packet as specified in RFC 2508 can already convey a new value for the delta IPv4 ID, but not the absolute value which is only conveyed by the FULL_HEADER packet. Therefore, a new flag I is added to the COMPRESSED_UDP packet to indicate inclusion of the absolute IPv4 ID value. The I flag replaces the dS flag which is not needed in the COMPRESSED_UDP packet since the delta RTP sequence number always remains 1 in the decompressor context and hence does not need to be updated. Note that IPv6 does not have an IP ID field, so when compressing IPv6 packets both the I and the dI flags are always set to 0.
对压缩的UDP数据包的三个更改中的最后一个涉及更新IPv4 ID字段。对于该字段，RFC 2508中指定的压缩的_UDP数据包已经可以传送增量IPv4 ID的新值，但不能传送仅由完整的_报头数据包传送的绝对值。因此，新标志I被添加到压缩的UDP数据包中，以指示包含绝对IPv4 ID值。I标志替换压缩的UDP数据包中不需要的dS标志，因为delta RTP序列号在解压器上下文中始终保持为1，因此不需要更新。请注意，IPv6没有IP ID字段，因此在压缩IPv6数据包时，I和dI标志始终设置为0。
The format of the flags/sequence byte for the original COMPRESSED_UDP packet is shown here for reference:
原始压缩的_UDP数据包的标志/序列字节格式如下所示，以供参考：
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 |dI | link sequence |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 |dI | link sequence |
+---+---+---+---+---+---+---+---+
The new definition of the flags/sequence byte plus an extension flags byte for the COMPRESSED_UDP packet is as follows, where the new F flag indicates the inclusion of the extension flags byte:
压缩的_UDP数据包的标志/序列字节加上扩展标志字节的新定义如下，其中新的F标志表示包含扩展标志字节：
+---+---+---+---+---+---+---+---+
| F | I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
: M : S : T : P : C : 0 : 0 : 0 : (if F = 1)
+...+...+...+...+...+...+...+...+
+---+---+---+---+---+---+---+---+
| F | I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
: M : S : T : P : C : 0 : 0 : 0 : (if F = 1)
+...+...+...+...+...+...+...+...+
dI = delta IPv4 ID dT = delta RTP timestamp I = absolute IPv4 ID F = additional flags byte M = marker bit S = absolute RTP sequence number T = absolute RTP timestamp P = RTP payload type C = CSRC count CID = Context ID
dI=增量IPv4 ID dT=增量RTP时间戳I=绝对IPv4 ID F=附加标志字节M=标记位S=绝对RTP序列号T=绝对RTP时间戳P=RTP有效负载类型C=CSC计数CID=上下文ID
When F=0, there is only one flags byte, and the only available flags are: dI, dT and I. In this case the packet includes the full RTP header. As in RFC 2508, if dI=0, the decompressor does not change deltaI. If dT=0, the decompressor sets deltaT to 0.
当F=0时，只有一个标志字节，唯一可用的标志是：dI、dT和I。在这种情况下，数据包包括完整的RTP报头。与RFC2508中一样，如果dI=0，则解压器不会改变deltaI。如果dT=0，则解压器将deltaT设置为0。
When C=1, an additional byte is added following the two flag bytes. This byte includes the CC, the count of CSRC identifiers, in its lower 4 bits:
当C=1时，在两个标志字节之后添加一个附加字节。该字节包括CC，即CSC标识符的计数，其低位为4位：
+---+---+---+---+---+---+---+---+
| F | I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
: M : S : T : P : C : 0 : 0 : 0 : (if F = 1)
+...+...+...+...+...+...+...+...+
: 0 : 0 : 0 : 0 : CC : (if C = 1)
+...+...+...+...+...............+
+---+---+---+---+---+---+---+---+
| F | I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
: M : S : T : P : C : 0 : 0 : 0 : (if F = 1)
+...+...+...+...+...+...+...+...+
: 0 : 0 : 0 : 0 : CC : (if C = 1)
+...+...+...+...+...............+
The bits marked "0" in the second flag byte and the CC byte SHOULD be set to zero by the sender and SHOULD be ignored by the receiver.
发送方应将第二个标志字节和CC字节中标记为“0”的位设置为零，接收方应忽略这些位。
Some example packet formats will illustrate the use of the new flags. First, when F=0, the "traditional" COMPRESSED_UDP packet which carries the full RTP header as part of the UDP data:
一些示例数据包格式将说明新标志的使用。首先，当F=0时，“传统”压缩的_UDP数据包携带完整的RTP报头作为UDP数据的一部分：
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+---+---+---+---+---+---+---+---+
|F=0| I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
: :
+ UDP checksum + (if nonzero in context)
: :
+...............................+
: :
+ "RANDOM" fields + (if encapsulated)
: :
+...............................+
: delta IPv4 ID : (if dI = 1)
+...............................+
: delta RTP timestamp : (if dT = 1)
+...............................+
: :
+ 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 |
+---+---+---+---+---+---+---+---+
|F=0| I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
: :
+ UDP checksum + (if nonzero in context)
: :
+...............................+
: :
+ "RANDOM" fields + (if encapsulated)
: :
+...............................+
: delta IPv4 ID : (if dI = 1)
+...............................+
: delta RTP timestamp : (if dT = 1)
+...............................+
: :
+ IPv4 ID + (if I = 1)
: :
+...............................+
| UDP data |
: (uncompressed RTP header) :
When F=1, there is an additional flags byte and the available flags are: dI, dT, I, M, S, T, P, C. If C=1, there is an additional byte that includes the number of CSRC identifiers. When F=1, the packet does not include the full RTP header, but includes selected fields from the RTP header as specified by the flags. As in RFC 2508, if dI=0 the decompressor does not change deltaI. However, in contrast to RFC 2508, if dT=0 the decompressor KEEPS THE CURRENT deltaT in the context (DOES NOT set deltaT to 0).
当F=1时，有一个附加标志字节，可用标志为：dI、dT、I、M、S、T、P、C。如果C=1，则有一个附加字节，包括CSC标识符的数量。当F=1时，数据包不包括完整的RTP报头，而是包括由标志指定的RTP报头中的选定字段。与RFC2508中一样，如果dI=0，则解压缩器不会改变deltaI。然而，与RFC2508相反，如果dT=0，解压器将在上下文中保留当前的deltaT（不将deltaT设置为0）。
An enhanced COMPRESSED_UDP packet is similar in contents and behavior to a COMPRESSED_RTP packet, but it has more flag bits, some of which correspond to absolute values for RTP header fields.
增强的压缩_UDP数据包在内容和行为上与压缩的_RTP数据包类似，但它有更多的标志位，其中一些标志位对应于RTP头字段的绝对值。
COMPRESSED_UDP with individual RTP fields, when F=1:
F=1时，使用单个RTP字段压缩的UDP：
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+---+---+---+---+---+---+---+---+
|F=1| I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
| M | S | T | P | C | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+
: 0 : 0 : 0 : 0 : CC : (if C = 1)
+...+...+...+...+...............+
: :
+ UDP checksum + (if nonzero in context)
: :
+...............................+
: :
: "RANDOM" fields : (if encapsulated)
: :
+...............................+
: delta IPv4 ID : (if dI = 1)
+...............................+
: delta RTP timestamp : (if dT = 1)
+...............................+
: :
+ IPv4 ID + (if I = 1)
: :
+...............................+
: :
+ RTP sequence number + (if S = 1)
: :
+...............................+
: :
+ +
: :
+ RTP timestamp + (if T = 1)
: :
+ +
: :
+...............................+
: RTP payload type : (if P = 1)
+...............................+
: :
: CSRC list : (if CC > 0)
: :
+...............................+
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+---+---+---+---+---+---+---+---+
|F=1| I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
| M | S | T | P | C | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+
: 0 : 0 : 0 : 0 : CC : (if C = 1)
+...+...+...+...+...............+
: :
+ UDP checksum + (if nonzero in context)
: :
+...............................+
: :
: "RANDOM" fields : (if encapsulated)
: :
+...............................+
: delta IPv4 ID : (if dI = 1)
+...............................+
: delta RTP timestamp : (if dT = 1)
+...............................+
: :
+ IPv4 ID + (if I = 1)
: :
+...............................+
: :
+ RTP sequence number + (if S = 1)
: :
+...............................+
: :
+ +
: :
+ RTP timestamp + (if T = 1)
: :
+ +
: :
+...............................+
: RTP payload type : (if P = 1)
+...............................+
: :
: CSRC list : (if CC > 0)
: :
+...............................+
: :
: RTP header extension : (if X set in context)
: :
+-------------------------------+
| |
/ RTP data /
/ /
| |
+-------------------------------+
: padding : (if P set in context)
+...............................+
: :
: RTP header extension : (if X set in context)
: :
+-------------------------------+
| |
/ RTP data /
/ /
| |
+-------------------------------+
: padding : (if P set in context)
+...............................+
Usage for the enhanced COMPRESSED_UDP packet:
增强型压缩_UDP数据包的用法：
It is useful for the compressor to periodically refresh the state of the decompressor to avoid having the decompressor send CONTEXT_STATE messages in the case of unrecoverable packet loss. Using the flags F=0 and I=1, dI=1, dT=1, the COMPRESSED_UDP packet refreshes all the context parameters.
压缩器定期刷新解压缩器的状态是有用的，以避免在无法恢复的数据包丢失的情况下让解压缩器发送上下文状态消息。使用标志F=0和I=1、dI=1、dT=1，压缩的_UDP数据包刷新所有上下文参数。
When compression is done over a lossy link with a long round trip delay, we want to minimize context invalidation. If the delta values are changing frequently, the context might get invalidated often. In such cases the compressor MAY choose to always send absolute values and never delta values, using COMPRESSED_UDP packets with the flags F=1, and any of S, T, I as necessary.
当压缩是在有损链路上进行的，并且有很长的往返延迟时，我们希望最小化上下文失效。如果增量值经常更改，则上下文可能经常失效。在这种情况下，压缩器可以选择始终发送绝对值，而从不发送增量值，使用带有标志F=1的压缩的UDP数据包，并根据需要使用S、T、I中的任何一个。
RFC 2508, in Section 3.3.5, describes how the UDP checksum may be used to validate header reconstruction periodically or when the "twice" algorithm is used. When a UDP checksum is not present (has value zero) in a stream, such validation would not be possible. To cover that case, this enhanced CRTP provides an option whereby the compressor MAY replace the null UDP checksum with a 16-bit headers checksum (HDRCKSUM) which is subsequently removed by the decompressor after validation. Note that this option is never used with IPv6 since a null UDP checksum is not allowed.
RFC 2508在第3.3.5节中描述了UDP校验和如何用于定期或在使用“两次”算法时验证报头重建。如果流中不存在UDP校验和（值为零），则无法进行此类验证。为了解决这种情况，此增强型CRTP提供了一个选项，压缩器可以使用16位报头校验和（HDRCKSUM）替换空UDP校验和，该校验和随后在验证后由解压缩器删除。请注意，此选项从未用于IPv6，因为不允许使用空UDP校验和。
A new flag C in the FULL_HEADER packet, as specified below, indicates when set that all COMPRESSED_UDP and COMPRESSED_RTP packets sent in that context will have HDRCKSUM inserted. The compressor MAY set the C flag when UDP packet carried in the FULL_HEADER packet originally contained a checksum value of zero. If the C flag is set, the FULL_HEADER packet itself MUST also have the HDRCKSUM inserted. If a packet in the same stream subsequently arrives at the compressor with a UDP checksum present, then a new FULL_HEADER packet MUST be sent with the flag cleared to re-establish the context.
如下文所述，完整_报头数据包中的新标志C表示，当设置时，在该上下文中发送的所有压缩_UDP和压缩_RTP数据包都将插入HDRCKSUM。当完整头数据包中携带的UDP数据包最初包含零校验和值时，压缩器可以设置C标志。如果设置了C标志，则完整的_头数据包本身也必须插入HDRCKSUM。如果同一流中的数据包随后到达压缩器，且UDP校验和存在，则必须发送新的完整_头数据包，清除标志以重新建立上下文。
The HDRCKSUM is calculated in the same way as a UDP checksum except that it does not cover all of the UDP data. That is, the HDRCKSUM is the 16-bit one's complement of the one's complement sum of the pseudo-IP header (as defined for UDP), the UDP header, the first 12 bytes of the UDP data which are assumed to hold the fixed part of an RTP header, and the CSRC list. The extended part of the RTP header beyond the CSRC list and the RTP data will not be included in the HDRCKSUM. The HDRCKSUM is placed in the COMPRESSED_UDP or COMPRESSED_RTP packet where a UDP checksum would have been. The decompressor MUST zero out the UDP checksum field in the reconstructed packets.
HDRCKSUM的计算方法与UDP校验和相同，只是它不覆盖所有UDP数据。也就是说，HDRCKSUM是伪IP报头（如为UDP定义的）、UDP报头、UDP数据的前12个字节（假定保存RTP报头的固定部分）和csc列表的补码和的16位1的补码。超出CSC列表的RTP头的扩展部分和RTP数据将不包括在HDRCKSUM中。HDRCKSUM放在压缩的_UDP或压缩的_RTP数据包中，在该数据包中可以使用UDP校验和。解压缩程序必须将重建数据包中的UDP校验和字段归零。
For a non-RTP context, there may be fewer than 12 UDP data bytes present. The IP and UDP headers can still be compressed into a COMPRESSED_UDP packet. For this case, the HDRCKSUM is calculated over the pseudo-IP header, the UDP header, and the UDP data bytes that are present. If the number of data bytes is odd, then a zero padding byte is appended for the purpose of calculating the checksum, but not transmitted.
对于非RTP上下文，可能存在少于12个UDP数据字节。IP和UDP报头仍可压缩为压缩的UDP数据包。对于这种情况，HDRCKSUM是通过伪IP头、UDP头和存在的UDP数据字节计算的。如果数据字节数为奇数，则会附加一个补零字节，用于计算校验和，但不会传输。
The HDRCKSUM does not validate the RTP data. If the link layer is configured to deliver packets without checking for errors, then errors in the RTP data will not be detected. Over such links, the compressor SHOULD add the HDRCKSUM if a UDP checksum is not present, and the decompressor SHOULD validate each reconstructed packet to make sure that at least the headers are correct. This ensures that the packet will be delivered to the right destination. If only HDRCKSUM is available, the RTP data will be delivered even if it includes errors. This might be a desirable feature for applications that can tolerate errors in the RTP data. The same holds for the extended part of the RTP header beyond the CSRC list.
HDRCKSUM不验证RTP数据。如果链路层配置为在不检查错误的情况下传送数据包，则不会检测到RTP数据中的错误。在这种链路上，如果UDP校验和不存在，压缩器应该添加HDRCKSUM，解压缩器应该验证每个重构的数据包，以确保至少报头是正确的。这确保了数据包将被传送到正确的目的地。如果只有HDRCKSUM可用，则即使RTP数据包含错误，也将交付该数据。对于能够容忍RTP数据错误的应用程序来说，这可能是一个理想的特性。对于中国证监会列表之外的RTP标题的扩展部分，也适用同样的情况。
Here is the format of the FULL_HEADER length fields with the new flag C to indicate that a header checksum will be added in COMPRESSED_UDP and COMPRESSED_RTP packets:
以下是带有新标志C的完整\u头长度字段的格式，以指示将在压缩的\u UDP和压缩的\u RTP数据包中添加头校验和：
For 8-bit context ID:
对于8位上下文ID：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Generation| CID | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Generation| CID | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |C| seq | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |C| seq | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added
For 16-bit context ID:
对于16位上下文ID：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Generation| 0 |C| seq | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Generation| 0 |C| seq | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Enhanced CRTP achieves robust operation by sending changes multiple times to keep the compressor and decompressor in sync. This method is characterized by a number "N" that represents the quality of the link between the hosts. What it means is that the probability of more than N adjacent packets getting lost on this link is small. For every change in a full value or a delta value, if the compressor includes the change in N+1 consecutive packets, then the decompressor can keep its context state in sync with the compressor using the "twice" algorithm so long as no more than N adjacent packets are lost.
增强型CRTP通过多次发送更改来保持压缩机和减压器同步，从而实现稳健的运行。此方法的特征是数字“N”，表示主机之间链路的质量。这意味着在该链路上丢失N个以上相邻数据包的概率很小。对于完整值或增量值中的每一变化，如果压缩器包括N+1个连续数据包中的变化，则解压缩器可以使用“两次”算法保持其上下文状态与压缩器同步，只要丢失的相邻数据包不超过N个。
Since updates are repeated in N+1 packets, if at least one of these N+1 update packets is received by the decompressor, both the full and delta values in the context at the decompressor will get updated and its context will stay synchronized with the context at the compressor. We can conclude that as long as less than N+1 adjacent packets are lost, the context at the decompressor is guaranteed to be synchronized with the context at the compressor, and use of the "twice" algorithm to recover from packet loss will successfully update the context and restore the compressed packets.
由于更新在N+1个数据包中重复，如果解压器接收到这些N+1个更新数据包中的至少一个，则解压器的上下文中的完整值和增量值都将得到更新，并且其上下文将与压缩器的上下文保持同步。我们可以得出结论，只要丢失的相邻数据包少于N+1个，解压器上的上下文就保证与压缩器上的上下文同步，并且使用“两次”算法从数据包丢失中恢复将成功更新上下文并恢复压缩数据包。
The link sequence number cycles in 16 packets, so it's not always clear how many packets were lost. For example, if the previous link sequence number was 5 and the current number is 4, one possibility is that 15 packets were lost, but another possibility is that due to misordering packet 5 arrived before packet 4 and they are really adjacent. If there is an interpretation of the link sequence numbers that could be a gap of less than N+1, the "twice" algorithm may be applied that many times and verified with the UDP checksum (or the HDRCKSUM).
链路序列号在16个数据包中循环，因此并不总是清楚丢失了多少数据包。例如，如果先前的链路序列号是5，而当前的序列号是4，则一种可能性是15个分组丢失，但另一种可能性是由于分组5在分组4之前到达，并且它们实际上是相邻的。如果对链路序列号的解释可能是小于N+1的间隙，则可以多次应用“两次”算法，并使用UDP校验和（或HDRCKSUM）进行验证。
When more than N packets are lost, all of the repetitions of an update might have been lost. The context state may then be different at the compressor and decompressor. The decompressor can still try to recover by making one or more guesses for how many packets were lost and then applying the "twice" algorithm that many times.
当丢失N个以上的数据包时，一次更新的所有重复都可能丢失。然后，在压缩器和解压缩器处，上下文状态可能不同。解压器仍然可以尝试通过一次或多次猜测丢失了多少数据包，然后多次应用“两次”算法来恢复。
However, since the IPv4 ID field is not included in the checksum, this does not validate the IPv4 ID.
但是，由于校验和中不包括IPv4 ID字段，因此这不会验证IPv4 ID。
The conclusion is that for IPv4 if more than N packets were lost, the decompressor SHOULD NOT try to recover using the "twice" algorithm and instead SHOULD invalidate the context and send a CONTEXT_STATE packet. In IPv6 the decompressor MAY always try to recover from packet loss by using the "twice" algorithm and verifying the result with the UDP checksum.
结论是，对于IPv4，如果丢失了N个以上的数据包，则解压缩程序不应尝试使用“两次”算法进行恢复，而是应使上下文无效并发送上下文状态数据包。在IPv6中，解压器可能总是尝试通过使用“两次”算法并使用UDP校验和验证结果来恢复数据包丢失。
It is up to the implementation to derive an appropriate N for a link. The value is maintained independently for each context and is not required to be the same for all contexts. When compressing a new stream, the compressor sets a value of N for that context and sends N+1 FULL_HEADER packets. The compressor MUST also repeat each subsequent COMPRESSED_UDP update N+1 times. The value of N may be changed for an existing context by sending a new sequence of FULL_HEADER packets.
由实现为链路导出适当的N。该值为每个上下文独立维护，不要求所有上下文的值都相同。压缩新流时，压缩器将该上下文的值设置为N，并发送N+1个完整的_头数据包。压缩器还必须重复每个后续压缩的UDP更新N+1次。可以通过发送新的全u报头分组序列来改变现有上下文的N值。
The decompressor learns the value of N by counting the number of times the FULL_HEADER packet is repeated and storing the resulting value in the corresponding context. If some of the FULL_HEADER packets are lost, the decompressor may still be able to determine the correct value of N by observing the change in the 4-bit sequence number carried in the FULL_HEADER packets. Any inaccuracy in the counting will lead the decompressor to assume a smaller value of N than the compressor is sending. This is safe in that the only negative consequence is that the decompressor might send a CONTEXT_STATE packet when it was not really necessary to do so. In response, the compressor will send FULL_HEADER packets again, providing another opportunity for the decompressor to count the correct N.
解压器通过计算完整的_报头数据包被重复的次数并将结果值存储在相应的上下文中来学习N的值。如果一些完整_报头分组丢失，则解压缩器仍然能够通过观察完整_报头分组中携带的4位序列号的变化来确定N的正确值。计数中的任何不准确都会导致减压器假定N的值小于压缩机发送的值。这是安全的，因为唯一的负面后果是解压器可能在实际上不需要发送上下文状态数据包时发送上下文状态数据包。作为响应，压缩器将再次发送完整的_报头数据包，为解压缩器提供另一个计算正确N的机会。
The sending of FULL_HEADER packets is also triggered by a change in one of the fields held constant in the context, such as the IP TOS. If such a change should occur while the compressor is in the middle of sending the N+1 FULL_HEADER packets, then the compressor MUST send N+1 FULL_HEADER packets after making the change. This could cause the decompressor to receive more than N+1 FULL_HEADER packets in a row with the result that it assumes a larger value for N than is correct. That could lead to an undetected loss of context synchronization. Therefore, the compressor MUST change the "generation" number in the context and in the FULL_HEADER packet when it begins sending the sequence of N+1 FULL_HEADER packets so the decompressor can detect the new sequence. For IPv4, this is a change in behavior relative to RFC 2508.
在上下文中保持不变的一个字段（如IP TOS）中的更改也会触发完整_报头数据包的发送。如果压缩机在发送N+ 1全包报头包的中间时发生这种变化，则压缩器在做出改变后必须发送N+ 1 Full头报文包。这可能会导致解压缩程序在一行中接收超过N+1个完整的\u头数据包，结果是它假定N的值大于正确值。这可能导致未检测到的上下文同步丢失。因此，当压缩器开始发送N+1个完整_头数据包序列时，它必须更改上下文和完整_头数据包中的“生成”编号，以便解压缩器能够检测到新序列。对于IPv4，这是相对于RFC2508的行为变化。
CONTEXT_STATE packets SHOULD also be repeated N+1 times (using the same sequence number for each context) to provide a similar measure of robustness against packet loss. Here N can be the largest N of all contexts included in the CONTEXT_STATE packet, or any number the decompressor finds necessary in order to ensure robustness.
上下文\状态数据包也应重复N+1次（每个上下文使用相同的序列号），以提供类似的抗数据包丢失的鲁棒性度量。这里，N可以是CONTEXT_STATE包中包含的所有上下文中最大的N，或者是解压器为确保健壮性而认为必要的任何数字。
Here are some examples to demonstrate the robust operation of enhanced CRTP using N+1 repetitions of updates. In this stream the audio codec sends a sample every 10 milliseconds. The first talkspurt is 1 second long. Then there are 2 seconds of silence, then another talkspurt. We also assume in this first example that the IPv4 ID field does not increment at a constant rate because the host is generating other uncorrelated traffic streams at the same time and therefore the delta IPv4 ID changes for each packet.
以下是一些示例，用N+1次重复更新来演示增强型CRTP的稳健运行。在此流中，音频编解码器每10毫秒发送一个样本。第一个talkspurt有1秒长。然后是2秒钟的沉默，然后是另一次谈话爆发。在第一个示例中，我们还假设IPv4 ID字段不会以恒定速率递增，因为主机同时生成其他不相关的流量流，因此每个数据包的增量IPv4 ID都会更改。
In these examples, we will use some short notations:
在这些示例中，我们将使用一些简短的符号：
FH FULL_HEADER CR COMPRESSED_RTP CU COMPRESSED_UDP
FH完整\u头CR压缩\u RTP CU压缩\u UDP
When operating on a link with low loss, we can just use COMPRESSED_RTP packets in the basic CRTP method specified in RFC 2508. We might have the following packet sequence:
当在低损耗链路上运行时，我们可以使用RFC2508中指定的基本CRTP方法中的压缩RTP数据包。我们可能有以下数据包序列：
seq Time pkt updates and comments # type 1 10 FH 2 20 CR dI dT=10 3 30 CR dI 4 40 CR dI ... 100 1000 CR dI
序列时间包更新和评论#类型1 10 FH 2 20 CR dI dT=10 3 30 CR dI 4 40 CR dI。。。100 1000 CR dI
101 3010 CR dI dT=2010 102 3020 CR dI dT=10 103 3030 CR dI 104 3040 CR dI ...
101 3010铬铸铁dT=2010 102 3020铬铸铁dT=10 103 3030铬铸铁104 3040铬铸铁。。。
In the above sequence, if a packet is lost we cannot recover ("twice" will not work due to the unpredictable IPv4 ID) and the context must be invalidated.
在上面的序列中，如果数据包丢失，我们将无法恢复（“两次”将无法工作，因为无法预测的IPv4 ID），并且上下文必须无效。
Here is the same example using the enhanced CRTP method specified in this document, when N=2. Note that the compressor only sends the absolute IPv4 ID (I) and not the delta IPv4 ID (dI).
当N=2时，下面是使用本文档中指定的增强CRTP方法的相同示例。请注意，压缩器只发送绝对IPv4 ID（I），而不发送增量IPv4 ID（dI）。
seq Time pkt CU flags updates and comments # type F I dT dI M S T P 1 10 FH 2 20 FH repeat constant fields 3 30 FH repeat constant fields 4 40 CU 1 1 1 0 M 0 1 0 I T=40 dT=10 5 50 CU 1 1 1 0 M 0 1 0 I T=50 dT=10 repeat update T & dT 6 60 CU 1 1 1 0 M 0 1 0 I T=60 dT=10 repeat update T & dT 7 70 CU 1 1 0 0 M 0 0 0 I 8 80 CU 1 1 0 0 M 0 0 0 I ... 100 1000 CU 1 1 0 0 M 0 0 0 I
序列时间pkt CU标志更新和注释#类型F I dT dI M S T P 1 10 FH 2 20 FH重复常量字段3 30 FH重复常量字段4 40 CU 1 1 1 1 0 M 0 1 0 I T=40 dT=10 5 50 CU 1 1 1 0 M 0 1 0 I T=50 dT=10重复更新T&dT 6 60 CU 1 1 1 0 M 0 I=60 dT=10重复更新T&dT 7 70 CU 1 0 0 0 0 0 0 0 0 0 0 0 0 0 I 8 CU1 1 1 0 0 0 0 0 0 0 0 0 I。。。1001000CU1010M00I
101 3010 CU 1 1 0 0 M 0 1 0 I T=3010 T changed, keep deltas 102 3020 CU 1 1 0 0 M 0 1 0 I T=3020 repeat updated T 103 3030 CU 1 1 0 0 M 0 1 0 I T=3030 repeat updated T 104 3040 CU 1 1 0 0 M 0 0 0 I 105 3050 CU 1 1 0 0 M 0 0 0 I ...
101 3010 CU 1 1 0 M 0 1 0 I T=3010 T已更改，保持增量102 3020 CU 1 1 0 M 0 0 1 0 I T=3020重复更新T 103 3030 CU 1 1 0 M 0 0 0 1 0 I T=3030重复更新T 104 3040 CU 1 1 0 M 0 0 0 I 105 3050 CU 1 0 0 0 0 0 0 0 0 0 0 0 0 I。。。
This second example is the same sequence, but assuming the delta IP ID is constant. First the basic CRTP for a lossless link:
第二个示例是相同的序列，但假设delta IP ID是常量。首先是无损链路的基本CRTP：
seq Time pkt updates and comments # type 1 10 FH 2 20 CR dI dT=10 3 30 CR 4 40 CR ... 100 1000 CR
seq Time pkt更新和评论#类型1 10 FH 2 20 CR dI dT=10 3 30 CR 4 40 CR。。。100 1000铬
101 3010 CR dT=2010 102 3020 CR dT=10 103 3030 CR 104 3040 CR ...
101 3010 CR dT=2010 102 3020 CR dT=10 103 3030 CR 104 3040 CR。。。
For the equivalent sequence in enhanced CRTP, the more efficient COMPRESSED_RTP packet can still be used once the deltas are all established:
对于增强型CRTP中的等效序列，在所有增量都建立后，仍然可以使用更高效的压缩RTP数据包：
seq Time pkt CU flags updates and comments # type F I dT dI M S T P 1 10 FH 2 20 FH repeat constant fields 3 30 FH repeat constant fields 4 40 CU 1 1 1 1 M 0 1 0 I dI T=40 dT=10 5 50 CU 1 1 1 1 M 0 1 0 I dI T=50 dT=10 repeat updates 6 60 CU 1 1 1 1 M 0 1 0 I dI T=60 dT=10 repeat updates 7 70 CR 8 80 CR ... 100 1000 CR
时间pkt CU标志更新和注释#类型F I dT dI M S T P 1 10 FH 2 20 FH重复常量字段3 30 FH重复常量字段4 40 CU 1 1 1 1 1 1 M 0 1 0 I dI T=40 dT=10 5 50 CU 1 1 1 1 1 1 M 0 I dI T=50 dT=10重复更新6 60 CU 1 1 1 1 1 1 1 M 0 I dI=60 dT=10重复更新7 70 CR 8 80 CR。。。100 1000铬
101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas 102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T 103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T 104 3040 CR 105 3050 CR ...
101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T已更改，保持增量102 3020 CU 1 0 0 0 M 0 1 0 T=3020重复更新T 103 3030 CU 1 0 0 M 0 1 0 T=3030重复更新T 104 3040 CR 105 3050 CR。。。
Here is the second example when using IPv6. First the basic CRTP for a lossless link:
下面是使用IPv6时的第二个示例。首先是无损链路的基本CRTP：
seq Time pkt updates and comments # type 1 10 FH 2 20 CR dT=10 3 30 CR 4 40 CR ... 100 1000 CR
seq Time pkt更新和评论#类型1 10 FH 2 20 CR dT=10 3 30 CR 4 40 CR。。。100 1000铬
101 3010 CR dT=2010 102 3020 CR dT=10 103 3030 CR 104 3040 CR ...
101 3010 CR dT=2010 102 3020 CR dT=10 103 3030 CR 104 3040 CR。。。
For the equivalent sequence in enhanced CRTP, the more efficient COMPRESSED_RTP packet can still be used once the deltas are all established:
对于增强型CRTP中的等效序列，在所有增量都建立后，仍然可以使用更高效的压缩RTP数据包：
seq Time pkt CU flags updates and comments # type F I dT dI M S T P 1 10 FH 2 20 FH repeat constant fields 3 30 FH repeat constant fields 4 40 CU 1 0 1 0 M 0 1 0 T=40 dT=10 5 50 CU 1 0 1 0 M 0 1 0 T=50 dT=10 repeat updates 6 60 CU 1 0 1 0 M 0 1 0 T=60 dT=10 repeat updates 7 70 CR 8 80 CR ... 100 1000 CR
时间pkt CU标志更新和注释#类型F I dT dI M S T P 1 10 FH 2 20 FH重复常量字段3 30 FH重复常量字段4 40 CU 1 0 1 0 M 0 1 0 T=40 dT=10 5 50 CU 1 0 1 0 M 0 1 0 T=50 dT=10重复更新6 60 CU 1 0 1 0 M 0 1 0 T=60 dT=10重复更新7 70 CR 8 80 CR。。。100 1000铬
101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas 102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T 103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T 104 3040 CR 105 3050 CR ...
101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T已更改，保持增量102 3020 CU 1 0 0 0 M 0 1 0 T=3020重复更新T 103 3030 CU 1 0 0 M 0 1 0 T=3030重复更新T 104 3040 CR 105 3050 CR。。。
The use of IP/UDP/RTP compression (CRTP) over a particular link is a function of the link-layer protocol. It is expected that negotiation of the use of CRTP will be defined separately for each link layer.
在特定链路上使用IP/UDP/RTP压缩（CRTP）是链路层协议的一项功能。预计将为每个链路层分别定义CRTP使用的协商。
For link layers that already have defined a negotiation for the use of CRTP as specified in RFC 2508, an extension to that negotiation will be required to indicate use of the enhanced CRTP defined in this document since the syntax of the existing packet formats has been extended.
对于已经定义了RFC 2508中规定的CRTP使用协商的链路层，需要对该协商进行扩展，以指示使用本文件中定义的增强CRTP，因为现有数据包格式的语法已经扩展。
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 [SRTP]. That would allow compression to still be applied.
由于加密消除了此压缩方案试图利用的冗余，因此有一些诱因导致放弃加密以实现在低带宽链路上的操作。然而，对于数据加密而非报头加密令人满意的情况，RTP确实指定了一种替代加密方法，其中仅对RTP有效负载进行加密，报头保留在clear[SRTP]中。这将允许仍然应用压缩。
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 [IPHCOMP].
发生故障或恶意压缩程序可能会导致解压缩程序重新生成与原始数据包不匹配但仍具有有效IP、UDP和RTP头，甚至可能具有有效UDP校验和的数据包。这种损坏可以通过端到端身份验证和完整性机制进行检测，而不会受到压缩的影响。身份验证标头的常量部分将按照[IPHCOMP]中的说明进行压缩。
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.
使用具有非均匀接收端计算负载的压缩技术时，存在潜在的拒绝服务威胁。攻击者可以向流中注入病理数据报，这些数据报很难解压，并导致接收器过载和降低对其他流的处理。然而，这种压缩并没有表现出任何明显的不均匀性。
The authors would like to thank Van Jacobson, co-author of RFC 2508, and the authors of RFC 2507, Mikael Degermark, Bjorn Nordgren, and Stephen Pink. The authors would also like to thank Dana Blair, Francois Le Faucheur, Tim Gleeson, Matt Madison, Hussein Salama, Mallik Tatipamula, Mike Thomas, Alex Tweedly, Herb Wildfeuer, Andrew Johnson, and Dan Wing.
作者要感谢RFC2508的合著者Van Jacobson和RFC2507的作者Mikael Degermark、Bjorn Nordgren和Stephen Pink。作者还要感谢达娜·布莱尔、弗朗索瓦·勒·福彻、蒂姆·格雷森、马特·麦迪逊、侯赛因·萨拉马、马利克·塔蒂帕穆拉、迈克·托马斯、亚历克斯·特威德、赫伯·维尔德费尔、安德鲁·约翰逊和丹·温。
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[CRTP]Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[IPHCOMP] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[IPHCOMP]Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[IPCPHC] Koren, T., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 3544, July 2003.
[IPCPHC]Koren，T.，Casner，S.和C.Bormann，“PPP上的IP报头压缩”，RFC 3544，2003年7月。
[KEYW] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYW]Bradner，S.“RFC中用于表示需求水平的关键词”，BCP 14，RFC 211997年3月。
[RTP] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[RTP]Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 35502003年7月。
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[ROHC]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP和未压缩”，RFC 3095，2001年7月。
[SRTP] Baugher, M., McGrew, D., Carrara, E., Naslund, M. and K. Norrman, "The Secure Real-time Transport Protocol", Work in Progress.
[SRTP]Baugher，M.，McGrew，D.，Carrara，E.，Naslund，M.和K.Norrman，“安全实时传输协议”，正在进行中。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Tmima Koren Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134-1706
EMail: tmima@cisco.com
EMail: tmima@cisco.com
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 USA
Stephen L.Casner Packet Design美国加利福尼亚州帕洛阿尔托市Hillview大道3400号3号楼，邮编94304
EMail: casner@acm.org
EMail: casner@acm.org
John Geevarghese Motorola India Electronics Ltd. No. 33 A Ulsoor Road Bangalore, India
印度班加罗尔乌尔苏尔路A号约翰·吉瓦盖斯摩托罗拉印度电子有限公司
EMail: geevjohn@hotmail.com
EMail: geevjohn@hotmail.com
Bruce Thompson Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
布鲁斯·汤普森思科系统公司，美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
EMail: brucet@cisco.com
EMail: brucet@cisco.com
Patrick Ruddy Cisco Systems, Inc. 3rd Floor 96 Commercial Street Leith, Edinburgh EH6 6LX Scotland
Patrick Ruddy Cisco Systems，Inc.位于苏格兰爱丁堡Leith商业街96号三楼EH6 6LX
EMail: pruddy@cisco.com
EMail: pruddy@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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编辑功能的资金目前由互联网协会提供。