tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3095

 
 
 

RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed

Part 4 of 7, p. 65 to 89
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 65 
5.5.  Operation in Bidirectional Reliable mode

5.5.1.  Compressor states and logic (R-mode)

   Below is the state machine for the compressor in Bidirectional
   Reliable mode.  The details of each state, state transitions, and
   compression logic are given subsequent to the figure.

                                       ACK
      +------>------>------>------>------>------>------>------+
      |                                                       |
      |               ACK                         ACK         |   ACK
      |      +------>------>------+      +------>------>------+  +->-+
      |      |                    |      |                    |  |   |
      |      |                    v      |                    v  |   v
    +----------+                +----------+                +----------+
    | IR State |                | FO State |                | SO State |
    +----------+                +----------+                +----------+
      ^      ^                    |      ^                    |      |
      |      |    STATIC-NACK     |      |    NACK / Update   |      |
      |      +------<------<------+      +------<------<------+      |
      |                                                              |
      |                         STATIC-NACK                          |
      +------<------<------<------<------<------<------<------<------+

5.5.1.1.  State transition logic (R-mode)

   The transition logic for compression states in Reliable mode is based
   on three principles: the secure reference principle, the need for
   updates, and negative acknowledgments.

5.5.1.1.1.  Upwards transition

   The upwards transition is determined by the secure reference
   principle.  The transition procedure is similar to the one described
   in section 5.3.1.1.1, with one important difference: the compressor

Top      Up      ToC       Page 66 
   bases its confidence only on acknowledgments received from the
   decompressor.  This ensures that the synchronization between the
   compression context and decompression context will never be lost due
   to packet losses.

5.5.1.1.2.  Downward transition

   Downward transitions are triggered by the need for updates or by
   negative acknowledgment (NACKs and STATIC_NACKs), as described in
   section 5.3.1.1.3 and 5.4.1.1.1, respectively.  Note that NACKs
   should rarely occur in R-mode because of the secure reference used
   (see fourth paragraph of next section).

5.5.1.2.  Compression logic and packets used (R-mode)

   The compressor starts in the IR state by sending IR packets.  It
   transits to the FO state once it receives a valid ACK for an IR
   packet sent (an ACK can only be valid if it refers to an SN sent
   earlier).  In the FO state, it sends the smallest packets that can
   communicate the changes, according to W-LSB or other encoding rules.
   Those packets could be of type R-1*, UOR-2, or even IR-DYN.

   The compressor will transit to the SO state after it has determined
   the presence of a string (see section 2), while also being confident
   that the decompressor has the string parameters.  The confidence can
   be based on ACKs.  For example, in a typical case where the string
   pattern has the form of non-SN-field = SN * slope + offset, one ACK
   is enough if the slope has been previously established by the
   decompressor (i.e., only the new offset needs to be synchronized).
   Otherwise, two ACKs are required since the decompressor needs two
   headers to learn both the new slope and the new offset.  In the SO
   state, R-0* packets will be sent.

   Note that a direct transition from the IR state to the SO state is
   possible.

   The secure reference principle is enforced in both compression and
   decompression logic.  The principle means that only a packet carrying
   a 7- or 8-bit CRC can update the decompression context and be used as
   a reference for subsequent decompression.  Consequently, only field
   values of update packets need to be added to the encoding sliding
   windows (see 4.5) maintained by the compressor.

   Reasons for the compressor to send update packets include:

   1) The update may lead to a transition to higher compression
      efficiency (meaning either a higher compression state or smaller
      packets in the same state).

Top      Up      ToC       Page 67 
   2) It is desirable to shrink sliding windows.  Windows are only
      shrunk when an ACK is received.

      The generation of a CRC is infrequent since it is only needed for
      an update packet.

   One algorithm for sending update packets could be:

     * Let pRTT be the number of packets that are sent during one
       round-trip time.  In the SO state, when (64 - pRTT) headers have
       been sent since the last acked reference, the compressor will
       send m1 consecutive R-0-CRC headers, then send (pRTT - m1) R-0
       headers.  After these headers have been sent, if the compressor
       has not received an ACK to at least one of the previously sent
       R0-CRC, it sends R-0-CRC headers continuously until it receives a
       corresponding ACK.  m1 is an implementation parameter, which can
       be as large as pRTT.

     * In the FO state, m2 UOR-2 headers are sent when there is a
       pattern change, after which the compressor sends (pRTT - m2)
       R-1-* headers.  m2 is an implementation parameter, which can be
       as large as pRTT.  At that time, if the compressor has not
       received enough ACKs to the previously sent UOR-2 packets in
       order to transit to SO state, it can repeat the cycle with the
       same m2, or repeat the cycle with a larger m2, or send UOR-2
       headers continuously (m2 = pRTT).  The operation stops when the
       compressor has received enough ACKs to make the transition.

   An algorithm for processing ACKs could be:

     * Upon reception of an ACK, the compressor first derives the
       complete SN (see section 5.7.6.1).  Then it searches the sliding
       window for an update packet that has the same SN.  If found, that
       packet is the one being ACKed.  Otherwise, the ACK is invalid and
       MUST be discarded.

     * It is possible, although unlikely, that residual errors on the
       reverse channel could cause a packet to mimic a valid ACK
       feedback.  The compressor may use a local clock to reduce the
       probability of processing such a mistaken ACK.  After finding the
       update packet as described above, the compressor can check the
       time elapsed since the packet was sent.  If the time is longer
       than RTT_U, or shorter than RTT_L, the compressor may choose to
       discard the ACK.  RTT_U and RTT_L correspond to an upper bound
       and lower bound of the RTT, respectively.  (These bounds should
       be chosen appropriately to allow some variation of RTT.)  Note
       that the only side effect of discarding a good ACK is slightly
       reduced compression efficiency.

