draft-ietf-rohc-rtp-impl-guide-20.txt   draft-ietf-rohc-rtp-impl-guide-21.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: March 2007 P. Kremer Expires: April 2007 P. Kremer
Ericsson Ericsson
September 19, 2006 October 13, 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-20.txt> <draft-ietf-rohc-rtp-impl-guide-21.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 54 skipping to change at page 2, line 54
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......................19 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..............................22
8.4. Multiple occurrences of the M bit..........................22 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..........................23
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
8.11. Context repairs, TS_STRIDE and TIME_STRIDE................23 8.11. Context repairs, TS_STRIDE and TIME_STRIDE................24
9. ROHC negotiation................................................24 9. ROHC negotiation................................................24
10. PROFILES suboption in ROHC-over-PPP............................25 10. PROFILES suboption in ROHC-over-PPP............................25
11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......25 11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......25
12. Security considerations........................................25 12. Security considerations........................................25
13. IANA considerations............................................25 13. IANA considerations............................................25
14. Acknowledgment.................................................25 14. Acknowledgment.................................................25
15. References.....................................................25 15. References.....................................................26
15.1. Normative References......................................25 15.1. Normative References......................................26
15.2. Informative References....................................26 15.2. Informative References....................................26
16. Authors' Addresses.............................................26 16. Authors' Addresses.............................................27
Appendix A - Sample CRC algorithm..................................27 Appendix A - Sample CRC algorithm..................................28
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 [8][9], UDP [10], RTP [11], and ESP [12]. During
interoperability testing of RFC 3095 some ambiguities and common implementation and interoperability testing of RFC 3095 some
misinterpretations have been identified, as well as a few errors. ambiguities and common misinterpretations have been identified, as
well as a few errors.
This document summarizes identified issues and provides corrections This document summarizes identified issues and provides corrections
needed for implementations of RFC 3095 to interoperate, i.e. it needed for implementations of RFC 3095 to interoperate, i.e. it
constitutes an update to RFC 3095. This document also provides other constitutes an update to RFC 3095. This document also provides other
clarifications related to common misinterpretations of the clarifications related to common misinterpretations of the
specification. When referring to RFC 3095, this document should specification. When referring to RFC 3095, this document should
therefore also be referenced. therefore also be referenced.
In addition, some clarifications and corrections are also provided In addition, some clarifications and corrections are also provided
for RFC 3241 [2] (ROHC over PPP), RFC 3843 [4] (ROHC IP-only for RFC 3241 [2] (ROHC over PPP), RFC 3843 [4] (ROHC IP-only
skipping to change at page 4, line 5 skipping to change at page 4, line 5
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [6]. document are to be interpreted as described in RFC 2119 [6].
When a section of this document makes formal corrections, additions When a section of this document makes formal corrections, additions
or invalidations to text in RFC 3095, this is clearly summarized. The or invalidations to text in RFC 3095, this is clearly summarized. The
text from RFC 3095 that is being addressed is given and labeled text from RFC 3095 that is being addressed is given and labeled
"INCOMPLETE", "INCORRECT" or "INCORRECT AND INVALIDATED", followed by "INCOMPLETE", "INCORRECT" or "INCORRECT AND INVALIDATED", followed by
the correct text labeled "CORRECTED", where applicable. When a formal the correct text labeled "CORRECTED", where applicable. When a formal
addition is provided, it is given with the label "FORMAL ADDITION". addition is provided, it is given with the label "FORMAL ADDITION".
In this document, a reference to a section or a chapter that is made In this document, a reference to a section in RFC 3095 [1] is written
without an explicit mention of a specific document refers to a as a prefixed section reference, RFC3095-<section number>.
section or a chapter in RFC 3095 [1], unless stated otherwise.
2. CRC calculation and coverage 2. CRC calculation and coverage
2.1. CRC calculation 2.1. CRC calculation
Section 5.9 defines polynomials for 3, 7 and 8-bit CRCs, but it does Section RFC3095-5.9 defines polynomials for 3, 7 and 8-bit CRCs, but
not specify what algorithm is used. The 3, 7 and 8-bit CRCs are it does not specify what algorithm is used. The 3, 7 and 8-bit CRCs
calculated using the CRC algorithm defined in [3]. are calculated using the CRC algorithm defined in [3].
A PERL implementation of the algorithm can be found in Appendix A of A Perl implementation of the algorithm can be found in Appendix A of
this document. this document.
2.2. Padding octet and CRC calculations 2.2. Padding octet and CRC calculations
Section 5.9.1 is incomplete, as it does not mention how to handle the Section RFC3095-5.9.1 is incomplete, as it does not mention how to
padding octet in CRC calculations for IR and IR-DYN packets. Padding handle the padding octet in CRC calculations for IR and IR-DYN
isn't meant to be a meaningful part of a packet and is not included packets. Padding isn't meant to be a meaningful part of a packet and
in the CRC calculation. As a result, the CRC does not cover the Add- is not included in the CRC calculation. As a result, the CRC does not
CID octet for CID 0, either. cover the Add-CID octet for CID 0, either.
INCOMPLETE RFC 3095 TEXT (section 5.9.1): INCOMPLETE RFC 3095 TEXT (section RFC3095-5.9.1):
"The CRC in the IR and IR-DYN packet is calculated over the entire "The CRC in the IR and IR-DYN packet is calculated over the entire
IR or IR-DYN packet, excluding Payload and including CID or any IR or IR-DYN packet, excluding Payload and including CID or any
Add-CID octet." Add-CID octet."
CORRECTED TEXT: CORRECTED TEXT:
"The CRC in the IR and IR-DYN packet is calculated over the entire "The CRC in the IR and IR-DYN packet is calculated over the entire
IR or IR-DYN packet, excluding Payload, Padding and including CID IR or IR-DYN packet, excluding Payload, Padding and including CID
or any Add-CID octet, except for the add-CID octet for CID 0." or any Add-CID octet, except for the add-CID octet for CID 0."
2.3. CRC coverage in CRC feedback options 2.3. CRC coverage in CRC feedback options
Section 5.7.6.3 is incomplete, as it does not mention how the "size" Section RFC3095-5.7.6.3 is incomplete, as it does not mention how the
field is handled when calculating the 8-bit CRC used in the CRC "size" field is handled when calculating the 8-bit CRC used in the
feedback option. Since the "size" field can be considered an CRC feedback option. Since the "size" field can be considered an
extension of the "code" field, it must be treated as the "code" extension of the "code" field, it must be treated in the same way.
field.
INCOMPLETE RFC 3095 TEXT (section 5.7.6.3): INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7.6.3):
"The CRC option contains an 8-bit CRC computed over the entire "The CRC option contains an 8-bit CRC computed over the entire
feedback payload, without the packet type and code octet, but feedback payload, without the packet type and code octet, but
including any CID fields, using the polynomial of section 5.9.1." including any CID fields, using the polynomial of section 5.9.1."
CORRECTED TEXT: CORRECTED TEXT:
"The CRC option contains an 8-bit CRC computed over the entire "The CRC option contains an 8-bit CRC computed over the entire
feedback payload including any CID fields but excluding the feedback payload including any CID fields but excluding the
packet type, the 'Size' field and the 'Code' octet, using the packet type, the 'Size' field and the 'Code' octet, using the
polynomial of section 5.9.1." polynomial of section 5.9.1."
2.4. CRC coverage of the ESP NULL header 2.4. CRC coverage of the ESP NULL header
Section 5.8.7 gives the CRC coverage of the ESP NULL header as Section RFC3095-5.8.7 gives the CRC coverage of the ESP NULL [13]
"Entire ESP header". This must be interpreted as including only the header as "Entire ESP header". This must be interpreted as including
initial part of the header (i.e. SPI and Sequence number), and not only the initial part of the header (i.e. SPI and Sequence number),
the trailer part at the end of the payload. Therefore, the ESP NULL and not the trailer part at the end of the payload. Therefore, the
header has the same CRC coverage as the ESP header used in the ESP ESP NULL header has the same CRC coverage as the ESP header used in
profile (section 5.7.7.7). the ESP profile (section RFC3095-5.7.7.7).
3. Mode transition 3. Mode transition
3.1. Feedback during mode transition to U- and O-mode 3.1. Feedback during mode transition to U- and O-mode
Section 5.6.1 states that during mode transitions, while the D_TRANS Section RFC3095-5.6.1 states that during mode transitions, while the
parameter is I, the decompressor send feedback for each received D_TRANS parameter is I, the decompressor send feedback for each
packet. This restrictive behavior prevents a decompressor from using received packet. This restrictive behavior prevents a decompressor
a sparse feedback algorithm during mode transitions. from using a sparse feedback algorithm during mode transitions.
To reduce transmission overhead and computational complexity To reduce transmission overhead and computational complexity
(including CRC calculation) associated with feedback packets sent for (including CRC calculation) associated with feedback packets sent for
each decompressed packet during mode transition, a decompressor MAY each decompressed packet during mode transition, a decompressor MAY
be implemented with slightly modified mode transition procedures be implemented with slightly modified mode transition procedures
compared to those defined in [1], as described in this section. compared to those defined in [1], as described in this section.
These enhanced procedures should be considered only as a possible These enhanced procedures should be considered only as a possible
improvement to a decompressor implementation, since interoperability improvement to a decompressor implementation, since interoperability
is not affected in any way. A decompressor implemented according to is not affected in any way. A decompressor implemented according to
skipping to change at page 6, line 12 skipping to change at page 6, line 10
decompressed packet, does however introduce some considerations in decompressed packet, does however introduce some considerations in
case feedback messages would be lost. Specifically, there is a risk case feedback messages would be lost. Specifically, there is a risk
for a deadlock situation when a transition from R-mode is performed for a deadlock situation when a transition from R-mode is performed
in case no feedback message successfully reaches the compressor and in case no feedback message successfully reaches the compressor and
the transition is not complete. For transition between U-mode and O- the transition is not complete. For transition between U-mode and O-
mode, there is also a small risk for reduced compression efficiency. mode, there is also a small risk for reduced compression efficiency.
To avoid this, the decompressor MUST continue to send feedback at To avoid this, the decompressor MUST continue to send feedback at
least periodically, also when in Pending transition state. This is least periodically, also when in Pending transition state. This is
equivalent to enhancing the definition of the D_TRANS parameter in equivalent to enhancing the definition of the D_TRANS parameter in
section 5.6.1, to include the definition of a Pending state: section RFC3095-5.6.1, to include the definition of a Pending state:
- D_TRANS: - D_TRANS:
Possible values for the D_TRANS parameter are (I)NITIATED, Possible values for the D_TRANS parameter are (I)NITIATED,
(P)ENDING and (D)ONE. D_TRANS MUST be initialized to D, and a mode (P)ENDING and (D)ONE. D_TRANS MUST be initialized to D, and a mode
transition can be initiated only when D_TRANS is D. While D_TRANS 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 is I, the decompressor sends a NACK or ACK carrying a CRC option
for each packet received. When D_TRANS is set to P, the for each packet received. When D_TRANS is set to P, the
decompressor do not have to send a NACK or ACK for each packet decompressor do not have to send a NACK or ACK for each packet
received, but it MUST continue to send feedback with some received, but it MUST continue to send feedback with some
periodicity, and all feedback packets sent MUST include the CRC periodicity, and all feedback packets sent MUST include the CRC
option. This ensures that all mode transitions will be completed option. This ensures that all mode transitions will be completed
also in case of feedback losses. also in case of feedback losses.
These modifications affect transitions to Optimistic and These modifications affect transitions to Optimistic and
Unidirectional modes of operation, i.e. the transitions described in Unidirectional modes of operation, i.e. the transitions described in
sections 5.6.5 and 5.6.6, and make those transition diagrams more sections RFC3095-5.6.5 and RFC3095-5.6.6, and make those transition
consistent with the diagram describing the transition to R-mode. diagrams more consistent with the diagram describing the transition
to R-mode.
3.1.2. Transition from Reliable to Optimistic mode 3.1.2. Transition from Reliable to Optimistic mode
The enhanced procedure for transition from Reliable to Optimistic The enhanced procedure for transition from Reliable to Optimistic
mode is shown below: mode is shown below:
Compressor Decompressor Compressor Decompressor
---------------------------------------------- ----------------------------------------------
| | | |
| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I | ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
skipping to change at page 7, line 32 skipping to change at page 7, line 32
| +-<-<-<-<-<-<-<-+ | | +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ | C_TRANS = D |-<-<-<-+ |
| | | |
|->->->-+ UO-0, UO-1* | |->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ | | +->->->->->->->-+ |
| +->->->-| D_TRANS = D | +->->->-| D_TRANS = D
| | D_MODE= U | | D_MODE= U
3.2. Feedback during mode transition 3.2. Feedback during mode transition
Section 5.6.1 states that feedback is always used during mode Section RFC3095-5.6.1 states that feedback is always used during mode
transitions. However, the text then continues by making concrete transitions. However, the text then continues by making concrete
applications of the rule in an inconsistent way, making it unclear applications of the rule in an inconsistent way, making it unclear
when CRC's are used. Further, the text does not define how the when CRCs are used. Further, the text does not define how the
compressor should act during mode transitions based on feedback not compressor should act during mode transitions based on feedback not
protected by CRCs, i.e. whether to carry out mode transition actions protected by CRCs, i.e. whether to carry out mode transition actions
or not. The proper behavior from the compressor is to perform any or not. The proper behavior from the compressor is to perform any
action related to mode transitions only when the feedback is action related to mode transitions only when the feedback is
protected by the CRC option. protected by the CRC option.
INCOMPLETE RFC 3095 TEXT (section 5.6.1): INCOMPLETE RFC 3095 TEXT (section RFC3095-5.6.1):
"As a safeguard against residual errors, all feedback sent during "As a safeguard against residual errors, all feedback sent during
a mode transition MUST be protected by a CRC, i.e., the CRC a mode transition MUST be protected by a CRC, i.e., the CRC
option MUST be used." option MUST be used."
CORRECTED TEXT: CORRECTED TEXT:
"As a safeguard against residual errors, all feedback sent by the "As a safeguard against residual errors, all feedback sent by the
decompressor during a mode transition MUST be protected by a CRC, decompressor during a mode transition MUST be protected by a CRC,
i.e., the CRC option MUST be used. The compressor MUST ignore i.e., the CRC option MUST be used. The compressor MUST ignore
feedback information related to mode transition if the feedback feedback information related to mode transition if the feedback
is not protected by the CRC option." is not protected by the CRC option."
One more related issue that requires clarifications comes from the One more related issue that requires clarifications comes from the
following text at the end of section 5.6.1: following text at the end of section RFC3095-5.6.1:
"While D_TRANS is I, the decompressor sends a NACK or ACK carrying "While D_TRANS is I, the decompressor sends a NACK or ACK carrying
a CRC option for each received packet." a CRC option for each received packet."
However, Section 5.5.2.2 already stated that for R-mode, feedback is However, Section RFC3095-5.5.2.2 already stated that for R-mode,
never sent for packets that do not update the context, i.e. for feedback is never sent for packets that do not update the context,
packets that do not carry a CRC such as R-0 and R-1* packets. i.e. for packets that do not carry a CRC such as R-0 and R-1*.
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
The purpose of a mode transition is to ensure that the compressor and The purpose of a mode transition is to ensure that the compressor and
the decompressor coherently move from one mode of operation to the decompressor coherently move from one mode of operation to
another using a three-way handshake. At one point during the mode another using a three-way handshake. At one point during the mode
transition, the decompressor acknowledges the reception of one (or transition, the decompressor acknowledges the reception of one (or
more) IR, IR-DYN or UOR-2 packet(s) that have mode bits set to the more) IR, IR-DYN or UOR-2 packet(s) that have mode bits set to the
new mode. Packets of type 0 or 1 that are received up to this point new mode. Packets of type 0 or 1 that are received up to this point
are decompressed using the old mode, while afterwards they are are decompressed using the old mode, while afterwards they are
decompressed using the new mode. If the enhanced transition decompressed using the new mode. If the enhanced transition
procedures described in section 3.1 of this document are used, the procedures described in section 3.1 are used, the setting of the
setting of the D_TRANS parameter to P represents this breakpoint. The D_TRANS parameter to P represents this breakpoint. The successful
successful decompression of a packet of type 0 or type 1 completes decompression of a packet of type 0 or type 1 completes the mode
the mode transition. transition.
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. When no TS bits are both when sent scaled and when sent unscaled. When no TS bits are
transmitted in a compressed packet, TS is always scaled. If a transmitted in a compressed packet, TS is always scaled. If a
compressed packet carries an extension 3 and field(Tsc)=0, the compressed packet carries an extension 3 and field(Tsc)=0, the
compressed packet must thus always carry unscaled TS bits. For TS compressed packet must thus always carry unscaled TS bits. For TS
values sent in Extension 3, W-LSB encoded values are sent using the values sent in Extension 3, W-LSB encoded values are sent using the
self-describing variable-length format (section 4.5.6), and this self-describing variable-length format (section RFC3095-4.5.6), and
applies to both scaled and unscaled values. 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 RFC3095-4.5.5 (see section 8.2). However, for TS it is only
is only defined how to decompress based on actual TS bits in the defined how to decompress based on actual TS bits in the compressed
compressed header, either scaled or unscaled, but not how to infer header, either scaled or unscaled, but not how to infer the TS from
the TS from the SN. This section specifies how the scaled TS is the SN. This section specifies how the scaled TS is decompressed when
decompressed when no TS bits are transmitted in the compressed no TS bits are received in the compressed header.
header.
When no TS bits are transmitted in the compressed header, the scaled When no TS bits are received in the compressed header, the scaled TS
TS value is reconstructed assuming a linear extrapolation from the value is reconstructed assuming a linear extrapolation from the SN,
SN, i.e. delta_TS = delta_SN * default-slope, where delta_SN and i.e. delta_TS = delta_SN * default-slope, where delta_SN and delta_TS
delta_TS are both signed integers. Section 5.7 defines the potential are both signed integers. Section RFC3095-5.7 defines the potential
values for default-slope. values for default-slope.
INCOMPLETE RFC 3095 TEXT (section 5.7): INCOMPLETE RFC 3095 TEXT (section RFC3095-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 scaled "When a compressed header with no TS bits is received, the scaled
skipping to change at page 9, line 46 skipping to change at page 9, line 44
the SN, i.e. delta_TS = delta_SN * default-slope(TS). the SN, i.e. delta_TS = delta_SN * default-slope(TS).
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). If a packet with no TS bits default-slope(TS) = value(TS_STRIDE). If a packet with no TS bits
is received with Tsc=0, the decompressor MUST discard the is received with Tsc=0, the decompressor MUST discard the
packet." packet."
INCORRECT AND INVALIDATED RFC 3095 TEXT (section 5.5.1.2): INCORRECT AND INVALIDATED RFC 3095 TEXT (section RFC3095-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 RFC3095-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 RFC3095-4.5.4 defines the interpretation interval, p, for
compression of the RTP timestamp. However, Section 5.7 defines a timer-based compression of the RTP timestamp. However, Section
different interpretation interval, which is defined as the RFC3095-5.7 defines a different interpretation interval, which is
interpretation interval to use for all TS values. It is thus unclear defined as the interpretation interval to use for all TS values. It
which p-value to use, at least for timer-based compression. is thus unclear which p-value to use, at least for timer-based
compression.
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 RFC3095-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 RFC3095-5.7)
4.4. Scaled RTP timestamp encoding 4.4. Scaled RTP timestamp encoding
This section redefines the algorithm for scaled RTP timestamp This section redefines the algorithm for scaled RTP timestamp
encoding, defined as a 5-step procedure in section 4.5.3. Two formal encoding, defined as a 5-step procedure in section RFC3095-4.5.3. Two
errors have been corrected, as described in subsections 4.4.1 and formal errors have been corrected, as described in subsections 4.4.1
4.4.2 below, and the whole algorithm has been reworked to be more 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 concise and use well-defined terminology. The resulting text can be
found in 4.4.3 below. found in 4.4.3 below.
4.4.1. TS_STRIDE for scaled timestamp encoding 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 as the explicitly communicated to the decompressor, and it is used as the
scaling factor for scaled TS encoding. scaling factor for scaled TS encoding.
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 RFC3095-4.5.3, defines the mathematical meaning
TS_STRIDE: of 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
definition or by the core equality above. If "/" were a generally definition or by the core equality above. If "/" were a generally
unambiguously defined operation meaning "the integral part of the unambiguously defined operation meaning "the integral part of the
result from dividing X by Y", the absence of TS_OFFSET could be result from dividing X by Y", the absence of TS_OFFSET could be
explained, but the formula would still lack a proper output for explained, but the formula would still lack a proper output for
TS_STRIDE equal to 0. The formula of "2. Compression" is thus TS_STRIDE equal to 0. The formula of "2. Compression" is thus
invalid. invalid.
4.4.2. 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 RFC3095-4.5.3 states in point 4 and 5 that the compressor is
required to initialize TS_OFFSET at wraparound, but that it is not 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 4.4.3. Algorithm for scaled timestamp encoding
INCORRECT RFC 3095 TEXT (section 4.5.3): INCORRECT RFC 3095 TEXT (section RFC3095-4.5.3):
"1. Initialization: The compressor sends to the decompressor the "1. Initialization: The compressor sends to the decompressor the
value of TS_STRIDE and the absolute value of one or several TS value of TS_STRIDE and the absolute value of one or several TS
fields. The latter are used by the decompressor to initialize fields. The latter are used by the decompressor to initialize
TS_OFFSET to (absolute value) modulo TS_STRIDE. Note that TS_OFFSET to (absolute value) modulo TS_STRIDE. Note that
TS_OFFSET is the same regardless of which absolute value is TS_OFFSET is the same regardless of which absolute value is
used, as long as the unscaled TS value does not wrap around; used, as long as the unscaled TS value does not wrap around;
see 4) below. see 4) below.
2. Compression: After initialization, the compressor no longer 2. Compression: After initialization, the compressor no longer
skipping to change at page 12, line 29 skipping to change at page 12, line 29
3. Decompression: When receiving a (compressed) TS_SCALED, the 3. Decompression: When receiving a (compressed) TS_SCALED, the
field is first decompressed, and the unscaled RTP TS is then field is first decompressed, and the unscaled RTP TS is then
calculated as TS = TS_SCALED * TS_STRIDE + TS_OFFSET. calculated as TS = TS_SCALED * TS_STRIDE + TS_OFFSET.
4. Offset at wraparound: If the value of TS_STRIDE is not equal 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 RFC3095-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.5. 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
skipping to change at page 12, line 52 skipping to change at page 12, line 52
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.6. 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 RFC3095-5.7.5 incorrectly states that value(TS_STRIDE) is
scaled TS, which is incorrect. used for 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 compressed header SHOULD carry unscaled TS bits, i.e. being set, the compressed header SHOULD carry unscaled TS bits, i.e.
the Tsc flag SHOULD NOT be set when Tss is set since an unscaled TS the Tsc flag SHOULD NOT be set when Tss is set since an unscaled TS
is needed together with TS_STRIDE to recalculate the TS_OFFSET. If is needed together with TS_STRIDE to recalculate the TS_OFFSET. If
TS_STRIDE is included in a compressed header with scaled TS, the TS_STRIDE is included in a compressed header with 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 RFC3095-5.7.5):
"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;
skipping to change at page 13, line 39 skipping to change at page 13, line 39
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.7. 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 RFC3095-4.5.4, may be used to reduce the number of transmitted
(bytes) needed when the timestamp can not be inferred from the SN. timestamp bits (bytes) needed when the timestamp can not be inferred
Timer-based compression is only used for decompression of compressed from the SN. Timer-based compression is only used for decompression
headers that contains a TS field, otherwise when no timestamp bits of compressed headers that contains a TS field, otherwise when no
are present the timestamp is linearly inferred from the SN (see timestamp bits are present the timestamp is linearly inferred from
section 4.2 of this document). the SN (see 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
TIME_STRIDE control field, which can be set either by an IR, an IR- TIME_STRIDE control field, which can be set either by an IR, an IR-
DYN, or by a compressed packet with extension 3. Before timer-based DYN, or by a compressed packet with extension 3. Before timer-based
compression can be used, the decompressor has to inform the compression can be used, the decompressor has to inform the
compressor (on a per-channel basis) about its clock resolution by compressor (on a per-channel basis) about its clock resolution by
sending a CLOCK feedback option for any CID on the channel. The sending a CLOCK feedback option for any CID on the channel. The
compressor can then initiate timer-based compression by sending (on a compressor can then initiate timer-based compression by sending (on a
per-context basis) a non-zero TIME_STRIDE to the decompressor. First per-context basis) a non-zero TIME_STRIDE to the decompressor. First
when the compressor is confident that the decompressor has received when the compressor is confident that the decompressor has received
the TIME_STRIDE value, it can switch to timer-based compression. the TIME_STRIDE value, it can switch to timer-based compression.
5. List compression 5. List compression
5.1. CSRC list items in RTP dynamic chain 5.1. CSRC list items in RTP dynamic chain
Section 5.7.7.6 defines the static and dynamic parts of the RTP Section RFC3095-5.7.7.6 defines the static and dynamic parts of the
header. This section indicates a 'Generic CSRC list' field in the RTP header. This section indicates a 'Generic CSRC list' field in the
dynamic chain, which has a variable length (see section 5.8.6). This dynamic chain, which has a variable length (see section RFC3095-
field is always at least one octet in size, even if the list is empty 5.8.6). This field is always at least one octet in size, even if the
(as opposed to the CSRC list in the uncompressed RTP header, which is list is empty (as opposed to the CSRC list in the uncompressed RTP
not present when the RTP CC field is set to 0). header, which is not present when the RTP CC field is set to 0).
5.2. Multiple occurrences of the CC field 5.2. Multiple occurrences of the CC field
The static and the dynamic parts of the RTP header are defined in The static and the dynamic parts of the RTP header are defined in
Section 5.7.7.6. In the dynamic part, a CC field indicates the number section RFC3095-5.7.7.6. In the dynamic part, a CC field indicates
of CSRC items present in the 'Generic CSRC list'. Another CC field the number of CSRC items present in the 'Generic CSRC list'. Another
also appears within the 'Generic CSRC list' (section 5.8.6.1), CC field also appears within the 'Generic CSRC list' (section
because Encoding Type 0 is always used in the dynamic chain. Both CC RFC3095-5.8.6.1), because Encoding Type 0 is always used in the
fields have the same meaning: the value of the CC field determines dynamic chain. Both CC fields have the same meaning: the value of the
the number of XI items in the CSRC list for Encoding Type 0, and it CC field determines the number of XI items in the CSRC list for
is not used otherwise. Therefore, the following applies: Encoding Type 0, and it is not used otherwise. Therefore, the
following applies:
FORMAL ADDITION TO RFC 3095: FORMAL ADDITION TO RFC 3095:
"The first octet in the dynamic part of the RTP header contains a "The first octet in the dynamic part of the RTP header contains a
CC field, as defined in section 5.7.7.6. A second occurrence CC field, as defined in section 5.7.7.6. A second occurrence
appears in the 'Generic CSRC list', which is also in the dynamic appears in the 'Generic CSRC list', which is also in the dynamic
part of the RTP header, where Encoding Type 0 is used according part of the RTP header, where Encoding Type 0 is used according
to the format defined in 5.8.6.1. to the format defined in RFC3095-5.8.6.1.
The compressor MUST set both occurrences of the CC field to the The compressor MUST set both occurrences of the CC field to the
same value. same value.
The decompressor MUST use the value of the CC field from the The decompressor MUST use the value of the CC field from the
Encoding Type 0 within the Generic CRSC list, and it MUST thus Encoding Type 0 within the Generic CRSC list, and it MUST thus
ignore the first occurrence of the CC field." ignore the first occurrence of the CC field."
5.3. Bit masks in list compression 5.3. Bit masks in list compression
The insertion and/or removal schemes, described in sections 5.8.6.2 - The insertion and/or removal schemes, described in sections RFC3095-
5.8.6.4, use bit masks to indicates insertion or removal positions 5.8.6.2 - 5.8.6.4, use bit masks to indicates insertion or removal
within the reference list. The size of the bit mask can be 7-bit or positions within the reference list. The size of the bit mask can be
15-bit. 7-bit or 15-bit.
The compressor MAY use a 7-bit mask, even if the reference list has The compressor MAY use a 7-bit mask, even if the reference list has
more than 7 items, provided that changes to the list are only applied more than 7 items, provided that changes to the list are only applied
to items within the first 7 items of the reference list, leaving to items within the first 7 items of the reference list, leaving
items with an index not covered by the 7-bit mask unchanged. items with an index not covered by the 7-bit mask unchanged.
The decompressor MUST NOT modify items with an index not covered by The decompressor MUST NOT modify items with an index not covered by
the 7-bit mask, when a 7-bit mask is received for a reference list the 7-bit mask, when a 7-bit mask is received for a reference list
that contains more than 7 items. that contains more than 7 items.
5.4. Headers compressed with list compression 5.4. Headers compressed with list compression
In section 5.8, it is stated that headers which can be part of In section RFC3095-5.8, it is stated that headers which can be part
extension header chains "include" AH, null ESP, minimal encapsulation of extension header chains "include" AH [14], ESP NULL [13], minimal
(MINE), GRE, and IPv6 extensions. This list of headers which can be encapsulation (MINE) [15], GRE [16][17], and IPv6 [9] extensions.
compressed is correct, but the word "include" should not be there, This list of headers which can be compressed is correct, but the word
since only the header types listed can actually be handled. It should "include" should not be there, since only the header types listed can
further be noted that for the Minimal Encapsulation (MINE) header, actually be handled. It should further be noted that for the Minimal
there is no explicit discussion of how to compress it, as the header Encapsulation (MINE) header, there is no explicit discussion of how
is either sent uncompressed or fully compressed away. to compress it, as the header is either sent uncompressed or fully
compressed away.
5.5. ESP NULL header list compression 5.5. ESP NULL header list compression
Due to the offset of the fields in the trailer part of the ESP Due to the offset of the fields in the trailer part of the ESP
header, a compressor MUST NOT compress packets containing more than header, a compressor MUST NOT compress packets containing more than
one NULL ESP header, unless the second-outermost header is treated as one NULL ESP [13] header, unless the second-outermost header is
a regular ESP header and the packets are compressed using profile treated as a regular ESP [12] header and the packets are compressed
0x0003. using profile 0x0003.
5.6. Translation tables and indexes for IP extension headers 5.6. Translation tables and indexes for IP extension headers
Section 5.8.4 describes how list indexes are associated to list items Section RFC3095-5.8.4 describes how list indexes are associated to
and how table lists are built for IP extension headers. The text list items and how table lists are built for IP extension headers.
incorrectly states that one index per type is used, since the same The text incorrectly states that one index per type is used, since
type can appear several times with different content in one single the same type can appear several times with different content in one
chain. single chain.
In IP extension header list compression, an index is associated with In IP extension header list compression, an index is associated with
each individual extension header of an extension header chain. When each individual extension header of an extension header chain. When
there are multiple non-identical occurrences of the same extension there are multiple non-identical occurrences of the same extension
type (Protocol Number) within a header chain, each MUST be given its type (Protocol Number) within a header chain, each MUST be given its
own index. own index.
In the case where there are multiple identical occurrences of the In the case where there are multiple identical occurrences of the
same extension type, the compressor can associate them to the same same extension type, the compressor can associate them to the same
index. When the value of an item whose index occurs more than once in index. When the value of an item whose index occurs more than once in
skipping to change at page 16, line 35 skipping to change at page 16, line 35
is not a desirable requirement. Using list encoding type 1, type 2, is not a desirable requirement. Using list encoding type 1, type 2,
and type 3 is therefore only allowed for non-empty reference lists. and type 3 is therefore only allowed for non-empty reference lists.
FORMAL ADDITION TO RFC 3095: FORMAL ADDITION TO RFC 3095:
"Regardless of the operating mode, for list encoding of type 1, "Regardless of the operating mode, for list encoding of type 1,
type 2, and type 3 lists, ref_id MUST refer to a non-empty list." type 2, and type 3 lists, ref_id MUST refer to a non-empty list."
5.8. Compression of AH and GRE sequence numbers 5.8. Compression of AH and GRE sequence numbers
Section 5.8.4.2 and section 5.8.4.4 describes how to compress the Section RFC3095-5.8.4.2 and section RFC3095-5.8.4.4 describes how to
Authentication Header (AH) and the Generic Routing Encapsulation compress the Authentication Header (AH) [14] and the Generic Routing
(GRE) header. Both these sections present a possibility to omit the Encapsulation (GRE) [16][17] header. Both these sections present a
AH/GRE sequence number in the compressed header, under certain possibility to omit the AH/GRE sequence number in the compressed
circumstances. However, the specific conditions for omitting the header, under certain circumstances. However, the specific conditions
AH/GRE sequence number, as well as the concrete compression and for omitting the AH/GRE sequence number, as well as the concrete
decompression procedures to apply, are not clearly defined to compression and decompression procedures to apply, are not clearly
guarantee robustness and facilitate interoperable implementation. defined to guarantee robustness and facilitate interoperable
implementation.
Proper rules are provided for the ESP case, i.e.: Proper rules are provided for the ESP case, i.e.:
"Sequence Number: Not sent when the offset from the sequence "Sequence Number: Not sent when the offset from the sequence
number of the compressed header is constant, when the compressor number of the compressed header is constant, when the compressor
has confidence that the decompressor has established the correct has confidence that the decompressor has established the correct
offset. When the offset is not constant, the sequence number may offset. When the offset is not constant, the sequence number may
be compressed by sending LSBs" be compressed by sending LSBs"
The same logic applies to the AH/GRE sequence numbers. The same logic applies to the AH/GRE sequence numbers.
INCORRECT RFC 3095 TEXT (section 5.8.4.2): INCORRECT RFC 3095 TEXT (section RFC3095-5.8.4.2):
"If the sequence number in the AH linearly increases as the RTP "If the sequence number in the AH linearly increases as the RTP
Sequence Number increases, and the compressor is confident that Sequence Number increases, and the compressor is confident that
the decompressor has obtained the pattern, the sequence number in the decompressor has obtained the pattern, the sequence number in
AH need not be sent. The decompressor applies linear AH need not be sent. The decompressor applies linear
extrapolation to reconstruct the sequence number in the AH." extrapolation to reconstruct the sequence number in the AH."
CORRECTED TEXT: CORRECTED TEXT:
"The AH sequence number can be omitted from the compressed header "The AH sequence number can be omitted from the compressed header
when the offset from the sequence number (SN) of the compressed when the offset from the sequence number (SN) of the compressed
header is constant, when the compressor has confidence that header is constant, when the compressor has confidence that
the decompressor has established the correct offset." the decompressor has established the correct offset."
INCORRECT RFC 3095 TEXT (section 5.8.4.4): INCORRECT RFC 3095 TEXT (section RFC3095-5.8.4.4):
"If the sequence number in the GRE header linearly increases as "If the sequence number in the GRE header linearly increases as
the RTP Sequence Number increases and the compressor is confident the RTP Sequence Number increases and the compressor is confident
that the decompressor has received the pattern, the sequence that the decompressor has received the pattern, the sequence
number in GRE need not be sent. The decompressor applies linear number in GRE need not be sent. The decompressor applies linear
extrapolation to reconstruct the sequence number in the GRE extrapolation to reconstruct the sequence number in the GRE
header." header."
CORRECTED TEXT: CORRECTED TEXT:
skipping to change at page 18, line 7 skipping to change at page 18, line 7
UO-1-ID packet (see section 6.2 of this document). In UO-mode, all UO-1-ID packet (see section 6.2 of this document). In UO-mode, all
packets are updating packets, while in R-mode all packets with a CRC packets are updating packets, while in R-mode all packets with a CRC
are updating packets. are updating packets.
For example, a UO-0 packet contains the compressed RTP sequence For example, a UO-0 packet contains the compressed RTP sequence
number (SN). Such a packet also implicitly updates RTP timestamp, number (SN). Such a packet also implicitly updates RTP timestamp,
IPv4 ID, and sequence numbers of IP extension headers. IPv4 ID, and sequence numbers of IP extension headers.
6.2. Updating properties of UO-1* 6.2. Updating properties of UO-1*
Section 5.7.3 states that the values provided in extensions carried Section RFC3095-5.7.3 states that the values provided in extensions
by a UO-1-ID packet do not update the context, except for SN, TS, or carried by a UO-1-ID packet do not update the context, except for SN,
IP-ID fields. However, section 5.8.1 correctly states that the TS, or IP-ID fields. However, section RFC3095-5.8.1 correctly states
translation table in the context is updated whenever an (Index, item) that the translation table in the context is updated whenever an
pair is received, something that is contradicted by the statement in (Index, item) pair is received, something that is contradicted by the
5.7.3 because the UO-1-ID packet can carry extension 3 with (Index, statement in RFC3095-5.7.3 because the UO-1-ID packet can carry
item) pair items within the 'Compressed CSRC list' field. In addition extension 3 with (Index, item) pair items within the 'Compressed CSRC
to this contradiction, the text does not mention what to do with the list' field. In addition to this contradiction, the text does not
other sequence numbers inferred from the SN, which are also to be mention what to do with the other sequence numbers inferred from the
implicitly updated. The updating properties of UO-1* as stated by SN, which are also to be implicitly updated. The updating properties
section 5.7.3 are thus incomplete. of UO-1* as stated by section RFC3095-5.7.3 are thus incomplete.
INCOMPLETE RFC 3095 TEXT (section 5.7.3): INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7.3):
"Values provided in extensions, except those in other SN, TS, "Values provided in extensions, except those in other SN, TS,
or IP-ID fields, do not update the context." or IP-ID fields, do not update the context."
CORRECTED TEXT: CORRECTED TEXT:
"UO-1-ID packets only updates TS, SN, IP-ID, and sequence "UO-1-ID packets only updates TS, SN, IP-ID, and sequence
numbers of IP extension headers. Other values numbers of IP extension headers. Other values
provided in extensions do not update the context. provided in extensions do not update the context.
The decompressor MUST update its translation table whenever an The decompressor MUST update its translation table whenever an
(Index, item) pair is received, as per Section 5.8.1, and this (Index, item) pair is received, as per Section RFC3095-5.8.1,
rule applies also to UO-1-ID packets." and this rule applies also to UO-1-ID packets."
6.3. Context updating properties for IR packets 6.3. Context updating properties for IR packets
IR packets do not clear the whole context, but update all fields IR packets do not clear the whole context, but update all fields
carried in the IR header. Similarly, an IR without a dynamic chain carried in the IR header. Similarly, an IR without a dynamic chain
simply updates the static part of the context, while the rest of the simply updates the static part of the context, while the rest of the
context is left unchanged. context is left unchanged.
A consequence of this is that fields that are not updated by the IR A consequence of this is that fields that are not updated by the IR
packet, e.g. the translation tables for list compression, MUST NOT be packet, e.g. the translation tables for list compression, MUST NOT be
invalidated by the decompressor when it assumes context damage. invalidated by the decompressor when it assumes context damage.
6.4. RTP padding field (R-P) in extension 3 6.4. RTP padding field (R-P) in extension 3
Section 5.7.5 defines the properties of RTP header flags and fields Section RFC3095-5.7.5 defines the properties of RTP header flags and
in extension 3. These get updated when the rtp flag of the extension fields in extension 3. These get updated when the rtp flag of the
3 is set, i.e. when rtp = 1, otherwise they are not updated. However, extension 3 is set, i.e. when rtp = 1, otherwise they are not
it is unclear how extension 3 updates the R-P bit in the context. updated. However, it is unclear how extension 3 updates the R-P bit
in the context.
INCOMPLETE RFC 3095 TEXT (section 5.7.5): INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7.5):
"R-P: RTP Padding bit, absolute value (presumed zero if absent)." "R-P: RTP Padding bit, absolute value (presumed zero if absent)."
CORRECTED TEXT: CORRECTED TEXT:
"R-P: RTP Padding bit. If R-PT = 1, R-P is the absolute value of "R-P: RTP Padding bit. If R-PT = 1, R-P is the absolute value of
the RTP padding bit and this value updates context(R-P). If the RTP padding bit and this value updates context(R-P). If
R-PT = 0, context(R-P) is updated to zero." R-PT = 0, context(R-P) is updated to zero."
6.5. RTP eXtension bit (X) in dynamic part 6.5. RTP eXtension bit (X) in dynamic part
Section 5.7.7.6 defines the properties of the RTP header flags and Section RFC3095-5.7.7.6 defines the properties of the RTP header
fields in the RTP part of the dynamic chain of IR and IR-DYN packets. flags and fields in the RTP part of the dynamic chain of IR and IR-
However, it is unclear how the X bit is updated in the context. DYN packets. However, it is unclear how the X bit is updated in the
context.
INCOMPLETE RFC 3095 TEXT (section 5.7.7.6): INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7.7.6):
"X: Copy of X bit from RTP header (presumed 0 if RX = 0)" "X: Copy of X bit from RTP header (presumed 0 if RX = 0)"
CORRECTED TEXT: CORRECTED TEXT:
"X: X bit from RTP header. If RX = 1, X is the X bit from the RTP "X: X bit from RTP header. If RX = 1, X is the X bit from the RTP
header and this value updates context(X). If RX = 0, header and this value updates context(X). If RX = 0,
context(X) is updated to zero." context(X) is updated to zero."
7. Context management and CID/context re-use 7. Context management and CID/context re-use
skipping to change at page 20, line 28 skipping to change at page 20, line 31
On a high level, CID/context re-use can be of two kinds, either re- On a high level, CID/context re-use can be of two kinds, either re-
use for a new context based on the same profile as the old context, use for a new context based on the same profile as the old context,
or for a new context based on a different profile. These cases, are or for a new context based on a different profile. These cases, are
discussed separately in the following two subsections. discussed separately in the following two subsections.
7.2.1. Re-using a CID/context with the same profile 7.2.1. Re-using a CID/context with the same profile
For multi-mode profiles, such as those defined in RFC 3095 [1], mode For multi-mode profiles, such as those defined in RFC 3095 [1], mode
transitions are performed using a decompressor-initiated handshake transitions are performed using a decompressor-initiated handshake
procedure, as defined in section 5.6. When a CID/context is re-used procedure, as defined in section RFC3095-5.6. When a CID/context is
for a new context based on the same profile as the old context, the re-used for a new context based on the same profile as the old
current mode of operation SHOULD be inherited from the old to the new context, the current mode of operation SHOULD be inherited from the
context. Specifically, the compressor SHOULD continue to operate old to the new context. Specifically, the compressor SHOULD continue
using the mode of operation of the old context also with the new to operate using the mode of operation of the old context also with
context. The reason for this is that there is no reliable way for the the new context. The reason for this is that there is no reliable way
compressor to inform the decompressor that a CID/context re-use is for the compressor to inform the decompressor that a CID/context re-
happening. The decompressor can thus not be expected to clear the use is happening. The decompressor can thus not be expected to clear
context memory for the CID (see section 6.3 of this document), and the context memory for the CID (see section 6.3), and there is no way
there is no way to trigger a safe mode switching (which requires the to trigger a safe mode switching (which requires the decompressor-
decompressor-initiated handshake procedure). initiated handshake procedure).
The rule of mode inheritance applies also when the The rule of mode inheritance applies also when the
CONTEXT_REINITIALIZATION signal (section 6.3.1) is used to reinitiate CONTEXT_REINITIALIZATION signal (section RFC3095-6.3.1) is used to
an entire context. reinitiate an entire context.
7.2.2. Re-using a CID/context with a different profile 7.2.2. Re-using a CID/context with a different profile
When a CID is re-used for a new context based on a different profile When a CID is re-used for a new context based on a different profile
than the old context, both the compressor and the decompressor MUST than the old context, both the compressor and the decompressor MUST
start operation with that context in the initial mode of the profile start operation with that context in the initial mode of the profile
(if it is a multi-mode profile). This applies both to IR-initiated (if it is a multi-mode profile). This applies both to IR-initiated
new contexts and profile downgrades with IR-DYN (e.g. the profile new contexts and profile downgrades with IR-DYN (e.g. the profile
0x0001 -> profile 0x0002 downgrade in [1], section 5.11.1). 0x0001 -> profile 0x0002 downgrade in section RFC3095-5.11.1).
Type 0 and type 1 packets have different formats in U/O- and R-mode, Type 0 and type 1 packets have different formats in U/O- and R-mode,
and these R-mode packets have no CRC. When initiating a new context and these R-mode packets have no CRC. When initiating a new context
on a re-used R-mode CID, there is a risk that the decompressor will on a re-used R-mode CID, there is a risk that the decompressor will
misinterpret compressed packets, if the initiating IR packets are misinterpret compressed packets, if the initiating IR packets are
lost. lost.
A CID for a context currently operating in R-mode SHOULD therefore A CID for a context currently operating in R-mode SHOULD therefore
not be re-used for a new context based on a different profile than not be re-used for a new context based on a different profile than
the old context. A compressor doing otherwise should minimize the the old context. A compressor doing otherwise should minimize the
risk for misinterpretation of R-0/R-1 by e.g. not using packets of risk for misinterpretation of R-0/R-1 by e.g. not using packets of
types beginning with 00 or 10 before it is highly confident that the types beginning with 00 or 10 before it is highly confident that the
new context has successfully been initiated at the decompressor. new context has successfully been initiated at the decompressor.
8. Other protocol clarifications 8. Other protocol clarifications
8.1. Meaning of NBO 8.1. Meaning of NBO
In IPv4 dynamic part (Section 5.7.7.4), if the 'NBO' bit is set, it In IPv4 dynamic part (section RFC3095-5.7.7.4), if the 'NBO' bit is
means that network byte order is used. set, it means that network byte order is used.
8.2. IP-ID 8.2. IP-ID
According to Section 5.7, IP-ID means the compressed value of the According to section RFC3095-5.7, IP-ID means the compressed value of
IPv4 header's 'Identification' field. Compressed packets contain this the IPv4 header's 'Identification' field. Compressed packets contain
compressed value (IP-ID), while IR packets with dynamic chain and IR- this compressed value (IP-ID), while IR packets with dynamic chain
DYN packets transmit the original, uncompressed Identification field and IR-DYN packets transmit the original, uncompressed Identification
value. The IP-ID field always represents the Identification value of field value. The IP-ID field always represents the Identification
the innermost IPv4 header whose corresponding RND flag is not 1. value of the innermost IPv4 header whose corresponding RND flag is
not 1.
If RND or RND2 is set to 1, the corresponding IP-ID(s) is(are) sent If RND or RND2 is set to 1, the corresponding IP-ID(s) is(are) sent
as 16-bit uncompressed Identification value(s) at the end of the as 16-bit uncompressed Identification value(s) at the end of the
compressed base header, according to the IP-ID description (see the compressed base header, according to the IP-ID description (see the
beginning of section 5.7). When there is no compressed IP-ID, i.e. beginning of section RFC3095-5.7). When there is no compressed IP-ID,
for IPv6 or when all IP Identification information is sent as-is (as i.e. for IPv6 or when all IP Identification information is sent as-is
indicated by RND/RND2 being set to 1), the decompressor ignores IP-ID (as indicated by RND/RND2 being set to 1), the decompressor ignores
bits sent within compressed base headers. IP-ID bits sent within compressed base headers.
When RND=RND2=0, IP-ID is compressed, i.e. expressed as an SN offset When RND=RND2=0, IP-ID is compressed, i.e. expressed as an SN offset
and byte-swapped if NBO=0. This is the case also when 16 bits of IP- and byte-swapped if NBO=0. This is the case also when 16 bits of IP-
ID is sent in extension 3. ID is sent in extension 3.
When RND=0 but no IP-ID bits are sent in the compressed header, the When RND=0 but no IP-ID bits are sent in the compressed header, the
SN offset for IP-ID stays unchanged, meaning that Offset_m equals SN offset for IP-ID stays unchanged, meaning that Offset_m equals
Offset_ref, as described in Section 4.5.5. This is further expressed Offset_ref, as described in Section 4.5.5. This is further expressed
in a slightly different way (with the same meaning) in Section 5.7, in a slightly different way (with the same meaning) in Section 5.7,
where it is said that "default-slope(IP-ID offset) = 0", meaning that where it is said that "default-slope(IP-ID offset) = 0", meaning that
skipping to change at page 22, line 7 skipping to change at page 22, line 14
8.3. Extension-3 in UOR-2* packets 8.3. Extension-3 in UOR-2* packets
Some flags of the IP header in the extension (e.g. NBO or RND) may Some flags of the IP header in the extension (e.g. NBO or RND) may
change the interpretation of fields in UOR-2* packets. In such cases, change the interpretation of fields in UOR-2* packets. In such cases,
when a flag changes in Extension-3, a decompressor MUST re-parse the when a flag changes in Extension-3, a decompressor MUST re-parse the
UOR-2* packet. UOR-2* packet.
8.4. Multiple occurrences of the M bit 8.4. Multiple occurrences of the M bit
The RTP header part of Extension 3, as defined by section 5.7.5, The RTP header part of Extension 3, as defined by section RFC3095-
includes a one-bit field for the RTP Marker bit. This field is also 5.7.5, includes a one-bit field for the RTP Marker bit. This field is
present in all compressed base header formats except for UO-1-ID, also present in all compressed base header formats except for UO-1-
meaning there may be multiple occurrences of the field within one ID, meaning there may be two occurrences of the field within one
single compressed header. In such cases, the two M fields must have single compressed header. In such cases, the two M fields must have
the same value. the same value.
FORMAL ADDITION TO RFC 3095: FORMAL ADDITION TO RFC 3095:
"When there are two occurrences of the M field in a compressed "When there are two occurrences of the M field in a compressed
header (both in the compressed base header and in the RTP part of header (both in the compressed base header and in the RTP part of
Extension 3), the compressor MUST set both these occurrences of Extension 3), the compressor MUST set both these occurrences of
the M field to the same value. the M field to the same value.
At the decompressor, if the two M field values of such a packet At the decompressor, if the two M field values of such a packet
are not identical, the packet MUST be discarded." are not identical, the packet MUST be discarded."
8.5. Multiple SN options in one feedback packet 8.5. Multiple SN options in one feedback packet
The length of the sequence number field in the original ESP header is The length of the sequence number field in the original ESP [12]
32 bits. The format of the SN feedback option (5.7.6.6) allows for 8 header is 32 bits. The format of the SN feedback option (section
additional SN bits to the 12 SN bits of the FEEDBACK-2 format RFC3095-5.7.6.6) allows for 8 additional SN bits to the 12 SN bits of
(5.7.6.1). One single SN feedback option is thus not enough for the the FEEDBACK-2 format (section RFC3095-5.7.6.1). One single SN
decompressor to send back all the 32 bits of the ESP sequence number feedback option is thus not enough for the decompressor to send back
in a feedback packet, unless it uses multiple SN options in one all the 32 bits of the ESP sequence number in a feedback packet,
feedback packet. Section 5.7.6.1 declares that a FEEDABCK-2 packet unless it uses multiple SN options in one feedback packet. Section
can contain variable number of feedback options and the options can RFC3095-5.7.6.1 declares that a FEEDABCK-2 packet can contain
appear in any order. variable number of feedback options and the options can appear in any
order.
When processing multiple SN options in one feedback packet, the SN When processing multiple SN options in one feedback packet, the SN
would be given by concatenating the fields. would be given by concatenating the fields.
8.6. Multiple CRC options in one feedback packet 8.6. Multiple CRC options in one feedback packet
Although it is not useful to have more than one single CRC option in Although it is not useful to have more than one single CRC option in
a feedback packet, having multiple CRC options is still allowed. If a feedback packet, having multiple CRC options is still allowed. If
multiple CRC options are included, all such CRC options MUST be multiple CRC options are included, all such CRC options MUST be
identical, as they will be calculated over the same header, the identical, as they will be calculated over the same header, the
skipping to change at page 23, line 6 skipping to change at page 23, line 15
8.7. Responding to lost feedback links 8.7. Responding to lost feedback links
Although this is neither desirable or expected, it may happen that a Although this is neither desirable or expected, it may happen that a
link used to carry feedback between two associated instances becomes link used to carry feedback between two associated instances becomes
unavailable. If the compressor can be notified of such event, the unavailable. If the compressor can be notified of such event, the
compressor SHOULD restart compression for each flow that is operating compressor SHOULD restart compression for each flow that is operating
in R-mode. When restarting compression, the compressor SHOULD use a in R-mode. When restarting compression, the compressor SHOULD use a
different CID for each flow being restarted; this is useful to avoid different CID for each flow being restarted; this is useful to avoid
that packet types for which both U/O-mode and R-mode share the same that packet types for which both U/O-mode and R-mode share the same
type identifier gets misinterpreted when restarting the flow in U- type identifier gets misinterpreted when restarting the flow in U-
mode (see also section 7.2 of this document). mode (see also section 7.2).
Generally, feedback links are not expected to disappear when once Generally, feedback links are not expected to disappear when once
present, but it should be noted that this might be the case for present, but it should be noted that this might be the case for
certain link technologies. certain link technologies.
8.8. UOR-2 in profile 0x0002 (UDP) and profile 0x0003 (ESP) 8.8. UOR-2 in profile 0x0002 (UDP) and profile 0x0003 (ESP)
One single new format is defined for UOR-2 in profile 0x0002 and One single new format is defined for UOR-2 in profile 0x0002 and
profile 0x0003, which replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) profile 0x0003, which replaces all three (UOR-2, UOR-2-ID, UOR-2-TS)
formats from profile 0x0001. The same UOR-2 format is thus used formats from profile 0x0001. The same UOR-2 format is thus used
independent of whether there are IP headers with a corresponding independent of whether there are IP headers with a corresponding
RND=1 or not. This also applies to the IP profile [4] and the IP/UDP- RND=1 or not. This also applies to the IP profile [4] and the IP/UDP-
Lite profile [5]. Lite profile [5].
8.9. Sequence number LSB's in IP extension headers 8.9. Sequence number LSB's in IP extension headers
In section 5.8.5, formats are defined for compression of IP extension In section RFC3095-5.8.5, formats are defined for compression of IP
header fields. These include compressed sequence number fields, and extension header fields. These include compressed sequence number
these fields contain "LSB of sequence number". These sequence numbers fields, and these fields contain "LSB of sequence number". These
are not "LSB-encoded" as e.g. the RTP sequence number, but are the sequence numbers are not "LSB-encoded" as e.g. the RTP sequence
LSB's of the uncompressed fields. number, but are the LSB's of the uncompressed fields.
8.10. Expecting UOR-2 ACKs in O-mode 8.10. Expecting UOR-2 ACKs in O-mode
Usage of UOR-2 ACKs in O-mode, as discussed in section 5.4.1.1.2, is Usage of UOR-2 ACKs in O-mode, as discussed in section RFC3095-
optional. A decompressor can also send ACKs for purposes other than 5.4.1.1.2, is optional. A decompressor can also send ACKs for
to acknowledge the UOR-2, without having to continue sending ACKs for purposes other than to acknowledge the UOR-2, without having to
all UOR-2. Similarly, a compressor implementation can ignore UOR-2 continue sending ACKs for all UOR-2. Similarly, a compressor
ACKs for the purpose of adapting the optimistic approach strategies. implementation can ignore UOR-2 ACKs for the purpose of adapting the
optimistic approach strategies.
It is thus RECOMMENDED to not use of the optional ACK mechanism in It is thus RECOMMENDED to not use of the optional ACK mechanism in
O-mode, neither in compressor nor in decompressor implementations. O-mode, neither in compressor nor in decompressor implementations.
Using an incorrect expectation on UOR-2 ACKs as a basis for Using an incorrect expectation on UOR-2 ACKs as a basis for
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
skipping to change at page 24, line 36 skipping to change at page 24, line 45
current profile. current profile.
When the compressor receives a static-NACK, it MUST include in When the compressor receives a static-NACK, it MUST include in
the IR header fields for both the TS_STRIDE and the TIME_STRIDE the IR header fields for both the TS_STRIDE and the TIME_STRIDE
whose value it has updated at least once since the establishment whose value it has updated at least once since the establishment
of that context, i.e. since the CID was first associated with its of that context, i.e. since the CID was first associated with its
current profile." current profile."
9. ROHC negotiation 9. ROHC negotiation
Section 4.1 states that the link layer must provide means to Section RFC3095-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 RFC3095-
these parameters is the PROFILES parameter, which is a set of non- 5.1.1. One of these parameters is the PROFILES parameter, which is a
negative integers where each integer indicates a profile supported by set of non-negative integers where each integer indicates a profile
the decompressor. supported by 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
of that profile (see chapter 8). In the ROHC headers sent over the of that profile (see chapter RFC3095-8). In the ROHC headers sent
link, the profile used is identified only with the 8 LSB bits, which over the link, the profile used is identified only with the 8 LSB
means that the compressor and decompressor must have agreed on which bits, which means that the compressor and decompressor must have
variant to use for each profile. agreed on which variant to use for each profile.
The negotiation protocol must thus be able to communicate to the The negotiation protocol must thus be able to communicate to the
compressor the set of profiles supported by the decompressor, and compressor the set of profiles supported by the decompressor, and
when multiple variants of the same profile are available, also when multiple variants of the same profile are available, also
provide means for the decompressor to know which variant will be used provide means for the decompressor to know which variant will be used
by the compressor. This basically means that the PROFILES set after by the compressor. This basically means that the PROFILES set after
negotiation MUST NOT include more than one variant of a profile. negotiation MUST NOT include more than one variant of a profile.
10. PROFILES suboption in ROHC-over-PPP 10. PROFILES suboption in ROHC-over-PPP
skipping to change at page 26, line 25 skipping to change at page 26, line 33
[6] S. Bradner, "Key words for use in RFCs to Indicate Requirement [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
15.2. Informative References 15.2. Informative References
[7] L-E. Jonsson, G. Pelletier & K. Sandlund, "RObust Header [7] L-E. Jonsson, G. Pelletier & K. Sandlund, "RObust Header
Compression (ROHC): A Link-Layer Assisted Profile for Compression (ROHC): A Link-Layer Assisted Profile for
IP/UDP/RTP", RFC 4362, June 2004. IP/UDP/RTP", RFC 4362, June 2004.
[8] J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
[9] S. Deering & R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[10] J. Postel, "User Datagram Protocol", STD 6, RFC 768, August
1980.
[11] H. Schulzrinne, S. Casner, R. Frederick & V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC 1889,
January 1996.
[12] S. Kent & R. Atkinson, "IP Encapsulating Security Payload", RFC
2406, November 1998.
[13] R. Glenn & S. Kent, "The NULL Encryption Algorithm and Its Use
With IPsec", RFC 2410, November 1998.
[14] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[16] D. Farinacci, T. Li, S. Hanks, D. Meyer & P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 2784, March 2000.
[17] G. Dommety, "Key and Sequence Number Extensions to GRE", RFC
2890, August 2000.
16. Authors' Addresses 16. Authors' Addresses
Lars-Erik Jonsson Lars-Erik Jonsson
Ericsson AB Ericsson AB
Box 920 Box 920
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61 Phone: +46 8 404 29 61
EMail: lars-erik.jonsson@ericsson.com EMail: lars-erik.jonsson@ericsson.com
Kristofer Sandlund Kristofer Sandlund
skipping to change at page 29, line 45 skipping to change at page 30, 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 March 19, 2007. This Internet-Draft expires April 13, 2007.
 End of changes. 78 change blocks. 
222 lines changed or deleted 263 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/