rfc2508.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,348 行 · 第 1/5 页

   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