Top      Up      ToC       Page 68 
5.5.2.  Decompressor states and logic (R-mode)

   The decompression states and the state transition logic are the same
   as for the Unidirectional case (see section 5.3.2).  What differs is
   the decompression and feedback logic.

5.5.2.1.  Decompression logic (R-mode)

   The rules for when decompression is allowed are the same as for U-
   mode.  Although the acking scheme in R-mode guarantees that non-
   decompressible packets are never sent by the compressor, residual
   errors can cause delivery of unexpected packets for which
   decompression should not be attempted.

   Decompression MUST follow the secure reference principle as described
   in 5.5.1.2.

   CRC verification is infrequent since only update packets carry CRCs.
   A CRC mismatch can only occur due to 1) residual bit errors in the
   current header, and/or 2) a damaged context due to residual bit
   errors in previous headers or feedback.  Although it is impossible to
   determine which is the actual cause, case 1 is more likely, as a
   previous header reconstructed according to a damaged packet is
   unlikely to pass the 7- or 8-bit CRC, and damaged packets are
   unlikely to result in feedback that damages the context.  The
   decompressor SHOULD act according to section 5.3.2.2.3 when CRCs
   fail, except that no local repair is performed.  Note that all the
   parameter numbers, k_1, n_1, k_2, and n_2, are applied to the update
   packets only (i.e., exclude R-0, R-1*).

5.5.2.2.  Feedback logic (R-mode)

   The feedback logic for the Bidirectional Reliable mode is as follows:

   - When an updating packet (i.e., a packet carrying a 7- or 8-bit CRC)
     is correctly decompressed, send an ACK(R), subject to the sparse
     ACK mechanism described below.

   - When context damage is detected, send a NACK(R) if in Full Context
     state, or a STATIC-NACK(R) if in Static Context state.

   - In No Context state, send a STATIC-NACK(R) when receiving a non-IR
     packet, subject to the considerations at the beginning of section
     5.7.6.  The decompressor SHOULD NOT send STATIC-NACK(R) when
     receiving an IR packet that fails the CRC check, as the compressor
     will stay in IR state and thus continue sending IR packets until a
     valid ACK is received (see section 5.5.1.2).

Top      Up      ToC       Page 69 
   - Feedback is never sent for packets not updating the context (i.e.,
     packets that do not carry a CRC)

   A mechanism called "Sparse ACK" can be applied to reduce the feedback
   overhead caused by a large RTT.  For a sequence of ACK-triggering
   events, a minimal set of ACKs MUST be sent:

   1) For a sequence of R-0-CRC packets, the first one MUST be ACKed.

   2) For a sequence of UOR-2, IR, or IR-DYN packets, the first N of
      them MUST be ACKEd, where N is the number of ACKs needed to give
      the compressor confidence that the decompressor has acquired the
      new string parameters (see second paragraph of 5.5.1.2).  In case
      the decompressor cannot determine the value of N, the default
      value 2 SHOULD be used.  If the subsequently received packets
      continue the same change pattern of header fields, sparse ACK can
      be applied.  Otherwise, each new pattern MUST be treated as a new
      sequence, i.e., the first N packets that exhibit a new pattern
      MUST be ACKed.

   After sending these minimal ACKs, the decompressor MAY choose to ACK
   only k subsequent packets per RTT ("Sparse ACKs"), where k is an
   implementation parameter.  To achieve robustness against loss of
   ACKs, k SHOULD be at least 1.

   To avoid ambiguity at the compressor, the decompressor MUST use the
   feedback format whose SN field length is equal to or larger than the
   one in the compressed packet that triggered the feedback.

   Context damage is detected according to the principles in 5.3.2.2.3.

   When the decompressor is capable of timer-based compression of the
   RTP Timestamp (e.g., it has access to a clock with sufficient
   resolution, and the jitter introduced internally in the receiving
   node is sufficiently small) it SHOULD signal that it is ready to do
   timer-based compression of the RTP Timestamp.  The compressor will
   then make a decision based on its knowledge of the channel and the
   observed properties of the packet stream.

5.6.  Mode transitions

   The decision to move from one compression mode to another is taken by
   the decompressor and the possible mode transitions are shown in the
   figure below.  Subsequent chapters describe how the transitions are
   performed together with exceptions for the compression and
   decompression functionality during transitions.

Top      Up      ToC       Page 70 
                      +-------------------------+
                      | Unidirectional (U) mode |
                      +-------------------------+
                        / ^                 \ ^
                       / / Feedback(U)       \ \ Feedback(U)
                      / /                     \ \
                     / /                       \ \
        Feedback(O) / /             Feedback(R) \ \
                   v /                           v \
   +---------------------+    Feedback(R)    +-------------------+
   | Optimistic (O) mode | ----------------> | Reliable (R) mode |
   |                     | <---------------- |                   |
   +---------------------+    Feedback(O)    +-------------------+

