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.
----------------------------------------------------------------[Page 74]
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
----------------------------------------------------------------[Page 75]
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.
----------------------------------------------------------------[Page 76]
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:
----------------------------------------------------------------[Page 77]
+===+===+===+===+===+===+===+===+
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.
----------------------------------------------------------------[Page 78]
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.
----------------------------------------------------------------[Page 79]
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.
----------------------------------------------------------------[Page 80]
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.
----------------------------------------------------------------[Page 81]
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.
----------------------------------------------------------------[Page 82]
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 |
+---+---+---+---+---+---+---+---+
----------------------------------------------------------------[Page 83]
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.
----------------------------------------------------------------[Page 84]
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.
----------------------------------------------------------------[Page 85]
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.
----------------------------------------------------------------[Page 86]
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.
----------------------------------------------------------------[Page 87]
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
----------------------------------------------------------------[Page 88]
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.
----------------------------------------------------------------[Page 89]
5.7.6. Feedback packets and formats
When the round-trip time between compressor and decompressor is
large, several packets can be in flight concurrently. Therefore,
several packets may be received by the decompressor after feedback
has been sent and before the compressor has reacted to feedback.
Moreover, decompression may fail due to residual errors in the
compressed header.
Therefore,
a) in O-mode, the decompressor SHOULD limit the rate at which
feedback on successful decompression is sent (if it is sent at
all);
b) when decompression fails, feedback SHOULD be sent only when
decompression of several consecutive packets has failed, and when
this occurs, the feedback rate SHOULD be limited;
c) when packets are received which belong to a rejected packet
stream, the feedback rate SHOULD be limited.
A decompressor MAY limit the feedback rate by sending feedback only
for one out of every k packets provoking the same (kind of) feedback.
The appropriate value of k is implementation dependent; k might be
chosen such that feedback is sent 1-3 times per link round-trip time.
See section 5.2.2 for a discussion concerning ways to provide
feedback information to the compressor.
5.7.6.1. Feedback formats for ROHC RTP
This section describes the format for feedback information in ROHC
RTP. See also 5.2.2.
Several feedback formats carry a field labeled SN. The SN field
contains LSBs of an RTP Sequence Number. The sequence number to use
is the sequence number of the header which caused the feedback
information to be sent. If that sequence number cannot be
determined, for example when decompression fails, the sequence number
to use is that of the last successfully decompressed header. If no
sequence number is available, the feedback MUST carry a SN-NOT-VALID
option. Upon reception, the compressor matches valid SN LSBs with
the most recent header sent with a SN with matching LSBs. The
decompressor must ensure that it sends enough SN LSBs in its feedback
that this correlation does not become ambiguous; e.g., if an 8-bit SN
LSB field could wrap around within a round-trip time, the FEEDBACK-1
format cannot be used.
----------------------------------------------------------------[Page 90]
FEEDBACK-1
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| SN |
+---+---+---+---+---+---+---+---+
A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK,
FEEDBACK-2 must be used. FEEDBACK-1 does not contain any mode
information; FEEDBACK-2 must be used when mode information is
required.
FEEDBACK-2
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| Mode | SN |
+---+---+---+---+---+---+---+---+
| SN |
+---+---+---+---+---+---+---+---+
/ Feedback options /
+---+---+---+---+---+---+---+---+
Acktype: 0 = ACK
1 = NACK
2 = STATIC-NACK
3 is reserved (MUST NOT be used for parseability)
Mode: 0 is reserved
1 = Unidirectional mode
2 = Bidirectional Optimistic mode
3 = Bidirectional Reliable mode
Feedback options: A variable number of feedback options, see
section 5.7.6.2. Options may appear in any order.
5.7.6.2. ROHC RTP Feedback options
A ROHC RTP Feedback option has variable length and the following
general format:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type | Opt Len |
+---+---+---+---+---+---+---+---+
/ option data / Opt Len octets
+---+---+---+---+---+---+---+---+
----------------------------------------------------------------[Page 91]
Sections 5.7.6.3-9 describe the currently defined ROHC RTP feedback
options.
5.7.6.3. The CRC option
The CRC option contains an 8-bit CRC computed over the entire
feedback payload, without the packet type and code octet, but
including any CID fields, using the polynomial of section 5.9.1. If
the CID is given with an Add-CID octet, the Add-CID octet immediately
precedes the FEEDBACK-1 or FEEDBACK-2 format. For purposes of
computing the CRC, the CRC fields of all CRC options are zero.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 1 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| CRC |
+---+---+---+---+---+---+---+---+
When receiving feedback information with a CRC option, the compressor
MUST verify the information by computing the CRC and comparing the
result with the CRC carried in the CRC option. If the two are not
identical, the feedback information MUST be ignored.
5.7.6.4. The REJECT option
The REJECT option informs the compressor that the decompressor does
not have sufficient resources to handle the flow.
+---+---+---+---+---+---+---+---+
| Opt Type = 2 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
When receiving a REJECT option, the compressor stops compressing the
packet stream, and should refrain from attempting to increase the
number of compressed packet streams for some time. Any FEEDBACK
packet carrying a REJECT option MUST also carry a CRC option.
5.7.6.5. The SN-NOT-VALID option
The SN-NOT-VALID option indicates that the SN of the feedback is not
valid. A compressor MUST NOT use the SN of the feedback to find the
corresponding sent header when this option is present.
+---+---+---+---+---+---+---+---+
| Opt Type = 3 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
----------------------------------------------------------------[Page 92]
5.7.6.6. The SN option
The SN option provides 8 additional bits of SN.
+---+---+---+---+---+---+---+---+
| Opt Type = 4 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| SN |
+---+---+---+---+---+---+---+---+
5.7.6.7. The CLOCK option
The CLOCK option informs the compressor of the clock resolution of
the decompressor. This is needed to allow the compressor to estimate
the jitter introduced by the clock of the decompressor when doing
timer-based compression of the RTP Timestamp.
+---+---+---+---+---+---+---+---+
| Opt Type = 5 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| clock resolution (ms) |
+---+---+---+---+---+---+---+---+
The smallest clock resolution which can be indicated is 1
millisecond. The value zero has a special meaning: it indicates that
the decompressor cannot do timer-based compression of the RTP
Timestamp. Any FEEDBACK packet carrying a CLOCK option SHOULD also
carry a CRC option.
5.7.6.8. The JITTER option
The JITTER option allows the decompressor to report the maximum
jitter it has observed lately, using the following formula which is
very similar to the formula for Max_Jitter_BC in section 4.5.4.
Let observation window i contain the decompressor's best
approximation of the sliding window of the compressor (see section
4.5.4) when header i is received.
Max_Jitter_i =
max {|(T_i - T_j) - ((a_i - a_j) / TIME_STRIDE)|,
for all headers j in observation window i}
Max_Jitter =
max { Max_Jitter_i, for a large number of recent headers i }
----------------------------------------------------------------[Page 93]
This information may be used by the compressor to refine the formula
for determining k when doing timer-based compression of the RTP
Timestamp.
+---+---+---+---+---+---+---+---+
| Opt Type = 6 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| Max_Jitter |
+---+---+---+---+---+---+---+---+
The decompressor MAY ignore the oldest observed values of
Max_Jitter_i. Thus, the reported Max_Jitter may decrease.
Robustness will be reduced if the compressor uses a jitter estimate
which is too small. Therefore, a FEEDBACK packet carrying a JITTER
option SHOULD also carry a CRC option. Moreover, the compressor MAY
ignore decreasing Max_Jitter values.
5.7.6.9. The LOSS option
The LOSS option allows the decompressor to report the largest
observed number of packets lost in sequence. This information MAY be
used by the compressor to adjust the size of the reference window
used in U- and O-mode.
+---+---+---+---+---+---+---+---+
| Opt Type = 7 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| longest loss event (packets) |
+---+---+---+---+---+---+---+---+
The decompressor MAY choose to ignore the oldest loss events. Thus,
the value reported may decrease. Since setting the reference window
too small can reduce robustness, a FEEDBACK packet carrying a LOSS
option SHOULD also carry a CRC option. The compressor MAY choose to
ignore decreasing loss values.
5.7.6.10. Unknown option types
If an option type unknown to the compressor is encountered, it must
continue parsing the rest of the FEEDBACK packet, which is possible
since the length of the option is explicit, but MUST otherwise ignore
the unknown option.
5.7.6.11. RTP feedback example
Feedback for CID 8 indicating an ACK for SN 17 and Bidirectional
Reliable mode can have the following formats.
----------------------------------------------------------------[Page 94]
Assuming small CIDs:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | 0 1 1 | feedback packet type, Code = 3
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | 1 0 0 0 | Add-CID octet with CID = 8
+---+---+---+---+---+---+---+---+
| 0 0 | 1 1 | SN MSB = 0 | AckType = ACK, Mode = Reliable
+---+---+---+---+---+---+---+---+
| SN LSB = 17 |
+---+---+---+---+---+---+---+---+
The second, third, and fourth octet are handed to the compressor.
The FEEDBACK-1 format may also be used. Assuming large CIDs:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | 0 1 0 | feedback packet type, Code = 2
+---+---+---+---+---+---+---+---+
| 0 0 0 0 1 0 0 0 | large CID with value 8
+---+---+---+---+---+---+---+---+
| SN LSB = 17 |
+---+---+---+---+---+---+---+---+
The second and third octet are handed to the compressor.
Assuming small CIDs:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | 0 1 0 | feedback packet type, Code = 2
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | 1 0 0 0 | Add-CID octet with CID = 8
+---+---+---+---+---+---+---+---+
| SN LSB = 17 |
+---+---+---+---+---+---+---+---+
The second and third octet are handed to the compressor.
----------------------------------------------------------------[Page 95]
Assuming small CIDs and CID 0 instead of CID 8:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | 0 0 1 | feedback packet type, Code = 1
+---+---+---+---+---+---+---+---+
| SN LSB = 17 |
+---+---+---+---+---+---+---+---+
The second octet is handed to the compressor.
5.7.7. RTP IR and IR-DYN packets
The subheaders which are compressible are split into a STATIC part
and a DYNAMIC part. These parts are defined in sections 5.7.7.3
through 5.7.7.7.
The structure of a chain of subheaders is determined by each header
having a Next Header, or Protocol, field. This field identifies the
type of the following header. Each Static part below that is
followed by another Static part contains the Next Header/Protocol
field and allows parsing of the Static chain; the Dynamic chain, if
present, is structured analogously.
IR and IR-DYN packets will cause a packet to be delivered to upper
layers if and only if the payload is non-empty. This means that an
IP/UDP/RTP packet where the UDP length indicates a UDP payload of
size 12 octets cannot be represented by an IR or IR-DYN packet. Such
packets can instead be represented using the UNCOMPRESSED profile
(section 5.10).
5.7.7.1. Basic structure of the IR packet
This packet type communicates the static part of the context, i.e.,
the values of the constant SN functions. It can optionally also
communicate the dynamic part of the context, i.e., the parameters of
nonconstant SN functions. It can also optionally communicate the
payload of an original packet, if any.
----------------------------------------------------------------[Page 96]
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
| Add-CID octet | if for small CIDs and CID != 0
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 | D |
+---+---+---+---+---+---+---+---+
| |
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
| |
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
| Static chain | variable length
| |
+---+---+---+---+---+---+---+---+
| |
| Dynamic chain | present if D = 1, variable length
| |
- - - - - - - - - - - - - - - -
| |
| Payload | variable length
| |
- - - - - - - - - - - - - - - -
D: D = 1 indicates that the dynamic chain is present.
Profile: Profile identifier, abbreviated as defined in section
5.2.3.
CRC: 8-bit CRC, computed according to section 5.9.1.
Static chain: A chain of static subheader information.
Dynamic chain: A chain of dynamic subheader information. What
dynamic information is present is inferred from the Static
chain.
Payload: The payload of the corresponding original packet, if any.
The presence of a payload is inferred from the packet length.
----------------------------------------------------------------[Page 97]
5.7.7.2. Basic structure of the IR-DYN packet
This packet type communicates the dynamic part of the context, i.e.,
the parameters of nonconstant SN functions.
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and CID != 0
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 0 | IR-DYN packet type
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Dynamic chain / variable length
| |
+---+---+---+---+---+---+---+---+
: :
/ Payload / variable length
: :
- - - - - - - - - - - - - - - -
Profile: Profile identifier, abbreviated as defined in section 5.2.3.
CRC: 8-bit CRC, computed according to section 5.9.1.
NOTE: As the CRC checks only the integrity of the header
itself, an acknowledgment of this header does not signify that
previous changes to the static chain in the context are also
acknowledged. In particular, care should be taken when IR
packets that update an existing context are followed by IR-DYN
packets.
Dynamic chain: A chain of dynamic subheader information. What
dynamic information is present is inferred from the Static chain of
the context.
Payload: The payload of the corresponding original packet, if any.
The presence of a payload is inferred from the packet length.
----------------------------------------------------------------[Page 98]
Note: The static and dynamic chains of IR or IR-DYN packets for
profile 0x0001 (ROHC RTP) MUST end with the static and dynamic parts
of an RTP header. If not, the packet MUST be discarded and the
context MUST NOT be updated.
Note: The static or dynamic chains of IR or IR-DYN packets for
profile 0x0002 (ROHC UDP) MUST end with the static and dynamic parts
of a UDP header. If not, the packet MUST be discarded and the
context MUST NOT be updated.
Note: The static or dynamic chains of IR or IR-DYN packets for
profile 0x0003 (ROHC ESP) MUST end with the static and dynamic parts
of an ESP header. If not, the packet MUST be discarded and the
context MUST NOT be updated.
5.7.7.3. Initialization of IPv6 Header [IPv6]
Static part:
+---+---+---+---+---+---+---+---+
| Version = 6 |Flow Label(msb)| 1 octet
+---+---+---+---+---+---+---+---+
/ Flow Label (lsb) / 2 octets
+---+---+---+---+---+---+---+---+
| Next Header | 1 octet
+---+---+---+---+---+---+---+---+
/ Source Address / 16 octets
+---+---+---+---+---+---+---+---+
/ Destination Address / 16 octets
+---+---+---+---+---+---+---+---+
Dynamic part:
+---+---+---+---+---+---+---+---+
| Traffic Class | 1 octet
+---+---+---+---+---+---+---+---+
| Hop Limit | 1 octet
+---+---+---+---+---+---+---+---+
/ Generic extension header list / variable length
+---+---+---+---+---+---+---+---+
Eliminated:
Payload Length
----------------------------------------------------------------[Page 99]
Extras:
Generic extension header list: Encoded according to section
5.8.6.1, with all header items present in uncompressed form.
CRC-DYNAMIC: Payload Length field (octets 5-6).
CRC-STATIC: All other fields (octets 1-4, 7-40).
CRC coverage for extension headers is defined in section 5.8.7.
Note: The Next Header field indicates the type of the following
header in the static chain, rather than being a copy of the Next
Header field of the original IPv6 header. See also section 5.7.7.8.
Next To :: RObust Header Compression - Part 5
Credits
-- UnKnown --
|