doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc2508.txt b/doc/rfc/rfc2508.txt
new file mode 100644
index 0000000..0515519
--- /dev/null
+++ b/doc/rfc/rfc2508.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group                                          S. Casner
+Request for Comments: 2508                                 Cisco Systems
+Category: Standards Track                                    V. Jacobson
+                                                           Cisco Systems
+                                                           February 1999
+
+
+       Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   This document describes a method for compressing the headers of
+   IP/UDP/RTP datagrams to reduce overhead on low-speed serial links.
+   In many cases, all three headers can be compressed to 2-4 bytes.
+
+   Comments are solicited and should be addressed to the working group
+   mailing list rem-conf@es.net and/or the author(s).
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119.
+
+1.  Introduction
+
+   Since the Real-time Transport Protocol was published as an RFC [1],
+   there has been growing interest in using RTP as one step to achieve
+   interoperability among different implementations of network
+   audio/video applications.  However, there is also concern that the
+   12-byte RTP header is too large an overhead for 20-byte payloads when
+   operating over low speed lines such as dial-up modems at 14.4 or 28.8
+   kb/s.  (Some existing applications operating in this environment use
+   an application-specific protocol with a header of a few bytes that
+   has reduced functionality relative to RTP.)
+
+
+
+
+
+
+Casner & Jacobson           Standards Track                     [Page 1]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   Header size may be reduced through compression techniques as has been
+   done with great success for TCP [2].  In this case, compression might
+   be applied to the RTP header alone, on an end-to-end basis, or to the
+   combination of IP, UDP and RTP headers on a link-by-link basis.
+   Compressing the 40 bytes of combined headers together provides
+   substantially more gain than compressing 12 bytes of RTP header alone
+   because the resulting size is approximately the same (2-4 bytes) in
+   either case.  Compressing on a link-by-link basis also provides
+   better performance because the delay and loss rate are lower.
+   Therefore, the method defined here is for combined compression of IP,
+   UDP and RTP headers on a link-by-link basis.
+
+   This document defines a compression scheme that may be used with
+   IPv4, IPv6 or packets encapsulated with more than one IP header,
+   though the initial focus is on IPv4.  The IP/UDP/RTP compression
+   defined here is intended to fit within the more general compression
+   framework specified in [3] for use with both IPv6 and IPv4.  That
+   framework defines TCP and non-TCP as two classes of transport above
+   IP.  This specification creates IP/UDP/RTP as a third class extracted
+   from the non-TCP class.
+
+2.  Assumptions and Tradeoffs
+
+   The goal of this compression scheme is to reduce the IP/UDP/RTP
+   headers to two bytes for most packets in the case where no UDP
+   checksums are being sent, or four bytes with checksums.  It is
+   motivated primarily by the specific problem of sending audio and
+   video over 14.4 and 28.8 dialup modems.  These links tend to provide
+   full-duplex communication, so the protocol takes advantage of that
+   fact, though the protocol may also be used with reduced performance
+   on simplex links.  This compression scheme performs best on local
+   links with low round-trip-time.
+
+   This specification does not address segmentation and preemption of
+   large packets to reduce the delay across the slow link experienced by
+   small real-time packets, except to identify in Section 4 some
+   interactions between segmentation and compression that may occur.
+   Segmentation schemes may be defined separately and used in
+   conjunction with the compression defined here.
+
+   It should be noted that implementation simplicity is an important
+   factor to consider in evaluating a compression scheme.
+   Communications servers may need to support compression over perhaps
+   as many as 100 dial-up modem lines using a single processor.
+   Therefore, it may be appropriate to make some simplifications in the
+   design at the expense of generality, or to produce a flexible design
+   that is general but can be subsetted for simplicity.  Higher
+   compression gain might be achieved by communicating more complex
+
+
+
+Casner & Jacobson           Standards Track                     [Page 2]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   models for the changing header fields from the compressor to the
+   decompressor, but that complexity is deemed unnecessary.  The next
+   sections discuss some of the tradeoffs listed here.
+
+2.1.  Simplex vs. Full Duplex
+
+   In the absence of other constraints, a compression scheme that worked
+   over simplex links would be preferred over one that did not.
+   However, operation over a simplex link requires periodic refreshes
+   with an uncompressed packet header to restore compression state in
+   case of error.  If an explicit error signal can be returned instead,
+   the delay to recovery may be shortened substantially.  The overhead
+   in the no-error case is also reduced.  To gain these performance
+   improvements, this specification includes an explicit error
+   indication sent on the reverse path.
+
+   On a simplex link, it would be possible to use a periodic refresh
+   instead.  Whenever the decompressor detected an error in a particular
+   packet stream, it would simply discard all packets in that stream
+   until an uncompressed header was received for that stream, and then
+   resume decompression.  The penalty would be the potentially large
+   number of packets discarded.  The periodic refresh method described
+   in Section 3.3 of [3] applies to IP/UDP/RTP compression on simplex
+   links or links with high delay as well as to other non-TCP packet
+   streams.
+
+2.2.  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 the variance in delay.  However, for
+   interactive conversations, minimizing the end-to-end delay is
+   critical.  Segmentation 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 a separate layer.  It
+   would be inappropriate to integrate segmentation 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 can be applied locally on the two
+   ends of a link independent of any other mechanisms except for the
+   requirements that the link layer provide some packet type codes, a
+   packet length indication, and good error detection.
+
+
+
+
+
+Casner & Jacobson           Standards Track                     [Page 3]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   Conversely, separately compressing the IP/UDP and RTP layers loses
+   too much of the compression gain that is possible by treating them
+   together.  Crossing these protocol layer boundaries is appropriate
+   because the same function 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 to that RFC for more information on the
+   underlying motivations and general principles of header compression.
+
+3.1.  The basic idea
+
+   In TCP header compression, the first factor-of-two reduction in data
+   rate comes from the observation that half of the bytes in the IP and
+   TCP headers remain constant over the life of the connection.  After
+   sending the uncompressed header once, these fields may be elided from
+   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 the length of the packet.  This length
+   is indicated by the link-level protocol.
+
+   For RTP header compression, some of the same techniques may be
+   applied.  However, the big gain comes from the observation that
+   although several fields change in every packet, the difference from
+   packet to packet is often constant and therefore the second-order
+   difference is zero.  By maintaining both the uncompressed header and
+   the first-order differences in the session state shared between the
+   compressor and decompressor, all that must be communicated is an
+   indication that the second-order difference was zero.  In that case,
+   the decompressor can reconstruct the original header without any loss
+   of information simply by adding the first-order differences to the
+   saved uncompressed header as each compressed packet 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, the UDP source and destination ports, and 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 packet carries a small integer, called the session context
+   identifier or CID, to indicate in which session context that packet
+   should be interpreted.  The decompressor can use the CID to index its
+   table of stored session contexts directly.
+
+
+
+
+Casner & Jacobson           Standards Track                     [Page 4]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   Because the RTP compression is lossless, it may be applied to any UDP
+   traffic that benefits from it.  Most likely, the only packets that
+   will benefit are RTP packets, but it is acceptable to use heuristics
+   to determine whether or not the packet is an RTP packet because no
+   harm is done if the heuristic gives the wrong answer.  This does
+   require executing the compression algorithm for all UDP packets, or
+   at least those 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 of attempts in order to avoid further attempts.
+   Failing to compress means that some fields in the potential RTP
+   header that are expected to remain constant most of the time, such as
+   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 in the negative cache to avoid consuming all
+   of the available session contexts.  The negative cache is indexed by
+   the source and destination IP address and UDP port pairs but not the
+   RTP SSRC field since the latter may be changing.  When RTP
+   compression fails, the IP and UDP headers MAY still be compressed.
+
+   Fragmented IP Packets that are not initial fragments and packets that
+   are not long enough to contain a complete UDP header MUST NOT be sent
+   as FULL_HEADER packets.  Furthermore, packets that do not
+   additionally contain at least 12 bytes of UDP data MUST NOT be used
+   to establish RTP context.  If such a packet is sent as a FULL_HEADER
+   packet, it MAY be followed by 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 is redundant
+   with the length provided by the link layer, and since this
+   compression scheme must depend upon the link layer to provide good
+   error detection (e.g., PPP's CRC [4]), the header checksum may also
+   be elided.  This leaves only the packet ID, which, assuming no IP
+   fragmentation, would not need to be communicated.  However, in order
+   to maintain lossless compression, changes in the packet ID will be
+   transmitted.  The packet ID usually increments by one or a small
+   number for each packet.  (Some systems increment the ID with the
+   bytes swapped, which results in slightly less compression.)  In the
+   IPv6 base header, there is no packet ID nor header checksum and only
+   the payload length field changes.
+
+
+
+
+
+
+
+Casner & Jacobson           Standards Track                     [Page 5]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   In the UDP header, the length field is redundant with the IP total
+   length field and the length indicated by the link layer.  The UDP
+   check-sum field will be a constant zero if the source elects not to
+   generate UDP checksums.  Otherwise, the checksum must be communicated
+   intact in order to preserve the lossless compression.  Maintaining
+   end-to-end error detection for applications that require it is an
+   important principle.
+
+   In the RTP header, the SSRC identifier is constant in a given context
+   since that is part of what identifies the particular context.  For
+   most packets, only the sequence number and the timestamp will change
+   from 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 of constant duration, the
+   timestamp will increment by the number of sample periods conveyed in
+   each packet.  For video, the timestamp will change on the first
+   packet of each frame, but then stay constant for any additional
+   packets in the frame.  If each video frame occupies only one packet,
+   but the video frames are generated at a constant rate, then again the
+   change in the timestamp from frame to frame is constant.  Note that
+   in each of these cases the second-order difference of the sequence
+   number and timestamp fields is zero, 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 is not zero, the magnitude of the change is usually much
+   smaller than the full number of bits in the field, so the size can be
+   reduced by encoding the new first-order difference and transmitting
+   it rather than the absolute value.
+
+   The M bit will be set on the first packet of an audio talkspurt and
+   the last packet of a video frame.  If it were treated as a constant
+   field such that each change required sending the full RTP header,
+   this would reduce the compression significantly.  Therefore, one bit
+   in the compressed header will carry the M bit explicitly.
+
+   If the packets are flowing through an RTP mixer, most commonly for
+   audio, then the CSRC list and CC count will also change.  However,
+   the CSRC list will typically remain constant during a talkspurt or
+   longer, so it need be sent only when it changes.
+
+3.3.  The protocol
+
+   The compression protocol must maintain a collection of shared
+   information in a consistent state between the compressor and
+   decompressor.  There is a separate session context for each
+   IP/UDP/RTP packet stream, as defined by a particular combination of
+   the IP source and destination addresses, UDP source and destination
+
+
+
+Casner & Jacobson           Standards Track                     [Page 6]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   ports, and the RTP SSRC field.  The number of session contexts to be
+   maintained MAY be negotiated between the compressor and decompressor.
+   Each context is identified by an 8- or 16-bit identifier, depending
+   upon the number of contexts negotiated, so the maximum number is
+   65536.  Both uncompressed and compressed packets MUST carry the
+   context ID and a 4-bit sequence number used 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.
+
+   The shared information in each context consists of the following
+   items:
+
+      o The full IP, UDP and RTP headers, possibly including a CSRC
+        list, for the last 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 for the RTP timestamp field,
+        initialized to 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 sequence number, which is used to
+        detect packet loss between the compressor and decompressor.
+
+      o The current generation number for non-differential coding of UDP
+        packets with IPv6 (see [3]).  For IPv4, the generation number
+        may be set to zero if the COMPRESSED_NON_TCP 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 the link layer being
+   able to provide an indication of four new packet formats in addition
+   to the normal IPv4 and IPv6 packet formats:
+
+      FULL_HEADER - communicates the uncompressed IP header plus any
+      following headers 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 and the 4-bit sequence number to establish
+
+
+
+Casner & Jacobson           Standards Track                     [Page 7]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+      synchronization between the compressor and decompressor.  The
+      format is shown in section 3.3.1.
+
+      COMPRESSED_UDP - communicates the IP and UDP headers compressed 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 packet type is used when there are differences in
+      the usually constant fields of the (potential) RTP header.  The
+      RTP header includes a potentially changed value of the SSRC field,
+      so this packet may redefine the session context.  The format is
+      shown in section 3.3.3.
+
+      COMPRESSED_RTP - indicates that the RTP header is compressed along
+      with the IP and UDP headers.  The size 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 of context
+      IDs for which synchronization has or may have been lost.  This
+      packet is only sent across the point-to-point 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 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 in order to carry the IPv4 ID
+      field.  For IPv6, there is no ID field and this non-differential
+      compression is more resilient to packet loss.
+
+   Assignments of numeric codes for these packet formats in the Point-
+   to-Point Protocol [4] are to be made by the Internet Assigned Numbers
+   Authority.
+
+3.3.1.  FULL_HEADER (uncompressed) packet format
+
+   The definition of the FULL_HEADER packet given here is intended to be
+   the consistent with the definition given in [3].  Full details on
+   design choices are given there.
+
+
+
+Casner & Jacobson           Standards Track                     [Page 8]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   The format of the FULL_HEADER 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, in which case there would be two IP headers
+   followed by UDP and possibly RTP.  Or in the case of IPv6, the packet
+   may be built of some combination of IPv6 and IPv4 headers.  Each
+   successive header is indicated by the type field 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 context ID and
+   the 4-bit sequence number.  In order to avoid expanding the size 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 link layer.  Two 16-bit length fields are
+   needed; these are taken from the first two available headers in the
+   packet.  That is, for an IPv4/UDP packet, the first length field is
+   the total length field of the IPv4 header, and the second is the
+   length field of the UDP header.  For an IPv4 encapsulated packet, the
+   first length field would come from the total length field of the
+   first IP header, and the second length field would come from the
+   total length field of the second IP header.
+
+   As specified in Sections 5.3.2 of [3], the position of the context ID
+   (CID) and 4-bit sequence number varies depending upon whether 8- or
+   16-bit context IDs have been selected, as shown in the following
+   diagram (16 bits wide, with the most-significant bit is to the left):
+
+           For 8-bit context ID:
+
+           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           |0|1| Generation|      CID      |  First length field
+           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           |            0          |  seq  |  Second length field
+           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+           For 16-bit context ID:
+
+           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           |1|1| Generation|   0   |  seq  |  First length field
+           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           |              CID              |  Second length field
+           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Casner & Jacobson           Standards Track                     [Page 9]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   The first bit in the first length field indicates the length of the
+   CID.  The length of the CID MUST either be constant for all contexts
+   or two additional distinct packet types MUST be provided to
+   separately indicate COMPRESSED_UDP and COMPRESSED_RTP packet formats
+   with 8- and 16-bit CIDs.  The second bit in the first length field is
+   1 to indicate that the 4-bit sequence number is present, as is always
+   the case for this IP/UDP/RTP compression scheme.
+
+   The generation field is used with IPv6 for COMPRESSED_NON_TCP packets
+   as described in [3].  For IPv4-only implementations that do not use
+   COMPRESSED_NON_TCP packets, the compressor SHOULD set the generation
+   value to zero.  For consistent operation between IPv4 and IPv6, the
+   generation value is stored in the context when it is received by the
+   decompressor, and the most recent value is returned in the
+   CONTEXT_STATE packet.
+
+   When a FULL_HEADER packet is received, the complete set of headers is
+   stored into the context selected by the context ID.  The 4-bit
+   sequence number is also stored in the context, thereby
+   resynchronizing the decompressor to the compressor.
+
+   When COMPRESSED_NON_TCP packets are used, the 4-bit sequence number
+   is inserted into the "Data Field" of that packet and the D bit is set
+   as described in Section 6 of [3].  When a COMPRESSED_NON_TCP packet
+   is received, the generation number is compared to the value stored in
+   the context.  If they are not the same, the context is not up to date
+   and MUST be refreshed by a FULL_HEADER packet.  If the generation
+   does match, then the compressed IP and UDP header information, the
+   4-bit sequence number, and the (potential) RTP header are all stored
+   into the saved context.
+
+   The amount of memory required to store the context will vary
+   depending upon how many encapsulating headers are included in the
+   FULL_HEADER packet.  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 is zero, the decompressor can reconstruct a packet simply by
+   adding the stored first-order differences to the stored uncompressed
+   header representing the previous packet.  All that need be
+   communicated is the session context identifier and a small sequence
+   number (not related to the RTP sequence number) to maintain
+   synchronization and detect packet loss between the compressor and
+   decompressor.
+
+
+
+
+
+Casner & Jacobson           Standards Track                    [Page 10]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   If the second-order difference of the RTP header is not zero for some
+   fields, the new first-order difference for just those fields is
+   communicated using a compact encoding.  The new first-order
+   difference values are added to the corresponding fields in the
+   uncompressed header in the decompressor's session context, and are
+   also stored explicitly in the context to be added to the
+   corresponding fields again on each subsequent packet in which the
+   second-order difference is zero.  Each time the first-order
+   difference changes, it is transmitted and stored in the context.
+
+   In practice, the only fields for which it is useful to store the
+   first-order difference are the IPv4 ID field and the RTP timestamp.
+   For 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 the next
+   packet.  Instead, the expected first-order difference remains fixed
+   at 1 so that the difference need not be explicitly communicated on
+   the next packet assuming it is in order.
+
+   For the RTP timestamp, when a FULL_HEADER, COMPRESSED_NON_TCP or
+   COMPRESSED_UDP packet is sent to refresh the RTP state, the stored
+   first-order difference is initialized to zero.  If the timestamp is
+   the same on the next packet (e.g., same video frame), then the
+   second-order difference is zero.  Otherwise, the difference between
+   the timestamps of the two packets is transmitted as the new first-
+   order difference to be added to the timestamp in the uncompressed
+   header stored in the decompressor's context and also stored as the
+   first-order difference in that context.  Each time the first-order
+   difference changes on subsequent packets, that difference is again
+   transmitted and used to update the context.
+
+   Similarly, since the IPv4 ID field frequently increments by one, the
+   first-order difference for that field is initialized to one when the
+   state is refreshed by a FULL_HEADER packet, or when 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 be used to indicate which fields have changed by
+   other than the expected difference.  In addition to the small link
+   sequence number, the list of items to be conditionally communicated
+   in the compressed IP/UDP/RTP header is as follows:
+
+
+
+
+
+
+
+
+
+Casner & Jacobson           Standards Track                    [Page 11]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+      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 the link sequence number to get a reasonable
+   probability of loss detection, there are too few bits remaining to
+   assign one bit to each of these items and still fit them all into a
+   single byte to go along with the context ID.
+
+   It is not necessary to explicitly carry the U bit to indicate the
+   presence of the UDP checksum because a source will typically include
+   check-sums on all 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 and list may be
+   the one least frequently used.  Rather than dedicating 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, will be included just as it appears in the
+   uncompressed RTP header.
+
+   The other fields of the RTP header (version, P bit, X bit, payload
+   type 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 is one of the factors selecting the context.
+   If any of the other fields change, 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 the delta value as explained in Section 3.3.4.
+
+
+
+
+
+
+Casner & Jacobson           Standards Track                    [Page 12]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+             0   1   2   3   4   5   6   7
+           +...............................+
+           :   msb of session context ID   :  (if 16-bit CID)
+           +-------------------------------+
+           |   lsb of session context ID   |
+           +---+---+---+---+---+---+---+---+
+           | M | S | T | 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 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 is present in the context as
+   initialized by the FULL_HEADER packet, then the IP ID fields of
+   encapsulating headers MUST be sent as absolute values as described in
+
+
+
+
+
+Casner & Jacobson           Standards Track                    [Page 13]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   [3].  These fields are identified as "RANDOM" fields.  They are
+   inserted into the COMPRESSED_RTP packet in the same order as they
+   appear in the original headers, immediately following the UDP
+   checksum if present or 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 are
+   normally constant (such as the payload type field), then an
+   uncompressed RTP header MUST be sent.  If the IP 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, S and T bits are always 0 and the
+   corresponding delta fields are never included:
+
+             0   1   2   3   4   5   6   7
+           +...............................+
+           :   msb of session context ID   :  (if 16-bit CID)
+           +-------------------------------+
+           |   lsb of session context ID   |
+           +---+---+---+---+---+---+---+---+
+           | 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
+
+
+
+Casner & Jacobson           Standards Track                    [Page 14]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   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
+
+
+
+Casner & Jacobson           Standards Track                    [Page 15]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   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
+
+
+
+Casner & Jacobson           Standards Track                    [Page 16]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   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):
+
+
+
+
+Casner & Jacobson           Standards Track                    [Page 17]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+             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
+
+
+
+Casner & Jacobson           Standards Track                    [Page 18]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   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.
+
+
+
+
+Casner & Jacobson           Standards Track                    [Page 19]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   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.  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 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.
+
+
+
+
+
+Casner & Jacobson           Standards Track                    [Page 20]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   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 the segmentation layer.
+
+5.  Negotiating Compression
+
+   The use of IP/UDP/RTP compression over a particular link is a
+   function of the link-layer protocol.  It is expected that such
+   negotiation will be defined separately for 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.
+
+6.  Acknowledgments
+
+   Several people have contributed to the design of this compression
+   scheme and related problems.  Scott Petrack initiated discussion of
+   RTP header compression in the AVT working group at Los Angeles in
+   March, 1996.  Carsten Bormann has developed an overall architecture
+   for compression in combination with traffic control across a low-
+   speed link, and made several specific contributions to the scheme
+   described here.  David Oran independently developed a note based on
+   similar ideas, and suggested the use of PPP Multilink protocol for
+   segmentation.  Mikael Degermark has contributed advice on integration
+   of this compression scheme with the IPv6 compression framework.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Casner & Jacobson           Standards Track                    [Page 21]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+7.  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 Protocol (PPP)", STD 51, RFC
+       1661, July 1994.
+
+   [5] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP
+       Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
+
+8.  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].
+
+   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
+
+
+
+Casner & Jacobson           Standards Track                    [Page 22]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+   does not exhibit any significant non-uniformity.
+
+   A security review of this protocol found no additional security
+   considerations.
+
+9.  Authors' Addresses
+
+   Stephen L. Casner
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   United States
+
+   EMail: casner@cisco.com
+
+
+   Van Jacobson
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   United States
+
+   EMail: van@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Casner & Jacobson           Standards Track                    [Page 23]
+
+RFC 2508             Compressing IP/UDP/RTP Headers        February 1999
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Casner & Jacobson           Standards Track                    [Page 24]
+