5.6.1.  Compression and decompression during mode transitions

   The following sections assume that, for each context, the compressor
   and decompressor maintain a variable whose value is the current
   compression mode for that context.  The value of the variable
   controls, for the context in question, which packet types to use,
   which actions to be taken, etc.

   As a safeguard against residual errors, all feedback sent during a
   mode transition MUST be protected by a CRC, i.e., the CRC option MUST
   be used.  A mode transition MUST NOT be initiated by feedback which
   is not protected by a CRC.

   The subsequent subsections define exactly when to change the value of
   the MODE variable.  When ROHC transits between compression modes,
   there are several cases where the behavior of compressor or
   decompressor must be restricted during the transition phase.  These
   restrictions are defined by exception parameters that specify which
   restrictions to apply.  The transition descriptions in subsequent
   chapters refer to these exception parameters and defines when they
   are set and to what values.  All mode related parameters are listed
   below together with their possible values, with explanations and
   restrictions:

   Parameters for the compressor side:

      - C_MODE:
         Possible values for the C_MODE parameter are (U)NIDIRECTIONAL,
         (O)PTIMISTIC and (R)ELIABLE.  C_MODE MUST be initialized to U.

      - C_TRANS:
         Possible values for the C_TRANS parameter are (P)ENDING and
         (D)ONE.  C_TRANS MUST be initialized to D.  When C_TRANS is P,
         it is REQUIRED

Top      Up      ToC       Page 71 
         1) that the compressor only use packet formats common to all
            modes,

         2) that mode information is included in packets sent, at least
            periodically,

         3) that the compressor not transit to the SO state,

         4) that new mode transition requests be ignored.

   Parameters for the decompressor side:

      - D_MODE:
         Possible values for the D_MODE parameter are (U)NIDIRECTIONAL,
         (O)PTIMISTIC and (R)ELIABLE.  D_MODE MUST be initialized to U.

      - D_TRANS:
         Possible values for the D_TRANS parameter are (I)NITIATED,
         (P)ENDING and (D)ONE.  D_TRANS MUST be initialized to D.  A
         mode transition can be initiated only when D_TRANS is D.  While
         D_TRANS is I, the decompressor sends a NACK or ACK carrying a
         CRC option for each received packet.

5.6.2.  Transition from Unidirectional to Optimistic mode

   When there is a feedback channel available, the decompressor may at
   any moment decide to initiate transition from Unidirectional to
   Bidirectional Optimistic mode.  Any feedback packet carrying a CRC
   can be used with the mode parameter set to O.  The decompressor can
   then directly start working in Optimistic mode.  The compressor
   transits from Unidirectional to Optimistic mode as soon as it
   receives any feedback packet that has the mode parameter set to O and
   that passes the CRC check.  The transition procedure is described
   below:

              Compressor                     Decompressor
             ----------------------------------------------
                   |                               |
                   |        ACK(O)/NACK(O) +-<-<-<-|  D_MODE = O
                   |       +-<-<-<-<-<-<-<-+       |
   C_MODE = O      |-<-<-<-+                       |
                   |                               |

   If the feedback packet is lost, the compressor will continue to work
   in Unidirectional mode, but as soon as any feedback packet reaches
   the compressor it will transit to Optimistic mode.

Top      Up      ToC       Page 72 
5.6.3.  From Optimistic to Reliable mode

   Transition from Optimistic to Reliable mode is permitted only after
   at least one packet has been correctly decompressed, which means that
   at least the static part of the context is established.  An ACK(R) or
   a NACK(R) feedback packet carrying a CRC is sent to initiate the mode
   transition.  The compressor MUST NOT use packet types 0 or 1 during
   transition.  The transition procedure is described below:

              Compressor                     Decompressor
             ----------------------------------------------
                   |                               |
                   |        ACK(R)/NACK(R) +-<-<-<-|  D_TRANS = I
                   |       +-<-<-<-<-<-<-<-+       |
   C_TRANS = P     |-<-<-<-+                       |
   C_MODE = R      |                               |
                   |->->->-+ IR/IR-DYN/UOR-2(SN,R) |
                   |       +->->->->->->->-+       |
                   |->-..                  +->->->-|  D_TRANS = P
                   |->-..                          |  D_MODE = R
                   |           ACK(SN,R)   +-<-<-<-|
                   |       +-<-<-<-<-<-<-<-+       |
   C_TRANS = D     |-<-<-<-+                       |
                   |                               |
                   |->->->-+   R-0*, R-1*          |
                   |       +->->->->->->->-+       |
                   |                       +->->->-|  D_TRANS = D
                   |                               |

   As long as the decompressor has not received an UOR-2, IR-DYN, or IR
   packet with the mode transition parameter set to R, it must stay in
   Optimistic mode.  The compressor must not send packet types 1 or 0
   while C_TRANS is P, i.e., not until it has received an ACK for a
   UOR-2, IR-DYN, or IR packet sent with the mode transition parameter
   set to R.  When the decompressor receives packet types 0 or 1, after
   having ACKed an UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.

5.6.4.  From Unidirectional to Reliable mode

   The transition from Unidirectional to Reliable mode follows the same
   transition procedure as defined in section 5.6.3 above.

