rfc3242.txt

RFC 的详细文档！

   The fields present in the ROHC RTP headers for U/O-mode PT0 are the
   packet type identifier, the sequence number and the CRC.  The
   subsequent sections elaborate more on how the functionality of these
   fields is replaced for NHP.

3.1.  Providing Packet Type Identification

   All ROHC headers carry a packet type identifier, indicating to the
   decompressor how the header should be interpreted.  This is a
   function that must be provided by some means in 0-byte header
   compression.  ROHC RTP packets with compressed headers will be
   possible to distinguish thanks to the packet type identifier, but a
   mechanism is needed to separate packets with a header from packets
   without a header.  This function MUST therefore be provided by the
   assisting layer in one way or another.

3.2.  Replacing the Sequence Number

   From the sending application, the RTP sequence number is increased by
   one for each packet sent.  The purpose of the sequence number is to
   cope with packet reordering and packet loss.  If reordering or loss
   has occurred before the transmission point, if needed the compressing
   side can easily avoid problems by not allowing the use of a header-
   free packet.

   However, at the transmission point, loss or reordering that may occur
   over the link can not be anticipated and covered for.  Therefore, for
   NHP the assisting layer MUST guarantee in-order delivery over the
   link (already assumed by [ROHC]) and at the receiving side it MUST
   provide an indication for each packet loss over the link.  This is
   basically the same principle as the VJ header compression [VJHC]
   relies on.

   Note that guaranteeing in-order delivery and packet loss indication
   over the link not only makes it possible to infer the sequence number
   information, but also supersedes the main function of the CRC, which
   normally takes care of errors due to long link losses and bit errors
   in the compressed sequence number.




Jonsson, et. al             Standards Track                     [Page 6]

RFC 3242             A Link-Layer Assisted ROHC RTP           April 2002


3.3.  CRC Replacement

   All context updating RRP packets carry a CRC calculated over the
   uncompressed header.  The CRC is used by the decompressor to verify
   that the updated context is correct.  This verification serves three
   purposes in U/O-mode:

      1) Detection of longer losses than can be covered by the sequence
         number LSBs
      2) Protection against failures caused by residual bit errors in
         compressed headers
      3) Protection against faulty implementations and other causes of
         error

   Since this profile defines an NHP packet without this CRC, care must
   be taken to fulfill these purposes by other means, when an NHP is
   used as a replacement for a context updating packet.  Detection of
   long losses (1) is already covered since the assisting layer MUST
   provide indication of all packet losses.  Furthermore, the NHP packet
   has one important advantage over RHP packets in that residual bit
   errors (2) cannot damage a header that is not even sent.

   It is thus reasonable to assume that compression and decompression
   transparency can be assured with high confidence even without a CRC
   in header-free packets.  However, to provide additional protection
   against damage propagation due to undetected residual bit errors in
   context updating packets (2) or other unexpected errors (3), periodic
   context verifications SHOULD be performed (see section 4.6).

3.4.  Applicability of This Profile

   The LLA profile can be used with any link technology capable of
   providing the required functionality described in previous sections.
   Whether LLA or ROHC RTP should be implemented thus depends on the
   characteristics of the link itself.  For most RTP packet streams, LLA
   will work exactly as ROHC RTP, while it will be more efficient for
   packet streams with certain characteristics.  LLA will never be less
   efficient than ROHC RTP.

   Note as well that LLA, like all other ROHC profiles, is fully
   transparent to any packet stream reaching the compressor.  LLA does
   not make any assumptions about the packet stream but will perform
   optimally for packet streams with certain characteristics, e.g.,
   synchronized streams exactly timed with the assisting link over which
   the LLA profile is implemented.






Jonsson, et. al             Standards Track                     [Page 7]

RFC 3242             A Link-Layer Assisted ROHC RTP           April 2002


   The LLA profile is obviously not applicable if the UDP checksum (2
   bytes) is enabled, which is always the case for IPv6/UDP.  For
   IPv4/UDP, the sender may choose to disable the UDP checksum.

4.  Additions and Exceptions Compared to ROHC RTP

4.1.  Additional Packet Types

   The LLA profile defines three new packet types to be used in addition
   to the RRP packet types defined by [ROHC].  The following sections
   describe these packet types and their purpose in detail.

4.1.1.  No-Header Packet (NHP)

   A No-Header Packet (NHP), i.e., a packet consisting only of a
   payload, is defined and MAY be used when only sequencing must be
   conveyed, i.e., when all header fields are either unchanged or follow
   the currently established change pattern.  In addition, there are
   some considerations for the use of the NHP (see 4.3, 4.5 and 4.6).
   An LLA compressor is not allowed to deliver NHP packets when
   operating in R-mode.

   The assisting layer MAY send the NHP for RTP SN = X only if an NHP
   was delivered by the LLA compressor AND the assisting layer can
   guarantee that the decompressor will infer the proper sequencing for
   this NHP.  This guarantee is based on the confidence that the
   decompressor

   a) has the means to infer proper sequencing for the packet
      corresponding to SN = X-1, AND
   b) has either received a loss indication or the packet itself for the
      packet corresponding to SN = X-1.

   Updating properties: NHP packets update context (RTP Sequence
   Number).

