rfc2508.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,348 行 · 第 1/4 页

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]