5.6.5.  From Reliable to Optimistic mode

   Either the ACK(O) or the NACK(O) feedback packet is used to initiate
   the transition from Reliable to Optimistic mode and the compressor
   MUST always run in the FO state during transition.  The transition
   procedure is described below:

Top      Up      ToC       Page 73 
              Compressor                     Decompressor
             ----------------------------------------------
                   |                               |
                   |        ACK(O)/NACK(O) +-<-<-<-|  D_TRANS = I
                   |       +-<-<-<-<-<-<-<-+       |
   C_TRANS = P     |-<-<-<-+                       |
   C_MODE = O      |                               |
                   |->->->-+ IR/IR-DYN/UOR-2(SN,O) |
                   |       +->->->->->->->-+       |
                   |->-..                  +->->->-|  D_MODE = O
                   |->-..                          |
                   |           ACK(SN,O)   +-<-<-<-|
                   |       +-<-<-<-<-<-<-<-+       |
   C_TRANS = D     |-<-<-<-+                       |
                   |                               |
                   |->->->-+  UO-0, UO-1*          |
                   |       +->->->->->->->-+       |
                   |                       +->->->-|  D_TRANS = D
                   |                               |

   As long as the decompressor has not received an UOR-2, IR-DYN, or IR
   packet with the mode transition parameter set to O, it must stay in
   Reliable mode.  The compressor must not send packet types 0 or 1
   while C_TRANS is P, i.e., not until it has received an ACK for an
   UOR-2, IR-DYN, or IR packet sent with the mode transition parameter
   set to O.  When the decompressor receives packet types 0 or 1, after
   having ACKed the UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.

5.6.6.  Transition to Unidirectional mode

   The decompressor can force a transition back to Unidirectional mode
   if it desires to do so.  Regardless of which mode this transition
   starts from, a three-way handshake MUST be carried out to ensure
   correct transition on the compressor side.  The transition procedure
   is described below:

Top      Up      ToC       Page 74 
              Compressor                     Decompressor
             ----------------------------------------------
               |                               |
               |        ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
               |       +-<-<-<-<-<-<-<-+       |
   C_TRANS = P |-<-<-<-+                       |
   C_MODE = U  |                               |
               |->->->-+ IR/IR-DYN/UOR-2(SN,U) |
               |       +->->->->->->->-+       |
               |->-..                  +->->->-|
               |->-..                          |
               |           ACK(SN,U)   +-<-<-<-|
               |       +-<-<-<-<-<-<-<-+       |
   C_TRANS = D |-<-<-<-+                       |
               |                               |
               |->->->-+  UO-0, UO-1*          |
               |       +->->->->->->->-+       |
               |                       +->->->-| D_TRANS = D, D_MODE= U

   After ACKing the first UOR-2(U), IR-DYN(U), or IR(U), the
   decompressor MUST continue to send feedback with the Mode parameter
   set to U until it receives packet types 0 or 1.

5.7.  Packet formats

   The following notation is used in this section:

      bits(X) = the number of bits for field X present in the compressed
                header (including extension).

      field(X) = the value of field X in the compressed header.

      context(X) = the value of field X as established in the context.

      value(X) = field(X) if X is present in the compressed header;
               = context(X) otherwise.

      hdr(X) = the value of field X in the uncompressed or
               decompressed header.

      Updating properties: Lists the fields in the context that are
         directly updated by processing the compressed header.  Note
         that there may be dependent fields that are implicitly also
         updated (e.g., an update to context(SN) often updates
         context(TS) as well).  See also section 5.2.7.

Top      Up      ToC       Page 75 
   The following fields occur in several headers and extensions:

   SN: The compressed RTP Sequence Number.

       Compressed with W-LSB.  The interpretation intervals, see section
       4.5.1, are defined as follows:

            p = 1                   if bits(SN) <= 4
            p = 2^(bits(SN)-5) - 1  if bits(SN) >  4

   IP-ID: A compressed IP-ID field.

      IP-ID fields in compressed base headers carry the compressed IP-ID
      of the innermost IPv4 header whose corresponding RND flag is not
      1.  The rules below assume that the IP-ID is for the innermost IP
      header.  If it is for an outer IP header, the RND2 and NBO2 flags
      are used instead of RND and NBO.

      If value(RND) = 0, hdr(IP-ID) is compressed using Offset IP-ID
      encoding (see section 4.5.5) using p = 0 and default-slope(IP-ID
      offset) = 0.

      If value(RND) = 1, IP-ID is the uncompressed hdr(IP-ID).  IP-ID is
      then passed as additional octets at the end of the compressed
      header, after any extensions.

      If value(NBO) = 0, the octets of hdr(IP-ID) are swapped before
      compression and after decompression.  The value of NBO is ignored
      when value(RND) = 1.

   TS: The compressed RTP Timestamp value.

      If value(TIME_STRIDE) > 0, timer-based compression of the RTP
      Timestamp is used (see section 4.5.4).

      If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
      compression (see section 4.5.3), and default-slope(TS) = 1.

      If value(Tsc) = 0, the Timestamp value is compressed as-is, and
      default-slope(TS) = value(TS_STRIDE).

      The interpretation intervals, see section 4.5.1, are defined as
      follows:

         p = 2^(bits(TS)-2) - 1

