draft-ietf-rohc-rtp-impl-guide-19.txt   draft-ietf-rohc-rtp-impl-guide-20.txt 
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT K. Sandlund INTERNET-DRAFT K. Sandlund
TO UPDATE: RFC 3095, 3241, 3843, 4019, 4362 G. Pelletier TO UPDATE: RFC 3095, 3241, 3843, 4019, 4362 G. Pelletier
Expires: November 2006 P. Kremer Expires: March 2007 P. Kremer
Ericsson Ericsson
May 22, 2006 September 19, 2006
RObust Header Compression (ROHC): RObust Header Compression (ROHC):
Corrections and Clarifications to RFC 3095 Corrections and Clarifications to RFC 3095
<draft-ietf-rohc-rtp-impl-guide-19.txt> <draft-ietf-rohc-rtp-impl-guide-20.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, each author accepts the provisions By submitting this Internet-Draft, each author accepts the provisions
of Section 3 of BCP 78. of Section 3 of BCP 78.
skipping to change at page 2, line 22 skipping to change at page 2, line 22
2.4. CRC coverage of the ESP NULL header.........................5 2.4. CRC coverage of the ESP NULL header.........................5
3. Mode transition..................................................5 3. Mode transition..................................................5
3.1. Feedback during mode transition to U- and O-mode............5 3.1. Feedback during mode transition to U- and O-mode............5
3.1.1. Mode transition procedures allowing sparse feedback....5 3.1.1. Mode transition procedures allowing sparse feedback....5
3.1.2. Transition from Reliable to Optimistic mode............6 3.1.2. Transition from Reliable to Optimistic mode............6
3.1.3. Transition to Unidirectional mode......................7 3.1.3. Transition to Unidirectional mode......................7
3.2. Feedback during mode transition.............................7 3.2. Feedback during mode transition.............................7
3.3. Packet decoding during mode transition......................8 3.3. Packet decoding during mode transition......................8
4. Timestamp encoding...............................................8 4. Timestamp encoding...............................................8
4.1. Encoding used for compressed TS bits........................8 4.1. Encoding used for compressed TS bits........................8
4.2. (De)compression of TS without transmitted TS bits...........9 4.2. (De)compression of TS without transmitted TS bits...........8
4.3. Interpretation intervals for TS encoding...................10 4.3. Interpretation intervals for TS encoding...................10
4.4. TS_STRIDE for scaled timestamp encoding....................10 4.4. Scaled RTP timestamp encoding..............................10
4.5. TS wraparound with scaled timestamp encoding...............11 4.4.1. TS_STRIDE for scaled timestamp encoding...............10
4.6. Recalculating TS_OFFSET....................................12 4.4.2. TS wraparound with scaled timestamp encoding..........11
4.7. TS_STRIDE and the Tsc flag in Extension 3..................12 4.4.3. Algorithm for scaled timestamp encoding...............11
4.8. Using timer-based compression..............................13 4.5. Recalculating TS_OFFSET....................................12
5. List compression................................................13 4.6. TS_STRIDE and the Tsc flag in Extension 3..................12
5.1. CSRC list items in RTP dynamic chain.......................13 4.7. Using timer-based compression..............................13
5. List compression................................................14
5.1. CSRC list items in RTP dynamic chain.......................14
5.2. Multiple occurrences of the CC field.......................14 5.2. Multiple occurrences of the CC field.......................14
5.3. Bit masks in list compression..............................14 5.3. Bit masks in list compression..............................14
5.4. Headers compressed with list compression...................14 5.4. Headers compressed with list compression...................15
5.5. ESP NULL header list compression...........................15 5.5. ESP NULL header list compression...........................15
5.6. Translation tables and indexes for IP extension headers....15 5.6. Translation tables and indexes for IP extension headers....15
5.7. Reference list.............................................15 5.7. Reference list.............................................16
5.8. Compression of AH and GRE sequence numbers.................16 5.8. Compression of AH and GRE sequence numbers.................16
6. Updating properties.............................................17 6. Updating properties.............................................17
6.1. Implicit updates...........................................17 6.1. Implicit updates...........................................17
6.2. Updating properties of UO-1*...............................17 6.2. Updating properties of UO-1*...............................18
6.3. Context updating properties for IR packets.................18 6.3. Context updating properties for IR packets.................18
6.4. RTP padding field (R-P) in extension 3.....................18 6.4. RTP padding field (R-P) in extension 3.....................18
6.5. RTP eXtension bit (X) in dynamic part......................18 6.5. RTP eXtension bit (X) in dynamic part......................19
7. Context management and CID/context re-use.......................19 7. Context management and CID/context re-use.......................19
7.1. Persistence of decompressor contexts.......................19 7.1. Persistence of decompressor contexts.......................19
7.2. CID/context re-use.........................................19 7.2. CID/context re-use.........................................19
7.2.1. Re-using a CID/context with the same profile..........20 7.2.1. Re-using a CID/context with the same profile..........20
7.2.2. Re-using a CID/context with a different profile.......20 7.2.2. Re-using a CID/context with a different profile.......20
8. Other protocol clarifications...................................21 8. Other protocol clarifications...................................21
8.1. Meaning of NBO.............................................21 8.1. Meaning of NBO.............................................21
8.2. IP-ID......................................................21 8.2. IP-ID......................................................21
8.3. Extension-3 in UOR-2* packets..............................21 8.3. Extension-3 in UOR-2* packets..............................21
8.4. Multiple occurrences of the M bit..........................21 8.4. Multiple occurrences of the M bit..........................22
8.5. Multiple SN options in one feedback packet.................22 8.5. Multiple SN options in one feedback packet.................22
8.6. Multiple CRC options in one feedback packet................22 8.6. Multiple CRC options in one feedback packet................22
8.7. Responding to lost feedback links..........................22 8.7. Responding to lost feedback links..........................22
8.8. UOR-2 in profile 0x0002 (UDP) and profile 0x0003 (ESP).....23 8.8. UOR-2 in profile 0x0002 (UDP) and profile 0x0003 (ESP).....23
8.9. Sequence number LSB's in IP extension headers..............23 8.9. Sequence number LSB's in IP extension headers..............23
8.10. Expecting UOR-2 ACKs in O-mode............................23 8.10. Expecting UOR-2 ACKs in O-mode............................23
9. ROHC negotiation................................................23 8.11. Context repairs, TS_STRIDE and TIME_STRIDE................23
10. PROFILES suboption in ROHC-over-PPP............................24 9. ROHC negotiation................................................24
11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......24 10. PROFILES suboption in ROHC-over-PPP............................25
12. Security considerations........................................24 11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......25
13. IANA considerations............................................24 12. Security considerations........................................25
14. Acknowledgment.................................................24 13. IANA considerations............................................25
14. Acknowledgment.................................................25
15. References.....................................................25 15. References.....................................................25
15.1. Normative References......................................25 15.1. Normative References......................................25
15.2. Informative References....................................25 15.2. Informative References....................................26
16. Authors' Addresses.............................................26 16. Authors' Addresses.............................................26
Appendix A - Sample CRC algorithm..................................27 Appendix A - Sample CRC algorithm..................................27
1. Introduction and terminology 1. Introduction and terminology
RFC 3095 [1] defines the RObust Header Compression (ROHC) framework RFC 3095 [1] defines the RObust Header Compression (ROHC) framework
and profiles for IP, UDP, RTP, and ESP. During implementation and and profiles for IP, UDP, RTP, and ESP. During implementation and
interoperability testing of RFC 3095 some ambiguities and common interoperability testing of RFC 3095 some ambiguities and common
misinterpretations have been identified, as well as a few errors. misinterpretations have been identified, as well as a few errors.
skipping to change at page 8, line 22 skipping to change at page 8, line 22
packets that do not carry a CRC such as R-0 and R-1* packets. packets that do not carry a CRC such as R-0 and R-1* packets.
This means that when D_TRANS=I during mode transition, a decompressor This means that when D_TRANS=I during mode transition, a decompressor
operating in R-mode sends an acknowledgement for each packet it operating in R-mode sends an acknowledgement for each packet it
receives and MUST use the sequence number that corresponds to the receives and MUST use the sequence number that corresponds to the
packet that last updated the context, i.e. the decompressor MUST NOT packet that last updated the context, i.e. the decompressor MUST NOT
use the sequence number of the R-0 or the R-1* packet." use the sequence number of the R-0 or the R-1* packet."
3.3. Packet decoding during mode transition 3.3. Packet decoding during mode transition
Each ROHC profile defines its own set of packet formats, and also its The purpose of a mode transition is to ensure that the compressor and
own feedback packets. The use of various operational modes is also the decompressor coherently move from one mode of operation to
defined by each specific profile. A decompressor can therefore not another using a three-way handshake. At one point during the mode
initiate a mode transition request before at least one packet of a transition, the decompressor acknowledges the reception of one (or
new context has been correctly decompressed, establishing the context more) IR, IR-DYN or UOR-2 packet(s) that have mode bits set to the
based on one specific profile (as specified in IR packets). The new mode. Packets of type 0 or 1 that are received up to this point
context must be established before the decompressor can know the are decompressed using the old mode, while afterwards they are
profile used, which modes are defined by that profile, and the decompressed using the new mode. If the enhanced transition
feedback packet formats available. Mode transition can therefore not procedures described in section 3.1 of this document are used, the
be initiated by the decompressor before it has an established context setting of the D_TRANS parameter to P represents this breakpoint. The
for the CID. successful decompression of a packet of type 0 or type 1 completes
the mode transition.
If the original transition procedures in sections 5.6.5 and 5.6.6 are
followed (and not the enhanced procedures described in section 3.1 of
this document), it is important to note that type 0 or type 1 packets
may be received by the decompressor during the first half of the
transition procedure, and these packets must not be mistakenly
interpreted as the packets sent by the compressor to indicate
completed transition. The decompressor side MUST therefore keep track
of the transition status, e.g. with an additional parameter. If the
enhanced transition procedures described in section 3 of this
document are used, the D_TRANS parameter can serve this purpose since
its definition and usage is slightly modified.
4. Timestamp encoding 4. Timestamp encoding
4.1. Encoding used for compressed TS bits 4.1. Encoding used for compressed TS bits
RTP Timestamp values (TS) are always encoded using W-LSB encoding, RTP Timestamp values (TS) are always encoded using W-LSB encoding,
both when sent scaled and when sent unscaled. For TS values sent in both when sent scaled and when sent unscaled. When no TS bits are
Extension 3, W-LSB encoded values are sent using the self-describing transmitted in a compressed packet, TS is always scaled. If a
variable-length format (section 4.5.6), and this applies to both compressed packet carries an extension 3 and field(Tsc)=0, the
scaled and unscaled values. compressed packet must thus always carry unscaled TS bits. For TS
values sent in Extension 3, W-LSB encoded values are sent using the
self-describing variable-length format (section 4.5.6), and this
applies to both scaled and unscaled values.
4.2. (De)compression of TS without transmitted TS bits 4.2. (De)compression of TS without transmitted TS bits
When ROHC RTP operate using its most efficient packet types, apart When ROHC RTP operate using its most efficient packet types, apart
from packet type identification and the error detection CRC, only RTP from packet type identification and the error detection CRC, only RTP
sequence number (SN) bits have to be transmitted in RTP compressed sequence number (SN) bits have to be transmitted in RTP compressed
headers. All other fields are then omitted either because they are headers. All other fields are then omitted either because they are
unchanged or because they can be reconstructed through a function unchanged or because they can be reconstructed through a function
from the SN (i.e. by combining the transmitted SN bits with state from the SN (i.e. by combining the transmitted SN bits with state
information from the context). Fields that can be inferred from the information from the context). Fields that can be inferred from the
SN are the IP Identification (IP-ID) and the RTP Timestamp (TS). SN are the IP Identification (IP-ID) and the RTP Timestamp (TS).
IP-ID compression and decompression, both with and without IP-ID compression and decompression, both with and without
transmitted IP-ID bits in the compressed header, are well defined in transmitted IP-ID bits in the compressed header, are well defined in
section 4.5.5 (see section 8.2 of this document). However, for TS it section 4.5.5 (see section 8.2 of this document). However, for TS it
is only defined how to decompress based on actual TS bits in the is only defined how to decompress based on actual TS bits in the
compressed header, either scaled or unscaled, but not how to infer compressed header, either scaled or unscaled, but not how to infer
the TS from the SN, i.e. in SO-state operation. This section the TS from the SN. This section specifies how the scaled TS is
specifies how the TS (scaled or unscaled) is decompressed when no TS decompressed when no TS bits are transmitted in the compressed
bits are transmitted in the compressed header. header.
When no TS bits are transmitted in the compressed header, the encoded When no TS bits are transmitted in the compressed header, the scaled
TS value (scaled or unscaled) is decompressed assuming a linear TS value is reconstructed assuming a linear extrapolation from the
extrapolation from the SN, i.e. delta_TS = delta_SN * default-slope, SN, i.e. delta_TS = delta_SN * default-slope, where delta_SN and
where delta_SN and delta_TS are both signed integers. Section 5.7 delta_TS are both signed integers. Section 5.7 defines the potential
defines the potential values for default-slope. values for default-slope.
INCOMPLETE RFC 3095 TEXT (section 5.7): INCOMPLETE RFC 3095 TEXT (section 5.7):
"If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before "If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
compression (see section 4.5.3), and default-slope(TS) = 1. compression (see section 4.5.3), and default-slope(TS) = 1.
If value(Tsc) = 0, the Timestamp value is compressed as-is, and If value(Tsc) = 0, the Timestamp value is compressed as-is, and
default-slope(TS) = value(TS_STRIDE)." default-slope(TS) = value(TS_STRIDE)."
CORRECTED TEXT: CORRECTED TEXT:
"When a compressed header with no TS bits is received, the encoded "When a compressed header with no TS bits is received, the scaled
TS value (scaled or unscaled) is decompressed assuming a linear TS value is reconstructed assuming a linear extrapolation from
extrapolation from the SN, i.e. delta_TS = delta_SN * default- the SN, i.e. delta_TS = delta_SN * default-slope(TS).
slope.
If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
compression (see section 4.5.3), and default-slope(TS) = 1. compression (see section 4.5.3), and default-slope(TS) = 1.
If value(Tsc) = 0, the Timestamp value is compressed as-is, and If value(Tsc) = 0, the Timestamp value is compressed as-is, and
default-slope(TS) = value(TS_STRIDE)." default-slope(TS) = value(TS_STRIDE). If a packet with no TS bits
is received with Tsc=0, the decompressor MUST discard the
packet."
INCORRECT AND INVALIDATED RFC 3095 TEXT (section 5.5.1.2): INCORRECT AND INVALIDATED RFC 3095 TEXT (section 5.5.1.2):
"For example, in a typical case where the string pattern has the "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 form of non-SN-field = SN * slope + offset, one ACK is enough if
the slope has been previously established by the decompressor the slope has been previously established by the decompressor
(i.e., only the new offset needs to be synchronized). Otherwise, (i.e., only the new offset needs to be synchronized). Otherwise,
two ACKs are required since the decompressor needs two headers to two ACKs are required since the decompressor needs two headers to
learn both the new slope and the new offset." learn both the new slope and the new offset."
Consequently, there is no other slope value than the default-slope, Consequently, there is no other slope value than the default-slope,
as defined in section 5.7. as defined in section 5.7.
4.3. Interpretation intervals for TS encoding 4.3. Interpretation intervals for TS encoding
Section 4.5.4 defines the interpretation interval, p, for timer-based Section 4.5.4 defines the interpretation interval, p, for timer-based
compression of the RTP timestamp. However, Section 5.7 defines a compression of the RTP timestamp. However, Section 5.7 defines a
different interpretation interval, which is defined as the different interpretation interval, which is defined as the
interpretation interval to use for all TS values. It is thus unclear interpretation interval to use for all TS values. It is thus unclear
which p-value to use, at least for timer-based compression. which p-value to use, at least for timer-based compression.
skipping to change at page 10, line 29 skipping to change at page 10, line 24
The way this should be interpreted is that the p-value differs The way this should be interpreted is that the p-value differs
depending on whether timer-based compression is enabled or not. depending on whether timer-based compression is enabled or not.
For timer-based compression (TIME_STRIDE set to a non-zero value), For timer-based compression (TIME_STRIDE set to a non-zero value),
the interpretation interval is: the interpretation interval is:
p = 2^(k-1) - 1 (as per section 4.5.4) p = 2^(k-1) - 1 (as per section 4.5.4)
Otherwise, the interpretation interval is: Otherwise, the interpretation interval is:
p = 2^(k-2) - 1 (as per section 5.7) p = 2^(k-2) - 1 (as per section 5.7)
Since two different p-values are used, the compressor must take this 4.4. Scaled RTP timestamp encoding
into account throughout the process of enabling timer-based
compression (see section 4.8 of this document). During transition
from window-based compression to timer-based compression, it is thus
necessary that the compressor keep k large enough to cover both
interpretation intervals.
4.4. TS_STRIDE for scaled timestamp encoding This section redefines the algorithm for scaled RTP timestamp
encoding, defined as a 5-step procedure in section 4.5.3. Two formal
errors have been corrected, as described in subsections 4.4.1 and
4.4.2 below, and the whole algorithm has been reworked to be more
concise and use well-defined terminology. The resulting text can be
found in 4.4.3 below.
4.4.1. TS_STRIDE for scaled timestamp encoding
RFC 3095 defines the timestamp stride (TS_STRIDE) as the expected RFC 3095 defines the timestamp stride (TS_STRIDE) as the expected
increase in the timestamp value between two RTP packets with increase in the timestamp value between two RTP packets with
consecutive sequence numbers. TS_STRIDE is set by the compressor and consecutive sequence numbers. TS_STRIDE is set by the compressor and
explicitly communicated to the decompressor, and it is used either as explicitly communicated to the decompressor, and it is used as the
the scaling factor for scaled TS encoding, or constitutes the scaling factor for scaled TS encoding.
default-slope used when decompressing an unscaled TS through a linear
extrapolation from the SN (see also section 4.2 of this document).
The relation between TS and TS_SCALED, given by the following The relation between TS and TS_SCALED, given by the following
equality in section 4.5.3, defines the mathematical meaning of equality in section 4.5.3, defines the mathematical meaning of
TS_STRIDE: TS_STRIDE:
TS = TS_SCALED * TS_STRIDE + TS_OFFSET TS = TS_SCALED * TS_STRIDE + TS_OFFSET
TS_SCALED is incorrectly written as TS / TS_STRIDE in the compression TS_SCALED is incorrectly written as TS / TS_STRIDE in the compression
step following the above core equality. This formula is incorrect step following the above core equality. This formula is incorrect
both because it excludes TS_OFFSET and because it would prevent a both because it excludes TS_OFFSET and because it would prevent a
TS_STRIDE value of 0, which is an alternative not excluded by the TS_STRIDE value of 0, which is an alternative not excluded by the
core equality above. If "/" were a generally unambiguously defined definition or by the core equality above. If "/" were a generally
operation meaning "the integral part of the result from dividing X by unambiguously defined operation meaning "the integral part of the
Y", the absence of TS_OFFSET could be explained, but the formula result from dividing X by Y", the absence of TS_OFFSET could be
would still lack a proper output for TS_STRIDE equal to 0. The explained, but the formula would still lack a proper output for
formula of "2. Compression" is thus invalid. TS_STRIDE equal to 0. The formula of "2. Compression" is thus
invalid.
INCORRECT RFC 3095 TEXT (section 4.5.3):
"2. Compression: After initialization, the compressor no longer
compresses the original TS values. Instead, it compresses the
downscaled values: TS_SCALED = TS / TS_STRIDE. The
compression method could be either W-LSB encoding or the
timer-based encoding described in the next section."
CORRECTED TEXT:
"2. Compression: After initialization, the compressor no longer
compresses the original TS values. Instead, it compresses the
downscaled values. The compression method could be either
W-LSB encoding or the timer-based encoding described in the
next section."
4.5. TS wraparound with scaled timestamp encoding 4.4.2. TS wraparound with scaled timestamp encoding
Section 4.5.3 states in point 4 and 5 that the compressor is not Section 4.5.3 states in point 4 and 5 that the compressor is not
required to initialize TS_OFFSET at wraparound, but that it is required to initialize TS_OFFSET at wraparound, but that it is
required to increase the number of bits sent for the scaled TS value required to increase the number of bits sent for the scaled TS value
when there is a TS wraparound. The decompressor is also required to when there is a TS wraparound. The decompressor is also required to
detect and cope with TS wraparound, including updating TS_OFFSET. detect and cope with TS wraparound, including updating TS_OFFSET.
This method is not interoperable and not robust. The gain is also This method is not interoperable and not robust. The gain is also
insignificant, as TS wraparound happens very seldom. Therefore, the insignificant, as TS wraparound happens very seldom. Therefore, the
compressor reinitializes TS_OFFSET upon TS wraparound, by sending compressor reinitializes TS_OFFSET upon TS wraparound, by sending
unscaled TS. unscaled TS.
4.4.3. Algorithm for scaled timestamp encoding
INCORRECT RFC 3095 TEXT (section 4.5.3): INCORRECT RFC 3095 TEXT (section 4.5.3):
"4. Offset at wraparound: Wraparound of the unscaled 32-bit TS "1. Initialization: The compressor sends to the decompressor the
value of TS_STRIDE and the absolute value of one or several TS
fields. The latter are used by the decompressor to initialize
TS_OFFSET to (absolute value) modulo TS_STRIDE. Note that
TS_OFFSET is the same regardless of which absolute value is
used, as long as the unscaled TS value does not wrap around;
see 4) below.
2. Compression: After initialization, the compressor no longer
compresses the original TS values. Instead, it compresses the
downscaled values: TS_SCALED = TS / TS_STRIDE. The
compression method could be either W-LSB encoding or the
timer-based encoding described in the next section.
3. Decompression: When receiving the compressed value of
TS_SCALED, the decompressor first derives the value of the
original TS_SCALED. The original RTP TS is then calculated as
TS = TS_SCALED * TS_STRIDE + TS_OFFSET.
4. Offset at wraparound: Wraparound of the unscaled 32-bit TS
will invalidate the current value of TS_OFFSET used in the will invalidate the current value of TS_OFFSET used in the
equation above. For example, let us assume TS_STRIDE = 160 = equation above. For example, let us assume TS_STRIDE = 160 =
0xA0 and the current TS = 0xFFFFFFF0. TS_OFFSET is then 0x50 0xA0 and the current TS = 0xFFFFFFF0. TS_OFFSET is then 0x50
= 80. Then if the next RTP TS = 0x00000130 (i.e., the = 80. Then if the next RTP TS = 0x00000130 (i.e., the
increment is 160 * 2 = 320), the new TS_OFFSET should be increment is 160 * 2 = 320), the new TS_OFFSET should be
0x00000130 modulo 0xA0 = 0x90 = 144. The compressor is not 0x00000130 modulo 0xA0 = 0x90 = 144. The compressor is not
required to re-initialize TS_OFFSET at wraparound. Instead, required to re-initialize TS_OFFSET at wraparound. Instead,
the decompressor MUST detect wraparound of the unscaled TS the decompressor MUST detect wraparound of the unscaled TS
(which is trivial) and update TS_OFFSET to (which is trivial) and update TS_OFFSET to
TS_OFFSET = (Wrapped around unscaled TS) modulo TS_STRIDE"
TS_OFFSET = (Wrapped around unscaled TS) modulo TS_STRIDE
CORRECTED TEXT: CORRECTED TEXT:
"4. Offset at wraparound: If the value of TS_STRIDE is not equal "1. Initialization and updating of RTP TS scaling function:
The compressor sends to the decompressor the value of
TS_STRIDE along with an unscaled TS. These are both needed by
the decompressor to initialize TS_OFFSET as hdr(TS) modulo
field(TS_STRIDE). Note that TS_OFFSET is the same for any TS
as long as TS_STRIDE does not change and as long as the
unscaled TS value does not wrap around; see 4) below.
2. Compression: After initialization, the compressor no longer
compresses the unscaled TS values. Instead, it compresses the
scaled values. The compression method can be either W-LSB
encoding or timer-based encoding.
3. Decompression: When receiving a (compressed) TS_SCALED, the
field is first decompressed, and the unscaled RTP TS is then
calculated as TS = TS_SCALED * TS_STRIDE + TS_OFFSET.
4. Offset at wraparound: If the value of TS_STRIDE is not equal
to a power of two, wraparound of the unscaled 32-bit TS will to a power of two, wraparound of the unscaled 32-bit TS will
change the value of TS_OFFSET. When this happens, the change the value of TS_OFFSET. When this happens, the
compressor SHOULD reinitialize TS_OFFSET by sending unscaled compressor SHOULD reinitialize TS_OFFSET by sending unscaled
TS, as in 1 above." TS, as in 1 above."
INCORRECT AND INVALIDATED RFC 3095 TEXT (section 4.5.3): INCORRECT AND INVALIDATED RFC 3095 TEXT (section 4.5.3):
The entire point 5, i.e. the entire text starting from "5. The entire point 5, i.e. the entire text starting from "5.
Interpretation interval at wraparound ...", down to and including Interpretation interval at wraparound ...", down to and including
the block of text that starts with "Let a be the number of LSBs" the block of text that starts with "Let a be the number of LSBs"
and that ends with "...interpretation interval is b." is incorrect and that ends with "...interpretation interval is b." is incorrect
and is thus invalid. and is thus invalid.
4.6. Recalculating TS_OFFSET 4.5. Recalculating TS_OFFSET
TS can be sent unscaled if the TS value change does not match the TS can be sent unscaled if the TS value change does not match the
established TS_STRIDE, but the TS_STRIDE might still stay unchanged. established TS_STRIDE, but the TS_STRIDE might still stay unchanged.
To ensure correct decompression of subsequent packets, the To ensure correct decompression of subsequent packets, the
decompressor MUST therefore always recalculate TS_OFFSET (RTP TS decompressor MUST therefore always recalculate TS_OFFSET (RTP TS
modulo TS_STRIDE) when a packet with an unscaled TS value is modulo TS_STRIDE) when a packet with an unscaled TS value is
received. received.
4.7. TS_STRIDE and the Tsc flag in Extension 3 4.6. TS_STRIDE and the Tsc flag in Extension 3
The Tsc flag in Extension 3 indicates whether TS is scaled or not. The Tsc flag in Extension 3 indicates whether TS is scaled or not.
The value of the Tsc flag thus applies to all TS bits, also if there The value of the Tsc flag thus applies to all TS bits, also if there
are no TS bits in the extension itself. When TS is scaled, it is are no TS bits in the extension itself. When TS is scaled, it is
always scaled using context(TS_STRIDE). The legend for Extension 3 in always scaled using context(TS_STRIDE). The legend for Extension 3 in
section 5.7.5 incorrectly states that value(TS_STRIDE) is used for section 5.7.5 incorrectly states that value(TS_STRIDE) is used for
scaled TS, which is incorrect. scaled TS, which is incorrect.
If TS_STRIDE is present in Extension 3, as indicated by the Tss flag If TS_STRIDE is present in Extension 3, as indicated by the Tss flag
being set, the TS field in the compressed header SHOULD contain being set, the compressed header SHOULD carry unscaled TS bits, i.e.
unscaled TS bits, i.e. the Tsc flag SHOULD NOT be set when Tss is set the Tsc flag SHOULD NOT be set when Tss is set since an unscaled TS
since an unscaled TS is needed together with TS_STRIDE to recalculate is needed together with TS_STRIDE to recalculate the TS_OFFSET. If
the TS_OFFSET. If TS_STRIDE is included in a compressed header with TS_STRIDE is included in a compressed header with scaled TS, the
scaled TS, the decompressor must ignore and discard field(TS_STRIDE). decompressor must ignore and discard field(TS_STRIDE).
INCORRECT RFC 3095 TEXT (section 4.5.3): INCORRECT RFC 3095 TEXT (section 4.5.3):
"Tsc: Tsc = 0 indicates that TS is not scaled; "Tsc: Tsc = 0 indicates that TS is not scaled;
Tsc = 1 indicates that TS is scaled according to section Tsc = 1 indicates that TS is scaled according to section
4.5.3, using value(TS_STRIDE). 4.5.3, using value(TS_STRIDE).
Context(Tsc) is always 1. If scaling is not desired, the Context(Tsc) is always 1. If scaling is not desired, the
compressor will establish TS_STRIDE = 1." compressor will establish TS_STRIDE = 1."
CORRECTED TEXT: CORRECTED TEXT:
"Tsc: Tsc = 0 indicates that TS is not scaled; "Tsc: Tsc = 0 indicates that TS is not scaled;
Tsc = 1 indicates that TS is scaled according to section Tsc = 1 indicates that TS is scaled according to section
4.5.3, using context(TS_STRIDE). 4.5.3, using context(TS_STRIDE).
Context(Tsc) is always 1. If scaling is not desired, the Context(Tsc) is always 1. If scaling is not desired, the
compressor will establish TS_STRIDE = 1. compressor will establish TS_STRIDE = 1.
If field(Tsc) = 1, and if TSS = 1 (meaning that TS_STRIDE is If field(Tsc) = 1, and if TSS = 1 (meaning that TS_STRIDE is
skipping to change at page 13, line 20 skipping to change at page 13, line 36
Context(Tsc) is always 1. If scaling is not desired, the Context(Tsc) is always 1. If scaling is not desired, the
compressor will establish TS_STRIDE = 1. compressor will establish TS_STRIDE = 1.
If field(Tsc) = 1, and if TSS = 1 (meaning that TS_STRIDE is If field(Tsc) = 1, and if TSS = 1 (meaning that TS_STRIDE is
present in the extension), field(TS_STRIDE) MUST be ignored present in the extension), field(TS_STRIDE) MUST be ignored
and discarded." and discarded."
When the compressor re-establishes a new value for TS_STRIDE using When the compressor re-establishes a new value for TS_STRIDE using
Extension-3, it should send unscaled TS bits together with TS_STRIDE. Extension-3, it should send unscaled TS bits together with TS_STRIDE.
4.8. Using timer-based compression 4.7. Using timer-based compression
Timer-based compression of the RTP timestamp, as described in section Timer-based compression of the RTP timestamp, as described in section
4.5.4, may be used to reduce the number of transmitted timestamp bits 4.5.4, may be used to reduce the number of transmitted timestamp bits
(bytes) needed when the timestamp can not be inferred from the SN. (bytes) needed when the timestamp can not be inferred from the SN.
Timer-based compression is only used for decompression of compressed Timer-based compression is only used for decompression of compressed
headers that contains a TS field, otherwise when no timestamp bits headers that contains a TS field, otherwise when no timestamp bits
are present the timestamp is linearly inferred from the SN (see are present the timestamp is linearly inferred from the SN (see
section 4.2 of this document). section 4.2 of this document).
Whether to use timer-based compression or not is controlled by the Whether to use timer-based compression or not is controlled by the
skipping to change at page 23, line 44 skipping to change at page 23, line 51
compressor behavior will significantly degrade the compression compressor behavior will significantly degrade the compression
performance. This is because UOR-2 ACKs can be sent from a performance. This is because UOR-2 ACKs can be sent from a
decompressor for other purposes than to acknowledge the UOR-2 packet, decompressor for other purposes than to acknowledge the UOR-2 packet,
e.g. to send feedback such as clock resolution, or to initiate a mode e.g. to send feedback such as clock resolution, or to initiate a mode
transition. If an implementation does use the optional acknowledgment transition. If an implementation does use the optional acknowledgment
algorithm described in Section 5.4.1.1.2, it must make sure to set algorithm described in Section 5.4.1.1.2, it must make sure to set
the k_3 and n_3 parameters to much larger values than one to ensure the k_3 and n_3 parameters to much larger values than one to ensure
that the compressor performance is not degraded due to the problem that the compressor performance is not degraded due to the problem
described above. described above.
8.11. Context repairs, TS_STRIDE and TIME_STRIDE
The 7-bit CRC used to verify the outcome of the decompression attempt
covers the original uncompressed header. The CRC verification thus
excludes TS_STRIDE and TIME_STRIDE, as these fields are not part of
the original uncompressed header.
The UOR-2 packet type can be used to update the value of the
TS_STRIDE and/or the TIME_STRIDE, with the extension 3. However,
these fields are not used for decompression of the RTP TS field for
this packet type and their respective value is thus not verified,
either implicitly or explicitly.
When the compressor receives a negative acknowledgement, it can thus
not determine if the failure may be caused by an unsuccessful update
to the TS_STRIDE and/or the TIME_STRIDE field(s), for which a
previous header that last attempted to update their value had
previously been acknowledged.
FORMAL ADDITION TO RFC 3095:
"When the compressor receives a NACK and uses the UOR-2 header
type to repair the decompressor context, it SHOULD include fields
that update the value of both the TS_STRIDE and the TIME_STRIDE
whose value it has updated at least once since the establishment
of that context, i.e. since the CID was first associated with its
current profile.
When the compressor receives a static-NACK, it MUST include in
the IR header fields for both the TS_STRIDE and the TIME_STRIDE
whose value it has updated at least once since the establishment
of that context, i.e. since the CID was first associated with its
current profile."
9. ROHC negotiation 9. ROHC negotiation
Section 4.1 states that the link layer must provide means to Section 4.1 states that the link layer must provide means to
negotiate e.g. the channel parameters listed in section 5.1.1. One of negotiate e.g. the channel parameters listed in section 5.1.1. One of
these parameters is the PROFILES parameter, which is a set of non- these parameters is the PROFILES parameter, which is a set of non-
negative integers where each integer indicates a profile supported by negative integers where each integer indicates a profile supported by
the decompressor. the decompressor.
Each profile is identified by a 16-bit value, where the 8 LSB bits Each profile is identified by a 16-bit value, where the 8 LSB bits
indicate the actual profile, and the 8 MSB bits indicate the variant indicate the actual profile, and the 8 MSB bits indicate the variant
skipping to change at page 24, line 49 skipping to change at page 25, line 40
considerations of [1] apply without additions. considerations of [1] apply without additions.
13. IANA considerations 13. IANA considerations
This document does not require any IANA actions. This document does not require any IANA actions.
14. Acknowledgment 14. Acknowledgment
The authors would like to thank Vicknesan Ayadurai, Carsten Bormann, The authors would like to thank Vicknesan Ayadurai, Carsten Bormann,
Mikael Degermark, Zhigang Liu, Abigail Surtees, Mark West, Tommy Mikael Degermark, Zhigang Liu, Abigail Surtees, Mark West, Tommy
Lundemo, Alan Kennington and Remi Pelland for their contributions and Lundemo, Alan Kennington, Remi Pelland, Lajos Zaccomer, Endre Szalai,
Mark Kalmanczhelyi, and Arpad Szakacs for their contributions and
comments. Thanks also to the committed document reviewers, Carl comments. Thanks also to the committed document reviewers, Carl
Knutsson and Biplab Sarkar, who reviewed the document during working Knutsson and Biplab Sarkar, who reviewed the document during working
group last-call. group last-call.
15. References 15. References
15.1. Normative References 15.1. Normative References
[1] C. Bormann, et al., "RObust Header Compression (ROHC): Framework [1] C. Bormann, et al., "RObust Header Compression (ROHC): Framework
and four profiles: RTP, UDP, ESP, and uncompressed", and four profiles: RTP, UDP, ESP, and uncompressed",
skipping to change at page 29, line 45 skipping to change at page 29, line 45
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires November 22, 2006. This Internet-Draft expires March 19, 2007.
 End of changes. 36 change blocks. 
110 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/