RFC 2508 (rfc2508) - Page 2 of 24
Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
Alternative Format: Original Text Document
RFC 2508 Compressing IP/UDP/RTP Headers February 1999
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.
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.
2. Assumptions and Tradeoffs
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.
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.
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
Casner & Jacobson Standards Track