Top      Up      ToC       Page 76 
   CRC: The CRC over the original, uncompressed, header.

      For 3-bit CRCs, the polynomial of section 5.9.2 is used.
      For 7-bit CRCs, the polynomial of section 5.9.2 is used.
      For 8-bit CRCs, the polynomial of section 5.9.1 is used.

   M: RTP Marker bit.

      Context(M) is initially zero and is never updated.  value(M) = 1
      only when field(M) = 1.

Top      Up      ToC       Page 77 
   The general format for a compressed RTP header is as follows:

     0   1   2   3   4   5   6   7
    --- --- --- --- --- --- --- ---
   :         Add-CID octet         :  if for small CIDs and CID 1-15
   +---+---+---+---+---+---+---+---+
   |   first octet of base header  |  (with type indication)
   +---+---+---+---+---+---+---+---+
   :                               :
   /   0, 1, or 2 octets of CID    /  1-2 octets if large CIDs
   :                               :
   +---+---+---+---+---+---+---+---+
   /   remainder of base header    /  variable number of bits
   +---+---+---+---+---+---+---+---+
   :                               :
   /     Extension (see 5.7.5)     /  extension, if X = 1 in base header
   :                               :
    --- --- --- --- --- --- --- ---
   :                               :
   +   IP-ID of outer IPv4 header  +  2 octets, if value(RND2) = 1
   :                               :
    --- --- --- --- --- --- --- ---
   /    AH data for outer list     /  variable (see 5.8.4.2)
    --- --- --- --- --- --- --- ---
   :                               :
   +   GRE checksum (see 5.8.4.4)  +  2 octets, if GRE flag C = 1
   :                               :
    --- --- --- --- --- --- --- ---
   :                               :
   +   IP-ID of inner IPv4 header  +  2 octets, if value(RND) = 1
   :                               :
    --- --- --- --- --- --- --- ---
   /    AH data for inner list     /  variable (see 5.8.4.2)
    --- --- --- --- --- --- --- ---
   :                               :
   +   GRE checksum (see 5.8.4.4)  +  2 octets, if GRE flag C = 1
   :                               :
    --- --- --- --- --- --- --- ---
   :                               :
   +         UDP Checksum          +  2 octets,
   :                               :  if context(UDP Checksum) != 0
    --- --- --- --- --- --- --- ---

   Note that the order of the fields following the optional extension is
   the same as the order between the fields in an uncompressed header.

   In subsequent sections, the position of the large CID in the diagrams
   is indicated using this notation:

Top      Up      ToC       Page 78 
   +===+===+===+===+===+===+===+===+

   Whether the UDP Checksum field is present or not is controlled by the
   value of the UDP Checksum in the context.  If nonzero, the UDP
   Checksum is enabled and sent along with each packet.  If zero, the
   UDP Checksum is disabled and not sent.  Should hdr(UDP Checksum) be
   nonzero when context(UDP Checksum) is zero, the header cannot be
   compressed.  It must be sent uncompressed or the context
   reinitialized using an IR packet.  Context(UDP Checksum) is updated
   only by IR or IR-DYN headers, never by UDP checksums sent in headers
   of type 2, 1, or 0.

   When an IPv4 header is present in the static context, for which the
   corresponding RND flag has not been established to be 1, the packet
   types R-1 and UO-1 MUST NOT be used.

   When no IPv4 header is present in the static context, or the RND
   flags for all IPv4 headers in the context have been established to be
   1, the packet types R-1-ID, R-1-TS, UO-1-ID, and UO-1-TS MUST NOT be
   used.

   While in the transient state in which an RND flag is being
   established, the packet types R-1-ID, R-1-TS, UO-1-ID, and UO-1-TS
   MUST NOT be used.  This implies that the RND flag(s) of the Extension
   3 may have to be inspected before the format of a base header
   carrying an Extension 3 can be determined.

5.7.1. Packet type 0: UO-0, R-0, R-0-CRC

   Packet type 0 is indicated by the first bit being 0:

   R-0

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 0   0 |          SN           |
   +===+===+===+===+===+===+===+===+

      Updating properties: R-0 packets do not update any part of the
      context.

Top      Up      ToC       Page 79 
   R-0-CRC

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 0   1 |          SN           |
   +===+===+===+===+===+===+===+===+
   |SN |            CRC            |
   +---+---+---+---+---+---+---+---+

      Note: The SN field straddles the CID field.

      Updating properties: R-0-CRC packets update context(RTP Sequence
      Number).

   UO-0

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 0 |      SN       |    CRC    |
   +===+===+===+===+===+===+===+===+

      Updating properties: UO-0 packets update the current value of
      context(RTP Sequence Number).

5.7.2. Packet type 1 (R-mode): R-1, R-1-TS, R-1-ID

   Packet type 1 is indicated by the first bits being 10:

   R-1

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   0 |          SN           |
   +===+===+===+===+===+===+===+===+
   | M | X |          TS           |
   +---+---+---+---+---+---+---+---+

      Note: R-1 cannot be used if the context contains at least one IPv4
      header with value(RND) = 0.  This disambiguates it from R-1-ID and
      R-1-TS.

