draft-ietf-rohc-rtp-impl-guide-22.txt   rfc4815.txt 
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT K. Sandlund Request for Comments: 4815 K. Sandlund
TO UPDATE: RFC 3095, 3241, 3843, 4019, 4362 G. Pelletier Updates: 3095, 3241, 3843, 4019, 4362 G. Pelletier
Expires: May 2007 P. Kremer Category: Standards Track P. Kremer
Ericsson February 2007
November 6, 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-22.txt>
Status of this memo Status of This Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/1id-abstracts.html Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should be Copyright (C) The IETF Trust (2007).
directed to the ROHC WG mailing list, rohc@ietf.org.
Abstract Abstract
RFC 3095 defines the RObust Header Compression (ROHC) framework and RFC 3095 defines the RObust Header Compression (ROHC) framework and
profiles for IP (Internet Protocol), UDP (User Datagram Protocol), profiles for IP (Internet Protocol), UDP (User Datagram Protocol),
RTP (Real-Time Transport Protocol), and ESP (Encapsulated Security RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security
Payload). Some parts of the specification are unclear or contain Payload). Some parts of the specification are unclear or contain
errors that may lead to misinterpretations that may impair errors that may lead to misinterpretations that may impair
interoperability between different implementations. This document interoperability between different implementations. This document
provides corrections, additions and clarifications to RFC 3095; this provides corrections, additions, and clarifications to RFC 3095; this
document thus updates RFC 3095. In addition, other clarifications document thus updates RFC 3095. In addition, other clarifications
related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and
RFC 4109 (ROHC UDP-Lite profiles) are also provided. RFC 4109 (ROHC UDP-Lite profiles) are also provided.
Table of Contents Table of Contents
1. Introduction and terminology.....................................3 1. Introduction and Terminology ....................................3
2. CRC calculation and coverage.....................................4 2. CRC Calculation and Coverage ....................................4
2.1. CRC calculation.............................................4 2.1. CRC Calculation ............................................4
2.2. Padding octet and CRC calculations..........................4 2.2. Padding Octet and CRC Calculations .........................4
2.3. CRC coverage in CRC feedback options........................4 2.3. CRC Coverage in CRC Feedback Options .......................5
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 .6
3.1.2. Transition from Reliable to Optimistic mode............6 3.1.2. Transition from Reliable to Optimistic Mode .........7
3.1.3. Transition to Unidirectional mode......................7 3.1.3. Transition to Unidirectional Mode ...................8
3.2. Feedback during mode transition.............................7 3.2. Feedback During Mode Transition ............................8
3.3. Packet decoding during mode transition......................8 3.3. Packet Decoding During Mode Transition .....................9
4. Timestamp encoding...............................................8 4. Timestamp Encoding ..............................................9
4.1. Encoding used for compressed TS bits........................8 4.1. Encoding Used for Compressed TS Bits .......................9
4.2. (De)compression of TS without transmitted TS bits...........8 4.2. (De)compression of TS without Transmitted TS Bits .........10
4.3. Interpretation intervals for TS encoding...................10 4.3. Interpretation Intervals for TS Encoding ..................11
4.4. Scaled RTP timestamp encoding..............................10 4.4. Scaled RTP Timestamp Encoding .............................11
4.4.1. TS_STRIDE for scaled timestamp encoding...............10 4.4.1. TS_STRIDE for Scaled Timestamp Encoding ............11
4.4.2. TS wraparound with scaled timestamp encoding..........11 4.4.2. TS Wraparound with Scaled Timestamp Encoding .......12
4.4.3. Algorithm for scaled timestamp encoding...............11 4.4.3. Algorithm for Scaled Timestamp Encoding ............12
4.5. Recalculating TS_OFFSET....................................12 4.5. Recalculating TS_OFFSET ...................................14
4.6. TS_STRIDE and the Tsc flag in Extension 3..................12 4.6. TS_STRIDE and the Tsc Flag in Extension 3 .................14
4.7. Using timer-based compression..............................13 4.7. Using Timer-Based Compression .............................15
5. List compression................................................14 5. List Compression ...............................................15
5.1. CSRC list items in RTP dynamic chain.......................14 5.1. CSRC List Items in RTP Dynamic Chain ......................15
5.2. Multiple occurrences of the CC field.......................14 5.2. Multiple Occurrences of the CC Field ......................15
5.3. Bit masks in list compression..............................14 5.3. Bit Masks in List Compression .............................16
5.4. Headers compressed with list compression...................15 5.4. Headers Compressed with List Compression ..................16
5.5. ESP NULL header list compression...........................15 5.5. ESP NULL Header List Compression ..........................17
5.6. Translation tables and indexes for IP extension headers....15 5.6. Translation Tables and Indexes for IP Extension Headers ...17
5.7. Reference list.............................................16 5.7. Reference List ............................................17
5.8. Compression of AH and GRE sequence numbers.................16 5.8. Compression of AH and GRE Sequence Numbers ................18
6. Updating properties.............................................17 6. Updating Properties ............................................19
6.1. Implicit updates...........................................17 6.1. Implicit Updates ..........................................19
6.2. Updating properties of UO-1*...............................18 6.2. Updating Properties of UO-1* ..............................20
6.3. Context updating properties for IR packets.................18 6.3. Context Updating Properties for IR Packets ................20
6.4. RTP padding field (R-P) in extension 3.....................18 6.4. RTP Padding Field (R-P) in Extension 3 ....................20
6.5. RTP eXtension bit (X) in dynamic part......................19 6.5. RTP eXtension bit (X) in dynamic part .....................21
7. Context management and CID/context re-use.......................19 7. Context management and CID/context Reuse .......................21
7.1. Persistence of decompressor contexts.......................19 7.1. Persistence of Decompressor Contexts ......................21
7.2. CID/context re-use.........................................19 7.2. CID/Context Reuse .........................................21
7.2.1. Re-using a CID/context with the same profile..........20 7.2.1. Reusing a CID/Context with the Same Profile ........22
7.2.2. Re-using a CID/context with a different profile.......20 7.2.2. Reusing a CID/Context with a Different Profile .....23
8. Other protocol clarifications...................................21 8. Other Protocol Clarifications ..................................23
8.1. Meaning of NBO.............................................21 8.1. Meaning of NBO ............................................23
8.2. IP-ID......................................................21 8.2. IP-ID .....................................................23
8.3. Extension-3 in UOR-2* packets..............................22 8.3. Extension-3 in UOR-2* Packets .............................24
8.4. Multiple occurrences of the M bit..........................22 8.4. Multiple Occurrences of the M Bit .........................24
8.5. Multiple SN options in one feedback packet.................22 8.5. Multiple SN options in one feedback packet ................24
8.6. Multiple CRC options in one feedback packet................22 8.6. Multiple CRC Options in One Feedback Packet ...............25
8.7. Responding to lost feedback links..........................23 8.7. Responding to Lost Feedback Links .........................25
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) ....25
8.9. Sequence number LSB's in IP extension headers..............23 8.9. Sequence Number LSB's in IP Extension Headers .............25
8.10. Expecting UOR-2 ACKs in O-mode............................23 8.10. Expecting UOR-2 ACKs in O-Mode ...........................26
8.11. Context repairs, TS_STRIDE and TIME_STRIDE................24 8.11. Context Repairs, TS_STRIDE and TIME_STRIDE ...............26
9. ROHC negotiation................................................24 9. ROHC Negotiation ...............................................27
10. PROFILES suboption in ROHC-over-PPP............................25 10. PROFILES Sub-option in ROHC-over-PPP ..........................27
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 ......27
12. Security considerations........................................25 12. Security Considerations .......................................28
13. IANA considerations............................................25 13. Acknowledgments ...............................................28
14. Acknowledgment.................................................25 14. References ....................................................28
15. References.....................................................26 14.1. Normative References .....................................28
15.1. Normative References......................................26 14.2. Informative References ...................................29
15.2. Informative References....................................26 Appendix A. Sample CRC Algorithm ..................................30
16. Authors' Addresses.............................................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 (Internet Protocol) [8][9], UDP (User Datagram and profiles for IP (Internet Protocol) [8][9], UDP (User Datagram
Protocol) [10], RTP (Real-Time Transport Protocol) [11], and ESP Protocol) [10], RTP (Real-Time Transport Protocol) [11], and ESP
(Encapsulated Security Payload) [12]. During implementation and (Encapsulating Security Payload) [12]. 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.
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. References to RFC 3095 should therefore also include specification. References to RFC 3095 should, therefore, also
this document. include this document.
In addition, some clarifications and corrections are also provided In addition, some clarifications and corrections are also provided
for RFC 3241 (ROHC over PPP) [2], RFC 3843 (ROHC IP-only profile) for RFC 3241 (ROHC over PPP) [2], RFC 3843 (ROHC IP-only profile)
[4], and RFC 4019 (ROHC UDP-Lite profiles) [5], which are thus also [4], and RFC 4019 (ROHC UDP-Lite profiles) [5], which are thus also
updated by this document. Furthermore, RFC 4362 (ROHC Link-Layer updated by this document. Furthermore, RFC 4362 (ROHC Link-Layer
Assisted Profile) [7] is implicitly updated by this document, since Assisted Profile) [7] is implicitly updated by this document, since
also RFC 4362 is based on RFC 3095. RFC 4362 is also based on RFC 3095.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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.
text from RFC 3095 that is being addressed is given and labeled The 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
the correct text labeled "CORRECTED", where applicable. When text is by the correct text labeled "CORRECTED", where applicable. When text
added that does not simply correct text in previous specifications, is added that does not simply correct text in previous
it is given with the label "FORMAL ADDITION". specifications, it is given with the label "FORMAL ADDITION".
In this document, a reference to a section in RFC 3095 [1] is written In this document, a reference to a section in RFC 3095 [1] is written
as a prefixed section reference, RFC3095-<section number>. as RFC 3095-Section <number>.
2. CRC calculation and coverage 2. CRC Calculation and Coverage
2.1. CRC calculation 2.1. CRC Calculation
Section RFC3095-5.9 defines polynomials for 3, 7 and 8-bit CRCs, but RFC 3095-Section 5.9 defines polynomials for 3-, 7-, and 8-bit Cyclic
it does not specify what algorithm is used. The 3, 7 and 8-bit CRCs Redundancy Checks (CRCs), but it does not specify what algorithm is
are calculated using the CRC algorithm defined in [3]. used. The 3-, 7- and 8-bit CRCs 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 RFC3095-5.9.1 is incomplete, as it does not mention how to RFC 3095-Section 5.9.1 is incomplete, as it does not mention how to
handle the padding octet in CRC calculations for IR and IR-DYN handle the padding octet in CRC calculations for IR and IR-DYN
packets. Padding isn't meant to be a meaningful part of a packet and packets. Padding isn't meant to be a meaningful part of a packet and
is not included in the CRC calculation. As a result, the CRC does not is not included in the CRC calculation. As a result, the CRC does
cover the Add-CID octet for CID 0, either. not cover the Add-CID octet for CID 0, either.
INCOMPLETE RFC 3095 TEXT (section RFC3095-5.9.1): INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 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 RFC3095-5.7.6.3 is incomplete, as it does not mention how the RFC 3095-Section 5.7.6.3 is incomplete, as it does not mention how
"size" field is handled when calculating the 8-bit CRC used in the the "size" field is handled when calculating the 8-bit CRC used in
CRC feedback option. Since the "size" field is an extension of the the CRC feedback option. Since the "size" field is an extension of
"code" field, it must be treated in the same way. the "code" field, it must be treated in the same way.
INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7.6.3): INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 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 RFC3095-5.8.7 gives the CRC coverage of the ESP NULL [13] RFC 3095-Section 5.8.7 gives the CRC coverage of the ESP NULL [13]
header as "Entire ESP header". This must be interpreted as including header as "Entire ESP header". This must be interpreted as including
only the initial part of the header (i.e. SPI and Sequence number), only the initial part of the header (i.e., Security Parameter Index
and not the trailer part at the end of the payload. Therefore, the (SPI) and sequence number), and not the trailer part at the end of
ESP NULL header has the same CRC coverage as the ESP header used in the payload. Therefore, the ESP NULL header has the same CRC
the ESP profile (section RFC3095-5.7.7.7). coverage as the ESP header used in the ESP profile (RFC 3095-Section
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 RFC3095-5.6.1 states that during mode transitions, while the RFC 3095-Section 5.6.1 states that during mode transitions, while the
D_TRANS parameter is I, the decompressor send feedback for each D_TRANS parameter is I, the decompressor sends feedback for each
received packet. This restrictive behavior prevents a decompressor received packet. This restrictive behavior prevents the decompressor
from using 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
the optimized procedures will interoperate with an RFC3095 the optimized procedures will interoperate with an RFC3095
compressor, as well as a decompressor implemented according to the compressor, as well as a decompressor implemented according to the
procedures described in RFC3095. procedures described in RFC3095.
3.1.1. Mode transition procedures allowing sparse feedback 3.1.1. Mode Transition Procedures Allowing Sparse Feedback
The purpose of these enhanced transition procedures is to allow the The purpose of these enhanced transition procedures is to allow the
decompressor to sparsely send feedback for packets decompressed decompressor to sparsely send feedback for packets decompressed
during the second half of the transition procedure, i.e. after an during the second half of the transition procedure, i.e., after an
appropriate IR/IR-DYN/UOR-2 packet has been received from the appropriate IR/IR-DYN/UOR-2 packet has been received from the
compressor. This is achieved by allowing the decompressor transition compressor. This is achieved by allowing the decompressor transition
parameter (D_TRANS) to be set to P (Pending) at that stage, as shown parameter (D_TRANS) to be set to P (Pending) at that stage, as shown
in the transition diagrams of sections 3.1.2 and 3.1.3 below. in the transition diagrams of Sections 3.1.2 and 3.1.3 below.
This enhanced transition, where feedback need not be sent for every This enhanced transition, where feedback need not be sent for every
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;
if no feedback message successfully reaches the compressor the if no feedback message successfully reaches the compressor, the
transition is never completed. For transition between U-mode and O- transition is never completed. For transition between U-mode and
mode, there is also a small risk for reduced compression efficiency. O-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, as well as when in a Pending transition state.
equivalent to enhancing the definition of the D_TRANS parameter in This is equivalent to enhancing the definition of the D_TRANS
section RFC3095-5.6.1, to include the definition of a Pending state: parameter in RFC 3095-Section 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
transition can be initiated only when D_TRANS is D. While D_TRANS mode transition can be initiated only when D_TRANS is D. While
is I, the decompressor sends a NACK or ACK carrying a CRC option D_TRANS is I, the decompressor sends a NACK or ACK carrying a CRC
for each packet received. When D_TRANS is set to P, the option 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 does 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.
The modifications affect transitions to Optimistic and Unidirectional The modifications affect transitions to Optimistic and Unidirectional
modes of operation, i.e. the transitions described in sections modes of operation (i.e., the transitions described in RFC 3095-
RFC3095-5.6.5 and RFC3095-5.6.6, and make those transition diagrams Section 5.6.5 and RFC 3095-Section 5.6.6) and make those transition
more 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
| +-<-<-<-<-<-<-<-+ | | +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ | C_TRANS = P |-<-<-<-+ |
skipping to change at page 7, line 5 skipping to change at page 8, line 5
|->-.. | D_MODE = O |->-.. | D_MODE = O
| ACK(SN,O) +-<-<-<-| | ACK(SN,O) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ | | +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ | C_TRANS = D |-<-<-<-+ |
| | | |
|->->->-+ UO-0, UO-1* | |->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ | | +->->->->->->->-+ |
| +->->->-| D_TRANS = D | +->->->-| D_TRANS = D
| | | |
3.1.3. Transition to Unidirectional mode 3.1.3. Transition to Unidirectional Mode
The enhanced procedure for transition to Unidirectional mode is shown The enhanced procedure for transition to Unidirectional mode is shown
on the following figure: on the following figure:
Compressor Decompressor Compressor Decompressor
---------------------------------------------- ----------------------------------------------
| | | |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I | ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ | | +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ | C_TRANS = P |-<-<-<-+ |
skipping to change at page 7, line 30 skipping to change at page 8, line 30
|->-.. | |->-.. |
| ACK(SN,U) +-<-<-<-| | ACK(SN,U) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ | | +-<-<-<-<-<-<-<-+ |
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 RFC3095-5.6.1 states that feedback is always used during mode RFC 3095-Section 5.6.1 states that feedback is always used during
transitions. However, the text then continues by making concrete mode transitions. However, the text then continues by making
applications of the rule in an inconsistent way, making it unclear concrete applications of the rule in an inconsistent way, making it
when CRCs are used. Further, the text does not define how the unclear when CRCs are used. Further, the text does not define how
compressor should act during mode transitions based on feedback not the compressor should act during mode transitions based on feedback
protected by CRCs, i.e. whether to carry out mode transition actions not protected by CRCs, i.e., whether or not to carry out mode
or not. The proper behavior from the compressor is to perform any transition actions. The proper behavior from the compressor is to
action related to mode transitions only when the feedback is perform any action related to mode transitions only when the feedback
protected by the CRC option. is protected by the CRC option.
INCOMPLETE RFC 3095 TEXT (section RFC3095-5.6.1): INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 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
skipping to change at page 8, line 4 skipping to change at page 9, line 6
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 RFC3095-5.6.1: following text at the end of RFC 3095-Section 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 RFC3095-5.5.2.2 already stated that for R-mode, However, RFC 3095-Section 5.5.2.2 already stated that for R-mode,
feedback is never sent for packets that do not update the context, feedback is never sent for packets that do not update the context,
i.e. for packets that do not carry a CRC such as R-0 and R-1*. 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 type 1 that are received up to this
are decompressed using the old mode, while afterwards they are point 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 are used, the setting of the procedures described in Section 3.1 are used, the setting of the
D_TRANS parameter to P represents this breakpoint. The successful D_TRANS parameter to P represents this breakpoint. The successful
decompression of a packet of type 0 or type 1 completes the mode decompression of a packet of type 0 or type 1 completes 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 (TS) values 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 unscaled. When no TS bits are transmitted
transmitted in a compressed packet, TS is always scaled. If a in a compressed packet, TS is always scaled. If a compressed packet
compressed packet carries an extension 3 and field(Tsc)=0, the carries an Extension 3 and field(Tsc)=0, the compressed packet must
compressed packet must thus always carry unscaled TS bits. For TS thus always carry unscaled TS bits. For TS values sent in Extension
values sent in Extension 3, W-LSB encoded values are sent using the 3, W-LSB encoded values are sent using the self-describing variable-
self-describing variable-length format (section RFC3095-4.5.6), and length format (RFC 3095-Section 4.5.6), and this applies to both
this applies to both scaled and unscaled values. 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 operates using its most efficient packet types, apart When ROHC RTP operates 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 are transmitted in RTP compressed headers. sequence number (SN) bits are transmitted in RTP compressed headers.
All other fields are then omitted either because they are unchanged All other fields are then omitted either because they are unchanged
or because they can be reconstructed through a function from the SN or because they can be reconstructed through a function from the SN
(i.e. by combining the transmitted SN bits with state information (i.e., by combining the transmitted SN bits with state information
from the context). Fields that can be inferred from the SN are the IP from the context). Fields that can be inferred from the SN are the
Identification (IP-ID) and the RTP Timestamp (TS). 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 RFC3095-4.5.5 (see section 8.2). For the TS field, however, RFC 3095-Section 4.5.5 (see Section 8.2). For the TS field, however,
RFC 3095 only defines how to decompress based on actual TS bits in RFC 3095 only defines how to decompress based on actual TS bits in
the compressed header, either scaled or unscaled, but not how to the compressed header, either scaled or unscaled, but not how to
infer the TS from the SN when there are no TS bits present in the infer the TS from the SN when there are no TS bits present in the
compressed header. compressed header.
When no TS bits are received in the compressed header, the scaled TS When no TS bits are received in the compressed header, the scaled TS
value is reconstructed assuming a linear extrapolation from the SN, value is reconstructed assuming a linear extrapolation from the SN,
i.e. delta_TS = delta_SN * default-slope, where delta_SN and delta_TS i.e., delta_TS = delta_SN * default-slope, where delta_SN and
are both signed integers. Section RFC3095-5.7 defines the potential delta_TS are both signed integers. RFC 3095-Section 5.7 defines the
values for default-slope. potential values for default-slope.
INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7): INCOMPLETE RFC 3095 TEXT (RFC 3095-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 scaled "When a compressed header with no TS bits is received, the scaled
TS value is reconstructed assuming a linear extrapolation from TS value is reconstructed assuming a linear extrapolation from
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
is received with Tsc=0, the decompressor MUST discard the bits is received with Tsc = 0, the decompressor MUST discard the
packet." packet."
INCORRECT AND INVALIDATED RFC 3095 TEXT (Section RFC 3095-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 RFC3095-5.7. as defined in RFC 3095-Section 5.7.
4.3. Interpretation intervals for TS encoding 4.3. Interpretation Intervals for TS Encoding
Section RFC3095-4.5.4 defines the interpretation interval, p, for RFC 3095-Section 4.5.4 defines the interpretation interval, p, for
timer-based compression of the RTP timestamp. However, Section timer-based compression of the RTP timestamp. However, RFC 3095-
RFC3095-5.7 defines a different interpretation interval, which is Section 5.7 defines a different interpretation interval, which is
defined as the interpretation interval to use for all TS values. It defined as the interpretation interval to use for all TS values. It
is thus unclear which p-value to use, at least for timer-based is thus unclear which p-value to use, at least for timer-based
compression. 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 or not timer-based compression is enabled.
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 RFC3095-4.5.4)
p = 2^(k-1) - 1 (as per RFC 3095-Section 4.5.4)
Otherwise, the interpretation interval is: Otherwise, the interpretation interval is:
p = 2^(k-2) - 1 (as per section RFC3095-5.7)
4.4. Scaled RTP timestamp encoding p = 2^(k-2) - 1 (as per RFC 3095-Section 5.7)
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 RFC3095-4.5.3. Two encoding, defined as a 5-step procedure in RFC 3095-Section 4.5.3.
formal errors have been corrected, as described in subsections 4.4.1 Two formal errors have been corrected, as described in sub-sections
and 4.4.2 below, and the whole algorithm has been reworked to be more 4.4.1 and 4.4.2 below, and the whole algorithm has been reworked to
concise and use well-defined terminology. The resulting text can be be more concise and to use well-defined terminology. The resulting
found in 4.4.3 below. text can be 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 RFC3095-4.5.3, defines the mathematical meaning equality in RFC 3095-Section 4.5.3, defines the mathematical meaning
of TS_STRIDE: of TS_STRIDE:
TS = TS_SCALED * TS_STRIDE + TS_OFFSET TS = TS_SCALED * TS_STRIDE + TS_OFFSET
TS_SCALED is incompletely written as TS / TS_STRIDE in the TS_SCALED is incompletely written as TS / TS_STRIDE in the
compression step following the above core equality. This formula is compression step following the above core equality. This formula is
incorrect both because it excludes TS_OFFSET and because it would incorrect both because it excludes TS_OFFSET and because it would
prevent a TS_STRIDE value of 0, which is an alternative not excluded prevent a TS_STRIDE value of 0, which is an alternative not excluded
by the definition or by the core equality above. If "/" were a by the definition or by the core equality above. If "/" were a
generally unambiguously defined operation meaning "the integral part generally unambiguously defined operation meaning "the integral part
skipping to change at page 11, line 6 skipping to change at page 12, line 25
incorrect both because it excludes TS_OFFSET and because it would incorrect both because it excludes TS_OFFSET and because it would
prevent a TS_STRIDE value of 0, which is an alternative not excluded prevent a TS_STRIDE value of 0, which is an alternative not excluded
by the definition or by the core equality above. If "/" were a by the definition or by the core equality above. If "/" were a
generally unambiguously defined operation meaning "the integral part generally unambiguously defined operation meaning "the integral part
of the result from dividing X by Y", the absence of TS_OFFSET could of the result from dividing X by Y", the absence of TS_OFFSET could
be explained, but the formula would still lack a proper output for be explained, but the formula would still lack a proper output for
TS_STRIDE equal to 0. The formula of "2. Compression" is thus valid TS_STRIDE equal to 0. The formula of "2. Compression" is thus valid
only with the following requirements: only with the following requirements:
a) "/" means "the integral part of the result from dividing X by Y" a) "/" means "the integral part of the result from dividing X by Y"
b) TS_STRIDE>0 (TS is never sent scaled when TS_STRIDE=0) b) TS_STRIDE>0 (TS is never sent scaled when TS_STRIDE=0)
4.4.2. TS wraparound with scaled timestamp encoding 4.4.2. TS Wraparound with Scaled Timestamp Encoding
Section RFC3095-4.5.3 states in point 4 and 5 that the compressor is RFC 3095-Section 4.5.3 states in points 4 and 5 that the compressor
not required to initialize TS_OFFSET at wraparound, but that it is 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 seldomly. Therefore,
compressor should reinitialize TS_OFFSET upon TS wraparound, by the compressor should reinitialize TS_OFFSET upon TS wraparound, by
sending unscaled TS. sending an unscaled TS.
4.4.3. Algorithm for scaled timestamp encoding 4.4.3. Algorithm for Scaled Timestamp Encoding
INCORRECT RFC 3095 TEXT (section RFC3095-4.5.3): INCORRECT RFC 3095 TEXT (RFC 3095-Section 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
compresses the original TS values. Instead, it compresses the compresses the original TS values. Instead, it compresses the
downscaled values: TS_SCALED = TS / TS_STRIDE. The downscaled values: TS_SCALED = TS / TS_STRIDE. The compression
compression method could be either W-LSB encoding or the method could be either W-LSB encoding or the timer-based
timer-based encoding described in the next section. encoding described in the next section.
3. Decompression: When receiving the compressed value of 3. Decompression: When receiving the compressed value of
TS_SCALED, the decompressor first derives the value of the TS_SCALED, the decompressor first derives the value of the
original TS_SCALED. The original RTP TS is then calculated as original TS_SCALED. The original RTP TS is then calculated as
TS = TS_SCALED * TS_STRIDE + TS_OFFSET. TS = TS_SCALED * TS_STRIDE + TS_OFFSET.
4. Offset at wraparound: Wraparound of the unscaled 32-bit TS 4. Offset at wraparound: Wraparound of the unscaled 32-bit TS will
will invalidate the current value of TS_OFFSET used in the invalidate the current value of TS_OFFSET used in the equation
equation above. For example, let us assume TS_STRIDE = 160 = above. For example, let us assume TS_STRIDE = 160 = 0xA0 and
0xA0 and the current TS = 0xFFFFFFF0. TS_OFFSET is then 0x50 the current TS = 0xFFFFFFF0. TS_OFFSET is then 0x50 = 80.
= 80. Then if the next RTP TS = 0x00000130 (i.e., the Then if the next RTP TS = 0x00000130 (i.e., the increment is
increment is 160 * 2 = 320), the new TS_OFFSET should be 160 * 2 = 320), the new TS_OFFSET should be 0x00000130 modulo
0x00000130 modulo 0xA0 = 0x90 = 144. The compressor is not 0xA0 = 0x90 = 144. The compressor is not required to re-
required to re-initialize TS_OFFSET at wraparound. Instead, initialize TS_OFFSET at wraparound. Instead, the decompressor
the decompressor MUST detect wraparound of the unscaled TS MUST detect wraparound of the unscaled TS (which is trivial)
(which is trivial) and update TS_OFFSET to and update TS_OFFSET to TS_OFFSET = (Wrapped around unscaled
TS_OFFSET = (Wrapped around unscaled TS) modulo TS_STRIDE" TS) modulo TS_STRIDE"
CORRECTED TEXT: CORRECTED TEXT:
"1. Initialization and updating of RTP TS scaling function: "1. Initialization and updating of RTP TS scaling function: The
The compressor sends to the decompressor the value of compressor sends to the decompressor the value of TS_STRIDE
TS_STRIDE along with an unscaled TS. These are both needed by along with an unscaled TS. These are both needed by the
the decompressor to initialize TS_OFFSET as hdr(TS) modulo decompressor to initialize TS_OFFSET as hdr(TS) modulo
field(TS_STRIDE). Note that TS_OFFSET is the same for any TS 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 as long as TS_STRIDE does not change and as long as the
unscaled TS value does not wrap around; see 4) below. unscaled TS value does not wrap around; see 4) below.
2. Compression: After initialization, the compressor no longer 2. Compression: After initialization, the compressor no longer
compresses the unscaled TS values. Instead, it compresses the compresses the unscaled TS values. Instead, it compresses the
scaled values. The compression method can be either W-LSB scaled values. The compression method can be either W-LSB
encoding or timer-based encoding. encoding or timer-based encoding.
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
to a power of two, wraparound of the unscaled 32-bit TS will 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 (RFC 3095-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
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.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 or not TS is scaled.
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, as well as if
are no TS bits in the extension itself. When TS is scaled, it is there are no TS bits in the extension itself. When TS is scaled, it
always scaled using context(TS_STRIDE). The legend for Extension 3 in is always scaled using context(TS_STRIDE). The legend for Extension
section RFC3095-5.7.5 incorrectly states that value(TS_STRIDE) is 3 in RFC 3095-Section 5.7.5 incorrectly states that value(TS_STRIDE)
used for scaled TS, which is incorrect. is used for scaled TS.
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 RFC3095-5.7.5): INCORRECT RFC 3095 TEXT (RFC 3095-Section 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;
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
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 RFC
RFC3095-4.5.4, may be used to reduce the number of transmitted 3095-Section 4.5.4, may be used to reduce the number of transmitted
timestamp bits (bytes) needed when the timestamp can not be inferred timestamp bits (bytes) needed when the timestamp can not be inferred
from the SN. Timer-based compression is only used for decompression from the SN. Timer-based compression is only used for decompression
of compressed headers that contains a TS field, otherwise when no of compressed headers that contains a TS field; otherwise, when no
timestamp bits are present the timestamp is linearly inferred from timestamp bits are present, the timestamp is linearly inferred from
the SN (see 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 or not to use timer-based compression 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 by either an IR, an IR-
DYN, or by a compressed packet with extension 3. Before timer-based DYN, or 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. When per-context basis) a non-zero TIME_STRIDE to the decompressor. When
the compressor is confident that the decompressor has received the the compressor is confident that the decompressor has received the
TIME_STRIDE value, it can switch to timer-based compression. 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 RFC3095-5.7.7.6 defines the static and dynamic parts of the RFC 3095-Section 5.7.7.6 defines the static and dynamic parts of the
RTP header. This section indicates a 'Generic CSRC list' field in the RTP header. This section indicates a 'Generic CSRC list' field in
dynamic chain, which has a variable length (see section RFC3095- the dynamic chain, which has a variable length (see RFC 3095-Section
5.8.6). This field is always at least one octet in size, even if the 5.8.6). This field is always at least one octet in size, even if the
list is empty (as opposed to the CSRC list in the uncompressed RTP list is empty (as opposed to the CSRC list in the uncompressed RTP
header, which is 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 RFC
section RFC3095-5.7.7.6. In the dynamic part, a CC field indicates 3095-Section 5.7.7.6. In the dynamic part, a CC field indicates the
the number of CSRC items present in the 'Generic CSRC list'. Another number of CSRC items present in the 'Generic CSRC list'. Another CC
CC field also appears within the 'Generic CSRC list' (section field also appears within the 'Generic CSRC list' (RFC 3095-Section
RFC3095-5.8.6.1), because Encoding Type 0 is always used in the 5.8.6.1), because Encoding Type 0 is always used in the dynamic
dynamic chain. Both CC fields have the same meaning: the value of the chain. Both CC fields have the same meaning: the value of the CC
CC field determines the number of XI items in the CSRC list for field determines the number of XI items in the CSRC list for Encoding
Encoding Type 0, and it is not used otherwise. Therefore, the Type 0, and it is not used otherwise. Therefore, the following
following applies: 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 RFC3095-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 RFC3095- The insertion and/or removal schemes, described in RFC 3095-Sections
5.8.6.2 - 5.8.6.4, use bit masks to indicates insertion or removal 5.8.6.2 - 5.8.6.4, use bit masks to indicates insertion or removal
positions within the reference list. The size of the bit mask can be positions within the reference list. The size of the bit mask can be
7-bit or 15-bit. 7 bits or 15 bits.
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 seven items, provided that changes to the list are only
to items within the first 7 items of the reference list, leaving applied to items within the first seven items of the reference list,
items with an index not covered by the 7-bit mask unchanged. leaving 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 seven items.
5.4. Headers compressed with list compression 5.4. Headers Compressed with List Compression
In section RFC3095-5.8, it is stated that headers which can be part In RFC 3095-Section 5.8, it states that headers that can be part of
of extension header chains "include" AH [14], ESP NULL [13], minimal extension header chains "include" AH [14], ESP NULL [13], minimal
encapsulation (MINE) [15], GRE [16][17], and IPv6 [9] extensions. encapsulation (MINE) [15], GRE [16][17], and IPv6 [9] extensions.
This list of headers which can be compressed is correct, but the word This list of headers that can be compressed is correct, but the word
"include" should not be there, since only the header types listed can "include" should not be there, since only the header types listed can
actually be handled. It should further be noted that for the Minimal actually be handled. It should further be noted that for the Minimal
Encapsulation (MINE) header, there is no explicit discussion of how Encapsulation (MINE) header, there is no explicit discussion of how
to compress it, as the header is either sent uncompressed or fully to compress it, as the header is sent either uncompressed or fully
compressed away. 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 [13] header, unless the second-outermost header is one NULL ESP [13] header, unless the second-outermost header is
treated as a regular ESP [12] header and the packets are compressed treated as a regular ESP [12] header and the packets are compressed
using profile 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 RFC3095-5.8.4 describes how list indexes are associated to RFC 3095-Section 5.8.4 describes how list indexes are associated to
list items and how table lists are built for IP extension headers. list items and how table lists are built for IP extension headers.
The text incorrectly states that one index per type is used, since The text incorrectly states that one index per type is used, since
the same type can appear several times with different content in one the same type can appear several times with different content in one
single 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
the list is updated, the compressor MUST send the value for each in the list is updated, the compressor MUST send the value for each
occurrence of that index in the list. occurrence of that index in the list.
When content of extension headers changes, an implementation can When content of extension headers changes, an implementation can
choose to either use a different index, or update the existing one. choose to either use a different index or update the existing one.
Some extensions can be compressed away even when some fields change, Some extensions can be compressed away even when some fields change,
as those changes can be conveyed to the decompressor implicitly (e.g. as those changes can be conveyed to the decompressor implicitly (e.g.
sequence numbers in extension headers that can be inferred from the sequence numbers in extension headers that can be inferred from the
RTP SN) or explicitly (e.g. as part of the 'IP extension header(s)' RTP SN) or explicitly (e.g., as part of the 'IP extension header(s)'
field in extension 3). field in Extension 3).
When there is more than one IP header, there is more than one list of When there is more than one IP header, there is more than one list of
extension headers, and a translation table is maintained for each extension headers, and a translation table is maintained for each
list independently of one another. list independently of one another.
5.7. Reference list 5.7. Reference List
A list compressed using encoding type 1 (insertion), type 2 (removal) A list compressed using encoding type 1 (insertion), type 2
or type 3 (removal/insertion) uses a coding scheme that is based on (removal), or type 3 (removal/insertion) uses a coding scheme that is
the use of a reference list in the context (identified as ref_id). based on the use of a reference list in the context (identified as
ref_id).
While it could seem a fair choice to send a type 1 list when ref_id While it could seem to be a fair choice to send a type 1 list when
is an empty list, there is no gain in doing so with respect to using ref_id is an empty list, there is nothing gained in doing so with
a type 0 list. Sending a type 2 list when ref_id is an empty list respect to using a type 0 list. Sending a type 2 list when ref_id is
would lead to a failure, while sending a type 3 list has very little an empty list would lead to a failure, while sending a type 3 list
meaning. All these alternatives could be seen as possible, based on has very little meaning. All these alternatives could be seen as
how list compression is specified in RFC 3095. possible, based on how list compression is specified in RFC 3095.
If these alternatives were allowed, a decompressor would become If these alternatives were allowed, a decompressor would become
required to maintain a sliding window of ref_id lists in R-mode, even required to maintain a sliding window of ref_id lists in R-mode, even
for the case where no items are sent in the compressed list, and this for the case where no items are sent in the compressed list, and this
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 RFC3095-5.8.4.2 and section RFC3095-5.8.4.4 describes how to RFC 3095-Section 5.8.4.2 and RFC 3095-Section 5.8.4.4 describe how to
compress the Authentication Header (AH) [14] and the Generic Routing compress the Authentication Header (AH) [14] and the Generic Routing
Encapsulation (GRE) [16][17] header. Both these sections present a Encapsulation (GRE) [16][17] header. Both these sections present a
possibility to omit the AH/GRE sequence number in the compressed possibility to omit the AH/GRE sequence number in the compressed
header, under certain circumstances. However, the specific conditions header, under certain circumstances. However, the specific
for omitting the AH/GRE sequence number, as well as the concrete conditions for omitting the AH/GRE sequence number, as well as the
compression and decompression procedures to apply, are not clearly concrete compression and decompression procedures to apply, are not
defined to guarantee robustness and facilitate interoperable clearly defined to guarantee robustness and facilitate interoperable
implementation. 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 RFC3095-5.8.4.2): INCORRECT RFC 3095 TEXT (RFC 3095-Section 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
the decompressor has established the correct offset." decompressor has established the correct offset."
INCORRECT RFC 3095 TEXT (section RFC3095-5.8.4.4): INCORRECT RFC 3095 TEXT (RFC 3095-Section 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:
"The GRE sequence number can be omitted from the compressed header "The GRE 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 the header is constant, when the compressor has confidence that the
decompressor has established the correct offset." decompressor has established the correct offset."
6. Updating properties 6. Updating Properties
6.1. Implicit updates 6.1. Implicit Updates
A context updating packet that contains compressed sequence number A context updating packet that contains compressed sequence number
information may also carry information about other fields; in such information may also carry information about other fields; in such
cases, these fields are updated according to the content of the cases, these fields are updated according to the content of the
packet. The updating packet also implicitly updates inferred fields packet. The updating packet also implicitly updates inferred fields
(e.g. RTP timestamp) according to the current mode and the (e.g., RTP Timestamp) according to the current mode and the
appropriate mapping function of the updated and the inferred fields. appropriate mapping function of the updated and inferred fields.
An updating packet thus updates the reference values of all header An updating packet thus updates the reference values of all header
fields, either explicitly or implicitly, except for the UO-1-ID fields, either explicitly or implicitly, except for the UO-1-ID
packet (see section 6.2 of this document). In UO-mode, all packets 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 are are updating packets, while in R-mode, all packets with a CRC are
updating packets. 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 RFC3095-5.7.3 states that the values provided in extensions RFC 3095-Section 5.7.3 states that the values provided in extensions
carried by a UO-1-ID packet do not update the context, except for SN, carried by a UO-1-ID packet do not update the context, except for SN,
TS, or IP-ID fields. However, section RFC3095-5.8.1 correctly states TS, or IP-ID fields. However, RFC 3095-Section 5.8.1 correctly
that the translation table in the context is updated whenever an states that the translation table in the context is updated whenever
(Index, item) pair is received, something that is contradicted by the an (Index, item) pair is received, something that is contradicted by
statement in RFC3095-5.7.3 because the UO-1-ID packet can carry the statement in RFC 3095-5.7.3 because the UO-1-ID packet can carry
extension 3 with (Index, item) pair items within the 'Compressed CSRC Extension 3 with (Index, item) pair items within the 'Compressed CSRC
list' field. In addition to this contradiction, the text does not list' field. In addition to this contradiction, the text does not
mention what to do with the other sequence numbers inferred from the mention what to do with the other sequence numbers inferred from the
SN, which are also to be implicitly updated. The updating properties SN, which are also to be implicitly updated. The updating properties
of UO-1* as stated by section RFC3095-5.7.3 are thus incomplete. of UO-1* as stated by RFC 3095-Section 5.7.3 are thus incomplete.
INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7.3): INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.3):
"Values provided in extensions, except those in other SN, TS, "Values provided in extensions, except those in other SN, TS, or
or IP-ID fields, do not update the context." 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
numbers of IP extension headers. Other values of IP extension headers. Other values provided in extensions do
provided in extensions do not update the context. 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 RFC3095-5.8.1, (Index, item) pair is received, as per RFC 3095-Section 5.8.1,
and this 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
invalidated by the decompressor when it assumes context damage. be 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 RFC3095-5.7.5 defines the properties of RTP header flags and RFC 3095-Section 5.7.5 defines the properties of RTP header flags and
fields in extension 3. These get updated when the rtp flag of the fields in Extension 3. These get updated when the rtp flag of the
extension 3 is set, i.e. when rtp = 1, otherwise they are not Extension 3 is set, i.e., when rtp = 1; otherwise, they are not
updated. However, it is unclear how extension 3 updates the R-P bit updated. However, it is unclear how Extension 3 updates the R-P bit
in the context. in the context.
INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7.5): INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 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 RFC3095-5.7.7.6 defines the properties of the RTP header RFC 3095-Section 5.7.7.6 defines the properties of the RTP header
flags and fields in the RTP part of the dynamic chain of IR and IR- flags and fields in the RTP part of the dynamic chain of IR and IR-
DYN packets. However, it is unclear how the X bit is updated in the DYN packets. However, it is unclear how the X bit is updated in the
context. context.
INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7.7.6): INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 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 Reuse
7.1. Persistence of decompressor contexts 7.1. Persistence of Decompressor Contexts
As part of the negotiated channel parameters, compressor and As part of the negotiated channel parameters, compressor and
decompressor have through the MAX_CID parameter agreed on the highest decompressor have, through the MAX_CID parameter, agreed on the
context identification (CID) number to be used. By agreeing on highest context identification (CID) number to be used. By agreeing
MAX_CID, the decompressor also agrees to provide memory resources to on MAX_CID, the decompressor also agrees to provide memory resources
host at least MAX_CID+1 contexts, and an established context with a to host at least MAX_CID+1 contexts, and an established context with
CID within this negotiated space MUST be kept by the decompressor a CID within this negotiated space MUST be kept by the decompressor
until either the CID gets re-used, or the channel is taken down or until either the CID gets reused, or the channel is taken down or
re-negotiated. renegotiated.
7.2. CID/context re-use 7.2. CID/Context Reuse
As part of the channel negotiation, the maximal number of active As part of the channel negotiation, the maximal number of active
contexts supported is negotiated between the compressor and the contexts supported is negotiated between the compressor and the
decompressor through the MAX_CID parameter. The value of MAX_CID can decompressor through the MAX_CID parameter. The value of MAX_CID can
differ significantly from one link application to another, as well as differ significantly from one link application to another, as well as
the load in terms of the number of packet streams to compress. The the load in terms of the number of packet streams to compress. The
lifetime of a ROHC channel can also vary, from almost permanent to lifetime of a ROHC channel can also vary, from almost permanent to
rather short-lived. However, in general it is not expected that rather short-lived. However, in general, it is not expected that
resources will be allocated for more contexts than what can resources will be allocated for more contexts than what can
reasonably be expected to be active concurrently over the link. As a reasonably be expected to be active concurrently over the link. As a
consequence hereof, context identifiers (CIDs) and context memory are consequence hereof, context identifiers (CIDs) and context memory are
resources that will have to be re-used by the compressor as part of resources that will have to be reused by the compressor as part of
what can be considered normal operation. what can be considered normal operation.
How context resources are re-used is left unspecified in RFC 3095 [1] How context resources are reused is left unspecified in RFC 3095 [1]
and subsequent 3095-based ROHC specifications. This document does not and subsequent 3095-based ROHC specifications. This document does
intends to change that, i.e. ROHC resource management is still not intend to change that, i.e., ROHC resource management is still
considered an implementation detail. However, re-using a CID and its considered an implementation detail. However, reusing a CID and its
allocated memory is not always as simple as initiating a context with allocated memory is not always as simple as initiating a context with
a previously unused CID. Because some profiles can be operating in a previously unused CID. Because some profiles can be operating in
various modes where packet formats vary depending on current mode, various modes where packet formats vary depending on current mode,
care has to be taken to ensure that the old context data will be care has to be taken to ensure that the old context data will be
completely and safely overwritten, eliminating the risk of undesired completely and safely overwritten, eliminating the risk of undesired
side effects from interactions between old and new context data. This side effects from interactions between old and new context data.
document therefore points out some important core aspects to consider This document therefore points out some important core aspects to
when implementing resource management in ROHC compressors and consider when implementing resource management in ROHC compressors
decompressors. and decompressors.
On a high level, CID/context re-use can be of two kinds, either re- On a high level, CID/context reuse can be of two kinds, either reuse
use for a new context based on the same profile as the old context, for a new context based on the same profile as the old context, or
or for a new context based on a different profile. These cases, are 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 sub-sections.
7.2.1. Re-using a CID/context with the same profile 7.2.1. Reusing 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 RFC3095-5.6. When a CID/context is procedure, as defined in RFC 3095-Section 5.6. When a CID/context is
re-used for a new context based on the same profile as the old reused for a new context based on the same profile as the old
context, the current mode of operation SHOULD be inherited from the context, the current mode of operation SHOULD be inherited from the
old to the new context. Specifically, the compressor SHOULD continue old to the new context. Specifically, the compressor SHOULD continue
to operate using the mode of operation of the old context also with to operate using the mode of operation of the old context also with
the new context. The reason for this is that there is no reliable way the new context. The reason for this is that there is no reliable
for the compressor to inform the decompressor that a CID/context re- way for the compressor to inform the decompressor that a CID/context
use is happening. The decompressor can thus not be expected to clear reuse is happening. The decompressor can thus not be expected to
the context memory for the CID (see section 6.3), and there is no way clear the context memory for the CID (see Section 6.3), and there is
to trigger a safe mode switching (which requires the decompressor- no way to trigger a safe mode switching (which requires the
initiated handshake procedure). decompressor-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 RFC3095-6.3.1) is used to CONTEXT_REINITIALIZATION signal (RFC 3095-Section 6.3.1) is used to
reinitiate an entire context. reinitiate an entire context.
7.2.2. Re-using a CID/context with a different profile 7.2.2. Reusing 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 reused 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 section RFC3095-5.11.1). 0x0001 -> profile 0x0002 downgrade in RFC 3095-Section 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 reused 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 reused for a new context based on a different profile than the
the old context. A compressor doing otherwise should minimize the old context. A compressor doing otherwise should minimize the risk
risk for misinterpretation of R-0/R-1 by e.g. not using packets of for misinterpretation of R-0/R-1 by, e.g., not using packets of types
types beginning with 00 or 10 before it is highly confident that the beginning with 00 or 10 before it is highly confident that the new
new context has successfully been initiated at the decompressor. 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 RFC3095-5.7.7.4), if the 'NBO' bit is In IPv4 dynamic part (RFC 3095-Section 5.7.7.4), if the 'NBO' bit is
set, it 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 RFC3095-5.7, IP-ID means the compressed value of According to RFC 3095-Section 5.7, IP-ID means the compressed value
the IPv4 header's 'Identification' field. Compressed packets contain of the IPv4 header's 'Identification' field. Compressed packets
this compressed value (IP-ID), while IR packets with dynamic chain contain this compressed value (IP-ID), while IR packets with dynamic
and IR-DYN packets transmit the original, uncompressed Identification chain and IR-DYN packets transmit the original, uncompressed
field value. The IP-ID field always represents the Identification Identification field value. The IP-ID field always represents the
value of the innermost IPv4 header whose corresponding RND flag is Identification value of the innermost IPv4 header whose corresponding
not 1. 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 RFC3095-5.7). When there is no compressed IP-ID, beginning of RFC 3095-Section 5.7). When there is no compressed IP-
i.e. for IPv6 or when all IP Identification information is sent as-is ID, i.e., for IPv6 or when all IP Identification information is sent
(as indicated by RND/RND2 being set to 1), the decompressor ignores as is (as indicated by RND/RND2 being set to 1), the decompressor
IP-ID bits sent within compressed base headers. ignores 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
ID is sent in extension 3. IP-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, if
if no bits are sent for IP-ID, its SN offset slope defaults to 0. no bits are sent for IP-ID, its SN offset slope defaults to 0.
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
when a flag changes in Extension-3, a decompressor MUST re-parse the cases, when a flag changes in Extension 3, a decompressor MUST re-
UOR-2* packet. parse the 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 RFC3095- The RTP header part of Extension 3, as defined by RFC 3095-Section
5.7.5, includes a one-bit field for the RTP Marker bit. This field is 5.7.5, includes a one-bit field for the RTP Marker bit. This field
also present in all compressed base header formats except for UO-1- is also present in all compressed base header formats except for UO-
ID, meaning there may be two occurrences of the field within one 1-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 [12] The length of the sequence number field in the original ESP [12]
header is 32 bits. The format of the SN feedback option (section header is 32 bits. The format of the SN feedback option (RFC 3095-
RFC3095-5.7.6.6) allows for 8 additional SN bits to the 12 SN bits of Section 5.7.6.6) allows for 8 additional SN bits to the 12 SN bits of
the FEEDBACK-2 format (section RFC3095-5.7.6.1). One single SN the FEEDBACK-2 format (RFC 3095-Section 5.7.6.1). One single SN
feedback option is thus not enough for the decompressor to send back feedback option is thus not enough for the decompressor to send back
all the 32 bits of the ESP sequence number in a feedback packet, all the 32 bits of the ESP sequence number in a feedback packet,
unless it uses multiple SN options in one feedback packet. Section unless it uses multiple SN options in one feedback packet.
RFC3095-5.7.6.1 declares that a FEEDABCK-2 packet can contain
variable number of feedback options and the options can appear in any RFC 3095-Section 5.7.6.1 declares that a FEEDBACK-2 packet can
order. contain a 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
compressor MUST otherwise discard the feedback packet. compressor MUST otherwise discard the feedback packet.
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 an 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 the possibility of misinterpreting the type of the compressed header
type identifier gets misinterpreted when restarting the flow in U- for the packet type identifiers that are common to both U/O-mode and
mode (see also section 7.2). R-mode, when the flow is restarted in U-mode (see also Section 7.2).
Generally, feedback links are not expected to disappear when once Generally, feedback links are not expected to disappear once present,
present, but it should be noted that this might be the case for but it should be noted that this might be the case for certain link
certain link technologies. 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 or not there are IP headers with a
RND=1 or not. This also applies to the IP profile [4] and the IP/UDP- corresponding RND=1. This also applies to the IP profile [4] and the
Lite profile [5]. IP/UDP-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 RFC3095-5.8.5, formats are defined for compression of IP In RFC 3095-Section 5.8.5, formats are defined for compression of IP
extension header fields. These include compressed sequence number extension header fields. These include compressed sequence number
fields, and these fields contain "LSB of sequence number". These fields, and these fields contain the "LSB of sequence number". These
sequence numbers are not "LSB-encoded" as e.g. the RTP sequence sequence numbers are not "LSB-encoded" as, e.g., the RTP sequence
number, but are the 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 RFC3095- Usage of UOR-2 ACKs in O-mode, as discussed in RFC 3095-Section
5.4.1.1.2, is optional. A decompressor can also send ACKs for 5.4.1.1.2, is optional. A decompressor can also send ACKs for
purposes other than to acknowledge the UOR-2, without having to purposes other than to acknowledge the UOR-2, without having to
continue sending ACKs for all UOR-2. Similarly, a compressor continue sending ACKs for all UOR-2. Similarly, a compressor
implementation can ignore UOR-2 ACKs for the purpose of adapting the implementation can ignore UOR-2s ACKs for the purpose of adapting the
optimistic approach strategies. optimistic approach strategies.
It is thus NOT RECOMMENDED to use of the optional ACK mechanism in It is thus NOT RECOMMENDED to use the optional ACK mechanism in O-
O-mode, neither in compressor nor in decompressor implementations. mode, either in compressor or 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
transition. If an implementation does use the optional acknowledgment mode transition. If an implementation does use the optional
algorithm described in Section 5.4.1.1.2, it must make sure to set acknowledgment algorithm described in Section 5.4.1.1.2, it must make
the k_3 and n_3 parameters to much larger values than one to ensure sure to set the k_3 and n_3 parameters to much larger values than 1
that the compressor performance is not degraded due to the problem to ensure that the compressor performance is not degraded due to the
described above. problem described above.
8.11. Context repairs, TS_STRIDE and TIME_STRIDE 8.11. Context Repairs, TS_STRIDE and TIME_STRIDE
The 7-bit CRC used to verify the outcome of the decompression attempt The 7-bit CRC used to verify the outcome of the decompression attempt
covers the original uncompressed header. The CRC verification thus covers the original uncompressed header. The CRC verification thus
excludes TS_STRIDE and TIME_STRIDE, as these fields are not part of excludes TS_STRIDE and TIME_STRIDE, as these fields are not part of
the original uncompressed header. the original uncompressed header.
The UOR-2 packet type can be used to update the value of the 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, 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 these fields are not used for decompression of the RTP TS field for
this packet type and their respective value is thus not verified, this packet type and their respective value is thus not verified,
either implicitly or explicitly. either implicitly or explicitly.
When the compressor receives a negative acknowledgement, it can thus When the compressor receives a negative acknowledgement, it thus
not determine if the failure may be caused by an unsuccessful update cannot determine whether the failure may be caused by an unsuccessful
to the TS_STRIDE and/or the TIME_STRIDE field(s), for which a 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 previous header that last attempted to update their value had
previously been acknowledged. previously been acknowledged.
FORMAL ADDITION TO RFC 3095: FORMAL ADDITION TO RFC 3095:
"When the compressor receives a NACK and uses the UOR-2 header "When the compressor receives a NACK and uses the UOR-2 header
type to repair the decompressor context, it SHOULD include fields type to repair the decompressor context, it SHOULD include fields
that update the value of both the TS_STRIDE and the TIME_STRIDE that update the value of 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
current profile. its 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
current profile." its current profile."
9. ROHC negotiation 9. ROHC Negotiation
Section RFC3095-4.1 states that the link layer must provide means to RFC 3095-Section 4.1 states that the link layer must provide means to
negotiate e.g. the channel parameters listed in section RFC3095- negotiate, e.g., the channel parameters listed in RFC 3095-Section
5.1.1. One of these parameters is the PROFILES parameter, which is a 5.1.1. One of these parameters is the PROFILES parameter, which is a
set of non-negative integers where each integer indicates a profile set of non-negative integers where each integer indicates a profile
supported by 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 RFC3095-8). In the ROHC headers sent of that profile (see RFC 3095-Section 8). In the ROHC headers sent
over the link, the profile used is identified only with the 8 LSB over the link, the profile used is identified only with the 8 LSB
bits, which means that the compressor and decompressor must have bits, which means that the compressor and decompressor must have
agreed on which 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. When
when multiple variants of the same profile are available, also multiple variants of the same profile are available, the negotiation
provide means for the decompressor to know which variant will be used protocol must provide the means for the decompressor to know which
by the compressor. This basically means that the PROFILES set after variant will be used by the compressor. This basically means that
negotiation MUST NOT include more than one variant of a profile. the PROFILES set after negotiation MUST NOT include more than one
variant of a profile.
10. PROFILES suboption in ROHC-over-PPP 10. PROFILES Sub-option in ROHC-over-PPP
The logical union of suboptions for IPCP and IPV6CP negotiations, as The logical union of sub-options for IPCP and IPV6CP negotiations, as
specified by ROHC over PPP [2], can not be used for the PROFILES specified by ROHC over PPP [2], can not be used for the PROFILES
suboption, as the whole union would then have to be considered within suboption, as the whole union would then have to be considered within
each of the two IPCP negotiations, to avoid getting an ambiguous each of the two IPCP negotiations to avoid getting an ambiguous
profile set. An implementation of RFC 3241 MUST therefore ensure the profile set. An implementation of RFC 3241 MUST therefore ensure
same profile set is negotiated for both IPv4 and IPv6 (IPCP/IPV6CP). that the same profile set is negotiated for both IPv4 and IPv6
(IPCP/IPV6CP).
11. Constant IP-ID encoding in IP-only and UPD-Lite profiles 11. Constant IP-ID Encoding in IP-only and UPD-Lite Profiles
In the ROHC IP-only profile, section 3.3 of RFC 3843 [4], a mechanism In the ROHC IP-only profile, Section 3.3 of RFC 3843 [4], a mechanism
for encoding of a constant Identification value in IPv4 (constant IP- for encoding of a constant Identification value in IPv4 (constant
ID) is defined. This mechanism is also used by the ROHC UDP-Lite IP-ID) is defined. This mechanism is also used by the ROHC UDP-Lite
profiles, RFC 4019 [5]. profiles, RFC 4019 [5].
The "Constant IP-ID" mechanism applies to both the inner and the The "Constant IP-ID" mechanism applies to both the inner and outer IP
outer IP header, when present, meaning that there will be both a SID header, when present, meaning that there will be both a SID and a
and a SID2 context value. SID2 context value.
12. Security considerations 12. Security Considerations
This document provides a number of corrections and clarifications to This document provides a number of corrections and clarifications to
[1], but it does not make any changes with regards to the security [1], but it does not make any changes with regard to the security
aspects of the protocol. As a consequence, the security aspects of the protocol. As a consequence, the security
considerations of [1] apply without additions. considerations of [1] apply without additions.
13. IANA considerations 13. Acknowledgments
This document does not require any IANA actions.
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, Remi Pelland, Lajos Zaccomer, Endre Szalai, Lundemo, Alan Kennington, Remi Pelland, Lajos Zaccomer, Endre Szalai,
Mark Kalmanczhelyi, and Arpad Szakacs for their contributions and 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 14. References
15.1. Normative References 14.1. Normative References
[1] C. Bormann, et al., "RObust Header Compression (ROHC): Framework [1] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
and four profiles: RTP, UDP, ESP, and uncompressed", Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu,
Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001. RFC 3095, July 2001.
[2] C. Bormann, "Robust Header Compression (ROHC) over PPP", [2] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC
RFC 3241, April 2002. 3241, April 2002.
[3] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994. [3] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July
1994.
[4] L-E. Jonsson & G. Pelletier, "RObust Header Compression (ROHC): [4] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
A Compression Profile for IP", RFC 3843, June 2004. (ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[5] G. Pelletier, "RObust Header Compression (ROHC): Profiles for [5] Pelletier, G., "RObust Header Compression (ROHC): Profiles for
User Datagram Protocol (UDP) Lite", RFC 4019, April 2005. User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
[6] S. Bradner, "Key words for use in RFCs to Indicate Requirement [6] Bradner, S., "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 14.2. Informative References
[7] L-E. Jonsson, G. Pelletier & K. Sandlund, "RObust Header [7] Jonsson, L-E., Pelletier, G., and 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, January 2006.
[8] J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981. [8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[9] S. Deering & R. Hinden, "Internet Protocol, Version 6 (IPv6) [9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[10] J. Postel, "User Datagram Protocol", STD 6, RFC 768, August [10] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980. 1980.
[11] H. Schulzrinne, S. Casner, R. Frederick & V. Jacobson, "RTP: A [11] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
Transport Protocol for Real-Time Applications", RFC 1889, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
January 1996. RFC 3550, July 2003.
[12] S. Kent & R. Atkinson, "IP Encapsulating Security Payload", RFC [12] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
2406, November 1998. December 2005.
[13] R. Glenn & S. Kent, "The NULL Encryption Algorithm and Its Use [13] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
With IPsec", RFC 2410, November 1998. Use With IPsec", RFC 2410, November 1998.
[14] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, [14] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
November 1998.
[15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, [15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996. October 1996.
[16] D. Farinacci, T. Li, S. Hanks, D. Meyer & P. Traina, "Generic [16] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
Routing Encapsulation (GRE)", RFC 2784, March 2000. "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
Lars-Erik Jonsson
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61
EMail: lars-erik.jonsson@ericsson.com
Kristofer Sandlund
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 41 58
EMail: kristofer.sandlund@ericsson.com
Ghyslain Pelletier
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 43
EMail: ghyslain.pelletier@ericsson.com
Peter Kremer [17] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC
Conformance and Software Test Laboratory 2890, September 2000.
Ericsson Hungary
H-1300 Bp. 3., P.O. Box 107, HUNGARY
Phone: +36 1 437 7033
EMail: peter.kremer@ericsson.com
Appendix A - Sample CRC algorithm Appendix A. Sample CRC Algorithm
#!/usr/bin/perl -w #!/usr/bin/perl -w
use strict; use strict;
#================================= #=================================
# #
# ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02 # ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
# #
# This little demo shows the four types of CRC in use in RFC 3095, # This little demo shows the four types of CRCs in use in RFC 3095,
# the specification for robust header compression. Type your data in # the specification for robust header compression. Type your data in
# hexadecimal form and then press Control+D. # hexadecimal form and then press Control+D.
# #
#--------------------------------- #---------------------------------
# #
# utility # utility
# #
sub dump_bytes($) { sub dump_bytes($) {
my $x = shift; my $x = shift;
my $i; my $i;
skipping to change at page 29, line 19 skipping to change at page 31, line 21
# #
$/ = undef; $/ = undef;
$_ = <>; # read until EOF $_ = <>; # read until EOF
my $string = ""; # extract all that looks hex: my $string = ""; # extract all that looks hex:
s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg; s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
dump_bytes($string); dump_bytes($string);
#--------------------------------- #---------------------------------
# #
# 32-bit segmentation CRC # 32-bit segmentation CRC
# Note that the text implies this is complemented like for PPP # Note that the text implies that this is complemented like for PPP
# (this differs from 8, 7, and 3-bit CRC) # (this differs from 8-, 7-, and 3-bit CRCs)
# #
# C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + # C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
# x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32 # x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
# #
do_crc(32, 0xedb88320, $string); do_crc(32, 0xedb88320, $string);
#--------------------------------- #---------------------------------
# #
# 8-bit IR/IR-DYN CRC # 8-bit IR/IR-DYN CRC
# #
skipping to change at page 30, line 5 skipping to change at page 32, line 5
do_crc(7, 0x79, $string); do_crc(7, 0x79, $string);
#--------------------------------- #---------------------------------
# #
# 3-bit FO/SO CRC # 3-bit FO/SO CRC
# #
# C(x) = x^0 + x^1 + x^3 # C(x) = x^0 + x^1 + x^3
# #
do_crc(3, 0x6, $string); do_crc(3, 0x6, $string);
Intellectual Property Statement Authors' Addresses
Lars-Erik Jonsson
Optand 737
SE-831 92 Ostersund, Sweden
Phone: +46 70 365 20 58
EMail: lars-erik@lejonsson.com
Kristofer Sandlund
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 41 58
EMail: kristofer.sandlund@ericsson.com
Ghyslain Pelletier
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 43
EMail: ghyslain.pelletier@ericsson.com
Peter Kremer
Conformance and Software Test Laboratory
Ericsson Hungary
H-1300 Bp. 3., P.O. Box 107, HUNGARY
Phone: +36 1 437 7033
EMail: peter.kremer@ericsson.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Disclaimer of Validity
This document and the information contained herein are provided on an Acknowledgement
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires May 6, 2007. Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 239 change blocks. 
588 lines changed or deleted 583 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/