4.1.2.  Context Synchronization Packet (CSP)

   The case where the packet stream overruns the channel bandwidth may
   lead to data being discarded, which may result in decompressor
   context invalidation.  It might therefore be beneficial to send a
   packet with only the header information and discard the payload.
   This would be helpful to maintain synchronization of the decompressor
   context, while efficiently using the available bandwidth.







Jonsson, et. al             Standards Track                     [Page 8]

RFC 3242             A Link-Layer Assisted ROHC RTP           April 2002


   This case can be handled with the Context Synchronization Packet
   (CSP), which has the following format:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1   0   1   0 | Packet type identifier
   +===+===+===+===+===+===+===+===+
   :  ROHC header without padding  :
   :    see [ROHC, section 5.7]    :
   +---+---+---+---+---+---+---+---+

   Updating properties: CSP maintains the updating properties of the
   ROHC header it carries.

   The CSP is defined by one of the unused packet type identifiers from
   ROHC RTP, carried in the one-octet base header.  As for any ROHC
   packet, except the NHP, the packet may begin with ROHC padding and/or
   feedback.  It may also carry context identification after the packet
   type identifier.  It is possible to have two CID fields present, one
   after the packet type ID and one within the encapsulated ROHC header.
   If a decompressor receives a CSP with two non-equal CID values
   included, the packet MUST be discarded.  ROHC segmentation may also
   be applied to the CSP.

   Note that when the decompressor has received and processed a CSP, the
   packet (including any possible data following the CSP encapsulated
   compressed header) MUST be discarded.

4.1.3.  Context Check Packet (CCP)

   A Context Check Packet (CCP), which does not carry any payload but
   only an optional CRC value in addition to the packet type identifier,
   is defined.

   The purpose of the CCP is to provide a useful packet that MAY be sent
   by a synchronized physical link layer in the case where data must be
   sent at fixed intervals, even if no compressed packet is available.
   Whether the CCP is sent over the link and delivered to the
   decompressor is decided by the assisting layer.  The CCP has the
   following format:











Jonsson, et. al             Standards Track                     [Page 9]

RFC 3242             A Link-Layer Assisted ROHC RTP           April 2002


     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1   0   1   1 | Packet type identifier
   +===+===+===+===+===+===+===+===+
   | C |          CRC              |
   +---+---+---+---+---+---+---+---+

     C: C = 0 indicates that the CRC field is not used;
        C = 1 indicates that a valid CRC is present.

   Updating properties: CCP packets do not update context.

   The CCP is defined by one of the unused packet type identifiers from
   ROHC RTP, carried in the first octet of the base header.  The first
   bit of the second octet, the C bit, indicates whether the CRC field
   is used or not.  If C=1, the CRC field MUST be set to the 7-bits CRC
   calculated over the original uncompressed header defined in [ROHC
   section 5.9.2].  As for any ROHC packet, except NHP, the packet MAY
   begin with ROHC padding and/or carry context identification.

   The use of the CRC field to perform decompressor context verification
   is optional and is therefore a compressor implementation issue.
   However, a CCP MUST always be made available to the assisting layer.

   If the assisting layer receives CCPs with the C-bit set (C=1) from
   the compressor, it MUST use the last CCP received if a CCP is to be
   sent, i.e., the CCP corresponding to the last non-CCP packet sent
   (NHP, RRP or CSP).  An assisting layer MAY use the CCP for other
   purposes, such as signaling a packet loss before the link.

   The decompressor is REQUIRED to handle a CCP received with the C bit
   set (C=1), indicating a valid CRC field, and perform context
   verification.  The received CRC MUST then be applied to the last
   decompressed packet, unless a packet loss indication was previously
   received.  Upon CRC failure, actions MUST be taken as specified in
   [ROHC, section 5.3.2.2.3].  A CCP received with C=0 MUST be ignored
   by the decompressor.  The decompressor is not allowed to make any
   further interpretation of the CCP.

   The use of CCP by an assisting layer is optional and depends on the
   characteristics of the actual link.  Whether it is used or not MUST
   therefore be specified in link layer implementation specifications
   for this profile.








Jonsson, et. al             Standards Track                    [Page 10]

RFC 3242             A Link-Layer Assisted ROHC RTP           April 2002


4.2.  Interfaces Towards the Assisting Layer

   This profile relies on the lower layers to provide the necessary
   functionality to allow NHP packets to be sent.  This interaction
   between LLA and the assisting layer is defined as interfaces between
   the LLA compressor/decompressor and the LLA applicable link
   technology.

                |                              |
                +                              +
   +-------------------------+    +-------------------------+
   |       ROHC RTP HC       |    |       ROHC RTP HD       |
   +-------------------------+    +-------------------------+
   |       LLA profile       |    |       LLA profile       |
   +=========================+    +=========================+
   |       Interface         |    |        Interface        |
   | ROHC to assisting layer |    | Assisting layer to ROHC |
   +=========================+    +=========================+
   |       Applicable        |    |       Applicable        |
   |     link technology     |    |     link technology     |
   +=========================+    +=========================+
                |                              |
                +------>---- CHANNEL ---->-----+