Network Working Group S. Casner
Request for Comments: 2508 Cisco Systems
Category: Standards Track V. Jacobson
Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
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.
Copyright (C) The Internet Society (1999). All Rights Reserved.
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.
Comments are solicited and should be addressed to the working group
mailing list email@example.com and/or the author(s).
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.
Since the Real-time Transport Protocol was published as an RFC ,
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.)
Casner & Jacobson Standards Track [Page 1]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 . 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  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.