Audio/Video Transport Working Group                               Stephen Casner                         Tmima Koren
Internet Draft                                                     Packet Design
November 17, 2000                                                   Van Jacobson
Expires June                                            Cisco Systems
July 16, 2001                                            Stephen Casner
Expires March 2002                                        Packet Design
draft-ietf-avt-crtp-enhance-01.txt                                   Tmima Koren
draft-ietf-avt-crtp-enhance-02.txt                     John Geevarghese
                                                                Telseon
                                                         Bruce Thompson
                                                                        Dan Wing
                                                          Patrick Ruddy
                                                                    Alex Tweedly
                                                          Cisco Systems
                                                                John Geevarghese
                                                                         Telseon

       Compressing IP/UDP/RTP Headers for Low-Speed Serial Links headers on links with high delay,
		      packet loss and reordering

Status of this memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026. Internet Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   Areas, and its Working Groups. Note that other groups may also
   distribute working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsolete by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as "work in
   progress".

   The list of current Internet-Drafts can be accessed at:
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at:
   http://www.ietf.org/shadow.txt

   This draft is being submitted as a possible work item to of the IETF Audio/Video Transport working
   group.  To subscribe to the The working group mailing list send a message to
rem-conf-request@es.net with the line "subscribe" in the body of is avt@ietf.org. Subscribe via
   the message.
Archives are available from:
ftp://ftp.es.net/pub/mail-archive/rem-conf

Copyright Notice web at http://www.ietf.org/mailman/listinfo/avt.

   Copyright (C) The Internet Society (1999-2000). (1999-2001). All Rights Reserved.

Abstract

   This document describes a method header compression scheme for compressing point to
   point links with packet loss and long delays. It is based on CRTP,
   the headers of IP/UDP/RTP datagrams to reduce overhead header compression described in [RFC2508]. CRTP does
   not perform well on low-speed serial links.
   In such links: packet loss results in context
   corruption and due to the long delay, many cases, all three headers can be compressed more packets are
   discarded before the context is repaired. To correct the behavior of
   CRTP over such links, a few extensions to 2-4 bytes.

   Comments the protocol are solicited and should be addressed specified
   here. The extensions aim to reduce context corruption by changing
   the working group
   mailing list rem-conf@es.net and/or way the author(s).

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", compressor updates the context at the decompressor:
   updates are repeated and "OPTIONAL" include updates to full and differential
   context parameters. With these extensions, CRTP performs well over
   links with packet loss, packet reordering and long delays.

   The IPCP option 'IP header compression' (described in this
   document are RFC 2509) is
   also extended to be interpreted negotiate using the extended CRTP.

1.0 Introduction

   RTP header compression (CRTP) as described in RFC 2119.

1.  Introduction

   Since the Real-time Transport Protocol 2508 was published as an RFC [1],
   there has been growing interest in using RTP as one step designed
   to achieve
   interoperability among different implementations of network
   audio/video applications.  However, there is also concern that reduce 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.)

   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 IP/UDP/RTP datagrams by compressing
   the 40 bytes of combined three headers. The IP/UDP/RTP headers together provides
   substantially more gain than compressing 12 are compressed to 2-4
   bytes most 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 time.

   CRTP was designed for combined compression reliable point to point links with short
   delays. It does not perform well over links with high rate of IP,
   UDP packet
   loss, packet reordering and RTP headers on long delays.

   An example of such a link-by-link basis.

   This document defines link is a compression scheme PPP session 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 tunneled using an
   IP level tunneling protocol such as L2TP. Packets within the more general compression
   framework specified in [3] for use with both IPv6 tunnel
   are carried by an IP network and IPv4.  That
   framework defines TCP hence may get lost and non-TCP reordered.
   The longer the tunnel, the longer the round trip time.

   Another example is an IP network that uses layer 2 technologies such
   as two classes ATM and Frame Relay for the access portion of the network. Layer
   2 transport above
   IP.  This specification creates IP/UDP/RTP networks such as a third class extracted
   from the non-TCP class.

2.  Assumptions ATM and Tradeoffs

   The goal of this compression scheme is to reduce the IP/UDP/RTP
   headers Frame Relay behave like point
   to two bytes for most packets point serial links 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 that they do not reorder packets. In
   addition, Frame Relay and 28.8 dialup modems. ATM virtual circuits used as IP access
   technologies often have a low bit rate associated with them. These
   virtual circuits differ from low speed serial links tend to provide
   full-duplex communication, so the protocol takes advantage of in that
   fact, though the protocol they 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
   span a larger physical distance than a point to reduce the delay across point serial link.
   Speed of light delays within the slow link experienced by
   small real-time packets, except to identify layer 2 transport network will
   result in Section 4 some
   interactions higher round trip delays between segmentation and compression that may occur.
   Segmentation schemes the endpoints of the
   circuit. In addition, congestion within the layer 2 transport
   network may be defined separately and used result in
   conjunction with an effective drop rate for the compression defined here.

   It should be noted that implementation simplicity virtual circuit
   which is an important
   factor significantly higher than error rates typically experienced
   on point to consider in evaluating a compression scheme.
   Communications servers may need point serial links.

   CRTP is widely deployed and has relatively low computational
   complexity. It is desirable to support compression extend its usage over perhaps
   as many as 100 dial-up modem lines using a single processor.
   Therefore, it may such links.
   This can be appropriate achieved with a few simple extensions to make some simplifications in the
   design at the expense protocol.

1.1 CRTP Operation

   During compression of generality, or to produce an RTP stream, a flexible design
   that session context is general but can be subsetted for simplicity.  Higher
   compression gain might be achieved by communicating more complex
   models for defined.
   For each context, the changing header fields from session state is established and shared
   between the compressor to and the
   decompressor, but that complexity decompressor. Once the context state
   is deemed unnecessary. established, compressed packets may be sent.

   The next
   sections discuss some context state consists of the tradeoffs listed here.

2.1.  Simplex vs. Full Duplex

   In the absence of other constraints, full IP/UDP/RTP headers, a compression scheme that worked
   over simplex links would be preferred over one that did not.
   However, operation over few
   first order differential values, a simplex link requires periodic refreshes
   with an uncompressed sequence number, a
   generation number and a delta encoding table.

   The headers part of the context is set by the FULL_HEADER packet header to restore
   that always starts a compression session. The first order
   differential values (delta values) are set by sending COMPRESSED_RTP
   packets that include updates to the delta values.

   The context state in
   case of error.  If an explicit error signal can must be returned instead,
   the delay synchronized between compressor and
   decompressor for successful decompression to recovery may be shortened substantially.  The overhead
   in take place. If the no-error case is also reduced.  To gain these performance
   improvements, this specification includes an explicit error
   indication sent on
   context gets out of sync, the reverse path.

   On a simplex link, it would be possible decompressor is not able to use a periodic refresh
   instead.  Whenever restore
   the compressed headers accurately. The decompressor detected an error in invalidates the
   context and sends a particular CONTEXT_STATE packet stream, it would simply discard to the compressor
   indicating that the context has been corrupted. To resume
   compression, the compressor must reestablish the context.

   During the time the context is corrupted, the decompressor discards
   all the packets in that stream
   until an uncompressed header was received for that stream, and then
   resume decompression.  The penalty would be context. Since the potentially large
   number of packets discarded.  The periodic refresh method described context repair
   mechanism in Section 3.3 of [3] applies to IP/UDP/RTP compression on simplex
   links or links with high delay CRTP involves feedback from the decompressor, context
   repair takes at least as well much time as to other non-TCP packet
   streams.

2.2. Links with high bit error rate and long the round trip delay

IP/UDP/RTP header compression may be used in scenarios where a compressed link
could extend over a long physical distance and involve multiple layer-2
switching points. An example time of such a link is RTP transport over ATM AAL5,
where the "link" would actually traverse through multiple layer-2 switching
points on the path from the CRTP transmitter (compressor) to the CRTP receiver
(decompressor). Another example is a wireless
   link. Such links may experience
significant packet loss and/or long If the round trip delays. Contexts get invalidated
due to packet loss, but time of the CRTP error recovery mechanism using CONTEXT_STATE
messages link is not efficient due to long, and especially if
   the long round trip delay.

In scenarios link bandwidth is high, many packets will be discarded before
   the context is repaired. On such as this, links it is desirable to minimize
   context invalidation. A
set of enhancements is defined for error prevention and recovery. The
enhancements make CRTP more robust and resilient to packet loss, which in turn
will reduce context invalidation.

2.3.   Segmentation and Layering

   Delay induced by the time required to send a large packet over the
   slow link is not a problem for one-way audio, for example, because
   the receiver can adapt to

1.2 How do contexts get corrupted?

   As long as the variance fields in delay.  However, the combined IP/UDP/RTP headers change as
   expected for
   interactive conversations, minimizing the end-to-end delay is
   critical.  Segmentation sequence of large, non-real-time packets to allow
   small real-time packets to be transmitted between segments can reduce
   the delay.

   This specification deals only with compression and assumes
   segmentation, if included, will be handled as in a separate layer.  It
   would session, those headers can
   be inappropriate to integrate segmentation compressed, and compression in
   such a way that the compression could not be used by itself in
   situations where segmentation was deemed unnecessary or impractical.
   Similarly, one would like to avoid any requirements for a reservation
   protocol.  The compression scheme decompressor can be applied locally on fully restore the two
   ends of a link independent of any other mechanisms except for compressed
   headers using the
   requirements that context state. When the link layer provide headers don't change as
   expected it's necessary to update some packet type codes, a
   packet length indication, and good error detection.

   Conversely, separately compressing of the IP/UDP and RTP layers loses
   too much full or the delta
   values of the compression gain that is possible by treating them
   together.  Crossing these protocol layer boundaries is appropriate
   because context. For example, the same function RTP timestamp is being applied across all layers.

3.  The Compression Algorithm

   The compression algorithm defined in this document draws heavily upon
   the design of TCP/IP header compression as described in RFC 1144 [2].
   Readers are referred expected to that RFC for more information on
   increment by delta RTP timestamp (dT). If silence suppression is
   used, packets are not sent during silence periods. Then when voice
   activity resumes, packets are sent again, but the
   underlying motivations RTP timestamp is
   incremented by a large value and general principles of header compression.

3.1.  The basic idea not by dT. In TCP header compression, the first factor-of-two reduction in data
   rate comes from the observation this case an update
   must be sent.

   If a packet that half of includes an update to some context state values is
   lost, the bytes in state at the IP decompressor is not updated. The shared state
   is now different at the compressor and
   TCP headers remain constant over decompressor. When the life of next
   packet arrives at the connection.  After
   sending decompressor, the uncompressed header once, these fields may be elided from decompressor will fail to
   restore the compressed headers that follow.  The remaining compression 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 accurately since the length of context state at
   the packet.  This length decompressor is indicated by the link-level protocol.

   For RTP header compression, some of the same techniques may be
   applied.  However, different than the big gain comes from state at the observation compressor.