Top      Up      ToC       Page 80 
   R-1-ID

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   0 |          SN           |
   +===+===+===+===+===+===+===+===+
   | M | X |T=0|       IP-ID       |
   +---+---+---+---+---+---+---+---+

      Note: R-1-ID cannot be used if there is no IPv4 header in the
      context or if value(RND) and value(RND2) are both 1.

   R-1-TS

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   0 |          SN           |
   +===+===+===+===+===+===+===+===+
   | M | X |T=1|        TS         |
   +---+---+---+---+---+---+---+---+

      Note: R-1-TS cannot be used if there is no IPv4 header in the
      context or if value(RND) and value(RND2) are both 1.

      X: X = 0 indicates that no extension is present;
         X = 1 indicates that an extension is present.

      T: T = 0 indicates format R-1-ID;
         T = 1 indicates format R-1-TS.

      Updating properties: R-1* headers do not update any part of the
      context.

5.7.3. Packet type 1 (U/O-mode): UO-1, UO-1-ID, UO-1-TS

   UO-1

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   0 |          TS           |
   +===+===+===+===+===+===+===+===+
   | M |      SN       |    CRC    |
   +---+---+---+---+---+---+---+---+

      Note: UO-1 cannot be used if the context contains at least one
      IPv4 header with value(RND) = 0.  This disambiguates it from UO-
      1-ID and UO-1-TS.

Top      Up      ToC       Page 81 
   UO-1-ID

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   0 |T=0|       IP-ID       |
   +===+===+===+===+===+===+===+===+
   | X |      SN       |    CRC    |
   +---+---+---+---+---+---+---+---+

      Note: UO-1-ID cannot be used if there is no IPv4 header in the
      context or if value(RND) and value(RND2) are both 1.

   UO-1-TS

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   0 |T=1|        TS         |
   +===+===+===+===+===+===+===+===+
   | M |      SN       |    CRC    |
   +---+---+---+---+---+---+---+---+

      Note: UO-1-TS cannot be used if there is no IPv4 header in the
      context or if value(RND) and value(RND2) are both 1.

      X: X = 0 indicates that no extension is present;
         X = 1 indicates that an extension is present.

      T: T = 0 indicates format UO-1-ID;
         T = 1 indicates format UO-1-TS.

      Updating properties: UO-1* packets update context(RTP Sequence
      Number).  UO-1 and UO-1-TS packets update context(RTP Timestamp).
      UO-1-ID packets update context(IP-ID).  Values provided in
      extensions, except those in other SN, TS, or IP-ID fields, do not
      update the context.

Top      Up      ToC       Page 82 
5.7.4. Packet type 2: UOR-2

   Packet type 2 is indicated by the first bits being 110:

   UOR-2

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   0 |        TS         |
   +===+===+===+===+===+===+===+===+
   |TS | M |          SN           |
   +---+---+---+---+---+---+---+---+
   | X |            CRC            |
   +---+---+---+---+---+---+---+---+

      Note: UOR-2 cannot be used if the context contains at least one
      IPv4 header with value(RND) = 0.  This disambiguates it from UOR-
      2-ID and UOR-2-TS.

      Note: The TS field straddles the CID field.

   UOR-2-ID

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   0 |       IP-ID       |
   +===+===+===+===+===+===+===+===+
   |T=0| M |          SN           |
   +---+---+---+---+---+---+---+---+
   | X |            CRC            |
   +---+---+---+---+---+---+---+---+

      Note: UOR-2-ID cannot be used if there is no IPv4 header in the
      context or if value(RND) and value(RND2) are both 1.

   UOR-2-TS

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   0 |        TS         |
   +===+===+===+===+===+===+===+===+
   |T=1| M |          SN           |
   +---+---+---+---+---+---+---+---+
   | X |            CRC            |
   +---+---+---+---+---+---+---+---+

      Note: UOR-2-TS cannot be used if there is no IPv4 header in the
      context or if value(RND) and value(RND2) are both 1.

Top      Up      ToC       Page 83 
      X: X = 0 indicates that no extension is present;
         X = 1 indicates that an extension is present.

      T: T = 0 indicates format UOR-2-ID;
         T = 1 indicates format UOR-2-TS.

      Updating properties: All values provided in UOR-2* packets update
      the context, unless explicitly stated otherwise.

5.7.5.  Extension formats

   (Note: the term extension as used for additional information
   contained in the ROHC headers does not bear any relationship to the
   term extension header used in IP.)

   Fields in extensions are concatenated with the corresponding field in
   the base compressed header, if there is one.  Bits in an extension
   are less significant than bits in the base compressed header (see
   section 4.5.7).

   The TS field is scaled in all extensions, as it is in the base
   header, except optionally when using Extension 3 where the Tsc flag
   can indicate that the TS field is not scaled.  Value(TS_STRIDE) is
   used as the scale factor when scaling the TS field.

   In the following three extensions, the interpretation of the fields
   depends on whether there is a T-bit in the base compressed header,
   and if so, on the value of that field.  When there is no T-bit, +T
   and -T both mean TS.  This is the case when there are no IPv4 headers
   in the static context, and when all IPv4 headers in the static
   context have their corresponding RND flag set (i.e., RND = 1).

   If there is a T-bit,

      T = 1 indicates that +T is TS, and
                           -T is IP-ID;

      T = 0 indicates that +T is IP-ID, and
                           -T is TS.

   Extension 0:

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | 0   0 |    SN     |    +T     |
      +---+---+---+---+---+---+---+---+

