Network Working Group L-E. Jonsson
Request for Comments: 4815 K. Sandlund
Updates: 3095, 3241, 3843, 4019, 4362 G. Pelletier
Category: Standards Track P. Kremer
February 2007
Network Working Group L-E. Jonsson
Request for Comments: 4815 K. Sandlund
Updates: 3095, 3241, 3843, 4019, 4362 G. Pelletier
Category: Standards Track P. Kremer
February 2007
RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095
稳健的收割台压缩（ROHC）：对RFC 3095的更正和澄清
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the 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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security Payload). Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UDP-Lite profiles) are also provided.
RFC 3095为IP（互联网协议）、UDP（用户数据报协议）、RTP（实时传输协议）和ESP（封装安全有效负载）定义了健壮的报头压缩（ROHC）框架和配置文件。规范的某些部分不清楚或包含可能导致误解的错误，这些误解可能会损害不同实现之间的互操作性。本文件提供了对RFC 3095的更正、补充和澄清；因此，本文件更新了RFC 3095。此外，还提供了与RFC 3241（ROHC over PPP）、RFC 3843（ROHC IP配置文件）和RFC 4109（ROHC UDP Lite配置文件）相关的其他澄清。
Table of Contents
目录
1. Introduction and Terminology ....................................3
2. CRC Calculation and Coverage ....................................4
2.1. CRC Calculation ............................................4
2.2. Padding Octet and CRC Calculations .........................4
2.3. CRC Coverage in CRC Feedback Options .......................5
2.4. CRC Coverage of the ESP NULL Header ........................5
3. Mode Transition .................................................5
3.1. Feedback During Mode Transition to U- and O-Mode ...........5
3.1.1. Mode Transition Procedures Allowing Sparse Feedback .6
3.1.2. Transition from Reliable to Optimistic Mode .........7
3.1.3. Transition to Unidirectional Mode ...................8
3.2. Feedback During Mode Transition ............................8
3.3. Packet Decoding During Mode Transition .....................9
4. Timestamp Encoding ..............................................9
4.1. Encoding Used for Compressed TS Bits .......................9
4.2. (De)compression of TS without Transmitted TS Bits .........10
4.3. Interpretation Intervals for TS Encoding ..................11
4.4. Scaled RTP Timestamp Encoding .............................11
4.4.1. TS_STRIDE for Scaled Timestamp Encoding ............11
4.4.2. TS Wraparound with Scaled Timestamp Encoding .......12
4.4.3. Algorithm for Scaled Timestamp Encoding ............12
4.5. Recalculating TS_OFFSET ...................................14
4.6. TS_STRIDE and the Tsc Flag in Extension 3 .................14
4.7. Using Timer-Based Compression .............................15
5. List Compression ...............................................15
5.1. CSRC List Items in RTP Dynamic Chain ......................15
5.2. Multiple Occurrences of the CC Field ......................15
5.3. Bit Masks in List Compression .............................16
5.4. Headers Compressed with List Compression ..................16
5.5. ESP NULL Header List Compression ..........................17
5.6. Translation Tables and Indexes for IP Extension Headers ...17
5.7. Reference List ............................................17
5.8. Compression of AH and GRE Sequence Numbers ................18
6. Updating Properties ............................................19
6.1. Implicit Updates ..........................................19
6.2. Updating Properties of UO-1* ..............................20
6.3. Context Updating Properties for IR Packets ................20
6.4. RTP Padding Field (R-P) in Extension 3 ....................20
6.5. RTP eXtension bit (X) in dynamic part .....................21
7. Context management and CID/context Reuse .......................21
7.1. Persistence of Decompressor Contexts ......................21
7.2. CID/Context Reuse .........................................21
7.2.1. Reusing a CID/Context with the Same Profile ........22
7.2.2. Reusing a CID/Context with a Different Profile .....23
8. Other Protocol Clarifications ..................................23
8.1. Meaning of NBO ............................................23
1. Introduction and Terminology ....................................3
2. CRC Calculation and Coverage ....................................4
2.1. CRC Calculation ............................................4
2.2. Padding Octet and CRC Calculations .........................4
2.3. CRC Coverage in CRC Feedback Options .......................5
2.4. CRC Coverage of the ESP NULL Header ........................5
3. Mode Transition .................................................5
3.1. Feedback During Mode Transition to U- and O-Mode ...........5
3.1.1. Mode Transition Procedures Allowing Sparse Feedback .6
3.1.2. Transition from Reliable to Optimistic Mode .........7
3.1.3. Transition to Unidirectional Mode ...................8
3.2. Feedback During Mode Transition ............................8
3.3. Packet Decoding During Mode Transition .....................9
4. Timestamp Encoding ..............................................9
4.1. Encoding Used for Compressed TS Bits .......................9
4.2. (De)compression of TS without Transmitted TS Bits .........10
4.3. Interpretation Intervals for TS Encoding ..................11
4.4. Scaled RTP Timestamp Encoding .............................11
4.4.1. TS_STRIDE for Scaled Timestamp Encoding ............11
4.4.2. TS Wraparound with Scaled Timestamp Encoding .......12
4.4.3. Algorithm for Scaled Timestamp Encoding ............12
4.5. Recalculating TS_OFFSET ...................................14
4.6. TS_STRIDE and the Tsc Flag in Extension 3 .................14
4.7. Using Timer-Based Compression .............................15
5. List Compression ...............................................15
5.1. CSRC List Items in RTP Dynamic Chain ......................15
5.2. Multiple Occurrences of the CC Field ......................15
5.3. Bit Masks in List Compression .............................16
5.4. Headers Compressed with List Compression ..................16
5.5. ESP NULL Header List Compression ..........................17
5.6. Translation Tables and Indexes for IP Extension Headers ...17
5.7. Reference List ............................................17
5.8. Compression of AH and GRE Sequence Numbers ................18
6. Updating Properties ............................................19
6.1. Implicit Updates ..........................................19
6.2. Updating Properties of UO-1* ..............................20
6.3. Context Updating Properties for IR Packets ................20
6.4. RTP Padding Field (R-P) in Extension 3 ....................20
6.5. RTP eXtension bit (X) in dynamic part .....................21
7. Context management and CID/context Reuse .......................21
7.1. Persistence of Decompressor Contexts ......................21
7.2. CID/Context Reuse .........................................21
7.2.1. Reusing a CID/Context with the Same Profile ........22
7.2.2. Reusing a CID/Context with a Different Profile .....23
8. Other Protocol Clarifications ..................................23
8.1. Meaning of NBO ............................................23
8.2. IP-ID .....................................................23
8.3. Extension-3 in UOR-2* Packets .............................24
8.4. Multiple Occurrences of the M Bit .........................24
8.5. Multiple SN options in one feedback packet ................24
8.6. Multiple CRC Options in One Feedback Packet ...............25
8.7. Responding to Lost Feedback Links .........................25
8.8. UOR-2 in Profile 0x0002 (UDP) and Profile 0x0003 (ESP) ....25
8.9. Sequence Number LSB's in IP Extension Headers .............25
8.10. Expecting UOR-2 ACKs in O-Mode ...........................26
8.11. Context Repairs, TS_STRIDE and TIME_STRIDE ...............26
9. ROHC Negotiation ...............................................27
10. PROFILES Sub-option in ROHC-over-PPP ..........................27
11. Constant IP-ID Encoding in IP-only and UPD-Lite Profiles ......27
12. Security Considerations .......................................28
13. Acknowledgments ...............................................28
14. References ....................................................28
14.1. Normative References .....................................28
14.2. Informative References ...................................29
Appendix A. Sample CRC Algorithm ..................................30
8.2. IP-ID .....................................................23
8.3. Extension-3 in UOR-2* Packets .............................24
8.4. Multiple Occurrences of the M Bit .........................24
8.5. Multiple SN options in one feedback packet ................24
8.6. Multiple CRC Options in One Feedback Packet ...............25
8.7. Responding to Lost Feedback Links .........................25
8.8. UOR-2 in Profile 0x0002 (UDP) and Profile 0x0003 (ESP) ....25
8.9. Sequence Number LSB's in IP Extension Headers .............25
8.10. Expecting UOR-2 ACKs in O-Mode ...........................26
8.11. Context Repairs, TS_STRIDE and TIME_STRIDE ...............26
9. ROHC Negotiation ...............................................27
10. PROFILES Sub-option in ROHC-over-PPP ..........................27
11. Constant IP-ID Encoding in IP-only and UPD-Lite Profiles ......27
12. Security Considerations .......................................28
13. Acknowledgments ...............................................28
14. References ....................................................28
14.1. Normative References .....................................28
14.2. Informative References ...................................29
Appendix A. Sample CRC Algorithm ..................................30
RFC 3095 [1] defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol) [8][9], UDP (User Datagram Protocol) [10], RTP (Real-Time Transport Protocol) [11], and ESP (Encapsulating Security Payload) [12]. During implementation and interoperability testing of RFC 3095, some ambiguities and common misinterpretations have been identified, as well as a few errors.
RFC 3095[1]为IP（互联网协议）[8][9]、UDP（用户数据报协议）[10]、RTP（实时传输协议）[11]和ESP（封装安全有效载荷）[12]定义了健壮的报头压缩（ROHC）框架和配置文件。在RFC3095的实现和互操作性测试期间，发现了一些歧义和常见的误解，以及一些错误。
This document summarizes identified issues and provides corrections needed for implementations of RFC 3095 to interoperate, i.e., it constitutes an update to RFC 3095. This document also provides other clarifications related to common misinterpretations of the specification. References to RFC 3095 should, therefore, also include this document.
本文档总结了已识别的问题，并提供了RFC 3095实现互操作所需的更正，即它构成了对RFC 3095的更新。本文件还提供了与规范常见误解相关的其他澄清。因此，RFC 3095的参考文件也应包括本文件。
In addition, some clarifications and corrections are also provided 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 updated by this document. Furthermore, RFC 4362 (ROHC Link-Layer Assisted Profile) [7] is implicitly updated by this document, since RFC 4362 is also based on RFC 3095.
此外，还对RFC 3241（ROHC over PPP）[2]、RFC 3843（仅ROHC IP配置文件）[4]和RFC 4019（ROHC UDP Lite配置文件）[5]进行了一些澄清和更正，因此本文件也对其进行了更新。此外，由于RFC 4362也基于RFC 3095，因此RFC 4362（ROHC链路层辅助配置文件）[7]由本文档隐式更新。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[6]中所述进行解释。
When a section of this document makes formal corrections, additions or invalidations to text in RFC 3095, this is clearly summarized. The text from RFC 3095 that is being addressed is given and labeled "INCOMPLETE", "INCORRECT", or "INCORRECT AND INVALIDATED", followed by the correct text labeled "CORRECTED", where applicable. When text is added that does not simply correct text in previous specifications, it is given with the label "FORMAL ADDITION".
当本文件的某一部分对RFC 3095中的文本进行正式更正、添加或无效时，将对其进行明确总结。所述RFC 3095中的文本被给出并标记为“不完整”、“不正确”或“不正确且无效”，然后是标记为“更正”的正确文本（如适用）。当添加的文本不能简单地更正以前规范中的文本时，它会带有标签“正式添加”。
In this document, a reference to a section in RFC 3095 [1] is written as RFC 3095-Section <number>.
在本文档中，对RFC 3095[1]中某节的引用被写成RFC 3095节<number>。
RFC 3095-Section 5.9 defines polynomials for 3-, 7-, and 8-bit Cyclic Redundancy Checks (CRCs), but it does not specify what algorithm is used. The 3-, 7- and 8-bit CRCs are calculated using the CRC algorithm defined in [3].
RFC 3095第5.9节定义了3位、7位和8位循环冗余校验（CRC）的多项式，但未指定使用的算法。使用[3]中定义的CRC算法计算3、7和8位CRC。
A Perl implementation of the algorithm can be found in Appendix A of this document.
该算法的Perl实现可以在本文档的附录A中找到。
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 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 cover the Add-CID octet for CID 0, either.
RFC 3095第5.9.1节不完整，因为它没有提到如何在IR和IR-DYN数据包的CRC计算中处理填充八位组。填充并不意味着是数据包中有意义的部分，也不包括在CRC计算中。因此，CRC也不包括CID 0的Add CID八位字节。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.9.1):
RFC 3095文本不完整（RFC 3095第5.9.1节）：
"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 Add-CID octet."
“IR和IR-DYN数据包中的CRC是在整个IR或IR-DYN数据包上计算的，不包括有效载荷，包括CID或任何添加CID八位字节。”
CORRECTED TEXT:
更正文本：
"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 or any Add-CID octet, except for the add-CID octet for CID 0."
“IR和IR-DYN数据包中的CRC是在整个IR或IR-DYN数据包上计算的，不包括有效负载、填充和包括CID或任何添加CID八位字节，CID 0的添加CID八位字节除外。”
RFC 3095-Section 5.7.6.3 is incomplete, as it does not mention how the "size" field is handled when calculating the 8-bit CRC used in the CRC feedback option. Since the "size" field is an extension of the "code" field, it must be treated in the same way.
RFC 3095第5.7.6.3节不完整，因为它没有提到在计算CRC反馈选项中使用的8位CRC时如何处理“大小”字段。由于“大小”字段是“代码”字段的扩展，因此必须以相同的方式处理它。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.6.3):
RFC 3095文本不完整（RFC 3095第5.7.6.3节）：
"The CRC option contains an 8-bit CRC computed over the entire feedback payload, without the packet type and code octet, but including any CID fields, using the polynomial of section 5.9.1."
“CRC选项包含使用第5.9.1节的多项式在整个反馈有效负载上计算的8位CRC，不包括数据包类型和代码八位字节，但包括任何CID字段。”
CORRECTED TEXT:
更正文本：
"The CRC option contains an 8-bit CRC computed over the entire feedback payload including any CID fields but excluding the packet type, the 'Size' field and the 'Code' octet, using the polynomial of Section 5.9.1."
“CRC选项包含在整个反馈有效载荷上计算的8位CRC，包括任何CID字段，但不包括数据包类型、“大小”字段和“代码”八位字节，使用第5.9.1节的多项式。”
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 only the initial part of the header (i.e., Security Parameter Index (SPI) and sequence number), and not the trailer part at the end of the payload. Therefore, the ESP NULL header has the same CRC coverage as the ESP header used in the ESP profile (RFC 3095-Section 5.7.7.7).
RFC 3095第5.8.7节将ESP NULL[13]报头的CRC覆盖率规定为“整个ESP报头”。这必须解释为仅包括报头的初始部分（即安全参数索引（SPI）和序列号），而不包括有效负载末端的拖车部分。因此，ESP NULL报头与ESP配置文件中使用的ESP报头具有相同的CRC覆盖范围（RFC 3095第5.7.7.7节）。
RFC 3095-Section 5.6.1 states that during mode transitions, while the D_TRANS parameter is I, the decompressor sends feedback for each received packet. This restrictive behavior prevents the decompressor from using a sparse feedback algorithm during mode transitions.
RFC 3095第5.6.1节规定，在模式转换期间，当D_TRANS参数为I时，解压器为每个接收到的数据包发送反馈。这种限制性行为防止解压器在模式转换期间使用稀疏反馈算法。
To reduce transmission overhead and computational complexity (including CRC calculation) associated with feedback packets sent for each decompressed packet during mode transition, a decompressor MAY be implemented with slightly modified mode transition procedures compared to those defined in [1], as described in this section.
为了减少与在模式转换期间为每个解压缩分组发送的反馈分组相关联的传输开销和计算复杂性（包括CRC计算），可以使用与[1]中定义的那些相比稍微修改的模式转换过程来实现解压缩器，如本节所述。
These enhanced procedures should be considered only as a possible improvement to a decompressor implementation, since interoperability is not affected in any way. A decompressor implemented according to
由于互操作性不会受到任何影响，因此这些增强的过程只应被视为对解压缩器实现的可能改进。一种根据
the optimized procedures will interoperate with an RFC 3095 compressor, as well as a decompressor implemented according to the procedures described in RFC 3095.
优化程序将与RFC 3095压缩机以及根据RFC 3095中所述程序实施的减压器互操作。
The purpose of these enhanced transition procedures is to allow the decompressor to sparsely send feedback for packets decompressed during the second half of the transition procedure, i.e., after an appropriate IR/IR-DYN/UOR-2 packet has been received from the compressor. This is achieved by allowing the decompressor transition 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.
这些增强的转换过程的目的是允许解压器稀疏地发送在转换过程的后半部分期间解压的分组的反馈，即，在从压缩器接收到适当的IR/IR-DYN/UOR-2分组之后。如下面第3.1.2节和第3.1.3节的转换图所示，这是通过允许在该阶段将减压器转换参数（D_TRANS）设置为P（待定）来实现的。
This enhanced transition, where feedback need not be sent for every decompressed packet, does however introduce some considerations in case feedback messages would be lost. Specifically, there is a risk for a deadlock situation when a transition from R-mode is performed; if no feedback message successfully reaches the compressor, the transition is never completed. For transition between U-mode and O-mode, there is also a small risk for reduced compression efficiency.
这种增强的转换，不需要为每个解压缩的数据包发送反馈，但是在反馈消息丢失的情况下引入了一些注意事项。具体地说，当执行从R模式的转换时，存在死锁情况的风险；如果没有反馈消息成功到达压缩器，则转换永远不会完成。对于U模式和O模式之间的转换，压缩效率降低的风险也很小。
To avoid this, the decompressor MUST continue to send feedback at least periodically, as well as when in a Pending transition state. This is equivalent to enhancing the definition of the D_TRANS parameter in RFC 3095-Section 5.6.1, to include the definition of a Pending state:
为了避免这种情况，解压器必须至少定期地以及在挂起的转换状态下继续发送反馈。这相当于增强RFC 3095第5.6.1节中D_TRANS参数的定义，以包括未决状态的定义：
- D_TRANS: 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 transition can be initiated only when D_TRANS is D. While D_TRANS is I, the decompressor sends a NACK or ACK carrying a CRC option for each packet received. When D_TRANS is set to P, the decompressor does not have to send a NACK or ACK for each packet received, but it MUST continue to send feedback with some periodicity, and all feedback packets sent MUST include the CRC option. This ensures that all mode transitions will be completed also in case of feedback losses.
- D_TRANS：D_TRANS参数的可能值为（I）initiated，（P）ENDING和（D）ONE。D_TRANS必须初始化为D，并且只有当D_TRANS为D时才能启动模式转换。当D_TRANS为I时，解压器发送一个NACK或ACK，其中包含接收到的每个数据包的CRC选项。当D_TRANS设置为P时，解压缩器不必为接收到的每个数据包发送NACK或ACK，但它必须以一定的周期性继续发送反馈，并且发送的所有反馈数据包必须包括CRC选项。这确保了在反馈丢失的情况下，所有模式转换也将完成。
The modifications affect transitions to Optimistic and Unidirectional modes of operation (i.e., the transitions described in RFC 3095- Section 5.6.5 and RFC 3095-Section 5.6.6) and make those transition diagrams more consistent with the diagram describing the transition to R-mode.
修改会影响向乐观和单向运行模式的转换（即RFC 3095-第5.6.5节和RFC 3095-第5.6.6节中描述的转换），并使这些转换图与描述向R模式转换的图更加一致。
The enhanced procedure for transition from Reliable to Optimistic mode is shown below:
从可靠模式过渡到乐观模式的增强程序如下所示：
Compressor Decompressor
----------------------------------------------
| |
| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = O | |
|->->->-+ IR/IR-DYN/UOR-2(SN,O) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. | D_MODE = O
| ACK(SN,O) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
Compressor Decompressor
----------------------------------------------
| |
| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = O | |
|->->->-+ IR/IR-DYN/UOR-2(SN,O) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. | D_MODE = O
| ACK(SN,O) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
The enhanced procedure for transition to Unidirectional mode is shown on the following figure:
向单向模式过渡的增强程序如下图所示：
Compressor Decompressor
----------------------------------------------
| |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = U | |
|->->->-+ IR/IR-DYN/UOR-2(SN,U) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. |
| ACK(SN,U) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| | D_MODE= U
Compressor Decompressor
----------------------------------------------
| |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = U | |
|->->->-+ IR/IR-DYN/UOR-2(SN,U) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. |
| ACK(SN,U) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| | D_MODE= U
RFC 3095-Section 5.6.1 states that feedback is always used during mode transitions. However, the text then continues by making concrete applications of the rule in an inconsistent way, making it unclear when CRCs are used. Further, the text does not define how the compressor should act during mode transitions based on feedback not protected by CRCs, i.e., whether or not to carry out mode transition actions. The proper behavior from the compressor is to perform any action related to mode transitions only when the feedback is protected by the CRC option.
RFC 3095第5.6.1节规定，在模式转换期间始终使用反馈。然而，该文本接着以不一致的方式具体应用了该规则，使得何时使用CRC变得不明确。此外，本文未根据不受CRC保护的反馈定义压缩机在模式转换期间应如何动作，即是否执行模式转换动作。压缩机的正确行为是仅当反馈受CRC选项保护时，才执行与模式转换相关的任何操作。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.6.1):
RFC 3095文本不完整（RFC 3095第5.6.1节）：
"As a safeguard against residual errors, all feedback sent during a mode transition MUST be protected by a CRC, i.e., the CRC option MUST be used."
‘为防止残余错误，在模式转换期间发送的所有反馈必须由CRC保护，即必须使用CRC选项。’
CORRECTED TEXT:
更正文本：
"As a safeguard against residual errors, all feedback sent by the decompressor during a mode transition MUST be protected by a CRC, i.e., the CRC option MUST be used. The compressor MUST ignore
“为了防止残余错误，模式转换期间解压器发送的所有反馈必须受到CRC保护，即必须使用CRC选项。压缩机必须忽略
feedback information related to mode transition if the feedback is not protected by the CRC option."
如果反馈不受CRC选项保护，则与模式转换相关的反馈信息。”
One more related issue that requires clarifications comes from the following text at the end of RFC 3095-Section 5.6.1:
需要澄清的另一个相关问题来自RFC 3095第5.6.1节末尾的以下文本：
"While D_TRANS is I, the decompressor sends a NACK or ACK carrying a CRC option for each received packet."
“当D_TRANS为I时，解压器发送一个NACK或ACK，其中包含每个接收到的数据包的CRC选项。”
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, i.e., for packets that do not carry a CRC, such as R-0 and R-1*.
然而，RFC 3095第5.5.2.2节已经指出，对于R模式，对于不更新上下文的数据包，即对于不携带CRC的数据包，例如R-0和R-1*，从不发送反馈。
This means that when D_TRANS=I during mode transition, a decompressor operating in R-mode sends an acknowledgement for each packet it receives and MUST use the sequence number that corresponds to the 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.
这意味着，在模式转换期间，当D_TRANS=I时，在R模式下运行的解压缩器为其接收的每个分组发送确认，并且必须使用与上次更新上下文的分组相对应的序列号，即，解压缩器不得使用R-0或R-1*分组的序列号。
The purpose of a mode transition is to ensure that the compressor and the decompressor coherently move from one mode of operation to another using a three-way handshake. At one point during the mode 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 new mode. Packets of type 0 or type 1 that are received up to this point are decompressed using the old mode, while afterwards they are decompressed using the new mode. If the enhanced transition procedures described in Section 3.1 are used, the setting of the D_TRANS parameter to P represents this breakpoint. The successful decompression of a packet of type 0 or type 1 completes the mode transition.
模式转换的目的是确保压缩机和减压器通过三向握手从一种操作模式连贯地移动到另一种操作模式。在模式转换期间的一个点，解压缩器确认接收到一个（或多个）IR、IR-DYN或UOR-2分组，该分组的模式位设置为新模式。在此之前接收到的类型为0或类型为1的数据包使用旧模式进行解压缩，之后使用新模式进行解压缩。如果使用第3.1节中描述的增强转换程序，则将D_TRANS参数设置为P表示该断点。成功解压缩类型0或类型1的数据包将完成模式转换。
RTP Timestamp (TS) values are always encoded using W-LSB encoding, both when sent scaled and unscaled. When no TS bits are transmitted in a compressed packet, TS is always scaled. If a compressed packet carries an Extension 3 and field(Tsc)=0, the compressed packet must thus always carry unscaled TS bits. For TS values sent in Extension 3, W-LSB encoded values are sent using the self-describing variable-length format (RFC 3095-Section 4.5.6), and this applies to both scaled and unscaled values.
RTP时间戳（TS）值始终使用W-LSB编码进行编码，无论是按比例发送还是未按比例发送。当压缩包中没有传输TS比特时，TS总是按比例缩放。如果压缩包携带扩展名3和字段（Tsc）=0，则压缩包必须始终携带未标度的TS位。对于扩展3中发送的TS值，W-LSB编码值使用自描述变长格式（RFC 3095第4.5.6节）发送，这适用于缩放值和未缩放值。
When ROHC RTP operates using its most efficient packet types, apart from packet type identification and the error detection CRC, only RTP sequence number (SN) bits are transmitted in RTP compressed headers. All other fields are then omitted either because they are unchanged or because they can be reconstructed through a function from the SN (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 Identification (IP-ID) and the RTP Timestamp (TS).
当ROHC RTP使用其最有效的数据包类型运行时，除了数据包类型识别和错误检测CRC外，RTP压缩报头中仅传输RTP序列号（SN）位。然后省略所有其他字段，因为它们没有改变，或者因为它们可以通过来自SN的函数重建（即，通过将传输的SN比特与来自上下文的状态信息组合）。可以从SN推断的字段是IP标识（IP-ID）和RTP时间戳（TS）。
IP-ID compression and decompression, both with and without transmitted IP-ID bits in the compressed header, are well defined in 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 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 compressed header.
在RFC 3095第4.5.5节（见第8.2节）中明确定义了IP-ID压缩和解压缩，无论压缩头中有无传输的IP-ID位。然而，对于TS字段，RFC 3095仅定义如何基于压缩报头中的实际TS比特（缩放或未缩放）进行解压缩，而不定义如何在压缩报头中不存在TS比特时从SN推断TS。
When no TS bits are received in the compressed header, the scaled TS value is reconstructed assuming a linear extrapolation from the SN, i.e., delta_TS = delta_SN * default-slope, where delta_SN and delta_TS are both signed integers. RFC 3095-Section 5.7 defines the potential values for default-slope.
当在压缩的报头中没有接收到TS比特时，假定从SN进行线性外推，即，delta_TS＝delta_SN*默认斜率，其中delta_SN和delta_TS都是有符号整数，则重构缩放的TS值。RFC 3095第5.7节定义了默认坡度的潜在值。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7):
RFC 3095文本不完整（RFC 3095第5.7节）：
"If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before compression (see section 4.5.3), and default-slope(TS) = 1.
“如果值（Tsc）=1，则压缩前使用缩放RTP时间戳编码（见第4.5.3节），默认斜率（TS）=1。
If value(Tsc) = 0, the Timestamp value is compressed as-is, and
default-slope(TS) = value(TS_STRIDE)."
If value(Tsc) = 0, the Timestamp value is compressed as-is, and
default-slope(TS) = value(TS_STRIDE)."
CORRECTED TEXT:
更正文本：
"When a compressed header with no TS bits is received, the scaled TS value is reconstructed assuming a linear extrapolation from the SN, i.e., delta_TS = delta_SN * default-slope(TS).
“当接收到没有TS比特的压缩报头时，假定从SN进行线性外推，即delta_TS=delta_SN*默认斜率（TS），则重构缩放的TS值。
If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before compression (see Section 4.5.3), and default-slope(TS) = 1.
如果值（Tsc）=1，则压缩前使用缩放RTP时间戳编码（见第4.5.3节），默认斜率（TS）=1。
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 is received with Tsc = 0, the decompressor MUST discard the
packet."
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 is received with Tsc = 0, the decompressor MUST discard the
packet."
INCORRECT AND INVALIDATED RFC 3095 TEXT (Section RFC 3095-5.5.1.2):
RFC 3095文本不正确且无效（第RFC 3095-5.5.1.2节）：
"For example, in a typical case where the string pattern has the form of non-SN-field = SN * slope + offset, one ACK is enough if the slope has been previously established by the decompressor (i.e., only the new offset needs to be synchronized). Otherwise, two ACKs are required since the decompressor needs two headers to learn both the new slope and the new offset."
“例如，在字符串模式具有非SN字段=SN*斜率+偏移量形式的典型情况下，如果斜率先前已由解压器建立（即，仅需要同步新的偏移量），则一次确认就足够了。”。否则，需要两个ACK，因为解压器需要两个标头来了解新斜率和新偏移。”
Consequently, there is no other slope value than the default-slope, as defined in RFC 3095-Section 5.7.
因此，除了RFC 3095第5.7节中定义的默认坡度外，没有其他坡度值。
RFC 3095-Section 4.5.4 defines the interpretation interval, p, for timer-based compression of the RTP timestamp. However, RFC 3095- Section 5.7 defines a different interpretation interval, which is 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 compression.
RFC 3095第4.5.4节定义了基于计时器的RTP时间戳压缩的解释间隔p。但是，RFC 3095-第5.7节定义了不同的解释间隔，定义为所有TS值的解释间隔。因此，至少对于基于计时器的压缩，不清楚使用哪个p值。
The way this should be interpreted is that the p-value differs depending on whether or not timer-based compression is enabled.
对此的解释是，p值根据是否启用了基于计时器的压缩而有所不同。
For timer-based compression (TIME_STRIDE set to a non-zero value), the interpretation interval is:
对于基于计时器的压缩（时间步长设置为非零值），解释间隔为：
p = 2^(k-1) - 1 (as per RFC 3095-Section 4.5.4)
p = 2^(k-1) - 1 (as per RFC 3095-Section 4.5.4)
Otherwise, the interpretation interval is:
否则，解释间隔为：
p = 2^(k-2) - 1 (as per RFC 3095-Section 5.7)
p = 2^(k-2) - 1 (as per RFC 3095-Section 5.7)
This section redefines the algorithm for scaled RTP timestamp encoding, defined as a 5-step procedure in RFC 3095-Section 4.5.3. Two formal errors have been corrected, as described in sub-sections 4.4.1 and 4.4.2 below, and the whole algorithm has been reworked to be more concise and to use well-defined terminology. The resulting text can be found in 4.4.3 below.
本节重新定义了缩放RTP时间戳编码的算法，在RFC 3095第4.5.3节中定义为5步程序。如下文第4.4.1和4.4.2小节所述，已纠正了两个形式错误，并对整个算法进行了修改，使其更加简洁，并使用了定义良好的术语。结果文本见下文4.4.3。
RFC 3095 defines the timestamp stride (TS_STRIDE) as the expected increase in the timestamp value between two RTP packets with consecutive sequence numbers. TS_STRIDE is set by the compressor and
RFC 3095将时间戳步长（TS_步长）定义为具有连续序列号的两个RTP数据包之间时间戳值的预期增加。TS_步幅由压缩器和
explicitly communicated to the decompressor, and it is used as the scaling factor for scaled TS encoding.
显式地与解压缩器通信，并用作缩放TS编码的缩放因子。
The relation between TS and TS_SCALED, given by the following equality in RFC 3095-Section 4.5.3, defines the mathematical meaning of TS_STRIDE:
由RFC 3095第4.5.3节中的以下等式给出的TS和TS_标度之间的关系定义了TS_跨步的数学含义：
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 compression step following the above core equality. This formula is incorrect both because it excludes TS_OFFSET and because it would prevent a TS_STRIDE value of 0, which is an alternative not excluded by the definition or by the core equality above. If "/" were a generally unambiguously defined operation meaning "the integral part 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 TS_STRIDE equal to 0. The formula of "2. Compression" is thus valid only with the following requirements:
TS_SCALED未完全写入压缩步骤中的TS/TS_步长，遵循上述核心等式。此公式是不正确的，因为它排除了TS_偏移，并且会阻止TS_步长值为0，这是一个未被上述定义或核心等式排除的替代值。如果“/”是一个通常明确定义的运算，意思是“X除以Y的结果的整数部分”，则可以解释没有TS_偏移，但公式仍然缺少TS_步长等于0的正确输出。因此，“2.压缩”公式仅在满足以下要求时有效：
a) "/" means "the integral part of the result from dividing X by Y"
a) “/”表示“X除以Y所得结果的整数部分”
b) TS_STRIDE>0 (TS is never sent scaled when TS_STRIDE=0)
b) TS_步幅>0（当TS_步幅=0时，不会发送TS）
RFC 3095-Section 4.5.3 states in points 4 and 5 that the compressor 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 when there is a TS wraparound. The decompressor is also required to detect and cope with TS wraparound, including updating TS_OFFSET.
RFC 3095第4.5.3节在第4点和第5点中指出，不要求压缩器在环绕时初始化TS_偏移，但需要在TS环绕时增加为缩放TS值发送的位数。解压器还需要检测和处理TS环绕，包括更新TS_偏移量。
This method is not interoperable and not robust. The gain is also insignificant, as TS wraparound happens very seldomly. Therefore, the compressor should reinitialize TS_OFFSET upon TS wraparound, by sending an unscaled TS.
此方法不可互操作且不健壮。收益也是微不足道的，因为TS环绕很少发生。因此，压缩机应通过发送未标度的TS，在TS环绕时重新初始化TS_偏移。
INCORRECT RFC 3095 TEXT (RFC 3095-Section 4.5.3):
RFC 3095文本不正确（RFC 3095第4.5.3节）：
"1. Initialization: The compressor sends to the decompressor the value of TS_STRIDE and the absolute value of one or several TS fields. The latter are used by the decompressor to initialize TS_OFFSET to (absolute value) modulo TS_STRIDE. Note that TS_OFFSET is the same regardless of which absolute value is used, as long as the unscaled TS value does not wrap around; see 4) below.
“1.初始化：压缩器向解压器发送TS_步长值和一个或多个TS字段的绝对值。解压器使用后者将TS_偏移量初始化为（绝对值）模T_步长。请注意，只要未标度的T_值不环绕，无论使用哪一个绝对值，T_偏移量都是相同的；请参见下面的4）。
2. Compression: After initialization, the compressor no longer compresses the original TS values. Instead, it compresses the downscaled values: TS_SCALED = TS / TS_STRIDE. The compression method could be either W-LSB encoding or the timer-based encoding described in the next section.
2. 压缩：初始化后，压缩器不再压缩原始TS值。相反，它压缩缩小的值：TS_SCALED=TS/TS_STRIDE。压缩方法可以是W-LSB编码，也可以是下一节描述的基于定时器的编码。
3. Decompression: When receiving the compressed value of TS_SCALED, the decompressor first derives the value of the original TS_SCALED. The original RTP TS is then calculated as TS = TS_SCALED * TS_STRIDE + TS_OFFSET.
3. 解压缩：当接收到TS_缩放的压缩值时，解压缩器首先导出原始TS_缩放的值。然后将原始RTP TS计算为TS=TS_缩放*TS_步幅+TS_偏移。
4. Offset at wraparound: Wraparound of the unscaled 32-bit TS will invalidate the current value of TS_OFFSET used in the equation above. For example, let us assume TS_STRIDE = 160 = 0xA0 and the current TS = 0xFFFFFFF0. TS_OFFSET is then 0x50 = 80. Then if the next RTP TS = 0x00000130 (i.e., the increment is 160 * 2 = 320), the new TS_OFFSET should be 0x00000130 modulo 0xA0 = 0x90 = 144. The compressor is not required to re-initialize TS_OFFSET at wraparound. Instead, the decompressor MUST detect wraparound of the unscaled TS (which is trivial) and update TS_OFFSET to TS_OFFSET = (Wrapped around unscaled TS) modulo TS_STRIDE"
4. 环绕时的偏移量：未标度32位TS的环绕将使上述等式中使用的TS_偏移量的当前值无效。例如，假设TS_步长=160=0xA0，当前TS=0xFFFFF0。TS_偏移量为0x50=80。然后，如果下一个RTP TS=0x0000030（即，增量为160*2=320），则新的TS_偏移量应为0x0000030模0xA0=0x90=144。压缩机无需在环绕时重新初始化TS_偏移。相反，解压器必须检测未标度TS的环绕（这是微不足道的），并将TS_偏移量更新为TS_偏移量=（环绕未标度TS）模TS_”
CORRECTED TEXT:
更正文本：
"1. Initialization and updating of RTP TS scaling function: The compressor sends to the decompressor the value of TS_STRIDE along with an unscaled TS. These are both needed by the decompressor to initialize TS_OFFSET as hdr(TS) modulo field(TS_STRIDE). Note that TS_OFFSET is the same for any TS as long as TS_STRIDE does not change and as long as the unscaled TS value does not wrap around; see 4) below.
“1.RTP TS缩放功能的初始化和更新：压缩器向解压缩器发送TS_步长值以及未缩放的TS。解压缩器需要这两个值来将TS_偏移初始化为hdr（TS）模字段（TS_步长）。请注意，只要TS_步幅不变，并且只要未缩放的TS值没有环绕，则任何TS的TS_偏移都是相同的；请参见下面的4）。
2. Compression: After initialization, the compressor no longer compresses the unscaled TS values. Instead, it compresses the scaled values. The compression method can be either W-LSB encoding or timer-based encoding.
2. 压缩：初始化后，压缩器不再压缩未缩放的TS值。相反，它会压缩缩放值。压缩方法可以是W-LSB编码或基于定时器的编码。
3. Decompression: When receiving a (compressed) TS_SCALED, the field is first decompressed, and the unscaled RTP TS is then calculated as TS = TS_SCALED * TS_STRIDE + TS_OFFSET.
3. 解压缩：当接收到（压缩的）TS_缩放时，首先对字段进行解压缩，然后将未缩放的RTP TS计算为TS=TS_缩放*TS_步幅+TS_偏移。
4. Offset at wraparound: If the value of TS_STRIDE is not equal to a power of two, wraparound of the unscaled 32-bit TS will change the value of TS_OFFSET. When this happens, the compressor SHOULD reinitialize TS_OFFSET by sending unscaled TS, as in 1 above."
4. 环绕时的偏移量：如果TS_步长的值不等于2的幂，则未缩放32位TS的环绕将更改TS_偏移量的值。发生这种情况时，压缩器应通过发送未标度的TS重新初始化TS_偏移，如上文1所示。”
INCORRECT AND INVALIDATED RFC 3095 TEXT (RFC 3095-Section 4.5.3):
RFC 3095文本不正确且无效（RFC 3095第4.5.3节）：
The entire point 5, i.e. the entire text starting from "5. Interpretation interval at wraparound ...", down to and including 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 is thus invalid.
整个第5点，即从“5.概括时的解释间隔…”开始的整个文本，包括以“a为LSB数”开始并以“…解释间隔为b”结束的文本块是不正确的，因此无效。
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. To ensure correct decompression of subsequent packets, the decompressor MUST therefore always recalculate TS_OFFSET (RTP TS modulo TS_STRIDE) when a packet with an unscaled TS value is received.
如果TS值更改与已确定的TS_步幅不匹配，则TS可以不缩放发送，但TS_步幅可能仍保持不变。为了确保后续数据包的正确解压缩，因此，当接收到具有未标度TS值的数据包时，解压缩器必须始终重新计算TS_偏移量（RTP TS modulo TS_STRIDE）。
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, as well as if there are no TS bits in the extension itself. When TS is scaled, it is always scaled using context(TS_STRIDE). The legend for Extension 3 in RFC 3095-Section 5.7.5 incorrectly states that value(TS_STRIDE) is used for scaled TS.
扩展3中的Tsc标志指示TS是否缩放。因此，Tsc标志的值适用于所有TS位，以及如果扩展本身中没有TS位。缩放TS时，始终使用上下文（TS_步长）缩放TS。RFC 3095第5.7.5节中延伸段3的图例错误地说明了数值（TS_步长）用于缩放TS。
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., 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 TS_STRIDE is included in a compressed header with scaled TS, the decompressor must ignore and discard field(TS_STRIDE).
如果分机3中存在TS_步长，如设置的Tss标志所示，则压缩报头应携带未标度的TS位；i、 例如，设置Tss时不应设置Tsc标志，因为需要一个未标度的TS和TS_步幅来重新计算TS_偏移。如果TS_步长包含在带有缩放TS的压缩标头中，则解压缩程序必须忽略并放弃字段（TS_步长）。
INCORRECT RFC 3095 TEXT (RFC 3095-Section 5.7.5):
RFC 3095文本不正确（RFC 3095第5.7.5节）：
"Tsc: Tsc = 0 indicates that TS is not scaled;
Tsc = 1 indicates that TS is scaled according to section
4.5.3, using value(TS_STRIDE).
Context(Tsc) is always 1. If scaling is not desired, the
compressor will establish TS_STRIDE = 1."
"Tsc: Tsc = 0 indicates that TS is not scaled;
Tsc = 1 indicates that TS is scaled according to section
4.5.3, using value(TS_STRIDE).
Context(Tsc) is always 1. If scaling is not desired, the
compressor will establish TS_STRIDE = 1."
CORRECTED TEXT:
更正文本：
"Tsc: Tsc = 0 indicates that TS is not scaled; Tsc = 1 indicates that TS is scaled according to Section 4.5.3, using context(TS_STRIDE).
“Tsc:Tsc=0表示未缩放TS；Tsc=1表示根据第4.5.3节使用上下文（TS_）缩放TS。
Context(Tsc) is always 1. If scaling is not desired, the compressor will establish TS_STRIDE = 1.
上下文（Tsc）始终为1。如果不需要缩放，压缩机将建立TS_步长=1。
If field(Tsc) = 1, and if TSS = 1 (meaning that TS_STRIDE is present in the extension), field(TS_STRIDE) MUST be ignored and discarded."
如果字段（Tsc）=1，并且如果TSS=1（表示扩展中存在TS_步幅），则必须忽略并丢弃字段（TS_步幅）。”
When the compressor re-establishes a new value for TS_STRIDE using Extension 3, it should send unscaled TS bits together with TS_STRIDE.
当压缩器使用扩展名3为TS_步长重新建立新值时，它应将未标度的TS位与TS_步长一起发送。
Timer-based compression of the RTP timestamp, as described in RFC 3095-Section 4.5.4, may be used to reduce the number of transmitted timestamp bits (bytes) needed when the timestamp cannot be inferred from the SN. Timer-based compression is only used for decompression of compressed headers that contains a TS field; otherwise, when no timestamp bits are present, the timestamp is linearly inferred from the SN (see Section 4.2 of this document).
如RFC 3095第4.5.4节所述，RTP时间戳的基于定时器的压缩可用于减少无法从SN推断时间戳时所需的传输时间戳位（字节）的数量。基于计时器的压缩仅用于解压缩包含TS字段的压缩头；否则，当不存在时间戳位时，从SN线性推断时间戳（见本文件第4.2节）。
Whether or not to use timer-based compression is controlled by the TIME_STRIDE control field, which can be set by either an IR, an IR-DYN, or a compressed packet with Extension 3. Before timer-based compression can be used, the decompressor has to inform the compressor (on a per-channel basis) about its clock resolution by sending a CLOCK feedback option for any CID on the channel. The compressor can then initiate timer-based compression by sending (on a per-context basis) a non-zero TIME_STRIDE to the decompressor. When the compressor is confident that the decompressor has received the TIME_STRIDE value, it can switch to timer-based compression.
是否使用基于计时器的压缩由时间步长控制字段控制，该字段可由IR、IR-DYN或扩展名为3的压缩数据包设置。在使用基于计时器的压缩之前，解压缩器必须通过发送通道上任何CID的时钟反馈选项，将其时钟分辨率告知压缩器（基于每个通道）。然后，压缩器可以通过向解压缩器发送（基于每个上下文）非零时间步长来启动基于计时器的压缩。当压缩机确信解压器已收到时间步长值时，它可以切换到基于计时器的压缩。
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 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 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).
RFC 3095第5.7.7.6节定义了RTP收割台的静态和动态部分。本节指出动态链中的“通用CSC列表”字段，其长度可变（参见RFC 3095第5.8.6节）。即使列表为空，该字段的大小始终至少为一个八位字节（与未压缩RTP标头中的CSC列表相反，当RTP CC字段设置为0时，CSC列表不存在）。
The static and the dynamic parts of the RTP header are defined in RFC 3095-Section 5.7.7.6. In the dynamic part, a CC field indicates the number of CSRC items present in the 'Generic CSRC list'. Another CC field also appears within the 'Generic CSRC list' (RFC 3095-Section
RFC 3095第5.7.7.6节定义了RTP收割台的静态和动态部分。在动态部分，CC字段表示“通用CSC列表”中的CSC项目数量。“通用证监会名单”（RFC 3095部分）中也会出现另一个抄送字段
5.8.6.1), because Encoding Type 0 is always used in the dynamic chain. Both CC fields have the same meaning: the value of the CC field determines the number of XI items in the CSRC list for Encoding Type 0, and it is not used otherwise. Therefore, the following applies:
5.8.6.1），因为编码类型0总是在动态链中使用。CC字段都具有相同的含义：CC字段的值决定编码类型0的CSRC列表中的席项目数，否则不使用。因此，以下规定适用：
FORMAL ADDITION TO RFC 3095:
RFC 3095的正式增补：
"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 appears in the 'Generic CSRC list', which is also in the dynamic part of the RTP header, where Encoding Type 0 is used according to the format defined in RFC 3095-5.8.6.1.
“RTP报头动态部分的第一个八位字节包含CC字段，如第5.7.7.6节所定义。第二个出现在“通用CSC列表”中，该列表也出现在RTP报头的动态部分，其中编码类型0根据RFC 3095-5.8.6.1中定义的格式使用。
The compressor MUST set both occurrences of the CC field to the same value.
压缩器必须将CC字段的两个匹配项设置为相同的值。
The decompressor MUST use the value of the CC field from the Encoding Type 0 within the Generic CRSC list, and it MUST thus ignore the first occurrence of the CC field."
解压缩程序必须使用通用CRSC列表中编码类型0中CC字段的值，因此必须忽略CC字段的第一次出现。”
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 positions within the reference list. The size of the bit mask can be 7 bits or 15 bits.
RFC 3095第5.8.6.2-5.8.6.4节中描述的插入和/或移除方案使用位掩码指示参考列表中的插入或移除位置。位掩码的大小可以是7位或15位。
The compressor MAY use a 7-bit mask, even if the reference list has more than seven items, provided that changes to the list are only applied to items within the first seven items of the reference list, 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 7-bit mask, when a 7-bit mask is received for a reference list that contains more than seven items.
压缩器可以使用7位掩码，即使参考列表有七个以上的项，只要对列表的更改仅应用于参考列表前七个项中的项，保留7位掩码未涵盖索引的项不变。当收到包含七个以上项目的引用列表的七位掩码时，解压缩程序不得修改索引未包含在七位掩码中的项目。
In RFC 3095-Section 5.8, it states that headers that can be part of extension header chains "include" AH [14], ESP NULL [13], minimal encapsulation (MINE) [15], GRE [16][17], and IPv6 [9] extensions. 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 actually be handled. It should further be noted that for the Minimal Encapsulation (MINE) header, there is no explicit discussion of how to compress it, as the header is sent either uncompressed or fully compressed away.
在RFC 3095第5.8节中，它指出可以作为扩展头链一部分的头“包括”AH[14]、ESP NULL[13]、最小封装（MINE）[15]、GRE[16][17]和IPv6[9]扩展。这个可以压缩的头列表是正确的，但是单词“include”不应该在那里，因为实际上只能处理列出的头类型。应该进一步注意的是，对于最小封装（minimum-enclosuration，MINE）报头，没有明确讨论如何压缩它，因为报头是未压缩或完全压缩发送的。
Due to the offset of the fields in the trailer part of the ESP header, a compressor MUST NOT compress packets containing more than one NULL ESP [13] header, unless the second-outermost header is treated as a regular ESP [12] header and the packets are compressed using profile 0x0003.
由于ESP报头尾部字段的偏移，压缩器不得压缩包含多个空ESP[13]报头的数据包，除非第二个最外层的报头被视为常规ESP[12]报头，并且使用配置文件0x0003压缩数据包。
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. The text incorrectly states that one index per type is used, since the same type can appear several times with different content in one single chain.
RFC 3095第5.8.4节描述了列表索引如何与列表项相关联，以及如何为IP扩展头构建表列表。文本错误地指出，每种类型使用一个索引，因为同一类型可以在同一个链中多次出现不同的内容。
In IP extension header list compression, an index is associated with each individual extension header of an extension header chain. When there are multiple non-identical occurrences of the same extension type (Protocol Number) within a header chain, each MUST be given its own index.
在IP扩展头列表压缩中，索引与扩展头链的每个单独扩展头相关联。当报头链中存在多个相同扩展类型（协议号）的不相同事件时，必须为每个事件指定自己的索引。
In the case where there are multiple identical occurrences of the 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 the list is updated, the compressor MUST send the value for each occurrence of that index in the list.
在同一扩展类型存在多个相同引用的情况下，压缩器可以将它们关联到同一索引。当索引在列表中多次出现的项的值被更新时，压缩器必须发送该索引在列表中每次出现的值。
When content of extension headers changes, an implementation can choose to either use a different index or update the existing one. Some extensions can be compressed away even when some fields change, as those changes can be conveyed to the decompressor implicitly (e.g. 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)' field in Extension 3).
当扩展头的内容更改时，实现可以选择使用不同的索引或更新现有索引。即使某些字段发生更改，也可以压缩掉一些扩展，因为这些更改可以隐式（例如，可从RTP SN推断的扩展标头中的序列号）或显式（例如，作为扩展3中“IP扩展标头”字段的一部分）传递给解压缩器。
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 list independently of one another.
当有多个IP头时，就有多个扩展头列表，并且为每个列表分别维护一个翻译表。
A list compressed using encoding type 1 (insertion), type 2 (removal), or type 3 (removal/insertion) uses a coding scheme that is based on the use of a reference list in the context (identified as ref_id).
使用编码类型1（插入）、类型2（删除）或类型3（删除/插入）压缩的列表使用基于在上下文中使用引用列表（标识为ref_id）的编码方案。
While it could seem to be a fair choice to send a type 1 list when ref_id is an empty list, there is nothing gained in doing so with respect to using a type 0 list. Sending a type 2 list when ref_id is an empty list would lead to a failure, while sending a type 3 list has very little meaning. All these alternatives could be seen as possible, based on how list compression is specified in RFC 3095.
当ref_id为空列表时，发送类型1列表似乎是一个公平的选择，但这样做与使用类型0列表相比毫无益处。当ref_id为空列表时发送类型2列表将导致失败，而发送类型3列表意义不大。根据RFC3095中列表压缩的规定，所有这些替代方案都是可能的。
If these alternatives were allowed, a decompressor would become 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 is not a desirable requirement. Using list encoding type 1, type 2, and type 3 is therefore only allowed for non-empty reference lists.
如果允许这些替代方案，则需要解压器在R模式下维护参考id列表的滑动窗口，即使在压缩列表中没有发送项目的情况下也是如此，这不是一个理想的要求。因此，仅允许对非空引用列表使用列表编码类型1、类型2和类型3。
FORMAL ADDITION TO RFC 3095:
RFC 3095的正式增补：
"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."
“无论操作模式如何，对于类型1、类型2和类型3列表的列表编码，ref_id必须引用非空列表。”
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 Encapsulation (GRE) [16][17] header. Both these sections present a possibility to omit the AH/GRE sequence number in the compressed header, under certain circumstances. However, the specific conditions for omitting the AH/GRE sequence number, as well as the concrete compression and decompression procedures to apply, are not clearly defined to guarantee robustness and facilitate interoperable implementation.
RFC 3095第5.8.4.2节和RFC 3095第5.8.4.4节描述了如何压缩认证头（AH）[14]和通用路由封装（GRE）[16][17]头。在某些情况下，这两个部分都可能省略压缩头中的AH/GRE序列号。然而，省略AH/GRE序列号的具体条件以及要应用的具体压缩和解压缩程序没有明确定义，以保证健壮性并促进可互操作的实现。
Proper rules are provided for the ESP case, i.e.,:
为ESP案例提供了适当的规则，即：
"Sequence Number: Not sent when the offset from the sequence number of the compressed header is constant, when the compressor has confidence that the decompressor has established the correct offset. When the offset is not constant, the sequence number may be compressed by sending LSBs"
序列号：当压缩头序列号的偏移量恒定时，当压缩器确信解压器已建立正确的偏移量时，不发送序列号。当偏移量不恒定时，可以通过发送LSB来压缩序列号
The same logic applies to the AH/GRE sequence numbers.
同样的逻辑适用于AH/GRE序列号。
INCORRECT RFC 3095 TEXT (RFC 3095-Section 5.8.4.2):
RFC 3095文本不正确（RFC 3095第5.8.4.2节）：
"If the sequence number in the AH linearly increases as the RTP Sequence Number increases, and the compressor is confident that the decompressor has obtained the pattern, the sequence number in AH need not be sent. The decompressor applies linear extrapolation to reconstruct the sequence number in the AH."
“如果AH中的序列号随着RTP序列号的增加而线性增加，并且压缩器确信减压器已获得模式，则无需发送AH中的序列号。减压器应用线性外推来重建AH中的序列号。”
CORRECTED TEXT:
更正文本：
"The AH sequence number can be omitted from the compressed header when the offset from the sequence number (SN) of the compressed header is constant, when the compressor has confidence that the decompressor has established the correct offset."
‘当压缩头序列号（SN）的偏移量恒定时，当压缩机确信减压器已建立正确的偏移量时，AH序列号可以从压缩头中省略。’
INCORRECT RFC 3095 TEXT (RFC 3095-Section 5.8.4.4):
RFC 3095文本不正确（RFC 3095第5.8.4.4节）：
"If the sequence number in the GRE header linearly increases as the RTP Sequence Number increases and the compressor is confident that the decompressor has received the pattern, the sequence number in GRE need not be sent. The decompressor applies linear extrapolation to reconstruct the sequence number in the GRE header."
“如果GRE头中的序列号随着RTP序列号的增加而线性增加，并且压缩器确信解压器已收到该模式，则无需发送GRE头中的序列号。解压器应用线性外推来重建GRE头中的序列号。”
CORRECTED TEXT:
更正文本：
"The GRE sequence number can be omitted from the compressed header when the offset from the sequence number (SN) of the compressed header is constant, when the compressor has confidence that the decompressor has established the correct offset."
‘当压缩头序列号（SN）的偏移量恒定时，当压缩机确信解压器已建立正确的偏移量时，可以从压缩头中省略GRE序列号。’
A context updating packet that contains compressed sequence number information may also carry information about other fields; in such cases, these fields are updated according to the content of the packet. The updating packet also implicitly updates inferred fields (e.g., RTP Timestamp) according to the current mode and the appropriate mapping function of the updated and inferred fields.
包含压缩序列号信息的上下文更新分组也可以携带关于其他字段的信息；在这种情况下，根据分组的内容更新这些字段。更新包还根据当前模式和更新的和推断的字段的适当映射函数隐式地更新推断的字段（例如，RTP时间戳）。
An updating packet thus updates the reference values of all header fields, either explicitly or implicitly, except for the UO-1-ID packet (see Section 6.2 of this document). In UO-mode, all packets are updating packets, while in R-mode, all packets with a CRC are updating packets.
因此，更新数据包会显式或隐式更新所有报头字段的参考值，UO-1-ID数据包除外（见本文件第6.2节）。在UO模式下，所有数据包都在更新数据包，而在R模式下，所有具有CRC的数据包都在更新数据包。
For example, a UO-0 packet contains the compressed RTP sequence number (SN). Such a packet also implicitly updates RTP timestamp, IPv4 ID, and sequence numbers of IP extension headers.
例如，UO-0分组包含压缩的RTP序列号（SN）。这样的数据包还隐式地更新RTP时间戳、IPv4 ID和IP扩展头的序列号。
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, TS, or IP-ID fields. However, RFC 3095-Section 5.8.1 correctly states that the translation table in the context is updated whenever an (Index, item) pair is received, something that is contradicted by 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 list' field. In addition to this contradiction, the text does not mention what to do with the other sequence numbers inferred from the SN, which are also to be implicitly updated. The updating properties of UO-1* as stated by RFC 3095-Section 5.7.3 are thus incomplete.
RFC 3095第5.7.3节规定，UO-1-ID数据包携带的扩展中提供的值不会更新上下文，SN、TS或IP-ID字段除外。然而，RFC 3095第5.8.1节正确地指出，每当收到（索引，项目）对时，上下文中的翻译表都会更新，这与RFC 3095-5.7.3中的陈述相矛盾，因为UO-1-ID数据包可以在“压缩的CSC列表”字段中携带扩展名3和（索引，项目）对项目。除了这一矛盾，本文没有提到如何处理从序列号推断出的其他序列号，这些序列号也将被隐式更新。因此，RFC 3095第5.7.3节所述UO-1*的更新特性不完整。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.3):
RFC 3095文本不完整（RFC 3095第5.7.3节）：
"Values provided in extensions, except those in other SN, TS, or IP-ID fields, do not update the context."
扩展中提供的值（其他SN、TS或IP-ID字段中的值除外）不会更新上下文
CORRECTED TEXT:
更正文本：
"UO-1-ID packets only updates TS, SN, IP-ID, and sequence numbers of IP extension headers. Other values provided in extensions do not update the context.
UO-1-ID数据包仅更新IP扩展头的TS、SN、IP-ID和序列号。扩展中提供的其他值不更新上下文。
The decompressor MUST update its translation table whenever an (Index, item) pair is received, as per RFC 3095-Section 5.8.1, and this rule applies also to UO-1-ID packets."
根据RFC 3095第5.8.1节，每当收到（索引、项）对时，解压缩程序必须更新其翻译表，该规则也适用于UO-1-ID数据包。”
IR packets do not clear the whole context, but update all fields 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 context is left unchanged.
IR数据包不会清除整个上下文，但会更新IR头中包含的所有字段。类似地，没有动态链的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 invalidated by the decompressor when it assumes context damage.
这样做的结果是，当解压器假定上下文损坏时，IR数据包未更新的字段（例如，用于列表压缩的翻译表）不得被解压器失效。
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 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 in the context.
RFC 3095第5.7.5节定义了扩展3中RTP头标志和字段的属性。当设置了扩展3的rtp标志时，即，当rtp＝1时，这些被更新；否则，它们不会更新。然而，不清楚扩展3如何在上下文中更新R-P位。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.5):
RFC 3095文本不完整（RFC 3095第5.7.5节）：
"R-P: RTP Padding bit, absolute value (presumed zero if absent)."
R-P:RTP填充位，绝对值（如果没有，则假定为零）
CORRECTED TEXT:
更正文本：
"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
R-PT = 0, context(R-P) is updated to zero."
"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
R-PT = 0, context(R-P) is updated to zero."
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-DYN packets. However, it is unclear how the X bit is updated in the context.
RFC 3095第5.7.7.6节定义了IR和IR-DYN数据包动态链RTP部分中RTP头标志和字段的属性。然而，尚不清楚X位在上下文中是如何更新的。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.7.6):
RFC 3095文本不完整（RFC 3095第5.7.7.6节）：
"X: Copy of X bit from RTP header (presumed 0 if RX = 0)"
“X：从RTP标头复制X位（如果RX=0，则假定为0）”
CORRECTED TEXT:
更正文本：
"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,
context(X) is updated to zero."
"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,
context(X) is updated to zero."
As part of the negotiated channel parameters, compressor and decompressor have, through the MAX_CID parameter, agreed on the highest context identification (CID) number to be used. By agreeing on MAX_CID, the decompressor also agrees to provide memory resources to host at least MAX_CID+1 contexts, and an established context with a CID within this negotiated space MUST be kept by the decompressor until either the CID gets reused, or the channel is taken down or renegotiated.
作为协商信道参数的一部分，压缩器和解压缩器通过MAX_CID参数商定了要使用的最高上下文标识（CID）号。通过同意MAX_CID，解压器还同意提供内存资源以承载至少MAX_CID+1上下文，并且解压器必须保留在该协商空间内具有CID的已建立上下文，直到CID被重用，或者通道被关闭或重新协商。
As part of the channel negotiation, the maximal number of active contexts supported is negotiated between the compressor and the decompressor through the MAX_CID parameter. The value of MAX_CID can differ significantly from one link application to another, as well as 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
作为通道协商的一部分，通过MAX_CID参数在压缩器和解压缩器之间协商支持的最大活动上下文数。MAX_CID的值在不同的链路应用程序之间可能存在显著差异，并且负载在要压缩的数据包流的数量方面也可能存在显著差异。ROHC通道的寿命也可能不同，从几乎永久到
rather short-lived. However, in general, it is not expected that resources will be allocated for more contexts than what can reasonably be expected to be active concurrently over the link. As a consequence hereof, context identifiers (CIDs) and context memory are resources that will have to be reused by the compressor as part of what can be considered normal operation.
相当短暂。然而，一般来说，预计资源分配给的上下文不会超过合理预期的在链路上并发活动的上下文。因此，上下文标识符（CID）和上下文内存是压缩机必须重用的资源，作为正常操作的一部分。
How context resources are reused is left unspecified in RFC 3095 [1] and subsequent 3095-based ROHC specifications. This document does not intend to change that, i.e., ROHC resource management is still considered an implementation detail. However, reusing a CID and its allocated memory is not always as simple as initiating a context with a previously unused CID. Because some profiles can be operating in various modes where packet formats vary depending on current mode, care has to be taken to ensure that the old context data will be completely and safely overwritten, eliminating the risk of undesired side effects from interactions between old and new context data. This document therefore points out some important core aspects to consider when implementing resource management in ROHC compressors and decompressors.
在RFC 3095[1]和随后基于3095的ROHC规范中，上下文资源的重用方式没有明确说明。本文件不打算改变这一点，即ROHC资源管理仍被视为一个实施细节。但是，重用CID及其分配的内存并不总是像使用以前未使用的CID启动上下文那样简单。由于某些配置文件可以在各种模式下运行，其中数据包格式因当前模式而异，因此必须注意确保完全安全地覆盖旧的上下文数据，从而消除新旧上下文数据之间交互产生不期望的副作用的风险。因此，该文件指出了在ROHC压缩器和解压缩器中实现资源管理时需要考虑的一些核心方面。
On a high level, CID/context reuse can be of two kinds, either reuse for a new context based on the same profile as the old context, or for a new context based on a different profile. These cases are discussed separately in the following two sub-sections.
在较高的层次上，CID/上下文重用可以分为两种，一种是基于与旧上下文相同的概要文件的新上下文重用，另一种是基于不同概要文件的新上下文重用。以下两小节将分别讨论这些情况。
For multi-mode profiles, such as those defined in RFC 3095 [1], mode transitions are performed using a decompressor-initiated handshake procedure, as defined in RFC 3095-Section 5.6. When a CID/context is reused for a new context based on the same profile as the old context, the current mode of operation SHOULD be inherited from the old to the new context. Specifically, the compressor SHOULD continue 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 for the compressor to inform the decompressor that a CID/context reuse is happening. The decompressor can thus not be expected to clear the context memory for the CID (see Section 6.3), and there is no way to trigger a safe mode switching (which requires the decompressor-initiated handshake procedure).
对于多模式配置文件，如RFC 3095[1]中定义的配置文件，使用RFC 3095第5.6节中定义的解压器启动的握手程序执行模式转换。当基于与旧上下文相同的概要文件为新上下文重用CID/上下文时，当前操作模式应从旧上下文继承到新上下文。具体而言，压缩机应继续使用旧上下文的操作模式以及新上下文的操作模式进行操作。原因是压缩器没有可靠的方法通知解压缩器正在发生CID/上下文重用。因此，不能期望解压缩程序清除CID的上下文内存（参见第6.3节），也无法触发安全模式切换（这需要解压缩程序启动的握手过程）。
The rule of mode inheritance applies also when the CONTEXT_REINITIALIZATION signal (RFC 3095-Section 6.3.1) is used to reinitiate an entire context.
当使用上下文重新初始化信号（RFC 3095第6.3.1节）重新初始化整个上下文时，模式继承规则也适用。
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 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 new contexts and profile downgrades with IR-DYN (e.g., the profile 0x0001 -> profile 0x0002 downgrade in RFC 3095-Section 5.11.1).
当基于与旧上下文不同的概要文件将CID重新用于新上下文时，压缩器和解压缩器都必须在概要文件的初始模式（如果是多模式概要文件）中使用该上下文启动操作。这既适用于IR启动的新上下文，也适用于IR-DYN的配置文件降级（例如，RFC 3095第5.11.1节中的配置文件0x0001->配置文件0x0002降级）。
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 on a reused R-mode CID, there is a risk that the decompressor will misinterpret compressed packets if the initiating IR packets are lost.
类型0和类型1数据包在U/O和R模式下具有不同的格式，并且这些R模式数据包没有CRC。在重用的R模式CID上启动新上下文时，如果启动的IR数据包丢失，则解压器将有误解压缩数据包的风险。
A CID for a context currently operating in R-mode SHOULD therefore not be reused for a new context based on a different profile than the old context. A compressor doing otherwise should minimize the risk for misinterpretation of R-0/R-1 by, e.g., not using packets of types beginning with 00 or 10 before it is highly confident that the new context has successfully been initiated at the decompressor.
因此，当前在R模式下运行的上下文的CID不应基于与旧上下文不同的概要文件重新用于新上下文。否则，压缩器应尽量减少错误解释R-0/R-1的风险，例如，在高度确信新上下文已在解压器处成功启动之前，不使用以00或10开头的数据包。
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.
在IPv4动态部分（RFC 3095第5.7.7.4节）中，如果设置了“NBO”位，则表示使用了网络字节顺序。
According to RFC 3095-Section 5.7, IP-ID means the compressed value of the IPv4 header's 'Identification' field. Compressed packets contain this compressed value (IP-ID), while IR packets with dynamic chain and IR-DYN packets transmit the original, uncompressed Identification field value. The IP-ID field always represents the Identification value of the innermost IPv4 header whose corresponding RND flag is not 1.
根据RFC 3095第5.7节，IP-ID表示IPv4报头的“标识”字段的压缩值。压缩数据包包含此压缩值（IP-ID），而带有动态链的IR数据包和IR-DYN数据包传输原始的未压缩标识字段值。IP-ID字段始终表示对应RND标志不是1的最内层IPv4标头的标识值。
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 compressed base header, according to the IP-ID description (see the beginning of RFC 3095-Section 5.7). When there is no compressed IP-ID, i.e., for IPv6 or when all IP Identification information is sent as is (as indicated by RND/RND2 being set to 1), the decompressor ignores IP-ID bits sent within compressed base headers.
如果RND或RND2设置为1，则根据IP-ID说明（参见RFC 3095第5.7节开头），相应的IP-ID将作为16位未压缩标识值发送到压缩基本报头的末尾。当没有压缩的IP-ID时，即对于IPv6或当所有IP标识信息按原样发送时（如RND/RND2设置为1所示），解压器忽略压缩的基本报头内发送的IP-ID位。
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-ID is sent in Extension 3.
当RND=RND2=0时，IP-ID被压缩，即，表示为SN偏移量，如果NBO=0，则字节交换。在扩展3中发送16位IP-ID时也是如此。
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 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, where it is said that "default-slope(IP-ID offset) = 0", meaning, if no bits are sent for IP-ID, its SN offset slope defaults to 0.
当RND=0但压缩报头中没有发送IP-ID位时，IP-ID的SN偏移量保持不变，这意味着偏移量μm等于偏移量μref，如第4.5.5节所述。这在第5.7节中以稍微不同的方式（具有相同的含义）进一步表示，其中称为“默认斜率（IP-ID偏移）=0”，这意味着，如果没有为IP-ID发送位，其SN偏移斜率默认为0。
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, when a flag changes in Extension 3, a decompressor MUST re-parse the UOR-2* packet.
扩展中IP报头的一些标志（例如NBO或RND）可能会改变UOR-2*数据包中字段的解释。在这种情况下，当扩展3中的标志更改时，解压缩程序必须重新解析UOR-2*数据包。
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 also present in all compressed base header formats except for UO-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 the same value.
RFC 3095第5.7.5节定义的扩展3的RTP报头部分包括RTP标记位的一位字段。除UO-1-ID外，该字段还存在于所有压缩的基本头格式中；也就是说，在一个压缩头中可能会出现两个字段。在这种情况下，两个M字段必须具有相同的值。
FORMAL ADDITION TO RFC 3095:
RFC 3095的正式增补：
"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 Extension 3), the compressor MUST set both these occurrences of the M field to the same value.
'当压缩标题中有两个M字段出现时（都在压缩的基本标题和扩展3的RTP部分中），压缩器必须将这两个M字段的出现设置为相同的值。
At the decompressor, if the two M field values of such a packet are not identical, the packet MUST be discarded."
在解压器处，如果此类数据包的两个M字段值不相同，则必须丢弃该数据包。”
The length of the sequence number field in the original ESP [12] header is 32 bits. The format of the SN feedback option (RFC 3095- Section 5.7.6.6) allows for 8 additional SN bits to the 12 SN bits of 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 all the 32 bits of the ESP sequence number in a feedback packet, unless it uses multiple SN options in one feedback packet.
原始ESP[12]头中的序列号字段长度为32位。SN反馈选项的格式（RFC 3095-第5.7.6.6节）允许在反馈-2格式（RFC 3095-第5.7.6.1节）的12个SN位中增加8个SN位。因此，一个单一的SN反馈选项不足以使解压缩器发回反馈分组中ESP序列号的所有32位，除非它在一个反馈分组中使用多个SN选项。
RFC 3095-Section 5.7.6.1 declares that a FEEDBACK-2 packet can contain a variable number of feedback options, and the options can appear in any order.
RFC 3095第5.7.6.1节声明FEEDBACK-2数据包可以包含数量可变的反馈选项，并且这些选项可以以任何顺序出现。
When processing multiple SN options in one feedback packet, the SN would be given by concatenating the fields.
当在一个反馈包中处理多个SN选项时，SN将通过串联字段给出。
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 multiple CRC options are included, all such CRC options MUST be identical, as they will be calculated over the same header; the compressor MUST otherwise discard the feedback packet.
尽管在一个反馈数据包中有多个CRC选项没有用处，但仍然允许有多个CRC选项。如果包括多个CRC选项，则所有此类CRC选项必须相同，因为它们将在同一标头上计算；否则，压缩器必须丢弃反馈数据包。
Although this is neither desirable or expected, it may happen that a link used to carry feedback between two associated instances becomes unavailable. If the compressor can be notified of such an event, the compressor SHOULD restart compression for each flow that is operating in R-mode. When restarting compression, the compressor SHOULD use a different CID for each flow being restarted; this is useful to avoid the possibility of misinterpreting the type of the compressed header for the packet type identifiers that are common to both U/O-mode and R-mode, when the flow is restarted in U-mode (see also Section 7.2).
虽然这既不是期望的，也不是期望的，但可能会发生用于在两个关联实例之间传送反馈的链路变得不可用的情况。如果可以将此类事件通知压缩机，则压缩机应重新启动R模式下运行的每个流量的压缩。重新启动压缩时，压缩机应为重新启动的每个流量使用不同的CID；这有助于避免在U模式下重新启动流时，对U/O模式和R模式通用的数据包类型标识符的压缩报头类型产生误解的可能性（另请参见第7.2节）。
Generally, feedback links are not expected to disappear once present, but it should be noted that this might be the case for certain link technologies.
一般来说，反馈链接不会在出现后消失，但应注意的是，某些链接技术可能会出现这种情况。
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) formats from profile 0x0001. The same UOR-2 format is thus used independent of whether or not there are IP headers with a corresponding RND=1. This also applies to the IP profile [4] and the IP/UDP-Lite profile [5].
在概要文件0x0002和概要文件0x0003中为UOR-2定义了一种新格式，它替换了概要文件0x0001中的所有三种（UOR-2、UOR-2-ID、UOR-2-TS）格式。因此，使用相同的UOR-2格式与是否存在相应RND=1的IP头无关。这也适用于IP配置文件[4]和IP/UDP Lite配置文件[5]。
In RFC 3095-Section 5.8.5, formats are defined for compression of IP extension header fields. These include compressed sequence number fields, and these fields contain the "LSB of sequence number". These sequence numbers are not "LSB-encoded" as, e.g., the RTP sequence number, but are the LSB's of the uncompressed fields.
在RFC 3095第5.8.5节中，定义了用于压缩IP扩展头字段的格式。其中包括压缩序列号字段，这些字段包含“序列号的LSB”。这些序列号不是“LSB编码”的，例如RTP序列号，而是未压缩字段的LSB。
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 purposes other than to acknowledge the UOR-2, without having to continue sending ACKs for all UOR-2. Similarly, a compressor implementation can ignore UOR-2s ACKs for the purpose of adapting the optimistic approach strategies.
如RFC 3095第5.4.1.1.2节所述，在O模式下使用UOR-2 ACK是可选的。解压器也可以发送ACK用于确认UOR-2以外的目的，而无需继续发送所有UOR-2的ACK。类似地，压缩机实施可以忽略UOR-2s确认，以适应乐观方法策略。
It is thus NOT RECOMMENDED to use the optional ACK mechanism in O-mode, either in compressor or in decompressor implementations.
因此，无论是在压缩器还是在解压器实现中，都不建议在O模式下使用可选的ACK机制。
Using an incorrect expectation on UOR-2 ACKs as a basis for compressor behavior will significantly degrade the compression performance. This is because UOR-2 ACKs can be sent from a 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 transition. If an implementation does use the optional acknowledgment algorithm described in Section 5.4.1.1.2, it must make sure to set the k_3 and n_3 parameters to much larger values than 1 to ensure that the compressor performance is not degraded due to the problem described above.
在UOR-2 ACK上使用不正确的预期作为压缩机行为的基础将显著降低压缩性能。这是因为UOR-2确认可以从解压器发送用于确认UOR-2数据包以外的其他目的，例如，发送诸如时钟分辨率之类的反馈，或启动模式转换。如果实施使用第5.4.1.1.2节中描述的可选确认算法，则必须确保将k_3和n_3参数设置为比1大得多的值，以确保压缩机性能不会因上述问题而降低。
The 7-bit CRC used to verify the outcome of the decompression attempt covers the original uncompressed header. The CRC verification thus excludes TS_STRIDE and TIME_STRIDE, as these fields are not part of the original uncompressed header.
用于验证解压缩尝试结果的7位CRC覆盖原始未压缩标头。因此，CRC验证不包括TS_步长和TIME_步长，因为这些字段不是原始未压缩头的一部分。
The UOR-2 packet type can be used to update the value of the TS_STRIDE and/or the TIME_STRIDE, with the Extension 3. However, these fields are not used for decompression of the RTP TS field for this packet type and their respective value is thus not verified, either implicitly or explicitly.
UOR-2数据包类型可用于使用扩展名3更新TS_步幅和/或时间_步幅的值。然而，这些字段不用于对该分组类型的RTP TS字段进行解压缩，因此它们各自的值不会被隐式或显式地验证。
When the compressor receives a negative acknowledgement, it thus cannot determine whether the failure may be caused by an unsuccessful update to the TS_STRIDE and/or the TIME_STRIDE field(s), for which a previous header that last attempted to update their value had previously been acknowledged.
当压缩器接收到否定确认时，它无法确定故障是否是由于TS_步长和/或时间_步长字段的更新不成功引起的，对于该字段，上一次尝试更新其值的前一报头先前已被确认。
FORMAL ADDITION TO RFC 3095:
RFC 3095的正式增补：
"When the compressor receives a NACK and uses the UOR-2 header type to repair the decompressor context, it SHOULD include fields that update the value of both the TS_STRIDE and the TIME_STRIDE whose value it has updated at least once since the establishment
“当压缩器接收到NACK并使用UOR-2标头类型修复解压器上下文时，它应包括更新TS_步长值和时间_步长值的字段，自建立以来，其值已至少更新一次
of that context, i.e., since the CID was first associated with its current profile.
即，由于CID首先与其当前配置文件相关联。
When the compressor receives a static-NACK, it MUST include in the IR header fields for both the TS_STRIDE and the TIME_STRIDE whose value it has updated at least once since the establishment of that context, i.e., since the CID was first associated with its current profile."
当压缩器接收到静态NACK时，它必须在IR报头字段中包括TS_步幅和TIME_步幅，其值自该上下文建立以来，即自CID首次与其当前配置文件关联以来，至少更新了一次。”
RFC 3095-Section 4.1 states that the link layer must provide means to 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 set of non-negative integers where each integer indicates a profile supported by the decompressor.
RFC 3095第4.1节规定链路层必须提供协商方法，例如RFC 3095第5.1.1节中列出的信道参数。其中一个参数是PROFILES参数，它是一组非负整数，其中每个整数表示解压缩程序支持的概要文件。
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 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 bits, which means that the compressor and decompressor must have agreed on which variant to use for each profile.
每个配置文件由一个16位值标识，其中8个LSB位表示实际配置文件，8个MSB位表示该配置文件的变体（参见RFC 3095第8节）。在通过链路发送的ROHC报头中，使用的配置文件仅用8个LSB位标识，这意味着压缩器和解压缩器必须就每个配置文件使用哪种变体达成一致。
The negotiation protocol must thus be able to communicate to the compressor the set of profiles supported by the decompressor. When multiple variants of the same profile are available, the negotiation protocol must provide the means for the decompressor to know which variant will be used by the compressor. This basically means that the PROFILES set after negotiation MUST NOT include more than one variant of a profile.
因此，协商协议必须能够与压缩器通信解压器支持的配置文件集。当同一配置文件的多个变量可用时，协商协议必须为解压缩程序提供方法，以了解压缩机将使用哪个变量。这基本上意味着协商后设置的配置文件不得包含多个配置文件变体。
The logical union of sub-options for IPCP and IPV6CP negotiations, as specified by ROHC over PPP [2], cannot be used for the PROFILES suboption, as the whole union would then have to be considered within each of the two IPCP negotiations to avoid getting an ambiguous profile set. An implementation of RFC 3241 MUST therefore ensure that the same profile set is negotiated for both IPv4 and IPv6 (IPCP/IPV6CP).
根据ROHC对PPP[2]的规定，IPCP和IPV6CP谈判的子选项逻辑联合不能用于配置文件子选项，因为整个联合必须在两个IPCP谈判中考虑，以避免获得不明确的配置文件集。因此，RFC 3241的实现必须确保为IPv4和IPv6（IPCP/IPV6CP）协商相同的配置文件集。
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-ID) is defined. This mechanism is also used by the ROHC UDP-Lite profiles, RFC 4019 [5].
在RFC 3843[4]第3.3节的ROHC纯IP配置文件中，定义了IPv4（恒定IP-ID）中恒定标识值的编码机制。ROHC UDP Lite配置文件RFC 4019也使用此机制[5]。
The "Constant IP-ID" mechanism applies to both the inner and outer IP header, when present, meaning that there will be both a SID and a SID2 context value.
“常量IP-ID”机制适用于内部和外部IP头（当存在时），这意味着将同时存在SID和SID2上下文值。
This document provides a number of corrections and clarifications to [1], but it does not make any changes with regard to the security aspects of the protocol. As a consequence, the security considerations of [1] apply without additions.
本文件对[1]进行了大量更正和澄清，但并未对协议的安全方面做出任何更改。因此，[1]中的安全注意事项适用，无需添加。
The authors would like to thank Vicknesan Ayadurai, Carsten Bormann, Mikael Degermark, Zhigang Liu, Abigail Surtees, Mark West, Tommy Lundemo, Alan Kennington, Remi Pelland, Lajos Zaccomer, Endre Szalai, Mark Kalmanczhelyi, and Arpad Szakacs for their contributions and comments. Thanks also to the committed document reviewers, Carl Knutsson and Biplab Sarkar, who reviewed the document during working group last-call.
作者要感谢维克尼桑·阿亚杜赖、卡斯滕·鲍曼、米凯尔·德格马克、刘志刚、阿比盖尔·萨提斯、马克·韦斯特、汤米·伦德莫、艾伦·肯宁顿、雷米·佩兰德、拉乔斯·扎科默、恩德·萨莱、马克·卡尔曼奇莱伊和阿帕德·萨卡茨的贡献和评论。还要感谢致力于文件审查的Carl Knutsson和Biplab Sarkar，他们在工作组上次电话会议期间审查了文件。
[1] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 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.
[1] Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP和未压缩”，RFC 3095，2001年7月。
[2] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[2] Bormann，C.，“PPP上的鲁棒头压缩（ROHC）”，RFC 32412002年4月。
[3] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[3] 辛普森，W.“HDLC类框架中的PPP”，STD 51，RFC 16621994年7月。
[4] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[4] Jonsson，L-E.和G.Pelletier，“鲁棒头压缩（ROHC）：IP的压缩配置文件”，RFC 3843，2004年6月。
[5] Pelletier, G., "RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
[5] Pelletier，G.“鲁棒头压缩（ROHC）：用户数据报协议（UDP）Lite的配置文件”，RFC40192005年4月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Jonsson, L-E., Pelletier, G., and K. Sandlund, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 4362, January 2006.
[7] Jonsson，L-E.，Pelletier，G.和K.Sandlund，“鲁棒头压缩（ROHC）：IP/UDP/RTP的链路层辅助配置文件”，RFC 4362，2006年1月。
[8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[8] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[9] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[10] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[10] Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[11] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[11] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[12] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[12] Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[13] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[13] Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月。
[14] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[14] Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[15] Perkins，C.，“IP内的最小封装”，RFC 2004，1996年10月。
[16] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[16] Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[17] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[17] Dommety，G.，“GRE的密钥和序列号扩展”，RFC 28902000年9月。
#!/usr/bin/perl -w
use strict;
#=================================
#
# ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
#
# This little demo shows the four types of CRCs in use in RFC 3095,
# the specification for robust header compression. Type your data in
# hexadecimal form and then press Control+D.
#
#---------------------------------
#
# utility
#
sub dump_bytes($) {
my $x = shift;
my $i;
for ($i = 0; $i < length($x); ) {
printf("%02x ", ord(substr($x, $i, 1)));
printf("\n") if (++$i % 16 == 0);
}
printf("\n") if ($i % 16 != 0);
}
#!/usr/bin/perl -w
use strict;
#=================================
#
# ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
#
# This little demo shows the four types of CRCs in use in RFC 3095,
# the specification for robust header compression. Type your data in
# hexadecimal form and then press Control+D.
#
#---------------------------------
#
# utility
#
sub dump_bytes($) {
my $x = shift;
my $i;
for ($i = 0; $i < length($x); ) {
printf("%02x ", ord(substr($x, $i, 1)));
printf("\n") if (++$i % 16 == 0);
}
printf("\n") if ($i % 16 != 0);
}
#---------------------------------
#
# The CRC calculation algorithm.
#
sub do_crc($$$) {
my $nbits = shift;
my $poly = shift;
my $string = shift;
#---------------------------------
#
# The CRC calculation algorithm.
#
sub do_crc($$$) {
my $nbits = shift;
my $poly = shift;
my $string = shift;
my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
for (my $i = 0; $i < length($string); ++$i) {
my $byte = ord(substr($string, $i, 1));
for( my $b = 0; $b < 8; $b++ ) {
if (($crc & 1) ^ ($byte & 1)) {
$crc >>= 1;
$crc ^= $poly;
} else {
$crc >>= 1;
}
$byte >>= 1;
}
}
my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
for (my $i = 0; $i < length($string); ++$i) {
my $byte = ord(substr($string, $i, 1));
for( my $b = 0; $b < 8; $b++ ) {
if (($crc & 1) ^ ($byte & 1)) {
$crc >>= 1;
$crc ^= $poly;
} else {
$crc >>= 1;
}
$byte >>= 1;
}
}
printf "%2d bits, ", $nbits;
printf "CRC: %02x\n", $crc;
}
printf "%2d bits, ", $nbits;
printf "CRC: %02x\n", $crc;
}
#---------------------------------
#
# Test harness
#
$/ = undef;
$_ = <>; # read until EOF
my $string = ""; # extract all that looks hex:
s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
dump_bytes($string);
#---------------------------------
#
# Test harness
#
$/ = undef;
$_ = <>; # read until EOF
my $string = ""; # extract all that looks hex:
s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
dump_bytes($string);
#---------------------------------
#
# 32-bit segmentation CRC
# Note that the text implies that this is complemented like for PPP
# (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 +
# x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
#
do_crc(32, 0xedb88320, $string);
#---------------------------------
#
# 32-bit segmentation CRC
# Note that the text implies that this is complemented like for PPP
# (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 +
# x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
#
do_crc(32, 0xedb88320, $string);
#---------------------------------
#
# 8-bit IR/IR-DYN CRC
#
# C(x) = x^0 + x^1 + x^2 + x^8
#
do_crc(8, 0xe0, $string);
#---------------------------------
#
# 8-bit IR/IR-DYN CRC
#
# C(x) = x^0 + x^1 + x^2 + x^8
#
do_crc(8, 0xe0, $string);
#---------------------------------
#
# 7-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
#
do_crc(7, 0x79, $string);
#---------------------------------
#
# 7-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
#
do_crc(7, 0x79, $string);
#---------------------------------
#
# 3-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^3
#
do_crc(3, 0x6, $string);
#---------------------------------
#
# 3-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^3
#
do_crc(3, 0x6, $string);
Authors' Addresses
作者地址
Lars-Erik Jonsson Optand 737 SE-831 92 Ostersund, Sweden Phone: +46 70 365 20 58 EMail: lars-erik@lejonsson.com
Lars Erik Jonsson Optand 737 SE-831 92 Ostersund，瑞典电话：+46 70 365 20 58电子邮件：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
Kristofer Sandlund Ericsson AB信箱920 SE-971 28 Lulea，瑞典电话：+46 8 404 41 58电子邮件：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
Ghyslain Pelletier Ericsson AB信箱920 SE-971 28 Lulea，瑞典电话：+46 8 404 29 43电子邮件：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
Peter Kremer合规性和软件测试实验室爱立信匈牙利H-1300 Bp。3，匈牙利邮政信箱107电话：+3614377033电子邮件：peter。kremer@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any 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 such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。