1.3 Preventing context corruption

   Note that
   although several fields change in every packet, the difference from
   packet to decompressor fails not when a packet is often constant and therefore lost, but when
   the second-order
   difference is zero.  By maintaining both next compressed packet arrives. If the uncompressed header and next packet happens to
   include the first-order differences same context update as in the session state shared between lost packet, the
   compressor and decompressor, all that must be communicated is context
   at the decompressor may be updated successfully and decompression
   may continue uninterrupted. If the lost packet included an
   indication that update to
   a delta field such as the second-order difference was zero.  In that case, delta RTP timestamp (dT), the decompressor can reconstruct next packet
   can't compensate for the original header without any loss
   of information simply by adding since the first-order differences update of a delta value is
   relative to the
   saved uncompressed header as each compressed previous packet which was lost. But if the update is received.

   Just as TCP/IP header compression maintains shared state for multiple
   simultaneous TCP connections, this IP/UDP/RTP compression SHOULD
   maintain state
   for multiple session contexts.  A session context is
   defined by the combination of the IP source and destination
   addresses, an absolute value such as the UDP source and destination ports, and full RTP timestamp or the RTP SSRC
   field.  A compressor implementation might use a hash function on
   these fields to index a table of stored session contexts.  The
   compressed
   payload type, this update can be repeated in the next packet carries a small integer, called
   independently of the session context
   identifier or CID, lost packet. Hence it is useful to indicate in which session context that packet
   should be interpreted.  The decompressor can use the CID able to index its
   table
   update the absolute values of stored session contexts directly.

   Because the RTP compression is lossless, it may be applied context.

   The next chapter describes several extensions to any UDP
   traffic CRTP that benefits from it.  Most likely, add the only packets that
   will benefit are RTP packets, but it is acceptable
   capability to use heuristics
   to determine whether or not selectively update absolute values of the packet is an RTP packet because no
   harm is done if context,
   rather than sending a FULL_HEADER packet, in addition to the heuristic gives
   existing updates of the wrong answer. delta values. This does
   require executing enhanced version of CRTP
   is intended to minimize context invalidation and thus improve the compression algorithm for all UDP packets, or
   at least those
   performance over lossy links with even port numbers (see section 3.4).

   Most compressor implementations will need to maintain a "negative
   cache" of packet streams that have failed to compress as RTP packets
   for some number long round trip time.

1.4 Specification of attempts in order to avoid further attempts.
   Failing to compress means that some fields Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the potential RTP
   header that this
   document are expected to remain constant most of the time, such be interpreted as described in [RFC2119].

2. Enhanced CRTP

   This chapter specifies the payload type field, keep changing.  Even if the other such fields
   remain constant, a packet stream with a constantly changing SSRC
   field SHOULD be entered changes in this enhanced version of CRTP.
   They are:

    - Extensions to the negative cache COMPRESSED_UDP packet to avoid consuming all
   of allow updating the available session contexts.  The negative cache is indexed by
      differential RTP values in the source decompressor context and destination to
      selectively update the absolute IP address ID and UDP port pairs but not the RTP SSRC field since the latter may values. This
      allows context sync to be changing.  When RTP
   compression fails, maintained even with some packet
      loss.

    - A 'headers checksum' to be inserted by the IP compressor and
      removed by the decompressor when the UDP headers MAY still be compressed.

   Fragmented IP Packets that are checksum is not initial fragments and packets
      present so that
   are not long enough validation of the decompressed headers is
      still possible. This allows the decompressor to contain a complete UDP header MUST NOT be sent
   as FULL_HEADER packets.  Furthermore, packets verify that do
      context sync has not
   additionally contain at least 12 bytes of UDP data MUST NOT be used
   to establish RTP context.  If such been lost after a packet loss.

   An algorithm is sent as a FULL_HEADER
   packet, it MAY be followed by then described to use these changes with repeated
   updates to achieve robust operation over links with packet loss and
   long delay.

2.1 Extended COMPRESSED_UDP packets but MUST NOT be
   followed by COMPRESSED_RTP packets.

