Compressed RTP

The standard for CRTP is specified in RFC 2508. ²⁶ It was designed for operation over low-speed serial links, such as dial-up modems, that exhibit low bit-error rates. CRTP is a direct out-growth of the Van Jacobson header compression algorithm used for TCP, ^{4 , 25} having similar performance and limitations.

The principal gain of TCP header compression comes from the observation that half of the octets in the TCP/IP headers are constant between packets. These are sent once ”in a full header packet ”and then elided from the following update packets. The remaining gain 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.

RTP header compression uses many of the same techniques, extended by 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. The constant second-order difference allows the compressor to suppress the unvarying fields and the fields that change predictably from packet to packet.

Figure 11.1 shows the process in terms of just the RTP header fields. The shaded header fields are constant between packets ”they have a first-order difference of zero ”and do not need to be sent. The unshaded fields are varying fields; they have a nonzero first-order difference. However, their second-order difference is often constant and zero, making the varying fields predictable.

Figure 11.1. Principles of Header Compression

In Figure 11.1 all the fields except the M bit either are constant or have a zero second-order difference. Therefore, if the initial values for the predictable fields are known, only the change in the M bit needs to be communicated.

Operation of CRTP: Initialization and Context

Compressed RTP starts by sending an initial packet containing full headers, thereby establishing the same state in the compressor and decompressor. This state is the initial context of the compressed stream. Subsequent packets contain reduced headers, which either indicate that the decompressor should use the existing context to predict the headers, or contain updates to the context that must be used for the future packets. Periodically a full header packet can be sent to ensure that any loss of synchronization between compressor and decompressor is corrected.

Full header packets comprise the uncompressed original packet, along with two additional pieces of information ”a context identifier and a sequence number ”as shown in Figure 11.2. The context identifier is an 8- or 16-bit field that uniquely identifies this particular stream. The sequence number is 4 bits and is used to detect packet loss on the link. The additional fields replace the IP and UDP length fields in the original packet, with no loss of data because the length fields are redundant with the link-layer frame length. The full header packet format is common to several compression schemes ”including IPv4 and IPv6, TCP, and UDP header compression ”hence the inclusion of the generation field, which is not used with RTP header compression.

Figure 11.2. Additional Fields Added to a Full Header Packet

The link-layer protocol indicates to the transport layer that this is a CRTP (rather than IP) full header packet. This information allows the transport layer to route the packets to the CRTP decompressor instead of treating them as normal IP packets. The means by which the link layer provides this indication depends on the type of link in use. Operation over PPP links is specified in RFC 2509. ²⁷

Context identifiers are managed by the compressor, which generates a new context whenever it sees a new stream that it believes it can compress. On receiving a new context identifier, the decompressor allocates storage for the context. Otherwise it uses the context identifier as an index into a table of stored context state. Context identifiers are not required to be allocated sequentially; an implementation that expects relatively few contexts should use a hash table to reduce the amount of storage space needed for the state, and one that expects many contexts should simply use an array with the context identifier as an index.

The context contains the following state information, which is initialized when a full header packet is received:

• The full IP, UDP, and RTP headers, possibly including a CSRC list, for the last packet transferred.

• The first-order difference for the IPv4 ID field, initialized to one when a full header packet is received. (This information is not needed when RTP-over-UDP/IPv6 is being compressed, because IPv6 does not have an ID field.)

• The first-order difference for the RTP timestamp field, initialized to zero when a full header packet is received.

• The last value of the four-bit CRTP sequence number, used to detect packet loss on the compressed link.

Given the context information, the receiver can decompress each consecutive packet it receives. No additional state is needed, although the state stored in the context may need to be updated with each packet.

Operation of CRTP: Compression and Decompression

After a full header packet has been sent to establish the context, the transition to Compressed RTP packets may occur. Each Compressed RTP packet indicates that the decompressor may predict the headers of the next packet on the basis of the stored context. Compressed RTP packets may update that context, allowing for common changes in the headers to be communicated without full header packet being sent. The format of a Compressed RTP packet is shown in Figure 11.3. In most cases, only the fields with solid outline are present, indicating that the next header may be directly predicted from the context. Other fields are present as needed, to update the context, and their presence is either inferred from the context or signaled directly within the compressed header.

Figure 11.3. A Compressed RTP Packet

The compressor observes the characteristics of the stream and omits fields that are constant or that change in a predictable fashion. The compression algorithm will work on any stream of packets in which the bits in the position of the IPv4 ID, RTP sequence number, and RTP timestamp are predictable. In general, the compressor has no way of knowing whether a particular stream really is RTP; it must look for patterns in the headers and, if they are present, start compression. If the stream is not RTP, it is unlikely that the patterns will be present, so it will not be compressed (of course, if the stream is non-RTP but has the appropriate pattern, that the stream can be compressed). The compressor is expected to keep state to track which streams are compressible and which are not, to avoid wasting compression effort.

