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

Document Type RFC - Proposed Standard (February 1999; No errata)
Authors Stephen Casner  , Van Jacobson 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2508 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          S. Casner
Request for Comments: 2508                                 Cisco Systems
Category: Standards Track                                    V. Jacobson
                                                           Cisco Systems
                                                           February 1999

       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 Notice

   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 and/or the author(s).

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.

1.  Introduction

   Since the Real-time Transport Protocol was published as an RFC [1],
   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 [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
Show full document text