3.2.  Header Compression for RTP Data Packets

   In the IPv4 header, only the total length, packet ID, and header
   check-sum fields will normally change.  The total length

   It is redundant
   with the length provided by possible to accommodate some packet loss between the link layer,
   compressor and since this
   compression scheme must depend upon decompressor using the link layer to provide good
   error detection (e.g., PPP's CRC [4]), "twice" algorithm in RFC 2508
   so long as the header checksum may also
   be elided. context remains in sync. This leaves only requires reliably
   communicating both the packet ID, which, assuming no IP
   fragmentation, would not need to be communicated.  However, in order
   to maintain lossless compression, changes in absolute value and the packet ID will delta value whenever
   the delta value changes. For many environments, sufficient
   reliability can be
   transmitted.  The packet ID usually increments achieved by one or a small
   number for each packet.  (Some systems increment repeating the ID update with the
   bytes swapped, which results in slightly less compression.)  In the
   IPv6 base header, there is no each of
   several successive packets.

   The COMPRESSED_UDP packet ID nor header checksum and only satisfies the payload length field changes.

   In need to communicate the UDP header,
   absolute values of the length field differential RTP fields, but it is redundant specified
   in RFC 2508 to reset the delta RTP timestamp. That limitation can be
   removed with the IP total
   length field and following simple change: RFC 2508 describes the length indicated by
   format of COMPRESSED_UDP as being the link layer.  The UDP
   check-sum field will be a constant zero if same as COMPRESSED_RTP except
   that the source elects not M, S and T bits are always 0 and the corresponding delta
   fields are never included.  This enhanced version of CRTP changes
   that specification to
   generate UDP checksums.  Otherwise, say that the checksum must T bit may be communicated
   intact in order nonzero to preserve the lossless compression.  Maintaining
   end-to-end error detection for applications indicate
   that require it is an
   important principle.

   In the delta RTP header, the SSRC identifier timestamp is constant in a given context
   since that is part included explicitly rather than
   being reset to zero.

   A second change adds another byte of what identifies the particular context.  For
   most packets, only the sequence number and flag bits to the timestamp will change
   from COMPRESSED_UDP
   packet to packet.  If packets are not lost or misordered
   upstream from the compressor, the sequence number will increment by
   one for each packet.  For audio packets allow only selected individual uncompressed fields of constant duration, the
   timestamp will increment by the number of sample periods conveyed
   RTP header to be included in
   each packet.  For video, the timestamp will change on the first packet rather than carrying the
   full RTP header as part of each frame, but then stay constant for any additional
   packets in the frame.  If each video frame occupies only one packet, UDP data. The additional flags do
   increase computational complexity somewhat, but the video frames are generated at a constant rate, then again the
   change corresponding
   increase in the timestamp from frame to frame bit efficiency is constant.  Note that
   in each of these cases important when the second-order difference differential field
   updates are communicated multiple times in successive COMPRESSED_UDP
   packets.  With this change, there are flag bits to indicate
   inclusion of the sequence
   number both delta values and timestamp fields is zero, absolute values, so the next packet header can be
   constructed from the previous packet header by adding the first-order
   differences for these fields that are stored in the session context
   along with the previous uncompressed header.  When the second-order
   difference flag
   nomenclature is not zero, changed. The original S, T, I bits which indicate
   the magnitude inclusion of deltas are renamed dS, dT, dI, and the change inclusion of
   absolute values is usually much
   smaller than the full number indicated by S, T, I. The M bit is absolute as
   before. A new flag P indicates inclusion of bits in the field, so the size can be
   reduced by encoding absolute RTP payload
   type value and, as in the new first-order difference and transmitting
   it rather than COMPRESSED_RTP packet, a four-bit CC field
   copies the absolute value.

   The M bit will be set on the first packet value of an audio talkspurt and the last packet of a video frame.  If it were treated as a constant CC field such that each change required sending in the full RTP header,
   this would reduce header.

   The last of the compression significantly.  Therefore, one bit
   in three changes to the compressed header will carry COMPRESSED_UDP packet deals
   with updating the M bit explicitly.

   If IP ID field.  For this field, the packets are flowing through an RTP mixer, most commonly COMPRESSED_UDP
   packet as specified in RFC 2508 can already convey a new value for
   audio, then
   the CSRC list and CC count will also change.  However, delta IP ID, but not the CSRC list will typically remain constant during a talkspurt or
   longer, so it need be sent absolute value which is only when it changes.

3.3.  The protocol

   The compression protocol must maintain a collection of shared
   information in a consistent state between conveyed
   by the compressor and
   decompressor.  There is FULL_HEADER packet. Therefore, a separate session context for each
   IP/UDP/RTP new flag I is added to the
   COMPRESSED_UDP packet stream, as defined by a particular combination to indicate inclusion of the absolute IP source and destination addresses, UDP source and destination
   ports, and the RTP SSRC field. ID
   value.  The number of session contexts to be
   maintained MAY be negotiated between I flag replaces the compressor and decompressor.
   Each context dS flag which is identified by an 8- or 16-bit identifier, depending
   upon not needed in the number of contexts negotiated, so
   COMPRESSED_UDP packet since the maximum delta RTP sequence number is
   65536.  Both uncompressed and compressed packets MUST carry always
   remains 1 in the decompressor context ID and a 4-bit sequence number used hence does not need to detect packet loss
   between the compressor and decompressor.  Each context has its own
   separate sequence number space so that a single packet loss need only
   invalidate one context. be
   updated.

   The shared information in each context consists format of the following
   items:

      o The full IP, UDP and RTP headers, possibly including a CSRC
        list, flags/sequence byte for the last original
   COMPRESSED_UDP packet sent by the compressor or
        reconstructed by the decompressor.

      o The first-order difference for the IPv4 ID field, initialized to
        1 whenever an uncompressed IP header for this context is
        received and updated each time a delta IPv4 ID field is received
        in a compressed packet.

      o The first-order difference shown here for the RTP timestamp field,
        initialized to reference:

               +---+---+---+---+---+---+---+---+
               | 0 whenever an uncompressed packet for this
        context is received and updated each time a delta RTP timestamp
        field is received in a compressed packet.

      o The last value of the 4-bit | 0 | 0 |dI | link sequence number, which is used to
        detect packet loss between the compressor and decompressor.

      o |
               +---+---+---+---+---+---+---+---+

   The current generation number for non-differential coding new definition of UDP
        packets with IPv6 (see [3]).  For IPv4, the generation number
        may be set to zero if flags/sequence byte plus an extension
   flags byte for the COMPRESSED_NON_TCP COMPRESSED_UDP packet type,
        defined below, is never used.

      o A context-specific delta encoding table (see section 3.3.4) may
        optionally be negotiated for each context.

   In order to communicate packets in the various uncompressed and
   compressed forms, this protocol depends upon as follows, where the link layer being
   able to provide an indication of four
   new packet formats in addition
   to F flag indicates the normal IPv4 and IPv6 packet formats:

      FULL_HEADER - communicates inclusion of the uncompressed extension flags byte:

               +---+---+---+---+---+---+---+---+
               | F | I |dT |dI | link sequence |
               +---+---+---+---+---+---+---+---+
               : M : S : T : P :      CC       :  (if F = 1)
               +...+...+...+...+...............+

	       dI = delta IP header plus any
      following headers ID
	       dT = delta RTP timestamp
	       I  = absolute IP ID
	       F  = additional flags byte
	       M  = marker bit
	       S  = absolute RTP sequence number
	       T  = absolute RTP timestamp
	       P  = RTP payload type
	       CC = number of CSRC identifiers
   When F=0, there is only one flags byte, and data to establish the uncompressed header
      state in the decompressor for a particular context.  The FULL-
      HEADER packet also carries the 8- or 16-bit session context
      identifier only available flags
   are: dI, dT and I. In this case the 4-bit sequence number to establish
      synchronization between packet includes the compressor and decompressor.  The
      format is shown full RTP
   header. As in section 3.3.1.

      COMPRESSED_UDP - communicates RFC 2508, if dI=0, the IP and UDP headers compressed decompressor does not change
   deltaI. If dT=0, the decompressor sets deltaT to
      6 or fewer bytes (often 2 if UDP checksums are disabled), followed
      by any subsequent headers (possibly RTP) in uncompressed form,
      plus data.  This 0.

   Some example packet type is used when there are differences in formats will illustrate the usually constant fields use of the (potential) RTP header.  The
      RTP header includes a potentially changed value of new
   flags.  First, when F=0, the SSRC field,
      so this 'traditional' COMPRESSED_UDP packet may redefine the session context.  The format is
      shown in section 3.3.3.

      COMPRESSED_RTP - indicates that
   which carries the full RTP header is compressed along
      with as part of the IP and UDP headers.  The size data:

                0   1   2   3   4   5   6   7
              +...............................+
              :   msb of this header may still be
      just two bytes, or more if differences must be communicated.  This
      packet type is used when the second-order difference (at least in
      the usually constant fields) is zero.  It includes delta encodings
      for those fields that have changed by other than the expected
      amount to establish the first-order differences after an
      uncompressed RTP header is sent and whenever they change.  The
      format is shown in section 3.3.2.

      CONTEXT_STATE - indicates a special packet sent from the
      decompressor to the compressor to communicate a list session context ID   :  (if 16-bit CID)
              +-------------------------------+
              |   lsb of session context
      IDs for which synchronization has or may have been lost.  This
      packet is only sent across the point-to-point ID   |
              +---+---+---+---+---+---+---+---+
              |F=0| I |dT |dI | link so it requires
      no IP header.  The format is shown in section 3.3.5.

   When this compression scheme is used with IPv6 as part of the general
   header compression framework specified in [3], another packet type
   MAY be used:

      COMPRESSED_NON_TCP - communicates the compressed IP and sequence |
              +---+---+---+---+---+---+---+---+
              :                               :
              +         UDP
      headers as defined in [3] without differential encoding.  If it
      were used for IPv4, it would require one or two bytes more than
      the COMPRESSED_UDP form listed above checksum          +  (if nonzero in order to carry the context)
              :                               :
              +...............................+
              :                               :
              +        "RANDOM" fields        +  (if encapsulated)
              :                               :
              +...............................+
              :         delta IPv4 ID
      field.  For IPv6,         :  (if dI = 1)
              +...............................+
              :      delta RTP timestamp      :  (if dT = 1)
              +...............................+
              :                               :
              +           IPv4 ID             +  (if I = 1)
              :                               :
              +...............................+
              |           UDP data            |
              :   (uncompressed RTP header)   :

   When F=1, there is no ID field an additional flags byte and the available flags
   are: dI, dT, I, M, S, T, P, CC. In this non-differential
      compression is more resilient to packet loss.

   Assignments of numeric codes for these case the packet formats in does not
   include the Point-
   to-Point Protocol [4] are to be made full RTP header, but includes selected fields from the
   RTP header as specified by the Internet Assigned Numbers
   Authority.

3.3.1.  FULL_HEADER (uncompressed) packet format

   The definition of flags. As in RFC 2508, if dI=0 the FULL_HEADER packet given here is intended
   decompressor does not change deltaI. However, in contrast to be
   the consistent with RFC
   2508, if dT=0 the definition given decompressor KEEPS THE CURRENT deltaT in [3].  Full details on
   design choices are given there.

   The format of the FULL_HEADER
   context (DOES NOT set deltaT to 0).

   An enhanced COMPRESSED_UDP packet is the same as that of the
   original packet.  In the IPv4 case, this is usually an IP header,
   followed by a UDP header and UDP payload that may be an RTP header
   and its payload.  However, the FULL_HEADER packet may also carry IP
   encapsulated packets, similar in which case there would be two IP headers
   followed by UDP contents and possibly RTP.  Or in the case of IPv6, the packet
   may be built of
   behavior to a COMPRESSED_RTP packet, but it has more flag bits, some combination
   of IPv6 and IPv4 headers.  Each
   successive which correspond to absolute values for RTP header is indicated by the type field fields.

   COMPRESSED_UDP with individual RTP fields, when F=1:

                0   1   2   3   4   5   6   7
              +...............................+
              :   msb of the previous
   header, as usual.

   The FULL_HEADER packet differs from the corresponding normal IPv4 or
   IPv6 packet in that it must also carry the compression session context ID and
   the 4-bit sequence number.  In order to avoid expanding the size   :  (if 16-bit CID)
              +-------------------------------+
              |   lsb of
   the header, these values are inserted into length fields in the IP
   and UDP headers since the actual length may be inferred from the
   length provided by the session context ID   |
              +---+---+---+---+---+---+---+---+
              |F=1| I |dT |dI | link layer.  Two 16-bit length fields are
   needed; these are taken from the first two available headers sequence |
              +---+---+---+---+---+---+---+---+
              | M | S | T | P |      CC       |
              +---+---+---+---+---------------+
              :                               :
              +         UDP checksum          +  (if nonzero in the
   packet.  That is, for an IPv4/UDP packet, the first length field is
   the total length field of the context)
              :                               :
              +...............................+
              :                               :
              :        "RANDOM" fields        :  (if encapsulated)
              :                               :
              +...............................+
              :         delta IPv4 header, and ID         :  (if dI = 1)
              +...............................+
              :      delta RTP timestamp      :  (if dT = 1)
              +...............................+
              :                               :
              +           IPv4 ID             +  (if I = 1)
              :                               :
              +...............................+
              :                               :
              +     RTP sequence number       +  (if S = 1)
              :                               :
              +...............................+
              :                               :
              +                               +
              :                               :
              +         RTP timestamp         +  (if T = 1)
              :                               :
              +                               +
              :                               :
              +...............................+
              :       RTP payload type        :  (if P = 1)
              +...............................+
              :                               :
              :           CSRC list           :  (if CC > 0)
              :                               :
              +...............................+
              :                               :
              :      RTP header extension     :  (if X set in context)
              :                               :
              +-------------------------------+
              |                               |
              /           RTP data            /
              /                               /
              |                               |
              +-------------------------------+
              :            padding            :  (if P set in context)
              +...............................+
   Usage for the second enhanced COMPRESSED_UDP packet:

   It is useful for the
   length field of the UDP header.  For an IPv4 encapsulated packet, the
   first length field would come from compressor to periodically refresh the total length field state of
   the
   first IP header, and the second length field would come from the
   total length field of decompressor to avoid having the second IP header.

   As specified decompressor send CONTEXT_STATE
   messages in Sections 5.3.2 of [3], the position case of unrecoverable packet loss. Using the context ID
   (CID) flags
   F=0 and 4-bit sequence number varies depending upon whether 8- or
   16-bit context IDs have been selected, as shown in I=1, dI=1, dT=1, the following
   diagram (16 bits wide, with COMPRESSED_UDP packet refreshes all the most-significant bit
   context parameters.

   When compression is done over a lossy link with a long round trip
   delay, we want to the left):

           For 8-bit context ID:

           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |0|1| Generation|      CID      |  First length field
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |            0          |  seq  |  Second length field
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           For 16-bit minimize context ID:

           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |1|1| Generation|   0   |  seq  |  First length field
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |              CID              |  Second length field
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The first bit in the first length field indicates invalidation. If the length of delta values
   are changing frequently, the
   CID.  The length of context might get invalidated often. In
   such cases the CID MUST either be constant for all contexts
   or two additional distinct packet types MUST be provided compressor may choose to
   separately indicate COMPRESSED_UDP always send absolute values
   and COMPRESSED_RTP packet formats never delta values, using COMPRESSED_UDP packets with 8- the flags
   F=1, and 16-bit CIDs.  The second bit any of S, T, I as necessary.

2.2 CRTP Headers Checksum

   RFC 2508, in Section 3.3.5, describes how the first length field is
   1 UDP checksum may be
   used to indicate that validate header reconstruction periodically or when the 4-bit sequence number is present, as
   'twice' algorithm is always
   the case for this IP/UDP/RTP compression scheme.

   The generation field used. When a UDP checksum is used with IPv6 for COMPRESSED_NON_TCP packets
   as described not present (has
   value zero) in [3].  For IPv4-only implementations that do a stream, such validation would not use
   COMPRESSED_NON_TCP packets, be possible. To
   cover that case, this enhanced CRTP provides an option whereby the
   compressor SHOULD set the generation
   value to zero.  For consistent operation between IPv4 and IPv6, the
   generation value is stored in MAY replace the context when it null UDP checksum with a 16-bit headers
   checksum (HDRCKSUM) which is received subsequently removed by the
   decompressor, and the most recent value is returned
   decompressor after validation.

   A new flag C in the
   CONTEXT_STATE packet.

   When a FULL_HEADER packet is received, the complete packet, as specified below,
   indicates when set of headers is
   stored into the context selected by the that all COMPRESSED_UDP and COMPRESSED_RTP
   packets sent in that context ID. will have HDRCKSUM inserted. The 4-bit
   sequence number is also stored in the context, thereby
   resynchronizing
   compressor MAY set the decompressor to C flag when UDP packet carried in the compressor.

   When COMPRESSED_NON_TCP packets are used,
   FULL_HEADER packet originally contained a checksum value of zero.
   If the 4-bit sequence number C flag is inserted into set, the "Data Field" of that FULL_HEADER packet and itself MUST also have
   the D bit is set
   as described HDRCKSUM inserted. If a packet in Section 6 of [3].  When the same stream subsequently
   arrives at the compressor with a UDP checksum present, then a COMPRESSED_NON_TCP new
   FULL_HEADER packet
   is received, MUST be sent with the generation number is compared flag cleared to re-
   establish the value stored context.

   The HDRCKSUM is calculated in the context.  If they are same way as a UDP checksum except
   that it does not cover all of the same, UDP data. That is, the context HDRCKSUM is not up to date
   and MUST be refreshed by a FULL_HEADER packet.  If
   the generation
   does match, then 16-bit one's complement of the compressed IP and UDP one's complement sum of the
   pseudo-IP header information, (as defined for UDP), the
   4-bit sequence number, UDP header, and the (potential) RTP header first
   12 bytes of the UDP data which are all stored
   into assumed to hold the saved context. fixed part of
   an RTP header. The amount extended part of memory required to store the context RTP header and the RTP data
   will vary
   depending upon how many encapsulating headers are not be included in the
   FULL_HEADER packet. HDRCKSUM. The compressor and decompressor MAY negotiate a
   maximum header size.

3.3.2.  COMPRESSED_RTP packet format

   When the second-order difference of the RTP header from packet to
   packet HDRCKSUM is zero, placed in the decompressor can reconstruct a
   COMPRESSED_UDP or COMPRESSED_RTP packet simply by
   adding where a UDP checksum would
   have been. The decompressor MUST zero out the stored first-order differences to the stored uncompressed
   header representing UDP checksum field in
   the previous packet.  All that need reconstructed packets.

   For a non-RTP context, there may fewer than 12 UDP data bytes
   present. The IP and UDP headers may still be
   communicated compressed into a
   COMPRESSED_UDP packet. For this case, the HDRCKSUM is calculated
   over the session context identifier and a small sequence
   number (not related to pseudo-IP header, the RTP sequence number) to maintain
   synchronization UDP header, and detect packet loss between the compressor and
   decompressor. UDP data bytes
   that are present. If the second-order difference number of the RTP header data bytes is not odd, then a zero
   padding byte is appended for some
   fields, the new first-order difference for just those fields is
   communicated using a compact encoding. purpose of calculating the
   checksum, but not transmitted.

   The new first-order
   difference values are added to HDRCKSUM does not validate the corresponding fields in RTP data. If the
   uncompressed header link layer is
   configured to deliver packets without checking for errors, then
   errors in the decompressor's session context, RTP data will not be detected. Over such links, the
   compressor SHOULD add the HDRCKSUM if a UDP checksum is not present,
   and are
   also stored explicitly in the context to be added decompressor SHOULD validate each reconstructed packet to
   make sure that at least the headers are correct. This ensures that
   the
   corresponding fields again on each subsequent packet in which will be delivered to the
   second-order difference right destination. If only
   HDRCKSUM is zero.  Each time available, the first-order
   difference changes, RTP data will be delivered even if it is transmitted and stored
   includes errors. This might be a desirable feature for applications
   that can tolerate errors in the context.

   In practice, the only fields RTP data. The same holds for which it is useful to store the
   first-order difference are the IPv4 ID field and
   extended part of the RTP timestamp.
   For header.

   Here is the RTP sequence number field, the usual increment is 1.  If the
   sequence number changes by other than 1, the difference must be
   communicated but does not set the expected difference for format of the next
   packet.  Instead, FULL_HEADER length fields with the expected first-order difference remains fixed
   at 1 so new
   flag C to indicate that the difference need not a header checksum will be explicitly communicated on
   the next packet assuming it is added in order.

   For the RTP timestamp, when a FULL_HEADER, COMPRESSED_NON_TCP or
   COMPRESSED_UDP packet and COMPRESSED_RTP packets:

   For 8-bit context ID:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|1| Generation|      CID      |  First length field
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            0        |C|  seq  |  Second length field
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  C=1: HDRCKSUM will be added

   For 16-bit context ID:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|1| Generation| 0   |C|  seq  |  First length field
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  C=1: HDRCKSUM will be added

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              CID              |  Second length field
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.3 CRTP operation in 'N' mode

   The 'N' mode is sent to refresh the RTP state, a method of operation where the stored
   first-order difference is initialized compressor tries to zero.  If
   keep the timestamp decompressor in sync by sending changes multiple times. The
   'N' is a number that represents the same on the next packet (e.g., same video frame), then the
   second-order difference is zero.  Otherwise, quality of the difference link between the timestamps of
   hosts, and it means that the two probability of more than N adjacent
   packets getting lost on this link is transmitted as the new first-
   order difference to be added to the timestamp in the uncompressed
   header stored small. For every change in a
   full value or a delta value, if the decompressor's context and also stored as compressor includes the
   first-order difference change
   in that context.  Each time the first-order
   difference changes on subsequent N+1 consecutive packets, that difference there is again
   transmitted and used to update a very good chance that the context.

   Similarly, since
   compressor and decompressor can stay in sync using the IPv4 ID field frequently increments by one, 'twice'
   algorithm. CONTEXT_STATE packets should also be repeated N+1 times
   (using the
   first-order difference for that field same sequence number). It is initialized up to one when the
   state is refreshed by implementation to
   find a FULL_HEADER packet, or when scheme to derive an appropriate N for a
   COMPRESSED_NON_TCP packet is sent since it carries the ID field in
   uncompressed form.  Thereafter, whenever the first-order difference
   changes, it is transmitted and stored in the context.

   A bit mask will link.

   This scheme may be used at any time and does not require
   negotiation.

   Some short notations:

   FH    FULL_HEADER
   CR    COMPRESSED_RTP
   CU    COMPRESSED_UDP

   Here is an example to indicate which fields have changed by
   other than the expected difference.  In addition to the small link
   sequence number, demonstrate the list usage of items to be conditionally communicated
   in the compressed IP/UDP/RTP header is as follows:

      I = IPv4 packet ID (always 0 if no IPv4 header)
      U = UDP checksum
      M = RTP marker bit
      S = RTP sequence number
      T = RTP timestamp
      L = RTP CSRC count and list

   If 4 bits are needed for N scheme.
   In this stream the link sequence number to get audio codec sends a reasonable
   probability of loss detection, sample every 10 milliseconds
   The first talkspurt is 1 second long. Then there are too few bits remaining to
   assign one bit to each 2 seconds of these items and still fit them all into
   silence, then another talkspurt. We also assume in this example that
   the IP ID field does not increment at a
   single byte to go along with constant rate because the context ID.

   It
   host is not necessary to explicitly carry generating other uncorrelated traffic streams at the U bit to indicate same
   time and therefore the
   presence of delta IP ID changes for each packet.

   When there is no loss on the UDP checksum because a source will typically include
   check-sums on all link, we can use COMPRESSED_RTP packets of a session or none of them.  When the
   session state is initialized with an uncompressed header, if there is
   a nonzero checksum present, an unencoded 16-bit checksum will be
   inserted into the compressed header
   in all subsequent packets until
   this setting is changed by sending another uncompressed packet.

   Of the remaining items, the L bit for the CSRC count following sequence:

   seq Time pkt    updates and list may be comments
    #       type
   1   10   FH
   2   20   CR     dI dT=10
   3   30   CR     dI
   4   40   CR     dI
   ...
   100 1000 CR     dI

   101 3010 CR     dI dT=2010
   102 3020 CR     dI dT=10
   103 3030 CR     dI
   104 3040 CR     dI
   ...

   In the one least frequently used.  Rather than dedicating above sequence, if a bit in the
   mask to indicate CSRC change, an unusual combination of the other
   bits may be used instead.  This bit combination is denoted MSTI.  If
   all four of the bits for the IP packet ID, RTP marker bit, RTP
   sequence number and RTP timestamp are set, this is a special case
   indicating an extended form of the compressed RTP header will follow.
   That header will include an additional byte containing the real
   values of the four bits plus the CC count.  The CSRC list, of length
   indicated by the CC count, lost we cannot recover
   ('twice' will be included just as it appears in the
   uncompressed RTP header.

   The other fields of not work due to the RTP header (version, P bit, X bit, payload
   type unpredictable IP ID) and SSRC identifier) are assumed to remain relatively constant.
   In particular, the SSRC identifier is defined to be constant for a
   given
   context because it must be invalidated.

   Here is one of the factors selecting the context.
   If any of same example in 'N' mode, when N=2. Note that the other fields change,
   compressor only sends the uncompressed RTP header MUST
   sent as described in Section 3.3.3.

   The following diagram shows the compressed IP/UDP/RTP header with
   dotted lines indicating fields that are conditionally present.  The
   most significant bit is numbered 0.  Multi-byte fields are sent in
   network byte order (most significant byte first).  The delta fields
   are often a single byte as shown but may be two or three bytes
   depending upon absolute IP ID (I) and not the delta value as explained in Section 3.3.4.

             0 IP ID
   (dI).

   seq Time pkt  CU flags            updates and comments
    #       type F I dT dI M S T P
   1   10   FH
   2   20   FH                             repeat constant fields
   3   30   FH                             repeat constant fields
   4   40   CU   1 1  1  0 M 0 1 0   I T=40 dT=10
   5   50   CU   1 1  1  0 M 0 1 0   I T=50 dT=10 repeat update T & dT
   6   7
           +...............................+
           :   msb of session context ID   :  (if 16-bit CID)
           +-------------------------------+
           |   lsb of session context ID   |
           +---+---+---+---+---+---+---+---+
           |   60   CU   1 1  1  0 M | S | 0 1 0   I T=60 dT=10 repeat update T | & dT
   7   70   CU   1 1  0  0 M 0 0 0   I | link sequence |
           +---+---+---+---+---+---+---+---+
           :                               :
           +         UDP checksum          +  (if nonzero in context)
           :                               :
           +...............................+
           :                               :
           +        "RANDOM" fields        +  (if encapsulated)
           :                               :
           +...............................+
           : M'| S'| T'| I'|      CC       :  (if MSTI = 1111)
           +...............................+
           :         delta IPv4 ID         :  (if
   8   80   CU   1 1  0  0 M 0 0 0   I or I' = 1)
           +...............................+
           :      delta RTP sequence       :  (if S or S' = 1)
           +...............................+
           :      delta RTP timestamp      :  (if T or T' = 1)
           +...............................+
           :                               :
           :           CSRC list           :  (if MSTI = 1111
           :                               :   and CC nonzero)
           :                               :
           +...............................+
           :                               :
           :      RTP header extension     :  (if X set in context)
           :                               :
           :                               :
           +-------------------------------+
           |                               |
           |            RTP data           |
           /                               /
           /                               /
           |                               |
           +-------------------------------+
           :            padding            :  (if P set in context)
           +...............................+

   When more than one IPv4 header
   ...
   100 1000 CU   1 1  0  0 M 0 0 0   I

   101 3010 CU   1 1  0  0 M 0 1 0   I T=3010  T changed, keep deltas
   102 3020 CU   1 1  0  0 M 0 1 0   I T=3020  repeat updated T
   103 3030 CU   1 1  0  0 M 0 1 0   I T=3030  repeat updated T
   104 3040 CU   1 1  0  0 M 0 0 0   I
   105 3050 CU   1 1  0  0 M 0 0 0   I
   ...

   This second example is present in the context as
   initialized by the FULL_HEADER packet, then same sequence, but assuming the delta IP
   ID fields of
   encapsulating headers MUST be sent as absolute values as described in
   [3].  These fields are identified as "RANDOM" fields.  They are
   inserted into is constant.  First the COMPRESSED_RTP packet in basic CRTP for a lossless link:

   seq Time pkt    updates and comments
    #       type
   1   10   FH
   2   20   CR     dI dT=10
   3   30   CR
   4   40   CR
   ...
   100 1000 CR

   101 3010 CR     dT=2010
   102 3020 CR     dT=10
   103 3030 CR
   104 3040 CR
   ...

   For the same order as they
   appear equivalent sequence in 'N' mode, the original headers, immediately following the UDP
   checksum if present or more efficient
   COMPRESSED_RTP packet can still be used once the MSTI byte if not, as shown in the diagram.
   Only if an IPv4 packet immediately precedes the UDP header will the
   IP ID of that header be sent differentially, i.e., potentially with
   no bits if the second difference is zero, or as a delta IPv4 ID field
   if not.  If there is not an IPv4 header immediately preceding the UDP
   header, then the I bit MUST be 0 and no delta IPv4 ID field will be
   present.

3.3.3.  COMPRESSED_UDP packet format

   If there is a change in any of the fields of the RTP header that deltas are
   normally constant (such as the payload type field), then an
   uncompressed RTP header MUST be sent.  If the IP all
   established:

   seq Time pkt  CU flags            updates and UDP headers do
   not also require updating, this RTP header MAY be carried in a
   COMPRESSED_UDP packet rather than a FULL_HEADER packet.  The
   COMPRESSED_UDP packet has the same format as the COMPRESSED_RTP
   packet except that the M, comments
    #       type F I dT dI M S and T bits are always 0 and the
   corresponding delta fields are never included:

             0 P
   1   10   FH
   2   20   FH                             repeat constant fields
   3   30   FH                             repeat constant fields
   4   40   CU   1 1  1  1 M 0 1 0   I dI T=40 dT=10
   5   50   CU   1 1  1  1 M 0 1 0   I dI T=50 dT=10  repeat updates
   6   60   CU   1 1  1  1 M 0 1 0   I dI T=60 dT=10  repeat updates
   7
           +...............................+
           :   msb of session context ID   :  (if 16-bit CID)
           +-------------------------------+
           |   lsb of session context ID   |
           +---+---+---+---+---+---+---+---+
           |   70   CR
   8   80   CR
   ...
   100 1000 CR

   101 3010 CU   1 0 |  0 |  0 | I | link sequence |
           +---+---+---+---+---+---+---+---+
           :                               :
           +         UDP checksum          +  (if nonzero in context)
           :                               :
           +...............................+
           :                               :
           +        "RANDOM" fields        +  (if encapsulated)
           :                               :
           +...............................+
           :         delta IPv4 ID         :  (if I = 1)
           +-------------------------------+
           |           UDP data            |
           :   (uncompressed RTP header)   :

   Note that this constitutes a form of IP/UDP header compression
   different from COMPRESSED_NON_TCP packet type defined in [3].  The
   motivation is to allow reaching the target of two bytes when UDP
   checksums are disabled, as IPv4 allows.  The protocol in [3] does not
   use differential coding for UDP packets, so in the IPv4 case, two
   bytes of IP ID, and two bytes of UDP checksum if nonzero, would
   always be transmitted in addition to two bytes of compression prefix.
   For IPv6, the COMPRESSED_NON_TCP packet type MAY be used instead.

3.3.4.  Encoding of differences

   The delta fields in the COMPRESSED_RTP and COMPRESSED_UDP packets are
   encoded with a variable-length mapping for compactness of the more
   commonly-used values.  A default encoding is specified below, but it
   is RECOMMENDED that implementations use a table-driven delta encoder
   and decoder to allow negotiation of a table specific for each session
   if appropriate, possibly even an optimal Huffman encoding.  Encodings
   based on sequential interpretation of the bit stream, of which this
   default table and Huffman encoding are examples, allow a reasonable
   table size and may result in an execution speed faster than a non-
   table-driven implementation with explicit tests for ranges of values.

   The default delta encoding is specified in the following table.  This
   encoding was designed to efficiently encode the small changes that
   may occur in the IP ID and in RTP sequence number when packets are
   lost upstream from the compressor, yet still handling most audio and
   video deltas in two bytes.  The column on the left is the decimal
   value to be encoded, and the column on the right is the resulting
   sequence of bytes shown in hexadecimal and in the order in which they
   are transmitted (network byte order).  The first and last values in
   each contiguous range are shown, with ellipses in between:

         Decimal  Hex

          -16384  C0 00 00
               :  :
            -129  C0 3F 7F
            -128  80 00
               :  :
              -1  80 7F
               0  00
               :  :
             127  7F
             128  80 80
               :  :
           16383  BF FF
           16384  C0 40 00
               :  :
         4194303  FF FF FF

   For positive values, a change of zero through 127 is represented
   directly in one byte.  If the most significant two bits of the byte
   are 10 or 11, this signals an extension to a two- or three-byte
   value, respectively.  The least significant six bits of the first
   byte are combined, in decreasing order of significance, with the next
   one or two bytes to form a 14- or 22-bit value.

   Negative deltas may occur when packets are misordered or in the
   intentionally out-of-order RTP timestamps on MPEG video [5].  These
   events are less likely, so a smaller range of negative values is
   encoded using otherwise redundant portions of the positive part of
   the table.

   A change in the RTP timestamp value less than -16384 or greater than
   4194303 forces the RTP header to be sent uncompressed using a
   FULL_HEADER, COMPRESSED_NON_TCP or COMPRESSED_UDP packet type.  The
   IP ID and RTP sequence number fields are only 16 bits, so negative
   deltas for those fields SHOULD be masked to 16 bits and then encoded
   (as large positive 16-bit numbers).

3.3.5.  Error Recovery

   Whenever the 4-bit sequence number for a particular context
   increments by other than 1, except when set by a FULL_HEADER or
   COMPRESSED_NON_TCP packet, the decompressor MUST invalidate that
   context and send a CONTEXT_STATE packet back to the compressor
   indicating that the context has been invalidated.  All packets for
   the invalid context MUST be discarded until a FULL_HEADER or
   COMPRESSED_NON_TCP packet is received for that context to re-
   establish consistent state (unless the "twice" algorithm is used as
   described later in this section).  Since multiple compressed packets
   may arrive in the interim, the decompressor SHOULD NOT retransmit the
   CONTEXT_STATE packet for every compressed packet received, but
   instead SHOULD limit the rate of retransmission to avoid flooding the
   reverse channel.

   When an error occurs on the link, the link layer will usually discard
   the packet that was damaged (if any), but may provide an indication
   of the error.  Some time may elapse before another packet is
   delivered for the same context, and then that packet would have to be
   discarded by the decompressor when it is observed to be out of
   sequence, resulting in at least two packets lost.  To allow faster
   recovery if the link does provide an explicit error indication, the
   decompressor MAY optionally send an advisory CONTEXT_STATE packet
   listing the last valid sequence number and generation number for one
   or more recently active contexts (not necessarily all).  For a given
   context, if the compressor has sent no compressed packet with a
   higher sequence number, and if the generation number matches the
   current generation, no corrective action is required.  Otherwise, the
   compressor MAY choose to mark the context invalid so that the next
   packet is sent in FULL_HEADER or COMPRESSED_NON_TCP mode (FULL_HEADER
   is required if the generation doesn't match).  However, note that if
   the link round-trip-time is large compared to the inter-packet
   spacing, there may be several packets from multiple contexts in
   flight across the link, increasing the probability that the sequence
   numbers will already have advanced when the CONTEXT_STATE packet is
   received by the compressor.  The result could be that some contexts
   are invalidated unnecessarily, causing extra bandwidth to be
   consumed.

   The format of the CONTEXT_STATE packet is shown in the following
   diagrams.  The first byte is a type code to allow the CONTEXT_STATE
   packet type to be shared by multiple compression schemes within the
   general compression framework specified in [3].  The contents of the
   remainder of the packet depends upon the compression scheme.  For the
   IP/UDP/RTP compression scheme specified here, the remainder of the
   CONTEXT_STATE packet is structured as a list of blocks to allow the
   state for multiple contexts to be indicated, preceded by a one-byte
   count of the number of blocks.

   Two type code values are used for the IP/UDP/RTP compression scheme.
   The value 1 indicates that 8-bit session context IDs are being used:

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           | 1 = IP/UDP/RTP with 8-bit CID |
           +---+---+---+---+---+---+---+---+
           |         context count         |
           +---+---+---+---+---+---+---+---+
           +---+---+---+---+---+---+---+---+
           |       session context ID      |
           +---+---+---+---+---+---+---+---+
           | I | 0 | 0 | 0 |    sequence   |
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+
                          ...
           +---+---+---+---+---+---+---+---+
           |       session context ID      |
           +---+---+---+---+---+---+---+---+
           | I | 0 | 0 | 0 |    sequence   |
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+

   The value 2 indicates that 16-bit session context IDs are being used.
   The session context ID is sent in network byte order (most
   significant byte first):

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           | 2 = IP/UDP/RTP with 16-bit CID|
           +---+---+---+---+---+---+---+---+
           |         context count         |
           +---+---+---+---+---+---+---+---+
           +---+---+---+---+---+---+---+---+
           |                               |
           +       session context ID      +
           |                               |
           +---+---+---+---+---+---+---+---+
           | I | 0 | 0 | 0 |    sequence   |
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+
                          ...
           +---+---+---+---+---+---+---+---+
           |                               |
           +       session context ID      +
           |                               |
           +---+---+---+---+---+---+---+---+
           | I | 0 | 0 | 0 |    sequence   |
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+

   The bit labeled "I" is set to one for contexts that have been marked
   invalid and require a FULL_HEADER of COMPRESSED_NON_TCP packet to be
   transmitted.  If the I bit is zero, the context state is advisory.
   The I bit is set to zero to indicate advisory context state that MAY
   be sent following a link error indication.

   Since the CONTEXT_STATE packet itself may be lost, retransmission of
   one or more blocks is allowed.  It is expected that retransmission
   will be triggered only by receipt of another packet, but if the line
   is near idle, retransmission MAY be triggered by a relatively long
   timer (on the order of 1 second).

   If a CONTEXT_STATE block for a given context is retransmitted, it may
   cross paths with the FULL_HEADER or COMPRESSED_NON_TCP packet
   intended to refresh that context.  In that case, the compressor MAY
   choose to ignore the error indication.

   In the case where UDP checksums are being transmitted, the
   decompressor MAY attempt to use the "twice" algorithm described in
   section 10.1 of [3].  In this algorithm, the delta is applied more
   than once on the assumption that the delta may have been the same on
   the missing packet(s) and the one subsequently received.  Success is
   indicated by a checksum match.  For the scheme defined here, the
   difference in the 4- bit sequence number tells number of times the
   delta must be applied.  Note, however, that there is a nontrivial
   risk of an incorrect positive indication.  It may be advisable to
   request a FULL_HEADER or COMPRESSED_NON_TCP packet even if the
   "twice" algorithm succeeds.

   Some errors may not be detected, for example if 16 packets are lost
   in a row and the link level does not provide an error indication.  In
   that case, the decompressor will generate packets that are not valid.
   If UDP checksums are being transmitted, the receiver will probably
   detect the invalid packets and discard them, but the receiver does
   not have any means to signal the decompressor.  Therefore, it is
   RECOMMENDED that the decompressor verify the UDP checksum
   periodically, perhaps one out of 16 packets.  If an error is
   detected, the decompressor would invalidate the context and signal
   the compressor with a CONTEXT_STATE packet.

3.4.  Compression of RTCP Control Packets

   By relying on the RTP convention that data is carried on an even port
   number and the corresponding RTCP packets are carried on the next
   higher (odd) port number, one could tailor separate compression
   schemes to be applied to RTP and RTCP packets.  For RTCP, the
   compression could apply not only to the header but also the "data",
   that is, the contents of the different packet types.  The numbers in
   Sender Report (SR) and Receiver Report (RR) RTCP packets would not
   compress well, but the text information in the Source Description
   (SDES) packets could be compressed down to a bit mask indicating each
   item that was present but compressed out (for timing purposes on the
   SDES NOTE item and to allow the end system to measure the average
   RTCP packet size for the interval calculation).

   However, in the compression scheme defined here, no compression will
   be done on the RTCP headers and "data" for several reasons (though
   compression SHOULD still be applied to the IP and UDP headers).
   Since the RTP protocol specification suggests that the RTCP packet
   interval be scaled so that the aggregate RTCP bandwidth used by all
   participants in a session will be no more than 5% of the session
   bandwidth, there is not much to be gained from RTCP compression.
   Compressing out the SDES items would require a significant increase
   in the shared state that must be stored for each context ID.  And, in
   order to allow compression when SDES information for several sources
   was sent through an RTP "mixer", it would be necessary to maintain a
   separate RTCP session context for each SSRC identifier.  In a session
   with more than 255 participants, this would cause perfect thrashing
   of the context cache even when only one participant was sending data.

   Even though RTCP is not compressed, the fraction of the total
   bandwidth occupied by RTCP packets on the compressed link remains no
   more than 5% in most cases, assuming that the RTCP packets are sent
   as COMPRESSED_UDP packets.  Given that the uncompressed RTCP traffic
   consumes no more than 5% of the total session bandwidth, then for a
   typical RTCP packet length of 90 bytes, the portion of the compressed
   bandwidth used by RTCP will be no more than 5% if the size of the
   payload in RTP data packets is at least 108 bytes.  If the size of
   the RTP data payload is smaller, the fraction will increase, but is
   still less than 7% for a payload size of 37 bytes.  For large data
   payloads, the compressed RTCP fraction is less than the uncompressed
   RTCP fraction (for example, 4% at 1000 bytes).

3.5.  Compression of non-RTP UDP Packets

   As described earlier, the COMPRESSED_UDP packet MAY be used to
   compress UDP packets that don't carry RTP.  Whatever data follows the
   UDP header is unlikely to have some constant values in the bits that
   correspond to usually constant fields in the RTP header.  In
   particular, the SSRC field would likely change.  Therefore, it is
   necessary to keep track of the non-RTP UDP packet streams to avoid
   using up all the context slots as the "SSRC field" changes (since
   that field is part of what identifies a particular RTP context).
   Those streams may each be given a context, but the encoder would set
   a flag in the context to indicate that the changing SSRC field should
   be ignored and COMPRESSED_UDP packets should always be sent instead
   of COMPRESSED_RTP packets.

4.  Enhancements for links with high bit error rate and long round trip delay

4.1 The negative cache stream flag

Certain streams, known or suspected to not be RTP, can be placed in a "negative
cache" at the compressor, so only the IP and UDP headers are compressed. It is
beneficial to notify the decompressor that the compressed stream is in the
negative cache: for such streams the context is shorter - there is no need to
include the RTP header, and all RTP-related calculations can be avoided.

In this enhancement, a new flag bit "N" is added to the FULL_HEADER packet that
initializes a context at the decompressor.  The bit occupied by the new flag was
previously always set to zero.  If the N flag is set to 1, this indicates that
no COMPRESSED_RTP packets will be transmitted in this context.  This flag is
only an optimization and the decompressor may choose to ignore it.

Format of the FULL_HEADER length fields with the negative cache flag:

For 8-bit context ID:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Generation|      CID      |  First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            0        |N|  seq  |  Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  N=1: negative cache stream

For 16-bit context ID:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Generation|   0 |N|  seq  |  First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  N=1: negative cache stream

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              CID              |  Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2 Reject a new compressed stream

In a point to point link the two nodes can agree on the number of compressed
sessions they are prepared to support for this link. In an end-to-end scheme a
host may have compressed sessions with many hosts and eventually may run out of
resources.  When the end-to-end tunnel is negotiated, the number of contexts
needed may not be predictable.  This enhancement allows the negotiated number of
contexts to be larger than could be accommodated if many tunnels are
established.  Then, as context resources are consumed, an attempt to set up a
new context may be rejected.
The compressor initiates a compression of a stream by sending a FULL_HEADER
packet. Currently if the decompressor has insufficient resources to decompress
the new stream, it can send a CONTEXT_STATE packet to invalidate the newly
compressed stream. The compressor does not know the reason for the invalidation:
usually this happens when the decompressor gets out of synchronization due to
packet loss. The compressor will most likely reattempt to compress this stream
by sending another FULL_HEADER.
This enhancement specifies that the decompressor may reject the compression of a
stream by sending a REJECT message to the compressor. A REJECT message tells the
compressor to stop compressing this stream.
The REJECT message is a CONTEXT_STATE message with an additional flag:

   Type code = 1 :CONTEXT_STATE for 8-bit CID streams
   Type code = 2 :  CONTEXT_STATE for16-bit CID streams

Here is the format of CONTEXT_STATE packets with REJECT flags:

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           |Type code=1: CS, 8-bit CID |
           +---+---+---+---+---+---+---+---+
           |         context count         |
           +---+---+---+---+---+---+---+---+
           |       session context ID      |
           +---+---+---+---+---+---+---+---+
           | 1 |R=1| 0 | 0 |    sequence   |   R is the REJECT flag
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+
                         . . .
           +---+---+---+---+---+---+---+---+
           |       session context ID      |
           +---+---+---+---+---+---+---+---+
           | 1 |R=1| 0 | 0 |    sequence   |   R is the REJECT flag
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           |Type code=2: CS, 16-bit CID|
           +---+---+---+---+---+---+---+---+
           |         context count         |
           +---+---+---+---+---+---+---+---+
           |                               |
           +       session context ID      +
           |                               |
           +---+---+---+---+---+---+---+---+
           | 1 |R=1| 0 | 0 |    sequence   |   R is the REJECT flag
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+
                         . . .
           +---+---+---+---+---+---+---+---+
           |                               |
           +       session context ID      +
           |                               |
           +---+---+---+---+---+---+---+---+
           | 1 |R=1| 0 | 0 |    sequence   |   R is the REJECT flag
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+

The session CID, sequence and generation are taken from the FULL_HEADER.

The compressor may decide to wait for a while before attempting to compress
additional streams destined to the rejecting host.

4.3 Including IP ID in the UDP checksum

A UDP checksum can be used by the decompressor to verify validity of the packet
it reconstructed, especially when the 'twice' algorithm is used. When the
'twice' algorithm was defined in RFC 2507 and subsequently incorporated into RFC
2508, the fact that the IP ID field is not included in the checksum was
overlooked. Since the IP ID field is conveyed with a delta value, accurate
reconstruction of the IP ID field cannot be verified using the current
specifications.

This enhancement modifies the function of the UDP checksum to include the IP ID
value, but only between the compressor and decompressor. That is, when a UDP
checksum is present (nonzero), the compressor will 1's complement subtract the
IP ID value from the UDP checksum before compression and the decompressor will
1's complement add the IP ID value to the UDP checksum after any validation
operations and before delivering the packet further downstream.

4.4 CRTP Headers Checksum

When a UDP checksum is not present (has value zero) in a stream, the compressor
MAY replace it with a 16-bit headers checksum (HDRCKSUM). The HDRCKSUM can be
used to validate the IP ID and all the headers in the reconstructed packet.
Hence it can be used by the decompressor to validate reconstructed packets when
'twice' is used, and to validate every 16'th packet as recommended in RFC2508,
Section 3.3.5.

A new flag in the FULL_HEADER packet, as specified below, indicates when set
that all COMPRESSED_UDP and COMPRESSED_RTP packets sent in that context will
have HDRCKSUM inserted. If a packet in the same stream subsequently arrives at
the compressor with a UDP checksum present, then a new FULL_HEADER packet must
be sent with the flag cleared to re-establish the context.

The HDRCKSUM is calculated in the same way as a UDP checksum, but includes only
the pseudo-IP header (as defined for UDP), the IP ID (as in Section 2.3), the
UDP header and for COMPRESSED_RTP packets, the fixed part of the RTP header
(first 12 bytes). The extended part of the RTP header and the RTP data will not
be included in the HDRCKSUM. The HDRCKSUM is placed in the COMPRESSED_UDP or
COMPRESSED_RTP packets where a UDP checksum would have been.
The decompressor MUST zero out the UDP checksum field in the reconstructed
packets.

The HDRCKSUM does not validate the RTP data. If the link layer is configured to
deliver packets without checking for errors, errors in the RTP data will not be
detected. Over such links, the compressor SHOULD add the HDRCKSUM if a UDP
checksum is not present, and the decompressor SHOULD validate each reconstructed
packet to make sure that at least the headers are correct. This ensures that the
packet will be delivered to the right destination. If only HDRCKSUM is
available, the RTP data will be delivered even if it includes errors.
This might be a desirable feature for applications that can tolerate errors in
the RTP data. Same holds for the extended part of the RTP header.

Here is the format of the FULL_HEADER length fields with the new flag that
indicates that a header checksum will be added in COMPRESSED_UDP and
COMPRESSED_RTP packets:

For 8-bit context ID:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Generation|      CID      |  First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            0      |C|N|  seq  |  Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  C=1: HDRCKSUM will be added

For 16-bit context ID:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Generation| 0 |C|N|  seq  |  First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  C=1: HDRCKSUM will be added

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              CID              |  Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.5 Enhancement to COMPRESSED_UDP packet format (CU*)

The COMPRESSED_UDP packet includes the whole RTP header, so it can restore all
RTP-related parameters at the decompressor. It is also specified to reset the
delta RTP timestamp to zero and the delta RTP sequence number to zero.It can
also convey a new value for the delta IP ID.

It is possible to accommodate some packet loss between the compressor and
decompressor using the "twice" algorithm in RFC 2508, but this requires reliably
communicating the absolute values and the deltas for the differential fields.
The reliability of communication of the absolute values in the RTP header can be
increased by sending a COMPRESSED_UDP packet repeatedly, but this resets the
delta timestamp.
RFC 2508 describes the format of COMPRESSED_UDP as being the same as
COMPRESSED_RTP except that the M, S and T bits are always 0 and the
corresponding delta fields are never included.  This enhancement changes that
specification to say that the T bit may be nonzero to indicate that the RTP
timestamp delta is included explicitly rather than being reset to zero.

Sometimes it is necessary to change just a few fields of the RTP header. A
second part of this enhancement adds more flag bits to the COMPRESSED_UDP packet
to select individual uncompressed fields of the RTP header to be included in the
packet.  Since there are flag bits to indicate inclusion of both delta values
and absolute values, the flag nomenclature is changed.  The original S,T,I bits
which indicate the inclusion of deltas are renamed dS, dT, dI, and the inclusion
of absolute values is indicated by S,T,I.  The M bit is absolute as before.

The format of the flags/sequence byte for the original COMPRESSED_UDP packet is
shown here for reference:

            +---+---+---+---+---+---+---+---+
            | 0 | 0 | 0 |dI | link sequence |
            +---+---+---+---+---+---+---+---+

The new definition of the flags/sequence byte plus an extension flags byte is as
follows, where the new F flag indicates the inclusion of the extension flags
byte:

            +---+---+---+---+---+---+---+---+
            | F | I |dT |dI | link sequence |
            +---+---+---+---+---+---+---+---+
            : M : S : T :pt :      CC       :  (if F = 1)
            +...+...+...+...+...............+

dI = delta IP ID
dT = delta RTP timestamp
I  = absolute IP ID
F  = additional flags byte
M  = marker bit
S  = absolute RTP sequence number
T  = absolute RTP timestamp
pt = RTP payload type
CC = number of CSRC identifiers

Some short notations:

FH    FULL_HEADER
CR    COMPRESSED_RTP
CR+   COMPRESSED_RTP with delta fields
CU    COMPRESSED_UDP
CU*   enhanced COMPRESSED_UDP

When F=0, there is only one flags byte, and the only available flags are: dI, dT
and I.
In this case the packet includes the full RTP header
If dT=0, the decompressor sets deltaT to 0
If dI=0, the decompressor sets deltaI to 1

Some example packet formats will illustrate the use of the new flags.  First, a
'traditional' COMPRESSED_UDP with full RTP header, when F=0:

             0   1   2   3   4   5   6   7
           +...............................+
           :   msb of session context ID   :  (if 16-bit CID)
           +-------------------------------+
           |   lsb of session context ID   |
           +---+---+---+---+---+---+---+---+
           |F=0| I |dT |dI | link sequence |
           +---+---+---+---+---+---+---+---+
           :                               :
           +         UDP checksum          +  (if nonzero in context)
           :                               :
           +...............................+
           :                               :
           +        "RANDOM" fields        +  (if encapsulated)
           :                               :
           +...............................+
           :         delta IPv4 ID         :  (if dI = 1)
           +...............................+
           :      delta RTP timestamp      :  (if dT = 1)
           +...............................+
           :                               :
           +           IPv4 ID             +  (if I = 1)
           :                               :
           +...............................+
           |           UDP data            |
           :   (uncompressed RTP header)   :

When F=1, there is an additional flags byte and the available flags are: dI, dT,
I, M, S, T, pt, CC. In this case the packet does not include the full RTP
header, but includes selected fields from the RTP header as specified by the
flags. The delta values of the context are not reset even if they are not
specified in the packet:
If dT=0, the decompressor KEEPS THE CURRENT deltaT
   (and DOES NOT set the deltaT to 0)
If dI=0, the decompressor KEEPS THE CURRENT deltaI
   (and DOES NOT set the the deltaI to 1)

A CU* packet is similar in contents and behavior to a CR packet, but it has more
flag bits, some of which correspond to absolute values for RTP header fields.

COMPRESSED_UDP with individual RTP fields, when F=1 :

             0   1   2   3   4   5   6   7
           +...............................+
           :   msb of session context ID   :  (if 16-bit CID)
           +-------------------------------+
           |   lsb of session context ID   |
           +---+---+---+---+---+---+---+---+
           |F=1| I |dT |dI | link sequence |
           +---+---+---+---+---+---+---+---+
           : M : S : T :pt :      CC       :
           +...+...+...+...+...............+
           :                               :
           +         UDP checksum          +  (if nonzero in context)
           :                               :
           +...............................+
           :                               :
           :        "RANDOM" fields        :  (if encapsulated)
           :                               :
           +...............................+
           :         delta IPv4 ID         :  (if dI = 1)
           +...............................+
           :      delta RTP timestamp      :  (if dT = 1)
           +...............................+
           :                               :
           +           IPv4 ID             +  (if I = 1)
           :                               :
           +...............................+
           :                               :
           +     RTP sequence number       +  (if S = 1)
           :                               :
           +...............................+
           :                               :
           +                               +
           :                               :
           +         RTP timestamp         +  (if T = 1)
           :                               :
           +                               +
           :                               :
           +...............................+
           :       RTP payload type        :  (if pt = 1)
           +...............................+
           :                               :
           :           CSRC list           :  (if CC > 0)
           :                               :
           +...............................+
           :                               :
           :      RTP header extension     :  (if X set in context)
           :                               :
           +-------------------------------+
           |                               |
           /           RTP data            /
           /                               /
           |                               |
           +-------------------------------+
           :            padding            :  (if P set in context)
           +...............................+

Usage for the CU* packet:

It is useful for the compressor to periodically refresh the state of the
decompressor to avoid having the decompressor send CONTEXT_STATE messages in the
case of unrecoverable packet loss.
Using the flags F=0 I dI dT, this CU* packet refreshes all the context
parameters.

When compression is done over a lossy link with a long round trip delay, we want
to minimize context invalidation. If the delta values are changing frequently,
the context might get invalidated often. In such cases the compressor may choose
to include absolute values in the CRTP packets instead of delta values, using
CU* packets with the flags: F=1, and any of S, T, I as necessary.

4.6 Acknowledgement packet (ACK packet)

The ACK packet will be sent from decompressor to compressor to indicate receipt
of a compressed packet with the ACK'd RTP sequence number.
It's a CONTEXT_STATE packet with type codes 4 and 5.  The ACK packet is to be
used in a separately negotiated mode of operation as described in the next
section.

Type code = 4 :  ACK a packet of a context with 8-bit CID
Type code = 5 :  ACK a packet of a context with 16-bit CID

The format for the ACK packet is:

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           |  Type code=4: ACK, 8-bit CID  |
           +---+---+---+---+---+---+---+---+
           |         context count         |
           +---+---+---+---+---+---+---+---+
           |       session context ID      |
           +---+---+---+---+---+---+---+---+

           |                               |
           +      RTP sequence number      +
           |                               |
           +---+---+---+---+---+---+---+---+
                         . . .
           +---+---+---+---+---+---+---+---+
           |       session context ID      |
           +---+---+---+---+---+---+---+---+

           |                               |
           +      RTP sequence number      +
           |                               |
           +---+---+---+---+---+---+---+---+

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           |  Type code=5: ACK, 16-bit CID |
           +---+---+---+---+---+---+---+---+
           |         context count         |
           +---+---+---+---+---+---+---+---+
           |                               |
           +       session context ID      +
           |                               |
           +---+---+---+---+---+---+---+---+

           |                               |
           +      RTP sequence number      +
           |                               |
           +---+---+---+---+---+---+---+---+
                         . . .
           +---+---+---+---+---+---+---+---+
           |                               |
           +       session context ID      +
           |                               |
           +---+---+---+---+---+---+---+---+

           |                               |
           +      RTP sequence number      +
           |                               |
           +---+---+---+---+---+---+---+---+

4.6.1 CRTP operation in ACK mode

This mode of operation is optional and must be negotiated per link.

4.6.1.1   Description of the ACK mode

The ACK mode is a mode of operation in which the compressor and decompressor
continuously verify that their context states are synchronized. The compressor
repeatedly notifies the decompressor about changes in the context state, until
the decompressor acknowledges reception of the changes by sending ACK packets to
the decompressor.
This effort of synchronizing the context states helps minimize context
invalidation.

The context state shared between the compressor and decompressor includes all
the fields of the uncompressed headers and the first order differences (delta
fields) of the fields that change by a constant value from packet to packet.
Each field follows its known change pattern: either stays constant or is
incremented by its corresponding delta field. Fields that follow their change
pattern are compressed. They are reconstructed by the decompresor from the
context state at the decompressor. Correct decompression of a packet depends on
whether the context state at the compressor when the packet is compressed and
sent is identical to the context state at the decompressor when that packet is
received and decompressed.

When a field changes in a way that is different from its change pattern, the
compressor assigns a new value to the field, and stores it in the context state
at the compressor side. The decompressor must be informed about the change so
that it can update the state on its side to match the state at the compressor.
The compressor notifies the decompressor about such changes by including
information about the changed field in the compressed packet. (for example if dT
was assigned a new value, the compressor can send a CR+ packet that includes
dT). The context is not synchronized until the decompressor receives the packet
that includes the changed field and updates its state accordingly.

The decompressor indicates reception of the change by sending an ACK packet to
the compressor. The ACK packet includes the RTP sequence number of the packet
that it is ACK'ing, so the compressor can identify which packet is ACK'd. The
compressor can't assume that the decompressor received the change until the ACK
packet is received.

Depending on the round trip delay of the link, the compressor might have to send
a few more packets before the ACK from the decompressor arrives. In this case
the compressor must repeat the change in all subsequent packets. Reception of
the ACK is an indication that the decompressor updated its context with the
changed value. Now that their contexts are synchronized again, the compressor
can stop including the changed field in the compressed packets.

The decompressor must be able to recognize the repeat packets (the packets that
repeat the same change and were sent while the compressor was waiting for the
ACK packet). Those repeat packets don't require an ACK.

If in the process of changing some fields additional changes are required, the
compressor will switch to send packets that include all changes. The
decompressor must ACK one of the packets that include all the changes.

The compressor and decompressor must be in full agreement about which packets
must be ACK'd: packets that include changes are larger in size, and if they are
not ACK'd, the changes are repeated in all subsequent packets, and bandwidth is
wasted.

Let's summarize which packets require an ACK:

1. A Packet that assigns a value to any context state field  must be ACK'd. This
includes FH and CU packets because they initialize fields in the context
state.
2. Repeat packets don't require an ACK

How are repeat packets identified?

A packet is considered to be a repeat packet if:
1. It updates the same fields as the previous packet
2. Each field is updated by a value that is equal to the one assigned to this
field in the previous packet plus the corresponding delta for this field,
when applicable.

4.6.1.2   The Random IP ID

The IP ID change pattern is to be incremented by dI. In some implementations,
the IP ID counter is shared across multiple streams, so as a result of the
varying mix of packets the increment for any particular stream is not constant.
When compressing such a stream, the compressor must include in each packet
either dI or I. It is recommended to include I rather then dI because a loss of
a packet that includes a new delta value dI will invalidate the context.
According to the rules set above, each packet will have to be ACK'd.

To correct this we'll define a new change pattern for the IP ID: random value.
The IP ID assumes this change pattern when dI is set to be 0.

We add a rule to the ACK rules:
3. When the value of dI is 0, packets that update only the IP ID field don't
require an ACK.

And add to rule 2 of the repeat packet rules:
2. Each field is updated by a value that is equal to the one assigned to this
field in the previous packet plus the corresponding delta for this field, when
applicable. An exception to this rule is the IP ID field: if the value of dI is
0, the IP ID may be assigned any value.

4.6.1.3   Implementation hints when using the ACK scheme

1. When a delta field is updated, add the matching absolute field too (dT and T,
dI and I). Loss of a packet that updates only the delta value can easily
cause context invalidation.
2. Set dI=0 when the IP ID is changing randomly, and include I in all packets.
3. If you ACK'd a packet, but the number of repeat packets exceed your estimate,
ACK again (your previous ACK was probably lost)

Here is an example to demonstrate the usage of the ACK scheme.
In this stream the audio codec sends a sample every 10 msec
The first talk spurt is 1 second long. Then there are 2 seconds silence, then
another talk spurt.

When there is no loss on the link, we can use the following sequence:
(The deltaID is not constant so we send deltaID in each packet)

seq#  Time  pkt type
1     10    FH
2     20    CR+     dI dT=10
3     30    CR+     dI
4     40    CR+     dI
...
100   1000  CR+     dI

101   3010  CR+     dI dT=2010
102   3020  CR+     dI dT=10
103   3030  CR+     dI
104   3040  CR+     dI
...
In the above sequence if a packet is lost, we cannot recover ('twice' will not
work due to the random IP ID) and the context must be invalidated.

Here is the same sequence using the ACK scheme(CU* is the enhanced CU):

seq#  Time  pkt type  flags
1     10    FH                                       FH must be ACK'd
2     20    FH                                       repeat
ACK 1
3     30    CU*   1 I dT dI M 0 T 0   I T=30 dT=10 dI=0  dI,dT changed
 (packet 3 was lost)                               (I and T sent too)
4     40    CU*   1 I dT dI M 0 T 0   I T=40 dT=10 dI=0  repeat
5     50    CU*   1 I dT dI M 0 T 0   I T=50 dT=10 dI=0  repeat
6     60    CU*   1 I dT dI M 0 T 0   I T=60 dT=10 dI=0  repeat
ACK 4 == got new dI=0 and dT=10 at T=40.
          dI was set to 0, so I does not require an ACK.
          No need to ACK 5 and 6: repeat packets
7     70    CU*   1 I  0 0  M 0 0 0   I
8     80    CU*   1 I  0 0  M 0 0 0   I
...
100   1000  CU*   1 I  0 0  M 0 0 0   I

101   3010  CU*   1 I  0 0  M 0 T 0   I T=3010   T changed, keep deltas!
102   3020  CU*   1 I  0 0  M 0 T 0   I T=3020   repeat
ACK 101 == got new T at sequence 101
           No need to ACK packet 102 because 3010 + dT = 3020
           If 101 is lost, 102 will be ACK'd
103   3030  CU*   1 I  0 0  M 0 0 0   I
104   3040  CU*   1 I  0 0  M 0 0 0   I
...

The same sequences, when delta IP ID is constant:

seq#  Time  pkt type
1     10    FH
2     20    CR+     dI dT=10
3     30    CR
4     40    CR
...
100   1000  CR

101   3010  CR+    dT=2010
102   3020  CR+    dT=10
103   3030  CR
104   3040  CR
...

seq#  Time  pkt type  flags
1     10    FH                                       FH must be ACK'd
2     20    FH                                       repeat
ACK 1
3     30    CU*   1 I dT dI M 0 T 0   I dI T=30 dT=10  dI,dT changed
  (packet 3 was lost)                                 (I and T sent too)
4     40    CU*   1 I dT dI M 0 T 0   I dI T=40 dT=10  repeat
5     50    CU*   1 I dT dI M 0 T 0   I dI T=50 dT=10  repeat
6     60    CU*   1 I dT dI M 0 T 0   I dI T=60 dT=10  repeat
ACK 4 == got new dI and dT=10 at T=40.
          No need to ACK 5 and 6: no changes
7     70    CR
8     80    CR
...
100   1000  CR

101   3010  CU*   1 0  0 0  M 0 T 0   T=3010    T changed, keep deltas!
102   3020  CU*   1 0  0 0  M 0 T 0   T=3020    repeat
ACK 101 == got new T at sequence 101
          No need to ACK packet 102 because 3010 + dT = 3020
          If 101 is lost, 102 will be ACK'd
103   3030  CR
104   3040  CR
...

4.7 Accept a new compressed stream

Lack of any feedback from the decompressor might indicate either that everything
goes well (the stream is decompressed successfully), or that nothing goes well
(the link is down, the decompressor is not functioning, the decompressor is out
of sync but there is no back channel). The compressor initiates a compression of
a stream by sending a FULL_HEADER packet. This enhancement specifies that the
decompressor SHOULD acknowledge the reception of the FULL_HEADER packet by
sending an ACK packet (see 2.6) with the sequence number of the FULL_HEADER
packet. This reassures the compressor that the new compressed stream is received
and decompressed. It also indicates that a back channel exists.

4.8 CRTP operation in 'N' mode

This scheme is similar to the ACK scheme in that the compressor tries to keep
the decompressor in sync by sending changes multiple times. The 'N' is a number
that represents the quality of the link between the hosts, and it means that the
probability of more than 'N' adjacent packets getting lost on this link is
small. For every change in a base value or a delta value, if the compressor
includes the change in N+1 consecutive packets, there is a very good chance that
the compressor and decompressor can  stay in sync using the 'twice' algorithm.
CONTEXT_STATE packets should also be repeated N+1 times (using the same sequence
number).
It is up to the implementation to find a scheme to derive an appropriate N for a
link.

This scheme may be used at any time and does not require negotiation.

Here is the same example in 'N' mode, when N=2 and deltaID is constant:

seq#  Time  pkt type  flags
1     10    FH
2     20    FH                                  repeat constant fields
3     30    FH                                  repeat constant fields
4     40    CU*   1 I dT dI M 0 T 0   I dI T=40 dT=10
5     50    CU*   1 I dT dI M 0 T 0   I dI T=50 dT=10  repeat delta
6     60    CU*   1 I dT dI M 0 T 0   I dI T=60 dT=10  repeat delta
7     70    CR
8     80    CR
...
100   1000  CR

101   3010  CU*   1 0  0 0  M 0 T 0   T=3010    T changed, keep deltas!
102   3020  CU*   1 0  0 0  M 0 T 0   T=3020    repeat updated T
103   3030  CU*   1 0  0 0  M 0 T 0   T=3030    repeat updated T
104   3040  CR
105   3050  CR
...

4.9 Select mode of operation

As link conditions change, it might be necessary to change the mode of operation
from N mode to ACK mode and vice versa. Mode changes are initiated by the
compressor and acknowledged by the decompressor. When acknowledging a request to
move to N mode, the decompressor may suggest a different N to use (for example
based on loss patterns seen by the decompressor).
The decompressor may send multiple acknowledgement packets to one request
packet, e.g. send an ACK-Nmode packet when the decompressor suggests to change
the N that is currently being used.
The compressor determines the N to be used, and it MAY be different than the
value of the parameter N in the REQ-Nmode and ACK-Nmode packets exchanged
between the compressor and decompressor.
If the compressor receives an ACK packet that does not match the current mode,
the compressor SHOULD send another REQ packet to set the right mode. Hence the
compressor can use any of the ACK packets to verify the current mode: if the ACK
does not match the current mode, the compressor will send a REQ to set the mode. M 0 1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+---+---+
           |   Type code=6: Select operation mode  |
           +---+---+---+---+---+---+---+---+---+---+
           |                Opcode                 |
           +---+---+---+---+---+---+---+---+---+---+
           :                Parameter              :
           +.......................................+

Opcode	Mnemonic		Description					Parameter
-------------------------------------------------------------------------------- 0   T=3010  T changed, keep deltas
   102 3020 CU   1		REQ-Nmode		Request to move to N mode		N to be used
  2		ACK-Nmode		Acknowledge move to N mode		N to be used
  3		REQ-ACKmode		Request to move to ACK mode		none
  4		ACK-ACKmode		Acknowledge move to ACK mode		none

4.10 Negotiating usage of enhanced-CRTP and ACK scheme

RFC 2509 [IPCPHP] specifies how the use of CRTP is negotiated on PPP links using
the IP Compression Protocol option of IPCP:

    IPCP option 2: IP compression protocol
    protocol 0x61 indicates RFC 2507 header compression
    sub-option 0  0  0 M 0 1 enables use of COMPRESSED_RTP, COMPRESSED_UDP and
                  CONTEXT_STATE as specified in RFC 2508

For the enhancements defined in this document, two new sub-options are added:

    sub-option 2 (length=2) :  enables use of CRTP with
                               enhancements 4.1 - 4.5 and 4.7
                              (all except ACK mode)
    sub-option 3 (length=2) :  enables use of CRTP with
                               enhancements 4.1 - 4.7 (ACK scheme)

5.  Interaction With Segmentation

   A segmentation scheme may be used in conjunction with RTP header
   compression to allow small, real-time packets to interrupt large,
   presumably non-real-time packets in order to reduce delay.  It is
   assumed that the large packets bypass the compressor and decompressor
   since the interleaving would modify the sequencing of packets at the
   decompressor and cause the appearance of errors.  Header compression
   should be less important for large packets since the overhead ratio
   is smaller.

   If some packets from an RTP session context are selected for
   segmentation (perhaps based on size) and some are not, there is a
   possibility 0   T=3020  repeat updated T
   103 3030 CU   1 0  0  0 M 0 1 0   T=3030  repeat updated T
   104 3040 CR
   105 3050 CR
   ...

3. Negotiating usage of re-ordering.  This would reduce the compression
   efficiency because the large packets would appear as lost packets in
   the sequence space.  However, this should not cause more serious
   problems because the RTP sequence numbers should be reconstructed
   correctly and will allow the application to correct the ordering.

   Link errors detected by the segmentation scheme using its own
   sequencing information MAY be indicated to the compressor with an
   advisory CONTEXT_STATE message just as for link errors detected by
   the link layer itself.

   The context ID byte is placed first in the COMPRESSED_RTP header so
   that this byte MAY be shared with the segmentation layer if such
   sharing is feasible and has been negotiated.  Since the compressor
   may assign context ID values arbitrarily, the value can be set to
   match the context identifier from enhanced-CRTP

   RFC 2509 [IPCPHC] specifies how the segmentation layer.

6.  Negotiating Compression

   The use of IP/UDP/RTP compression over a particular link is a
   function of the link-layer protocol.  It CRTP is expected that such
   negotiation will be defined separately for negotiated on PPP [4], for example.  The
   following items MAY be negotiated:

      o The size of the context ID.
      o The maximum size of the stack of headers in the context.
      o A context-specific table for decoding of delta values.
      o Using CRTP enhancements.

7.  Acknowledgments

   Several people have contributed to
   links using the design IP Compression Protocol option of this IPCP:

         IPCP option 2: IP compression
   scheme and related problems.  Scott Petrack initiated discussion of
   RTP protocol
         protocol 0x61: indicates RFC 2507 header compression
         sub-option 1:  enables use of COMPRESSED_RTP, COMPRESSED_UDP
                        and CONTEXT_STATE as specified in RFC 2508

   To use the AVT working group at Los Angeles in
   March, 1996.  Carsten Bormann has developed an overall architecture
   for compression enhanced CRTP defined in combination with traffic control across this document, a low-
   speed link, new sub-option
   2 is added.  The new sup-option 2 is negotiated instead of, not in
   addition to, sub-option 1.

   Description

      Enable use of Protocol Identifiers COMPRESSED_RTP and made several specific contributions to the scheme
   described here.  David Oran independently developed a note based on
   similar ideas,
      CONTEXT_STATE as specified in RFC 2508 plus COMPRESSED_UDP with
      additional flags as defined in this document, and suggested the enable use of PPP Multilink protocol for
   segmentation.  Mikael Degermark has contributed advice on integration
   of this compression scheme
      the C flag with the IPv6 compression framework.

8.  References:

   [1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
       A Transport Protocol for real-time applications", RFC 1889,
       January 1996.

   [2] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links",
       RFC 1144, February 1990.

   [3] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for
       IPv6", RFC 2507, February 1999.

   [4] Simpson, W., "The Point-to-Point FULL_HEADER Protocol (PPP)", STD 51, RFC
       1661, July 1994.

   [5] Hoffman, D., Fernando, G., Goyal, V. Identifier as defined in
      this document to indicate use of HDRCKSUM with COMPRESSED_RTP and M. Civanlar, "RTP
       Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.

9.
      COMPRESSED_UDP packets.

                0                   1
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |     Type      |    Length     |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Type
               2

            Length
               2

4. Security Considerations

   Because encryption eliminates the redundancy that this compression
   scheme tries to exploit, there is some inducement to forego
   encryption in order to achieve operation over a low-bandwidth link.
   However, for those cases where encryption of data and not headers is
   satisfactory, RTP does specify an alternative encryption method in
   which only the RTP payload is encrypted and the headers are left in
   the clear. That would allow compression to still be applied.

   A malfunctioning or malicious compressor could cause the
   decompressor to reconstitute packets that do not match the original
   packets but still have valid IP, UDP and RTP headers and possibly
   even valid UDP check-sums.  Such corruption may be detected with
   end-to-end authentication and integrity mechanisms which will not be
   affected by the compression. Constant portions of authentication
   headers will be compressed as described in [3]. [IPHCOMP].

   No authentication is performed on the CONTEXT_STATE control packet
   sent by this protocol.  An attacker with access to the link between
   the decompressor and compressor could inject false CONTEXT_STATE
   packets and cause compression efficiency to be reduced, probably
   resulting in congestion on the link.  However, an attacker with
   access to the link could also disrupt the traffic in many other
   ways.

   A potential denial-of-service threat exists when using compression
   techniques that have non-uniform receiver-end computational load.
   The attacker can inject pathological datagrams into the stream which
   are complex to decompress and cause the receiver to be overloaded
   and degrading processing of other streams.  However, this
   compression does not exhibit any significant non-uniformity.

   A security review

5. Acknowledgements

   The authors would like to thank Van Jacobson, co-author of this protocol found no additional security
   considerations.

10. RFC 2508,
   and the authors of RFC 2507, Mikael Degermark, Bjorn Nordgren, and
   Stephen Pink. The authors would also like to thank Dana Blair,
   Francois Le Faucheur, Tim Gleeson, Matt Madison, Hussein Salama,
   Mallik Tatipamula, Mike Thomas, Alex Tweedly, Herb Wildfeuer, and
   Dan Wing.

6. References

   [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for
   Low-Speed Serial Links", RFC2508, February 1999.

   [IPHCOMP] M. Degermark, B. Nordgren, S. Pink,
   "IP Header Compression", RFC2507, February 1999.

   [IPCPHC] M. Engan, S. Casner, C. Bormann,
   "IP Header Compression over PPP", RFC2509, February 1999.

   [KEYW] S. Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC2119, BCP 14, March 1997.

   [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
   "RTP: A Transport Protocol for Real-Time Applications", RFC1889,
   January 1996.

7. Authors' Addresses

   Stephen L. Casner
   Packet Design, Inc.
   66 Willow Place
   Menlo Park, CA 94025
   United States of America

   Email: casner@acm.org

   Van Jacobson
   Packet Design, Inc.
   66 Willow Place
   Menlo Park, CA 94025
   United States of America

   EMail: van@packetdesign.com

   Tmima Koren
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134-1706
   United States of America
   Email: tmima@cisco.com
   Stephen L. Casner
   Packet Design
   2465 Latham Street, Third Floor
   Mountain View, CA  94040
   United States of America
   Email: casner@acm.org

   John Geevarghese
   Telseon Inc, Inc.
   480 S. California
   Palo-Alto, CA-94306

   Email: geevjohn@hotmail.com

   Bruce Thompson
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose,
   Palo Alto, CA  95134-1706  94306
   United States of America
   Email: brucet@cisco.com

   Dan Wing geevjohn@hotmail.com

   Bruce Thompson
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134-1706
   United States of America
   Email: dwing@cisco.com brucet@cisco.com

   Patrick Ruddy
   Cisco Systems, Inc.
   3rd Floor, 96 Commercial Street
   Edinburgh
   EH6 6LX
   Scotland
   Email: pruddy@cisco.com

   Alex Tweedly
   Cisco Systems, Inc.
   3 The Square, Stockley Park
   Uxbridge, Middlesex
   UB11 1BN
   United Kingdom

   Email: agt@cisco.com

10.  Full

8. Copyright Statement

   Copyright (C) The Internet Society (1999). 1999-2001.  All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.