Top      Up      ToC       Page 84 
   Extension 1:

      +---+---+---+---+---+---+---+---+
      | 0   1 |    SN     |    +T     |
      +---+---+---+---+---+---+---+---+
      |              -T               |
      +---+---+---+---+---+---+---+---+

   Extension 2:

      +---+---+---+---+---+---+---+---+
      | 1   0 |    SN     |    +T     |
      +---+---+---+---+---+---+---+---+
      |              +T               |
      +---+---+---+---+---+---+---+---+
      |              -T               |
      +---+---+---+---+---+---+---+---+

   Extension 3 is a more elaborate extension which can give values for
   fields other than SN, TS, and IP-ID.  Three optional flag octets
   indicate changes to IP header(s) and RTP header, respectively.

Top      Up      ToC       Page 85 
   Extension 3:

      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |  1     1  |  S  |R-TS | Tsc |  I  | ip  | rtp |            (FLAGS)
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |            Inner IP header flags        | ip2 |  if ip = 1
    ..... ..... ..... ..... ..... ..... ..... .....
   |            Outer IP header flags              |  if ip2 = 1
    ..... ..... ..... ..... ..... ..... ..... .....
   |                      SN                       |  if S = 1
    ..... ..... ..... ..... ..... ..... ..... .....
   /       TS (encoded as in section 4.5.6)        /  1-4 octets,
    ..... ..... ..... ..... ..... ..... ..... .....   if R-TS = 1
   |                                               |
   /            Inner IP header fields             /  variable,
   |                                               |  if ip = 1
    ..... ..... ..... ..... ..... ..... ..... .....
   |                     IP-ID                     |  2 octets, if I = 1
    ..... ..... ..... ..... ..... ..... ..... .....
   |                                               |
   /            Outer IP header fields             /  variable,
   |                                               |  if ip2 = 1
    ..... ..... ..... ..... ..... ..... ..... .....
   |                                               |
   /          RTP header flags and fields          /  variable,
   |                                               |  if rtp = 1
    ..... ..... ..... ..... ..... ..... ..... .....

      S, R-TS, I, ip, rtp, ip2: Indicate presence of fields as shown to
      the right of each field above.

      Tsc: Tsc = 0 indicates that TS is not scaled;
           Tsc = 1 indicates that TS is scaled according to section
           4.5.3, using value(TS_STRIDE).
           Context(Tsc) is always 1.  If scaling is not desired, the
           compressor will establish TS_STRIDE = 1.

      SN: See the beginning of section 5.7.

      TS: Variable number of bits of TS, encoded according to
          section 4.5.6.  See the beginning of section 5.7.

      IP-ID: See the beginning of section 5.7.

Top      Up      ToC       Page 86 
   Inner IP header flags

      These correspond to the inner IP header if there are two, and the
      single IP header otherwise.

      0     1     2     3     4     5     6     7
    ..... ..... ..... ..... ..... ..... ..... .....
   | TOS | TTL | DF  | PR  | IPX | NBO | RND | ip2 |  if ip = 1
    ..... ..... ..... ..... ..... ..... ..... .....

      TOS, TTL, PR, IPX: Indicates presence of fields as shown to the
          right of the field in question below.

      DF: Don't Fragment bit of IP header.

      NBO: Indicates whether the octets of hdr(IP identifier) of this IP
      header are swapped before compression and after decompression.

      NBO = 1 indicates that the octets need not be swapped.  NBO = 0
      indicates that the octets are to be swapped.  See section 4.5.5.

      RND: Indicates whether hdr(IP identifier) is not to be compressed
      but instead sent as-is in compressed headers.

      IP2: Indicates presence of Outer IP header fields.  Unless the
      static context contains two IP headers, IP2 is always zero.

   Inner IP header fields

    ..... ..... ..... ..... ..... ..... ..... .....
   |         Type of Service/Traffic Class         |  if TOS = 1
    ..... ..... ..... ..... ..... ..... ..... .....
   |         Time to Live/Hop Limit                |  if TTL = 1
    ..... ..... ..... ..... ..... ..... ..... .....
   |         Protocol/Next Header                  |  if PR = 1
    ..... ..... ..... ..... ..... ..... ..... .....
   /         IP extension headers                  /  variable,
    ..... ..... ..... ..... ..... ..... ..... .....   if IPX = 1

      Type of Service/Traffic Class: That field in the uncompressed IP
      header (absolute value).

      Time to Live/Hop Limit: That field in the uncompressed IP header.

      Protocol/Next Header: That field in the uncompressed IP header.

      IP extension header(s): According to section 5.8.5.

