RFC 2508 (rfc2508) - Page 2 of 24

Compressing IP/UDP/RTP Headers for Low-Speed Serial Links

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