On receiving a Compressed RTP packet, the decompressor reconstructs the headers. You may reconstruct the IPv4 header by taking the header previously stored in the context, inferring the values of the header checksum and total length fields from the link-layer headers. If the I or I bit in the Compressed RTP packet is set, the IPv4 ID is incremented by the delta IPv4 ID field in the Compressed RTP packet, and the stored first-order difference in IPv4 ID in the context is updated. Otherwise the IPv4 ID is incremented by the first-order difference stored in the context.

If multiple IPv4 headers are present in the context ”for example, because of IP-in-IP tunneling ”their IPv4 ID fields are recovered from the Compressed RTP packet, where they are stored in order as the "random" fields. If IPv6 is being used, there are no packet ID or header checksum fields, so all fields are constant except the payload length, which may be inferred from the link-layer length.

You may reconstruct the UDP header by taking the header previously stored in the context and inferring the length field from the link-layer headers. If the checksum stored in the context is zero, it is assumed that the UDP checksum is not used. Otherwise the Compressed RTP packet will contain the new value of the checksum.

You may reconstruct the RTP header by taking the header previously stored in the context, modified as described here:

• If all of M, S, T, and I are set to one, the packet contains a CC field and CSRC list, along with M , S , T , and I fields. In this case, the M , S , T , and I fields are used in predicting the marker bit, sequence number, timestamp, and IPv4 ID; and the CC field and CSRC list are updated on the basis of the Compressed RTP packet. Otherwise, the CC field and CSRC list are reconstructed on the basis of the previous packet.

• The M bit is replaced by the M (or M ) bit in the Compressed RTP packet.

• If the S or S bit in the Compressed RTP packet is set, the RTP sequence number is incremented by the delta RTP sequence field in the Compressed RTP packet. Otherwise the RTP sequence number is incremented by one.

• If the T or T bit in the Compressed RTP packet is set, the RTP timestamp is incremented by the delta RTP timestamp field in the Compressed RTP packet, and the stored first-order difference in timestamp in the context is updated. Otherwise the RTP timestamp is incremented by the stored first-order difference from the context.

• If the X bit is set in the context, the header extension is recovered from the Compressed RTP packet.

• If the P bit is set in the context, the padding is recovered from the Compressed RTP packet.

The context is updated with the newly received headers, as well as any updates to first-order difference in IPv4 ID and RTP timestamp, and the link-layer sequence number. The reconstructed headers, along with the payload data, are then passed to the IP stack for processing in the usual manner.

Typically only the context identifier, link sequence number, M, S, T, and I fields are present, giving a 2-octet header (3 octets if 16-bit context identifiers are used). This compares well with the 40 octets of the uncompressed headers.

Effects of Packet Loss

An RTP receiver detects packet loss by a discontinuity in the RTP sequence number; the RTP timestamp will also jump. When packet loss occurs upstream of the compressor, new delta values are sent to the decompressor to communicate these discontinuities. Although the compression efficiency is reduced, the packet stream is communicated accurately across the link.

Similarly, if packet loss occurs on the compressed link, the loss is detected by the link-layer sequence number in the Compressed RTP packets. The decompressor then sends a message back to the compressor, indicating that it should send a full header packet to repair the state. If the UDP checksum is present, the decompressor may also attempt to apply the deltas stored in the context twice, to see whether doing so generates a correct packet. The twice algorithm is possible only if the UDP checksum is included; otherwise the decompressor has no way of knowing whether the recovered packet is correct.

The need to request a full header packet to recover the context when loss occurs makes CRTP highly susceptible to packet loss on the compressed link. In particular, if the link round-trip time is high, it is possible that many packets are being received while the context recovery request is being delivered. As shown in Figure 11.4, the result is a loss multiplier effect, in which a single loss affects multiple packets until a full header packet is delivered. Thus, packet loss can seriously affect the performance of CRTP.

Figure 11.4. CRTP Operation When Packet Loss Occurs

The other limiting factor of CRTP is packet reordering . If packets are reordered prior to the compressed link, the compressor is required to send packets containing both sequence number and timestamp updates to compensate. These packets are relatively large ”commonly between two and four octets ”and they have a significant effect on the compression ratio, at least doubling the size of the compressed headers.

Basic CRTP assumes that there is no reordering on the compressed link. Work is under way on an extension to make CRTP more robust in the face of packet loss and reordering. ⁴³ It is expected that these enhancements will make CRTP suitable for environments with low to moderate amounts of loss or reordering over the compressed link. The Robust Header Compression scheme described in the next section is designed for more extreme environments.