RFC 3095
RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed
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
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).
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.
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).
- 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.
+-------------------------+
| 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
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.
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:
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:
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.
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
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.
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:
+===+===+===+===+===+===+===+===+ 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.
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.
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.
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.
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.
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 |
+---+---+---+---+---+---+---+---+
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.
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.
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.
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.
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
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 page on part 5)