Top      Up      ToC       Page 87 
   Outer IP header flags

      The fields in this part of the Extension 3 header refer to the
      outermost IP header:

         0     1     2     3     4     5     6     7
       ..... ..... ..... ..... ..... ..... ..... .....  | TOS2| TTL2|
      DF2 | PR2 |IPX2 |NBO2 |RND2 |  I2 |  if ip2 = 1
       ..... ..... ..... ..... ..... ..... ..... .....

      These flags are the same as the Inner IP header flags, but refer
      to the outer IP header instead of the inner IP header.  The
      following flag, however, has no counterpart in the Inner IP header
      flags:

         I2: Indicates presence of the IP-ID field.

   Outer IP header fields

       ..... ..... ..... ..... ..... ..... ..... .....
      |      Type of Service/Traffic Class            |  if TOS2 = 1
       ..... ..... ..... ..... ..... ..... ..... .....
      |         Time to Live/Hop Limit                |  if TTL2 = 1
       ..... ..... ..... ..... ..... ..... ..... .....
      |         Protocol/Next Header                  |  if PR2 = 1
       ..... ..... ..... ..... ..... ..... ..... .....
      /         IP extension header(s)                /  variable,
       ..... ..... ..... ..... ..... ..... ..... .....    if IPX2 = 1
      |                  IP-ID                        |  2 octets,
       ..... ..... ..... ..... ..... ..... ..... .....    if I2 = 1

      The fields in this part of Extension 3 are as for the Inner IP
      header fields, but they refer to the outer IP header instead of
      the inner IP header.  The following field, however, has no
      counterpart among the Inner IP header fields:

         IP-ID: The IP Identifier field of the outer IP header, unless
         the inner header is an IPv6 header, in which case I2 is always
         zero.

Top      Up      ToC       Page 88 
   RTP header flags and fields

      0     1     2     3     4     5     6     7
    ..... ..... ..... ..... ..... ..... ..... .....
   |   Mode    |R-PT |  M  | R-X |CSRC | TSS | TIS |  if rtp = 1
    ..... ..... ..... ..... ..... ..... ..... .....
   | R-P |             RTP PT                      |  if R-PT = 1
    ..... ..... ..... ..... ..... ..... ..... .....
   /           Compressed CSRC list                /  if CSRC = 1
    ..... ..... ..... ..... ..... ..... ..... .....
   /                  TS_STRIDE                    /  1-4 oct if TSS = 1
    ..... ..... ..... ..... ..... ..... ..... ....
   /           TIME_STRIDE (milliseconds)          /  1-4 oct if TIS = 1
    ..... ..... ..... ..... ..... ..... ..... .....

      Mode: Compression mode. 0 = Reserved,
                              1 = Unidirectional,
                              2 = Bidirectional Optimistic,
                              3 = Bidirectional Reliable.

      R-PT, CSRC, TSS, TIS: Indicate presence of fields as shown to the
          right of each field above.

      R-P: RTP Padding bit, absolute value (presumed zero if absent).

      R-X: RTP eXtension bit, absolute value.

      M: See the beginning of section 5.7.

      RTP PT: Absolute value of RTP Payload type field.

      Compressed CSRC list: See section 5.8.1.

      TS_STRIDE: Predicted increment/decrement of the RTP Timestamp
      field when it changes.  Encoded as in section 4.5.6.

      TIME_STRIDE: Predicted time interval in milliseconds between
      changes in the RTP Timestamp.  Also an indication that the
      compressor desires to perform timer-based compression of the RTP
      Timestamp field: see section 4.5.4.  Encoded as in section 4.5.6.

5.7.5.1.  RND flags and packet types

   The values of the RND and RND2 flags are changed by sending UOR-2
   headers with Extension 3, or IR-DYN headers, where the flag(s) have
   their new values.  The establishment procedure of the flags is the
   normal one for the current mode, i.e., in U-mode and O-mode the
   values are repeated several times to ensure that the decompressor

Top      Up      ToC       Page 89 
   receives at least one.  In R-mode, the flags are sent until an
   acknowledgment for a packet with the new RND flag values is received.

   The decompressor updates the values of its RND and RND2 flags
   whenever it receives an UOR-2 with Extension 3 carrying values for
   RND or RND2, and the UOR-2 CRC verifies successful decompression.

   When an IPv4 header for which the corresponding RND flag has not been
   established to be 1 is present in the static context, the packet
   types R-1 and UO-1 MUST NOT be used.

   When no IPv4 header is present in the static context, or the RND
   flags for all IPv4 headers in the context have been established to be
   1, the packet types R-1-ID, R-1-TS, UO-1-ID, and UO-1-TS MUST NOT be
   used.

   While in the transient state in which an RND flag is being
   established, the packet types R-1-ID, R-1-TS, UO-1-ID, and UO-1-TS
   MUST NOT be used.  This implies that the RND flag(s) of Extension 3
   may have to be inspected before the exact format of a base header
   carrying an Extension 3 can be determined, i.e., whether a T-bit is
   present or not.

5.7.5.2.  Flags/Fields in context

   Some flags and fields in Extension 3 need to be maintained in the
   context of the decompressor.  Their values are established using the
   mechanism appropriate to the compression mode, unless otherwise
   indicated in the table below and in referred sections.

   Flag/Field      Initial value   Comment
   ---------------------------------------------------------------------
     Mode          Unidirectional  See section 5.6

     NBO               1           See section 4.5.5
     RND               0           See sections 4.5.5, 5.7.5.1

     NBO2              1           As NBO, but for outer header
     RND2              0           As RND, but for outer header

     TS_STRIDE         1           See section 4.5.3
     TIME_STRIDE       0           See section 4.5.4
     Tsc               1           Tsc is always 1 in context;
                                   can be 0 only when an Extension 3
                                   is present. See the discussion of the
                                   TS field in the beginning of section
                                   5.7.


Next RFC Part