Network Working Group C. Bormann, Editor, TZI/Uni Bremen
Request for Comments: 3095 C. Burmeister, Matsushita
Category: Standards Track M. Degermark, Univ. of Arizona
H. Fukushima, Matsushita
H. Hannu, Ericsson
L-E. Jonsson, Ericsson
R. Hakenberg, Matsushita
T. Koren, Cisco
K. Le, Nokia
Z. Liu, Nokia
A. Martensson, Ericsson
A. Miyazaki, Matsushita
K. Svanbro, Ericsson
T. Wiebke, Matsushita
T. Yoshimura, NTT DoCoMo
H. Zheng, Nokia
July 2001
RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed
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 Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers.
この文書では、RTP / UDP / IPのための非常に堅牢かつ効率的なヘッダ圧縮方式（リアルタイムトランスポートプロトコル、ユーザデータグラムプロトコル、インターネット・プロトコル）、UDP / IP、およびESP / IP（カプセル化セキュリティペイロード）のヘッダーを指定します。
Existing header compression schemes do not work well when used over links with significant error rates and long round-trip times. For many bandwidth limited links where header compression is essential, such characteristics are common.
重大なエラー率と長い往復時間とのリンク上で使用する場合、既存のヘッダ圧縮方式はうまく機能しません。ヘッダ圧縮が不可欠である多くの帯域幅が限られたリンクについては、このような特性は一般的です。
This is done in a framework designed to be extensible. For example, a scheme for compressing TCP/IP headers will be simple to add, and is in development. Headers specific to Mobile IPv4 are not subject to special treatment, but are expected to be compressed sufficiently well by the provided methods for compression of sequences of extension headers and tunneling headers. For the most part, the same will apply to work in progress on Mobile IPv6, but future work might be required to handle some extension headers, when a standards track Mobile IPv6 has been completed.
これは、拡張できるように設計された枠組みの中で行われています。たとえば、TCP / IPヘッダを圧縮するためのスキームは、追加が簡単になり、開発中です。モバイルIPv4に特有のヘッダーは特別な治療を受けないが、拡張ヘッダおよびトンネルヘッダのシーケンスの圧縮のために提供される方法によって十分に圧縮されることが期待されます。ほとんどの部分については、同じことがモバイルIPv6で進行中の仕事に適用されますが、標準はモバイルIPv6が完了した追跡する際に、将来の仕事には、いくつかの拡張ヘッダを処理する必要がある場合があります。
Table of Contents
目次
1. Introduction....................................................6
2. Terminology.....................................................8
2.1. Acronyms.....................................................13
3. Background.....................................................14
3.1. Header compression fundamentals..............................14
3.2. Existing header compression schemes..........................14
3.3. Requirements on a new header compression scheme..............16
3.4. Classification of header fields..............................17
4. Header compression framework...................................18
4.1. Operating assumptions........................................18
4.2. Dynamicity...................................................19
4.3. Compression and decompression states.........................21
4.3.1. Compressor states..........................................21
4.3.1.1. Initialization and Refresh (IR) State....................22
4.3.1.2. First Order (FO) State...................................22
4.3.1.3. Second Order (SO) State..................................22
4.3.2. Decompressor states........................................23
4.4. Modes of operation...........................................23
4.4.1. Unidirectional mode -- U-mode..............................24
4.4.2. Bidirectional Optimistic mode -- O-mode....................25
4.4.3. Bidirectional Reliable mode -- R-mode......................25
4.5. Encoding methods.............................................25
4.5.1. Least Significant Bits (LSB) encoding .....................25
4.5.2. Window-based LSB encoding (W-LSB encoding).................28
4.5.3. Scaled RTP Timestamp encoding .............................28
4.5.4. Timer-based compression of RTP Timestamp...................31
4.5.5. Offset IP-ID encoding......................................34
4.5.6. Self-describing variable-length values ....................35
4.5.7. Encoded values across several fields in compressed headers 36
4.6. Errors caused by residual errors.............................36
4.7. Impairment considerations....................................37
5. The protocol...................................................39
5.1. Data structures..............................................39
5.1.1. Per-channel parameters.....................................39
5.1.2. Per-context parameters, profiles...........................40
5.1.3. Contexts and context identifiers ..........................41
5.2. ROHC packets and packet types................................41
5.2.1. ROHC feedback .............................................43
5.2.2. ROHC feedback format ......................................45
5.2.3. ROHC IR packet type .......................................47
5.2.4. ROHC IR-DYN packet type ...................................48
5.2.5. ROHC segmentation..........................................49
5.2.5.1. Segmentation usage considerations........................49
5.2.5.2. Segmentation protocol....................................50
5.2.6. ROHC initial decompressor processing.......................51
5.2.7. ROHC RTP packet formats from compressor to decompressor....53
5.2.8. Parameters needed for mode transition in ROHC RTP..........54
5.3. Operation in Unidirectional mode.............................55
5.3.1. Compressor states and logic (U-mode).......................55
5.3.1.1. State transition logic (U-mode)..........................55
5.3.1.1.1. Optimistic approach, upwards transition................55
5.3.1.1.2. Timeouts, downward transition..........................56
5.3.1.1.3. Need for updates, downward transition..................56
5.3.1.2. Compression logic and packets used (U-mode)..............56
5.3.1.3. Feedback in Unidirectional mode..........................56
5.3.2. Decompressor states and logic (U-mode).....................56
5.3.2.1. State transition logic (U-mode)..........................57
5.3.2.2. Decompression logic (U-mode).............................57
5.3.2.2.1. Decide whether decompression is allowed................57
5.3.2.2.2. Reconstruct and verify the header......................57
5.3.2.2.3. Actions upon CRC failure...............................58
5.3.2.2.4. Correction of SN LSB wraparound........................60
5.3.2.2.5. Repair of incorrect SN updates.........................61
5.3.2.3. Feedback in Unidirectional mode..........................62
5.4. Operation in Bidirectional Optimistic mode...................62
5.4.1. Compressor states and logic (O-mode).......................62
5.4.1.1. State transition logic...................................63
5.4.1.1.1. Negative acknowledgments (NACKs), downward transition..63
5.4.1.1.2. Optional acknowledgments, upwards transition...........63
5.4.1.2. Compression logic and packets used.......................63
5.4.2. Decompressor states and logic (O-mode).....................64
5.4.2.1. Decompression logic, timer-based timestamp decompression.64
5.4.2.2. Feedback logic (O-mode)..................................64
5.5. Operation in Bidirectional Reliable mode.....................65
5.5.1. Compressor states and logic (R-mode).......................65
5.5.1.1. State transition logic (R-mode)..........................65
5.5.1.1.1. Upwards transition.....................................65
5.5.1.1.2. Downward transition....................................66
5.5.1.2. Compression logic and packets used (R-mode)..............66
5.5.2. Decompressor states and logic (R-mode).....................68
5.5.2.1. Decompression logic (R-mode).............................68
5.5.2.2. Feedback logic (R-mode)..................................68
5.6. Mode transitions.............................................69
5.6.1. Compression and decompression during mode transitions......70
5.6.2. Transition from Unidirectional to Optimistic mode..........71
5.6.3. From Optimistic to Reliable mode...........................72
5.6.4. From Unidirectional to Reliable mode.......................72
5.6.5. From Reliable to Optimistic mode...........................72
5.6.6. Transition to Unidirectional mode..........................73
5.7. Packet formats...............................................74
5.7.1. Packet type 0: UO-0, R-0, R-0-CRC .........................78
5.7.2. Packet type 1 (R-mode): R-1, R-1-TS, R-1-ID ...............79
5.7.3. Packet type 1 (U/O-mode): UO-1, UO-1-ID, UO-1-TS ..........80
5.7.4. Packet type 2: UOR-2 ......................................82
5.7.5. Extension formats..........................................83
5.7.5.1. RND flags and packet types...............................88
5.7.5.2. Flags/Fields in context..................................89
5.7.6. Feedback packets and formats...............................90
5.7.6.1. Feedback formats for ROHC RTP............................90
5.7.6.2. ROHC RTP Feedback options................................91
5.7.6.3. The CRC option...........................................92
5.7.6.4. The REJECT option........................................92
5.7.6.5. The SN-NOT-VALID option..................................92
5.7.6.6. The SN option............................................93
5.7.6.7. The CLOCK option.........................................93
5.7.6.8. The JITTER option........................................93
5.7.6.9. The LOSS option..........................................94
5.7.6.10. Unknown option types....................................94
5.7.6.11. RTP feedback example....................................94
5.7.7. RTP IR and IR-DYN packets..................................96
5.7.7.1. Basic structure of the IR packet.........................96
5.7.7.2. Basic structure of the IR-DYN packet.....................98
5.7.7.3. Initialization of IPv6 Header [IPv6].....................99
5.7.7.4. Initialization of IPv4 Header [IPv4, section 3.1].......100
5.7.7.5. Initialization of UDP Header [RFC-768]..................101
5.7.7.6. Initialization of RTP Header [RTP]......................102
5.7.7.7. Initialization of ESP Header [ESP, section 2]...........103
5.7.7.8. Initialization of Other Headers.........................104
5.8. List compression............................................104
5.8.1. Table-based item compression..............................105
5.8.1.1. Translation table in R-mode.............................105
5.8.1.2. Translation table in U/O-modes..........................106
5.8.2. Reference list determination..............................106
5.8.2.1. Reference list in R-mode and U/O-mode...................107
5.8.3. Encoding schemes for the compressed list..................109
5.8.4. Special handling of IP extension headers..................112
5.8.4.1. Next Header field.......................................112
5.8.4.2. Authentication Header (AH)..............................114
5.8.4.3. Encapsulating Security Payload Header (ESP).............115
5.8.4.4. GRE Header [RFC 2784, RFC 2890].........................117
5.8.5. Format of compressed lists in Extension 3.................119
5.8.5.1. Format of IP Extension Header(s) field..................119
5.8.5.2. Format of Compressed CSRC List..........................120
5.8.6. Compressed list formats...................................120
5.8.6.1. Encoding Type 0 (generic scheme)........................120
5.8.6.2. Encoding Type 1 (insertion only scheme).................122
5.8.6.3. Encoding Type 2 (removal only scheme)...................123
5.8.6.4. Encoding Type 3 (remove then insert scheme).............124
5.8.7. CRC coverage for extension headers........................124
5.9. Header compression CRCs, coverage and polynomials...........125
5.9.1. IR and IR-DYN packet CRCs.................................125
5.9.2. CRCs in compressed headers................................125
5.10. ROHC UNCOMPRESSED -- no compression (Profile 0x0000).......126
5.10.1. IR packet................................................126
5.10.2. Normal packet............................................127
5.10.3. States and modes.........................................128
5.10.4. Feedback.................................................129
5.11. ROHC UDP -- non-RTP UDP/IP compression (Profile 0x0002)....129
5.11.1. Initialization...........................................130
5.11.2. States and modes.........................................130
5.11.3. Packet types.............................................131
5.11.4. Extensions...............................................132
5.11.5. IP-ID....................................................133
5.11.6. Feedback.................................................133
5.12. ROHC ESP -- ESP/IP compression (Profile 0x0003)............133
5.12.1. Initialization...........................................133
5.12.2. Packet types.............................................134
6. Implementation issues.........................................134
6.1. Reverse decompression.......................................134
6.2. RTCP........................................................135
6.3. Implementation parameters and signals.......................136
6.3.1. ROHC implementation parameters at compressor..............137
6.3.2. ROHC implementation parameters at decompressor............138
6.4. Handling of resource limitations at the decompressor........139
6.5. Implementation structures...................................139
6.5.1. Compressor context........................................139
6.5.2. Decompressor context......................................141
6.5.3. List compression: Sliding windows in R-mode and U/O-mode..142
7. Security Considerations.......................................143
8. IANA Considerations...........................................144
9. Acknowledgments...............................................145
10. Intellectual Property Right Claim Considerations.............145
11. References...................................................146
11.1. Normative References.......................................146
11.2. Informative References.....................................147
12. Authors' Addresses...........................................148
Appendix A. Detailed classification of header fields.............152
A.1. General classification......................................153
A.1.1. IPv6 header fields........................................153
A.1.2. IPv4 header fields........................................155
A.1.3. UDP header fields.........................................157
A.1.4. RTP header fields.........................................157
A.1.5. Summary for IP/UDP/RTP....................................159
A.2. Analysis of change patterns of header fields................159
A.2.1. IPv4 Identification.......................................162
A.2.2. IP Traffic-Class / Type-Of-Service........................163
A.2.3. IP Hop-Limit / Time-To-Live...............................163
A.2.4. UDP Checksum..............................................163
A.2.5. RTP CSRC Counter..........................................164
A.2.6. RTP Marker................................................164
A.2.7. RTP Payload Type..........................................164
A.2.8. RTP Sequence Number.......................................164
A.2.9. RTP Timestamp.............................................164
A.2.10. RTP Contributing Sources (CSRC)..........................165
A.3. Header compression strategies...............................165
A.3.1. Do not send at all........................................165
A.3.2. Transmit only initially...................................165
A.3.3. Transmit initially, but be prepared to update.............166
A.3.4. Be prepared to update or send as-is frequently............166
A.3.5. Guarantee continuous robustness...........................166
A.3.6. Transmit as-is in all packets.............................167
A.3.7. Establish and be prepared to update delta.................167
Full Copyright Statement..........................................168
During the last five years, two communication technologies in particular have become commonly used by the general public: cellular telephony and the Internet. Cellular telephony has provided its users with the revolutionary possibility of always being reachable with reasonable service quality no matter where they are. The main service provided by the dedicated terminals has been speech. The Internet, on the other hand, has from the beginning been designed for multiple services and its flexibility for all kinds of usage has been one of its strengths. Internet terminals have usually been general-purpose and have been attached over fixed connections. The experienced quality of some services (such as Internet telephony) has sometimes been low.
携帯電話やインターネット：過去5年間の間に、特に2つの通信技術は、一般的に、一般大衆によって使用されるようになっています。携帯電話は、常に彼らは関係なく、合理的なサービス品質で到達可能であることの革命的な可能性とそのユーザーに提供してきました。専用端末が提供する主なサービスは、音声となっています。インターネットは、他の一方で、最初から複数のサービスのために設計されており、利用状況のすべての種類の柔軟性は、その強みの一つとなっています。インターネット端末は、通常、汎用されていると、固定接続を介して接続されています。 （例えばインターネット電話など）いくつかのサービスの経験豊富な品質は、時々低かったです。
Today, IP telephony is gaining momentum thanks to improved technical solutions. It seems reasonable to believe that in the years to come, IP will become a commonly used way to carry telephony. Some future cellular telephony links might also be based on IP and IP telephony. Cellular phones may have become more general-purpose, and may have IP stacks supporting not only audio and video, but also web browsing, email, gaming, etc.
今日では、IPテレフォニーの向上技術的解決策に弾みのおかげを集めています。今後数年間で、IPテレフォニーを運ぶために一般的に使用される方法になるだろうと信じてすることは合理的と思われます。いくつかの将来の携帯電話リンクもIPやIP電話に基づいてされる可能性があります。携帯電話は、より汎用的になっている可能性があり、そしてなどだけでなく、オーディオやビデオ、だけでなく、Webブラウジング、電子メール、ゲームをサポートするIPスタックを有することができます
One of the scenarios we are envisioning might then be the one in Figure 1.1, where two mobile terminals are communicating with each other. Both are connected to base stations over cellular links, and the base stations are connected to each other through a wired (or possibly wireless) network. Instead of two mobile terminals, there could of course be one mobile and one wired terminal, but the case with two cellular links is technically more demanding.
我々が想定されるシナリオの一つは、2台の移動端末が互いに通信している図1.1中の1つ、であるかもしれません。双方は、セルラーリンクを介して基地局に接続され、基地局は、有線（あるいはワイヤレス）ネットワークを介して相互に接続されています。代わりに、2つの移動端末の、もちろん、一つの移動と一つ有線端末が、2つの細胞リンクの場合、技術的により厳しいである可能性があります。
Mobile Base Base Mobile Terminal Station Station Terminal
移動基地ベースのモバイルターミナル駅駅ターミナル
| ~ ~ ~ \ / \ / ~ ~ ~ ~ |
| | | |
+--+ | | +--+
| | | | | |
| | | | | |
+--+ | | +--+
| |
|=========================|
Cellular Wired Cellular
Link Network Link
Figure 1.1 : Scenario for IP telephony over cellular links
図1.1：携帯リンク上でIPテレフォニーのためのシナリオ
It is obvious that the wired network can be IP-based. With the cellular links, the situation is less clear. IP could be terminated in the fixed network, and special solutions implemented for each supported service over the cellular link. However, this would limit the flexibility of the services supported. If technically and economically feasible, a solution with pure IP all the way from terminal to terminal would have certain advantages. However, to make this a viable alternative, a number of problems have to be addressed, in particular problems regarding bandwidth efficiency.
有線ネットワークは、IPベースであることは明らかです。セルラーリンクを使用すると、状況はそれほど明確ではありません。 IPは固定ネットワークに終了することができ、特別な解決策は、セルラーリンク上でサポートされている各サービスのために実装されています。しかし、これはサポートされているサービスの柔軟性を制限します。技術的、経済的に実現可能な場合は、端末への端末からの純粋なIPとソリューションのすべての方法は、いくつかの利点を持っているでしょう。しかし、この実行可能な代替にするために、多くの問題は、帯域幅の効率に関する特定の問題に、対処する必要があります。
For cellular phone systems, it is of vital importance to use the scarce radio resources in an efficient way. A sufficient number of users per cell is crucial, otherwise deployment costs will be prohibitive. The quality of the voice service should also be as good as in today's cellular systems. It is likely that even with support for new services, lower quality of the voice service is acceptable only if costs are significantly reduced.
携帯電話システムの場合、それは効率的な方法で希少な無線リソースを使用するために極めて重要です。セルあたりのユーザーの十分な数がそうでない場合、展開コストは法外になり、非常に重要です。音声サービスの品質も、今日のセルラーシステムにおけるほど良いことがあります。それも、新しいサービスをサポートして、音声サービスの低品質、コストが大幅に削減されている場合にのみ許容されている可能性があります。
A problem with IP over cellular links when used for interactive voice conversations is the large header overhead. Speech data for IP telephony will most likely be carried by RTP [RTP]. A packet will then, in addition to link layer framing, have an IP [IPv4] header (20 octets), a UDP [UDP] header (8 octets), and an RTP header (12 octets) for a total of 40 octets. With IPv6 [IPv6], the IP header is 40 octets for a total of 60 octets. The size of the payload depends on the speech coding and frame sizes being used and may be as low as 15-20 octets.
インタラクティブ音声会話に使用セルラリンク上でIPに伴う問題は、大きなヘッダーオーバーヘッドです。 IPテレフォニーのための音声データは、最も可能性の高いRTP [RTP]によって運ばれます。パケットは、次に、層フレーミングをリンクするだけで、IP [IPv4の】ヘッダ（20オクテット）、UDP [UDP]ヘッダ（8つのオクテット）、および40オクテットの合計RTPヘッダ（12オクテット）を有するであろう。 IPv6の【のIPv6]で、IPヘッダは60オクテットの合計40オクテットです。ペイロードのサイズは、使用されている音声符号化とフレームのサイズに依存し、15〜20オクテットのように低くてもよいです。
From these numbers, the need for reducing header sizes for efficiency reasons is obvious. However, cellular links have characteristics that make header compression as defined in [IPHC,CRTP] perform less than well. The most important characteristic is the lossy behavior of cellular links, where a bit error rate (BER) as high as 1e-3 must be accepted to keep the radio resources efficiently utilized. In severe operating situations, the BER can be as high as 1e-2. The other problematic characteristic is the long round-trip time (RTT) of the cellular link, which can be as high as 100-200 milliseconds. An additional problem is that the residual BER is nontrivial, i.e., lower layers can sometimes deliver frames containing undetected errors. A viable header compression scheme for cellular links must be able to handle loss on the link between the compression and decompression point as well as loss before the compression point.
これらの数字から、効率上の理由からヘッダサイズを削減する必要性は明らかです。しかしながら、セルラリンクは[IPHC、CRTP]で定義されるようにヘッダ圧縮を行う特性が良く未満を行いました。最も重要な特徴は、1E-3と高いビット誤り率（BER）を効率的に利用する無線リソースを維持するために受け入れなければならないセルラリンク、の非可逆動作です。過酷な状況では、BERが1E-2と高くすることができます。他の問題の特徴は、100-200ミリ秒ほど高くすることができるセルラリンク、の長いラウンドトリップ時間（RTT）です。さらなる問題は、残留BER、すなわち、下位層は時々検出されないエラーを含むフレームを提供することができ、非自明なことです。携帯リンクのための実行可能なヘッダ圧縮方式は、圧縮ポイントの前に圧縮および伸張ポイントとの間のリンク上の損失だけでなく、損失を処理できなければなりません。
Bandwidth is the most costly resource in cellular links. Processing power is very cheap in comparison. Implementation or computational simplicity of a header compression scheme is therefore of less importance than its compression ratio and robustness.
帯域幅は、セルラーリンクの中で最も高価な資源です。処理能力は、比較して非常に安価です。実装またはヘッダ圧縮スキームの計算の単純さは、従って、その圧縮比と堅牢未満に重要です。
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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
BER
BER
Bit Error Rate. Cellular radio links can have a fairly high BER. In this document BER is usually given as a probability, but one also needs to consider the error distribution as bit errors are not independent.
ビット・エラー・レート。セルラー無線リンクがかなり高いBERを持つことができます。この文書ではBERは、通常、確率として与えられるが、一つはまた、ビットエラーが独立していないと誤差分布を考慮する必要があります。
Cellular links
セルラーリンク
Wireless links between mobile terminals and base stations.
モバイル端末と基地局との間の無線リンク。
Compression efficiency
圧縮効率
The performance of a header compression scheme can be described with three parameters: compression efficiency, robustness and compression transparency. The compression efficiency is determined by how much the header sizes are reduced by the compression scheme.
圧縮効率、堅牢性および圧縮透明度：ヘッダ圧縮スキームの性能は、三つのパラメータで記述することができます。圧縮効率は、ヘッダサイズは圧縮方式によって低減されるどの程度によって決定されます。
Compression transparency
圧縮透明性
The performance of a header compression scheme can be described with three parameters: compression efficiency, robustness, and compression transparency. The compression transparency is a measure of the extent to which the scheme ensures that the decompressed headers are semantically identical to the original headers. If all decompressed headers are semantically identical to the corresponding original headers, the transparency is 100 percent. Compression transparency is high when damage propagation is low.
圧縮効率、堅牢性、および圧縮透明度：ヘッダ圧縮スキームの性能は、三つのパラメータで記述することができます。圧縮透明度スキームを減圧ヘッダが元のヘッダと意味的に同じであることを保証する程度の尺度です。全て解凍ヘッダが対応するオリジナルヘッダと意味的に同じである場合、透明度が100％です。ダメージの伝播が低いときに圧縮透明性が高いです。
Context
状況
The context of the compressor is the state it uses to compress a header. The context of the decompressor is the state it uses to decompress a header. Either of these or the two in combination are usually referred to as "context", when it is clear which is intended. The context contains relevant information from previous headers in the packet stream, such as static fields and possible reference values for compression and decompression. Moreover, additional information describing the packet stream is also part of the context, for example information about how the IP Identifier field changes and the typical inter-packet increase in sequence numbers or timestamps.
コンプレッサのコンテキストは、ヘッダを圧縮するために使用する状態です。解凍器のコンテキストは、ヘッダを解凍するために使用する状態です。意図されている明確であるときに、これらのまたは組み合わせで2のいずれかが、通常は、「文脈」と呼ばれています。コンテキストは、静的フィールドと圧縮および圧縮解除のための可能な基準値としてパケットストリーム内の前のヘッダからの関連情報が含まれています。また、パケットストリームを記述する追加情報がどのIP識別子フィールドの変更およびシーケンス番号またはタイムスタンプにおける典型的なパケット間の増加に関する情報、例えば、また、コンテキストの一部です。
Context damage
コンテキストの損傷
When the context of the decompressor is not consistent with the context of the compressor, decompression may fail to reproduce the original header. This situation can occur when the context of the decompressor has not been initialized properly or when packets have been lost or damaged between compressor and decompressor.
解凍器のコンテキストが圧縮器のコンテキストと一致しない場合、減圧は、元のヘッダを再生できない場合があります。デコンプレッサのコンテキストが適切に初期化されていない場合、またはパケットがコンプレッサーと減圧器との間で紛失または破損している場合に、このような状況が発生する可能性があります。
Packets which cannot be decompressed due to inconsistent contexts are said to be lost due to context damage. Packets that are decompressed but contain errors due to inconsistent contexts are said to be damaged due to context damage.
一貫性のないコンテキストに解凍することができないパケットは原因コンテキストの損傷に失われると言われています。解凍が、一貫性のない状況に起因する誤差が含まれているパケットは原因コンテキストの損傷に破損すると言われています。
Context repair mechanism
コンテキスト修復機構
Context repair mechanisms are mechanisms that bring the contexts in sync when they were not. This is needed to avoid excessive loss due to context damage. Examples are the context request mechanism of CRTP, the NACK mechanisms of O- and R-mode, and the periodic refreshes of U-mode.
コンテキスト修復メカニズムは、彼らがいなかった時に同期して、コンテキストをもたらすメカニズムです。これは、コンテキストの損傷に起因する過剰損失を避けるために必要とされます。例としては、CRTPの文脈要求機構、O-及びRモードのNACK機構、及びUモードの周期的リフレッシュです。
Note that there are also mechanisms that prevent (some) context inconsistencies from occurring, for example the ACK-based updates of the context in R-mode, the repetitions after change in U- and O-mode, and the CRCs which protect context updating information.
防ぐ例えば、RモードのコンテキストのACKベースの更新を生じるから（いくつかの）コンテキストの不整合は、U-およびOモード、およびCRCの変更後の繰り返しは、コンテキストの更新を保護する機構も存在することに注意してください情報。
CRC-DYNAMIC
CRC-DYNAMIC
Opposite of CRC-STATIC.
CRC-STATICの反対。
CRC-STATIC
CRC-STATIC
A CRC over the original header is the primary mechanism used by ROHC to detect incorrect decompression. In order to decrease computational complexity, the fields of the header are conceptually rearranged when the CRC is computed, so that it is first computed over octets which are static (called CRC-STATIC in this document) and then over octets whose values are expected to change between packets (CRC-DYNAMIC). In this manner, the intermediate result of the CRC computation, after it has covered the CRC-STATIC fields, can be reused for several packets. The restarted CRC computation only covers the CRC-DYNAMIC octets. See section 5.9.
元のヘッダー上CRCが正しくない減圧を検出するためにROHCによって使用される主要なメカニズムです。 CRCが計算されたときに、最初に（本書ではCRC-STATICと呼ばれる）静的、次いでその値が予想されるオクテットを超えているオクテットにわたって計算されるように、計算の複雑さを低減するために、ヘッダのフィールドは、概念的に、再配置されますパケット（CRC-DYNAMIC）との間の変化。それはCRC-STATICフィールドをカバーした後、このように、CRC計算の中間結果は、いくつかのパケットのために再利用することができます。再起動CRC計算はCRC-DYNAMICオクテットをカバーしています。セクション5.9を参照してください。
Damage propagation
ダメージ伝播
Delivery of incorrect decompressed headers, due to errors in (i.e., loss of or damage to) previous header(s) or feedback.
原因（すなわち、への損失または損傷）前ヘッダ（S）またはフィードバックのエラーを誤っ解凍ヘッダの配達。
Loss propagation
損失の伝播
Loss of headers, due to errors in (i.e., loss of or damage to) previous header(s)or feedback.
（すなわち、損失または損傷に）の誤差に起因するヘッダの喪失、前ヘッダ（S）またはフィードバック。
Error detection
エラー検出
Detection of errors. If error detection is not perfect, there will be residual errors.
エラーの検出。エラー検出が完全でない場合は、残留エラーが発生します。
Error propagation
エラー伝播
Damage propagation or loss propagation.
被害伝播や損失伝播。
Header compression profile
ヘッダ圧縮プロファイル
A header compression profile is a specification of how to compress the headers of a certain kind of packet stream over a certain kind of link. Compression profiles provide the details of the header compression framework introduced in this document. The profile concept makes use of profile identifiers to separate different profiles which are used when setting up the compression scheme. All variations and parameters of the header compression scheme that are not part of the context state are handled by different profile identifiers.
ヘッダ圧縮プロファイルは、リンクの特定の種類を超えるパケットストリームの特定の種類のヘッダを圧縮する方法の仕様です。圧縮プロフィールは、本書で紹介したヘッダ圧縮フレームワークの詳細を提供します。プロファイルの概念は、圧縮方式を設定するときに使用されている別のプロファイルを分離するために、プロファイル識別子を使用しています。コンテキスト状態の一部ではないヘッダ圧縮スキームの全ての変形およびパラメータは、異なるプロファイル識別子によって処理されます。
Packet
パケット
Generally, a unit of transmission and reception (protocol data unit). Specifically, when contrasted with "frame", the packet compressed and then decompressed by ROHC. Also called "uncompressed packet".
一般に、送受信（プロトコルデータユニット）のユニット。具体的には、「フレーム」、圧縮されたパケットと対比した後、ROHCで減圧。また、「非圧縮パケット」と呼ばれます。
Packet Stream
パケットストリーム
A sequence of packets where the field values and change patterns of field values are such that the headers can be compressed using the same context.
フィールド値のフィールド値と変化パターンがヘッダーが同じコンテキストを使用して圧縮することができるようになっているパケットのシーケンス。
Pre-HC links
前HCリンク
The Pre-HC links are all links that a packet has traversed before the header compression point. If we consider a path with cellular links as first and last hops, the Pre-HC links for the compressor at the last link are the first cellular link plus the wired links in between.
プレHCリンクは、パケットがヘッダ圧縮ポイントの前に横断したすべてのリンクです。我々は最初と最後のホップのような細胞のリンクを持つパスを考慮した場合、最後のリンクで圧縮機の前HCのリンクは、第1のセルラーリンクプラスの間で、有線のリンクです。
Residual error
残差
Error introduced during transmission and not detected by lower-layer error detection schemes.
エラーが送信中に導入され、下層誤り検出方式によって検出されません。
Robustness
丈夫
The performance of a header compression scheme can be described with three parameters: compression efficiency, robustness, and compression transparency. A robust scheme tolerates loss and residual errors on the link over which header compression takes place without losing additional packets or introducing additional errors in decompressed headers.
圧縮効率、堅牢性、および圧縮透明度：ヘッダ圧縮スキームの性能は、三つのパラメータで記述することができます。ロバストな方式は、ヘッダ圧縮は、追加のパケットを失ったり解凍ヘッダに追加の誤差を導入せずに行われる上リンク上の損失および残留誤差を許容します。
RTT
RTT
The RTT (round-trip time) is the time elapsing from the moment the compressor sends a packet until it receives feedback related to that packet (when such feedback is sent).
RTT（ラウンドトリップ時間）は、（例えば、フィードバックが送信される）、そのパケットに関連するフィードバックを受信するまで圧縮機がパケットを送信した時点からの経過時間です。
Spectrum efficiency
スペクトル効率
Radio resources are limited and expensive. Therefore they must be used efficiently to make the system economically feasible. In cellular systems this is achieved by maximizing the number of users served within each cell, while the quality of the provided services is kept at an acceptable level. A consequence of efficient spectrum use is a high rate of errors (frame loss and residual bit errors), even after channel coding with error correction.
無線リソースは限られ、高価です。そこで彼らは、システムが経済的に実現可能にするために効率的に使用する必要があります。セルラシステムでは、これは、提供されるサービスの品質が許容可能なレベルに維持しつつ、各セル内で配信ユーザの数を最大にすることによって達成されます。効率的なスペクトル使用の結果は、チャネルが誤り訂正符号化した後でも、エラー（フレーム損失および残留ビットエラー）の高い割合です。
String
弦
A sequence of headers in which the values of all fields being compressed change according to a pattern which is fixed with respect to a sequence number. Each header in a string can be compressed by representing it with a ROHC header which essentially only carries an encoded sequence number. Fields not being compressed (e.g., random IP-ID, UDP Checksum) are irrelevant to this definition.
すべてのフィールドの値がシーケンス番号に対して固定されたパターンに応じて変化し、圧縮されたヘッダのシーケンス。文字列内の各ヘッダは、本質的にのみ符号化されたシーケンス番号を運ぶROHCヘッダとそれを表すことによって圧縮することができます。 （例えば、ランダムIP-ID、UDPチェックサム）が圧縮されていないフィールドは、この定義とは無関係です。
Timestamp stride
タイムスタンプストライド
The timestamp stride (TS_STRIDE) is the expected increase in the timestamp value between two RTP packets with consecutive sequence numbers.
タイムスタンプストライド（TS_STRIDE）が連続したシーケンス番号を有する2つのRTPパケット間のタイムスタンプ値の予想増加です。
This section lists most acronyms used for reference.
このセクションでは、参考のために使用されるほとんどの頭字語を示しています。
AH Authentication Header. CID Context Identifier. CRC Cyclic Redundancy Check. Error detection mechanism. CRTP Compressed RTP. RFC 2508. CTCP Compressed TCP. Also called VJ header compression. RFC 1144. ESP Encapsulating Security Payload. FC Full Context state (decompressor). FO First Order state (compressor). GRE Generic Routing Encapsulation. RFC 2784, RFC 2890. HC Header Compression. IPHC IP Header Compression. RFC 2507. IPX Flag in Extension 2. IR Initiation and Refresh state (compressor). Also IR packet. IR-DYN IR-DYN packet. LSB Least Significant Bits. MRRU Maximum Reconstructed Reception Unit. MTU Maximum Transmission Unit. MSB Most Significant Bits. NBO Flag indicating whether the IP-ID is in Network Byte Order. NC No Context state (decompressor). O-mode Bidirectional Optimistic mode. PPP Point-to-Point Protocol. R-mode Bidirectional Reliable mode. RND Flag indicating whether the IP-ID behaves randomly. ROHC RObust Header Compression. RTCP Real-Time Control Protocol. See RTP. RTP Real-Time Protocol. RFC 1889. RTT Round Trip Time (see section 2). SC Static Context state (decompressor). SN (compressed) Sequence Number. Usually RTP Sequence Number. SO Second Order state (compressor). SPI Security Parameters Index. SSRC Sending source. Field in RTP header. CSRC Contributing source. Optional list of CSRCs in RTP header. TC Traffic Class. Octet in IPv6 header. See also TOS. TOS Type Of Service. Octet in IPv4 header. See also TC. TS (compressed) RTP Timestamp. U-mode Unidirectional mode. W-LSB Window based LSB encoding. See section 4.5.2.
AH認証ヘッダー。 CIDコンテキスト識別子。 CRC巡回冗長検査。エラー検出メカニズム。 CRTP圧縮RTP。 RFC 2508 CTCP圧縮TCP。また、VJヘッダ圧縮と呼ばれます。 RFC 1144 ESPカプセル化セキュリティペイロード。 FC完全なコンテキスト状態（減圧装置）。 FO一次状態（コンプレッサー）。 GRE総称ルーティングカプセル化。 RFC 2784、RFC 2890. HCヘッダ圧縮。 IPHC IPヘッダー圧縮。 RFC 2507 IPX拡張2. IR開始のフラグとリフレッシュ状態（圧縮機）。また、IRパケット。 IR-DYN IR-DYNパケット。 LSB最下位ビット。 MRRU最大は、受信部を再構築します。 MTU最大伝送単位。 MSB最上位ビットが。 IP-IDは、ネットワークバイト順であるかどうかを示すフラグNBO。 NCいいえ文脈状態（デコンプレッサ）。 Oモード双方向楽観モード。 PPPポイントツーポイントプロトコル。 R-モード双方向の信頼できるモード。 IP-IDは、ランダムに動作しているかどうかを示すフラグRND。 ROHCロバストヘッダ圧縮。 RTCPリアルタイム制御プロトコル。 RTPを参照してください。 RTPリアルタイムプロトコル。 RFC 1889 RTTラウンドトリップタイム（セクション2を参照）。 SC静的コンテキスト状態（デコンプレッサ）。 SN（圧縮）シーケンス番号。通常、RTPシーケンス番号。 SO二次状態（コンプレッサー）。 SPIセキュリティパラメータインデックス。 SSRCは、ソースを送信します。 RTPヘッダ内のフィールド。 CSRCは、ソースを貢献します。 RTPヘッダ内のCSRCsのオプションのリスト。 TCトラフィッククラス。 IPv6ヘッダーのオクテット。また、TOSを参照してください。サービスのTOSタイプ。 IPv4ヘッダーのオクテット。また、TCを参照してください。 TS RTPタイムスタンプ（圧縮）。 U-モード単方向モード。 W-LSBウィンドウベースのLSBエンコーディング。セクション4.5.2を参照してください。
This chapter provides a background to the subject of header compression. The fundamental ideas are described together with existing header compression schemes. Their drawbacks and requirements are then discussed, providing motivation for new header compression solutions.
この章では、ヘッダ圧縮の被写体の背景を提供します。基本的なアイデアは、既存のヘッダ圧縮スキームと併せて説明します。彼らの欠点と要件は、新しいヘッダ圧縮ソリューションのための動機を提供し、議論されています。
The main reason why header compression can be done at all is the fact that there is significant redundancy between header fields, both within the same packet header but in particular between consecutive packets belonging to the same packet stream. By sending static field information only initially and utilizing dependencies and predictability for other fields, the header size can be significantly reduced for most packets.
ヘッダ圧縮は、全てで行うことができる主な理由は、ヘッダフィールドの間に有意な冗長性は、同じパケットヘッダ内の同じパケットストリームに属する連続するパケット間の特定の両方があるという事実です。のみ最初に静的なフィールド情報を送信し、他のフィールドに対する従属関係と予測可能性を利用することによって、ヘッダのサイズが大幅にほとんどのパケットのために低減することができます。
Relevant information from past packets is maintained in a context. The context information is used to compress (decompress) subsequent packets. The compressor and decompressor update their contexts upon certain events. Impairment events may lead to inconsistencies between the contexts of the compressor and decompressor, which in turn may cause incorrect decompression. A robust header compression scheme needs mechanisms for avoiding context inconsistencies and also needs mechanisms for making the contexts consistent when they were not.
過去のパケットからの関連情報は、コンテキスト内で維持されています。コンテキスト情報は、（解凍）後続パケットを圧縮するために使用されます。コンプレッサーと減圧器は、特定のイベント時にそのコンテキストを更新します。減損イベントは順番に間違った解凍を引き起こす可能性があり、コンプレッサとデコンプレッサのコンテキスト間で不整合が生じることがあります。堅牢なヘッダ圧縮方式は、コンテキストの不整合を回避するための仕組みが必要であり、また、彼らがいなかったときの状況を一貫させるための仕組みが必要です。
The original header compression scheme, CTCP [VJHC], was invented by Van Jacobson. CTCP compresses the 40 octet IP+TCP header to 4 octets. The CTCP compressor detects transport-level retransmissions and sends a header that updates the context completely when they occur. This repair mechanism does not require any explicit signaling between compressor and decompressor.
元のヘッダ圧縮方式、CTCP [VJHC]は、バン・ジェイコブソンによって発明されました。 CTCPは、4つのオクテットの40オクテットIP + TCPヘッダを圧縮します。 CTCP圧縮機は、トランスポート・レベルの再送信を検出し、それらが発生したときに完全にコンテキストを更新ヘッダを送信します。この修復機構は、コンプレッサとデコンプレッサとの間の明示的なシグナリングを必要としません。
A general IP header compression scheme, IP header compression [IPHC], improves somewhat on CTCP and can compress arbitrary IP, TCP, and UDP headers. When compressing non-TCP headers, IPHC does not use delta encoding and is robust. When compressing TCP, the repair mechanism of CTCP is augmented with a link-level nacking scheme which speeds up the repair. IPHC does not compress RTP headers.
一般的なIPヘッダ圧縮方式、IPヘッダー圧縮[IPHC]は、CTCPに幾分改善し、任意のIP、TCP、及びUDPヘッダを圧縮することができます。非TCPヘッダを圧縮する場合、IPHCはデルタエンコーディングを使用し、堅牢ではありません。 TCPを圧縮すると、CTCPの修理メカニズムは、修理をスピードアップリンクレベルnacking方式に強化されています。 IPHCはRTPヘッダを圧縮しません。
CRTP [CRTP, IPHC] by Casner and Jacobson is a header compression scheme that compresses 40 octets of IPv4/UDP/RTP headers to a minimum of 2 octets when the UDP Checksum is not enabled. If the UDP Checksum is enabled, the minimum CRTP header is 4 octets. CRTP cannot use the same repair mechanism as CTCP since UDP/RTP does not retransmit. Instead, CRTP uses explicit signaling messages from decompressor to compressor, called CONTEXT_STATE messages, to indicate that the context is out of sync. The link round-trip time will thus limit the speed of this context repair mechanism.
CasnerとヤコブソンによってCRTP [CRTP、IPHC]はUDPチェックサムが有効でない場合に2つのオクテットの最小値へのIPv4 / UDP / RTPヘッダの40個のオクテットを圧縮するヘッダ圧縮方式です。 UDPチェックサムが有効になっている場合、最小のCRTPヘッダは4つのオクテットです。 UDP / RTPを再送しないので、CRTPはCTCPと同じ修復機構を使用することはできません。その代わりに、CRTPは、コンテキストが同期外れであることを示すために、CONTEXT_STATEメッセージと呼ばれ、圧縮機に減圧装置から明示的なシグナリングメッセージを使用します。リンクのラウンドトリップ時間は、このように、この文脈の修復機構の速度を制限します。
On lossy links with long round-trip times, such as most cellular links, CRTP does not perform well. Each lost packet over the link causes several subsequent packets to be lost since the context is out of sync during at least one link round-trip time. This behavior is documented in [CRTPC]. For voice conversations such long loss events will degrade the voice quality. Moreover, bandwidth is wasted by the large headers sent by CRTP when updating the context. [CRTPC] found that CRTP did not perform well enough for a lossy cellular link. It is clear that CRTP alone is not a viable header compression scheme for IP telephony over cellular links.
そのようなほとんどの細胞リンクなどの長い往復時間と非可逆のリンク、で、CRTPはうまく実行されません。リンク上の各失われたパケットは、コンテキストが少なくとも1つのリンクのラウンドトリップ時間の間、同期していないので、いくつかの後続のパケットが失われます。この動作は、[CRTPC]に記述されています。音声会話のために、このような長い損失イベントは、音声品質が低下します。また、帯域幅は、コンテキストを更新するときCRTPによって送信された大ヘッダによって浪費されます。 [CRTPC] CRTPは損失セルラーリンクについて十分に行われなかったことがわかりました。それだけではCRTPは、携帯リンク上でIPテレフォニーのための実行可能なヘッダ圧縮方式ではないことは明らかです。
To avoid losing packets due to the context being out of sync, CRTP decompressors can attempt to repair the context locally by using a mechanism known as TWICE. Each CRTP packet contains a counter which is incremented by one for each packet sent out by the CRTP compressor. If the counter increases by more than one, at least one packet was lost over the link. The decompressor then attempts to repair the context by guessing how the lost packet(s) would have updated it. The guess is then verified by decompressing the packet and checking the UDP Checksum -- if it succeeds, the repair is deemed successful and the packet can be forwarded or delivered. TWICE derives its name from the observation that when the compressed packet stream is regular, the correct guess is to apply the update in the current packet twice. [CRTPC] found that even with TWICE, CRTP doubled the number of lost packets. TWICE improves CRTP performance significantly. However, there are several problems with using TWICE:
同期がずれているコンテキストにパケットを失うことを避けるために、CRTPの圧縮解除はTWICEとして知られているメカニズムを使用して、ローカルコンテキストを修復を試みることができます。各CRTPパケットはCRTP圧縮機によって送信される各パケットについて1だけインクリメントされるカウンタを含んでいます。以上のことにより、カウンタが増加した場合、少なくとも1つのパケットがリンクの上に失われました。デコンプレッサは、失われたパケット（s）はそれを更新しているだろうか推測してコンテキストを修復しようとします。推測では、パケットを解凍し、UDPチェックサムをチェックすることで検証される - それは成功した場合、修復が成功したとみなされ、パケットが転送または配信することができます。 TWICE圧縮されたパケットストリームが規則的であるとき、正しい推測は二回、現在のパケット内のアップデートを適用することであるという観察からその名の由来。 【CRTPC]も2回、CRTPは、失われたパケットの数を倍増することを見出しました。 TWICE大幅CRTP性能を向上させます。しかし、TWICE使用にはいくつかの問題があります。
1) It becomes mandatory to use the UDP Checksum:
1）これは、UDPチェックサムを使用することが必須になります：
- the minimal compressed header size increases by 100% to 4 octets.
- 4つのオクテットから100％の最小の圧縮ヘッダのサイズが大きくなります。
- most speech codecs developed for cellular links tolerate errors in the encoded data. Such codecs will not want to enable the UDP Checksum, since they do want damaged packets to be delivered.
- セルラーリンク用に開発された最も音声コーデックは、エンコードされたデータのエラーを許容します。彼らは、破損したパケットを配信することにしたいんので、そのようなコーデックは、UDPチェックサムを有効にする必要はありません。
- errors in the payload will make the UDP Checksum fail when the guess is correct (and might make it succeed when the guess is wrong).
- ペイロード中のエラーは推測が正しい場合、UDPチェックサムが失敗になります（と推測が間違っているとき、それは成功するかもしれません）。
2) Loss in an RTP stream that occurs before the compression point will make updates in CRTP headers less regular. Simple-minded versions of TWICE will then perform badly. More sophisticated versions would need more repair attempts to succeed.
2）圧縮ポイントの前に発生したRTPストリームの損失はCRTPヘッダーの更新が少なく、通常のようになります。 TWICEのシンプル志向のバージョンは、ひどく実行します。より洗練されたバージョンでは、成功するために多くの修復の試行が必要になります。
The major problem with CRTP is that it is not sufficiently robust against packets being damaged between compressor and decompressor. A viable header compression scheme must be less fragile. This increased robustness must be obtained without increasing the compressed header size; a larger header would make IP telephony over cellular links economically unattractive.
CRTPの主要な問題は、それが、コンプレッサとデコンプレッサとの間で損傷されるパケットに対して十分に強固ではないということです。実行可能なヘッダ圧縮方式はあまり脆弱でなければなりません。この増加したロバスト性は、圧縮ヘッダのサイズを増大させることなく得られなければなりません。大きなヘッダは、セルラーリンク上でIPテレフォニーは、経済的に魅力のないものでしょう。
A major cause of the bad performance of CRTP over cellular links is the long link round-trip time, during which many packets are lost when the context is out of sync. This problem can be attacked directly by finding ways to reduce the link round-trip time. Future generations of cellular technologies may indeed achieve lower link round-trip times. However, these will probably always be fairly high. The benefits in terms of lower loss and smaller bandwidth demands if the context can be repaired locally will be present even if the link round-trip time is decreased. A reliable way to detect a successful context repair is then needed.
携帯リンク上CRTPの悪いパフォーマンスの主な原因は、コンテキストが同期しているとき、多くのパケットが失われた時に、長いリンクのラウンドトリップ時間です。この問題は、リンクのラウンドトリップ時間を削減する方法を見つけることによって、直接攻撃することができます。携帯電話技術の将来の世代は確かに下のリンク往復時間を達成することができます。しかし、これらはおそらく、常にかなり高くなります。低損失およびコンテキストをローカルに修復することができ、リンクのラウンドトリップ時間が減少した場合でも存在する場合には小さな帯域幅需要の面でメリット。成功したコンテキストの修復を検出する信頼性の高い方法は、その後、必要とされています。
One might argue that a better way to solve the problem is to improve the cellular link so that packet loss is less likely to occur. Such modifications do not appear to come for free, however. If links were made (almost) error free, the system might not be able to support a sufficiently large number of users per cell and might thus be economically infeasible.
一つは、この問題を解決するためのより良い方法は、パケットロスが発生しにくくなるように、セルラーリンクを向上させることであると主張するかもしれません。このような改変は、しかし、自由のために来るように表示されません。リンクは（ほとんど）エラーフリー行われた場合、システムは、セルあたりのユーザーの十分な数をサポートすることができない場合がありますので、経済的に実行不可能であるかもしれません。
One might also argue that the speech codecs should be able to deal with the kind of packet loss induced by CRTP, in particular since the speech codecs probably must be able to deal with packet loss anyway if the RTP stream crosses the Internet. While the latter is true, the kind of loss induced by CRTP is difficult to deal with. It is usually not possible to completely hide a loss event where well over 100 ms worth of sound is completely lost. If such loss occurs frequently at both ends of the end-to-end path, the speech quality will suffer.
一つは、また、音声コーデックは、おそらくRTPストリームがインターネットを横断する場合は、とにかく、パケット損失に対処することができなければならないので、音声コーデックは特に、CRTPによって誘導されたパケット損失の種類に対処することができるはずと主張するかもしれません。後者は事実ですが、CRTPによって誘発される損失の種類は対処することは困難です。完全に音の価値をはるかに超える100ミリ秒が完全に失われた損失イベントを非表示にすることは通常不可能です。こうした損失は、エンドツーエンドのパスの両端で頻繁に発生する場合は、音声品質が低下します。
A detailed description of the requirements specified for ROHC may be found in [REQ].
ROHCのために指定された要件の詳細な説明は[REQ]に見出すことができます。
As mentioned earlier, header compression is possible due to the fact that there is much redundancy between header field values within packets, but especially between consecutive packets. To utilize these properties for header compression, it is important to understand the change patterns of the various header fields.
前述したように、ヘッダ圧縮が原因パケット内のヘッダフィールド値の間に大きな冗長性があるが、特に連続するパケットの間に、あるという事実のために可能です。ヘッダ圧縮のためにこれらの特性を利用するために、様々なヘッダフィールドの変化パターンを理解することが重要です。
All header fields have been classified in detail in appendix A. The fields are first classified at a high level and then some of them are studied more in detail. Finally, the appendix concludes with recommendations on how the various fields should be handled by header compression algorithms. The main conclusion that can be drawn is that most of the header fields can easily be compressed away since they never or seldom change. Only 5 fields, with a combined size of about 10 octets, need more sophisticated mechanisms. These fields are:
すべてのヘッダフィールドは、フィールドが最初にハイレベルに分類され、その後、それらのいくつかがより詳細に検討されている付録Aに詳細に分類されています。最後に、付録は、様々なフィールドがヘッダ圧縮アルゴリズムによって処理されるべき方法に関する推奨事項と結論します。描画することができます主な結論は、彼らは決して変わらないか、めったにないので、ヘッダフィールドのほとんどは簡単に離れて圧縮することができるということです。唯一の5つのフィールドには、約10オクテットの合計サイズで、より洗練されたメカニズムが必要です。これらのフィールドは以下のとおりです。
- IPv4 Identification (16 bits) - IP-ID - UDP Checksum (16 bits) - RTP Marker (1 bit) - M-bit - RTP Sequence Number (16 bits) - SN - RTP Timestamp (32 bits) - TS
- IPv4の識別（16ビット） - IP-ID - UDPチェックサム（16ビット） - RTPマーカ（1ビット） - Mビット - RTPシーケンス番号（16ビット） - SN - RTPタイムスタンプ（32ビット） - TS
The analysis in Appendix A reveals that the values of the TS and IP-ID fields can usually be predicted from the RTP Sequence Number, which increments by one for each packet emitted by an RTP source. The M-bit is also usually the same, but needs to be communicated explicitly occasionally. The UDP Checksum should not be predicted and is sent as-is when enabled.
付録Aの分析は、TS及びIP-IDフィールドの値は、通常、RTP光源によって放出された各パケットについて1ずつインクリメントRTPシーケンス番号から予測することができることがわかります。 Mビットも通常は同じですが、明示的に時折通信する必要があります。 UDPチェックサムを予測すべきでないと有効にした場合であるとして、送信されます。
The way ROHC RTP compression operates, then, is to first establish functions from SN to the other fields, and then reliably communicate the SN. Whenever a function from SN to another field changes, i.e., the existing function gives a result which is different from the field in the header to be compressed, additional information is sent to update the parameters of that function.
ROHC RTP圧縮が動作する方法は、その後、最初の他の分野にSNの機能を確立し、その後、確実SNを伝達することです。別のフィールドの変更にSNの機能、すなわち、既存の機能が圧縮されるヘッダフィールドとは異なる結果が得られるたびに、追加の情報は、その関数のパラメータを更新するために送られます。
Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any special treatment in this document. They are compressible, however, and it is expected that the compression efficiency for Mobile IP headers will be good enough due to the handling of extension header lists and tunneling headers. It would be relatively painless to introduce a new ROHC profile with special treatment for Mobile IPv6 specific headers should the completed work on the Mobile IPv6 protocols (work in progress in the IETF) make that necessary.
（IPv4またはIPv6のための）モバイルIPに固有のヘッダは、この文書に記載されている特別な治療を受けていません。しかし彼らは、圧縮可能であり、モバイルIPヘッダの圧縮効率が原因拡張ヘッダリストとトンネリングヘッダの取り扱いに十分であることが期待されます。モバイルIPv6プロトコル（IETFで作業中）に完成した作品は、それが必要で行う必要がありますモバイルIPv6特定のヘッダのための特別な治療と新しいROHCプロファイルを導入する比較的簡単でしょう。
Cellular links, which are a primary target for ROHC, have a number of characteristics that are described briefly here. ROHC requires functionality from lower layers that is outlined here and more thoroughly described in the lower layer guidelines document [LLG].
ROHCのための主要なターゲットですセルラーリンクは、ここで簡単に説明されている多くの特性を持っています。 ROHCは、ここで説明し、より徹底的下層ガイドラインドキュメント[LLG]に記載されている下位層からの機能を必要とします。
Channels
チャンネル
ROHC header-compressed packets flow on channels. Unlike many fixed links, some cellular radio links can have several channels connecting the same pair of nodes. Each channel can have different characteristics in terms of error rate, bandwidth, etc.
ROHCヘッダ圧縮パケットは、チャネルに流れます。多くの固定リンクとは異なり、いくつかのセルラ無線リンクは、ノードの同じペアを結ぶ複数のチャンネルを有することができます。各チャネルは、エラー・レート、帯域幅などの面で異なる特性を持つことができます
Context identifiers
コンテキスト識別子
On some channels, the ability to transport multiple packet streams is required. It can also be feasible to have channels dedicated to individual packet streams. Therefore, ROHC uses a distinct context identifier space per channel and can eliminate context identifiers completely for one of the streams when few streams share a channel.
いくつかのチャンネルでは、複数のパケットストリームを輸送する能力が必要とされます。また、個々のパケットストリーム専用のチャンネルを持っていることが実現可能であることができます。したがって、ROHCはチャンネルごとに異なるコンテクスト識別子空間を使用し、いくつかのストリームはチャネルを共有する場合のストリームのいずれかの完全コンテキスト識別子を排除することができます。
Packet type indication
パケットタイプの指示
Packet type indication is done in the header compression scheme itself. Unless the link already has a way of indicating packet types which can be used, such as PPP, this provides smaller compressed headers overall. It may also be less difficult to allocate a single packet type, rather than many, in order to run ROHC over links such as PPP.
パケットタイプの指示は、ヘッダ圧縮スキーム自体で行われます。リンクが既にPPPなどを使用することができるパケットタイプを示す方法を持っていない限り、これが全体的なより小さな圧縮ヘッダを提供します。また、PPPなどのリンク上でROHCを実行するために、かなり多くのよりも、単一パケットタイプを割り当てることが少なく難しいかもしれません。
Reordering
並べ替え
The channel between compressor and decompressor is required to maintain packet ordering, i.e., the decompressor must receive packets in the same order as the compressor sent them. (Reordering before the compression point, however, is dealt with, i.e., there is no assumption that the compressor will only receive packets in sequence.)
コンプレッサとデコンプレッサとの間のチャネルがパケットの順序を維持するために必要とされる、即ち、解凍器は、圧縮機がそれらを送信と同じ順序でパケットを受信しなければなりません。 （圧縮点の前に並べ替え、しかし、扱われる、すなわち、圧縮機のみの順序でパケットを受信することは想定されていません。）
Duplication
複製
The channel between compressor and decompressor is required to not duplicate packets. (Duplication before the compression point, however, is dealt with, i.e., there is no assumption that the compressor will receive only one copy of each packet.)
コンプレッサとデコンプレッサとの間のチャネルがパケットを複製しないことが要求されます。 （複製は、圧縮ポイントの前に、しかし、圧縮機は各パケットのコピーを1つだけ受信するという仮定が存在しない、すなわち、扱われています。）
Packet length
パケット長
ROHC is designed under the assumption that lower layers indicate the length of a compressed packet. ROHC packets do not contain length information for the payload.
ROHCは、下位層が圧縮されたパケットの長さを示すという仮定の下に設計されています。 ROHCパケットは、ペイロードの長さの情報が含まれていません。
Framing
フレーミング
The link layer must provide framing that makes it possible to distinguish frame boundaries and individual frames.
リンク層はフレーム境界と個々のフレームを区別することが可能となり、フレーミングを提供しなければなりません。
Error detection/protection
エラー検出/保護
The ROHC scheme has been designed to cope with residual errors in the headers delivered to the decompressor. CRCs and sanity checks are used to prevent or reduce damage propagation. However, it is RECOMMENDED that lower layers deploy error detection for ROHC headers and do not deliver ROHC headers with high residual error rates.
ROHC方式は、減圧装置に配信ヘッダ中の残留エラーに対処するように設計されています。 CRCと妥当性チェックが損傷伝播を防止または低減するために使用されます。しかし、下位層がROHCヘッダのエラー検出を展開し、高い残留エラー率でROHCヘッダを提供しないことをお勧めします。
Without giving a hard limit on the residual error rate acceptable to ROHC, it is noted that for a residual bit error rate of at most 1E-5, the ROHC scheme has been designed not to increase the number of damaged headers, i.e., the number of damaged headers due to damage propagation is designed to be less than the number of damaged headers caught by the ROHC error detection scheme.
ROHCに許容される残留エラーレートにハード制限を与えることなく、せいぜい1E-5の残留ビット誤り率のために、ROHC方式は、すなわち、損傷したヘッダの数を増加させない数を設計されていることに留意されたいです損傷の伝搬に損傷ヘッダのROHC誤り検出方式によって捕捉破損ヘッダの数よりも少なくなるように設計されています。
Negotiation
ネゴシエーション
In addition to the packet handling mechanisms above, the link layer MUST provide a way to negotiate header compression parameters, see also section 5.1.1. (For unidirectional links, this negotiation may be performed out-of-band or even a priori.)
上記パケット処理機構に加えて、リンク層は、ヘッダ圧縮パラメータを交渉する方法を提供し、またセクション5.1.1を見なければなりません。 （単方向リンクの場合、この交渉は、帯域外あるいは先験的に行われてもよいです。）
The ROHC protocol achieves its compression gain by establishing state information at both ends of the link, i.e., at the compressor and at the decompressor. Different parts of the state are established at different times and with different frequency; hence, it can be said that some of the state information is more dynamic than the rest.
ROHCプロトコルはすなわち、圧縮時と減圧時に、リンクの両端で状態情報を確立することによって、その圧縮利得を達成します。状態の異なる部分は、異なる時間に、異なる周波数で確立されます。したがって、状態情報の一部が残りの部分よりも動的であると言えます。
Some state information is established at the time a channel is established; ROHC assumes the existence of an out-of-band negotiation protocol (such as PPP), or predefined channel state (most useful for unidirectional links). In both cases, we speak of "negotiated channel state". ROHC does not assume that this state can change dynamically during the channel lifetime (and does not explicitly support such changes, although some changes may be innocuous from a protocol point of view). An example of negotiated channel state is the highest context ID number to be used by the compressor (MAX_CID).
いくつかの状態情報は、チャネルが確立された時点で確立されています。 ROHCは（PPPなど）、帯域外ネゴシエーションプロトコルの存在を前提とし、または事前定義されたチャネル状態（単方向リンクのために最も有用です）。どちらの場合も、私たちは「交渉し、チャネル状態」と話します。 ROHCは、（いくつかの変更がビューのプロトコル点から無害かもしれないが、明示的にそのような変更をサポートしていない）は、この状態は、チャネルの有効期間中に動的に変更できることは想定していません。ネゴシエートされたチャネル状態の例は、圧縮機（MAX_CID）によって使用される最高コンテキストID番号です。
Other state information is associated with the individual packet streams in the channel; this state is said to be part of the context. Using context identifiers (CIDs), multiple packet streams with different contexts can share a channel. The negotiated channel state indicates the highest context identifier to be used, as well as the selection of one of two ways to indicate the CID in the compressed header.
他の状態情報は、チャネル内の個々のパケットストリームと関連しています。この状態は、コンテキストの一部であると言われています。異なるコンテキストとコンテキスト識別子（CIDを）、複数のパケットストリームを使用してチャネルを共有することができます。ネゴシエートされたチャネル状態は、使用される最高のコンテキスト識別子、ならびに圧縮ヘッダでCIDを示す2つの方法の1つの選択を示しています。
It is up to the compressor to decide which packets to associate with a context (or, equivalently, which packets constitute a single stream); however, ROHC is efficient only when all packets of a stream share certain properties, such as having the same values for fields that are described as "static" in this document (e.g., the IP addresses, port numbers, and RTP parameters such as the payload type). The efficiency of ROHC RTP also depends on the compressor seeing most RTP Sequence Numbers.
これは、（パケットが単一のストリームを構成する、等価、または）コンテキストに関連付けるためにどのパケットを決定する圧縮機までです。しかし、ROHCは効率的である場合にのみ、そのような（本文書においてそのようなものとして、例えば、IPアドレス、ポート番号、RTPパラメータを「静的」と記載されているフィールドの同じ値を有するものとしてストリームの共有特定のプロパティのすべてのパケット、ペイロードタイプ）。 ROHC RTPの効率もほとんどのRTPシーケンス番号を見て、コンプレッサによって異なります。
Streams need not share all characteristics important for compression. ROHC has a notion of compression profiles: a compression profile denotes a predefined set of such characteristics. To provide extensibility, the negotiated channel state includes the set of profiles acceptable to the decompressor. The context state includes the profile currently in use for the context.
ストリームは、圧縮のための重要なすべての特性を共有する必要はありません。 ROHCは、圧縮プロファイルの概念を持っています圧縮プロファイルは、このような特性の所定のセットを意味します。拡張性を提供するために、ネゴシエートされたチャネル状態は、デコンプレッサに許容されるプロファイルのセットを含みます。コンテキスト状態は、コンテキストのために、現在使用中のプロファイルが含まれています。
Other elements of the context state may include the current values of all header fields (from these one can deduce whether an IPv4 header is present in the header chain, and whether UDP Checksums are enabled), as well as additional compression context that is not part of an uncompressed header, e.g., TS_STRIDE, IP-ID characteristics (incrementing as a 16-bit value in network byte order? random?), a number of old reference headers, and the compressor/decompressor state machines (see next section).
コンテキスト状態の他の要素はすべてのヘッダフィールドの現在の値（これらのいずれかからIPv4ヘッダは、ヘッダ鎖中に存在し、そしてUDPチェックサムかどうかを有効にするかどうかを推測することができる）、ならびに一部ではない追加の圧縮コンテキストを含んでいてもよいです非圧縮ヘッダの例えば、TS_STRIDE、（ネットワークバイト順の16ビット値としてインクリメント？ランダム？）IP-ID特性、古い基準ヘッダの数、及びコンプレッサ/デコンプレッサ・ステート・マシン（次のセクションを参照）。
This document actually defines four ROHC profiles: One uncompressed profile, the main ROHC RTP compression profile, and two variants of this profile for compression of packets with header chains that end in UDP and ESP, respectively, but where RTP compression is not applicable. The descriptive text in the rest of this section is referring to the main ROHC RTP compression profile.
それぞれ、一つの非圧縮プロファイル、メインROHC RTP圧縮プロファイル、およびUDPとESPで終わるヘッダチェーンを持つパケットの圧縮のため、このプロファイルの二つの変種が、しかし、RTP圧縮が適用されない場所：この文書では、実際には4つのROHCプロファイルを定義します。このセクションの残りの部分で説明のテキストは、メインROHC RTP圧縮プロフィールを参照しています。
Header compression with ROHC can be characterized as an interaction between two state machines, one compressor machine and one decompressor machine, each instantiated once per context. The compressor and the decompressor have three states each, which in many ways are related to each other even if the meaning of the states are slightly different for the two parties. Both machines start in the lowest compression state and transit gradually to higher states.
ROHCとヘッダ圧縮は、2台のステートマシン、1つの圧縮機機と一つデコンプレッサ・マシンとの間の相互作用、一度コンテキストごとにインスタンス化された各として特徴付けることができます。コンプレッサーとデコンプレッサは多くの方法で状態の意味は、両当事者のためにわずかに異なる場合でも、互いに関連している三つの状態それぞれを、持っています。両方のマシンが徐々に高く状態に最も低い圧縮状態とトランジットで開始します。
Transitions need not be synchronized between the two machines. In normal operation it is only the compressor that temporarily transits back to lower states. The decompressor will transit back only when context damage is detected.
トランジションは、2台のマシン間で同期させる必要はありません。通常の動作では、一時的に腰の状態に遷移するだけ圧縮機です。デコンプレッサは、コンテキスト損傷が検出された場合にのみトランジットバックになります。
Subsequent sections present an overview of the state machines and their corresponding states, respectively, starting with the compressor.
後続のセクションでは、圧縮機から始まる、それぞれ、状態機械とそれに対応する状態の概要を提示します。
For ROHC compression, the three compressor states are the Initialization and Refresh (IR), First Order (FO), and Second Order (SO) states. The compressor starts in the lowest compression state (IR) and transits gradually to higher compression states. The compressor will always operate in the highest possible compression state, under the constraint that the compressor is sufficiently confident that the decompressor has the information necessary to decompress a header compressed according to that state.
ROHC圧縮のために、3つのコンプレッサーの状態が初期化とリフレッシュ（IR）、ファーストオーダー（FO）、次および二次（SO）状態です。コンプレッサは最も低い圧縮状態（IR）で開始し、より高い圧縮状態に徐々に遷移します。圧縮機は常に圧縮機が減圧装置がその状態に応じて圧縮ヘッダを解凍するために必要な情報を持っていることを十分に確信している制約の下で、可能な限り最高の圧縮状態で動作します。
+----------+ +----------+ +----------+
| IR State | <--------> | FO State | <--------> | SO State |
+----------+ +----------+ +----------+
Decisions about transitions between the various compression states are taken by the compressor on the basis of:
様々な圧縮状態間の遷移についての決定は、に基づいて圧縮機によって取り込まれます。
- variations in packet headers - positive feedback from decompressor (Acknowledgments -- ACKs) - negative feedback from decompressor (Negative ACKs -- NACKs) - periodic timeouts (when operating in unidirectional mode, i.e., over simplex channels or when feedback is not enabled)
- パケットヘッダのばらつき - デコンプレッサ（ - のACK謝辞） - から正帰還解凍器からの負のフィードバック（負のACK - のNACK） - 周期的なタイムアウト（一方向モードで動作し、すなわち、単純チャネル上またはフィードバックが有効でない場合）
How transitions are performed is explained in detail in chapter 5 for each mode of operation.
どのように遷移が行われているが、各動作モードのために第5章で詳しく説明されています。
The purpose of the IR state is to initialize the static parts of the context at the decompressor or to recover after failure. In this state, the compressor sends complete header information. This includes all static and nonstatic fields in uncompressed form plus some additional information.
IR状態の目的は、減圧装置でコンテキストの静的な部分を初期化するか、障害が発生した後に回復することです。この状態で、圧縮機は、完全なヘッダ情報を送信します。これは、非圧縮形式に加えて、いくつかの追加情報のすべての静的および非静的フィールドが含まれています。
The compressor stays in the IR state until it is fairly confident that the decompressor has received the static information correctly.
解凍器が静的な情報を正しく受信したことをかなり確信しているまで、コンプレッサーがIR状態に留まります。
The purpose of the FO state is to efficiently communicate irregularities in the packet stream. When operating in this state, the compressor rarely sends information about all dynamic fields, and the information sent is usually compressed at least partially. Only a few static fields can be updated. The difference between IR and FO should therefore be clear.
FO状態の目的は、効率的にパケットストリームに凹凸を通信することです。この状態で動作している場合、コンプレッサーはほとんどすべての動的フィールドに関する情報を送信していないし、送られた情報は、通常、少なくとも部分的に圧縮されています。ほんの数静的フィールドを更新することができます。 IRとFOとの差は、したがって、明らかです。
The compressor enters this state from the IR state, and from the SO state whenever the headers of the packet stream do not conform to their previous pattern. It stays in the FO state until it is confident that the decompressor has acquired all the parameters of the new pattern. Changes in fields that are always irregular are communicated in all packets and are therefore part of what is a uniform pattern.
圧縮器は、パケットストリームのヘッダは、以前のパターンに適合しないときはいつでもIR状態から、及びSO状態からこの状態に入ります。デコンプレッサは、新しいパターンのすべてのパラメータを取得したことを確信するまで、それはFO状態に留まります。常に不規則なフィールドの変更は、すべてのパケットに伝え、したがって、一定のパターンであるものの一部です。
Some or all packets sent in the FO state carry context updating information. It is very important to detect corruption of such packets to avoid erroneous updates and context inconsistencies.
FO状態で送信された一部またはすべてのパケットがコンテキスト更新情報を運びます。間違ったアップデートとコンテキストの矛盾を避けるために、このようなパケットの破損を検出するために非常に重要です。
This is the state where compression is optimal. The compressor enters the SO state when the header to be compressed is completely predictable given the SN (RTP Sequence Number) and the compressor is sufficiently confident that the decompressor has acquired all parameters of the functions from SN to other fields. Correct decompression of packets sent in the SO state only hinges on correct decompression of the SN. However, successful decompression also requires that the information sent in the preceding FO state packets has been successfully received by the decompressor.
これは圧縮が最適な状態です。圧縮対象ヘッダがSN（RTPシーケンス番号）指定された完全に予測可能である場合、圧縮機はSO状態に入ると、圧縮機は、減圧装置が他の分野にSNの関数のすべてのパラメータを取得したことを十分に確信しています。 SO状態で送信されたパケットの正しい解凍はSNの正しい解凍にかかっています。しかし、成功した減圧はまた、先行FO状態パケットで送信された情報が正しく解凍器によって受信されていることを必要とします。
The compressor leaves this state and goes back to the FO state when the header no longer conforms to the uniform pattern and cannot be independently compressed on the basis of previous context information.
圧縮機は、この状態を出て、ヘッダは、もはや均一なパターンに準拠しており、独立して、以前のコンテキスト情報に基づいて、圧縮することができないときにバックFO状態へ移行しません。
The decompressor starts in its lowest compression state, "No Context" and gradually transits to higher states. The decompressor state machine normally never leaves the "Full Context" state once it has entered this state.
デコンプレッサは、より高い状態に遷移し、徐々にその最低の圧縮状態、「いいえ文脈」で始まり、。それがこの状態に入った後、デコンプレッサ・ステート・マシンは、通常、「完全なコンテキスト」状態を離れることはありません。
+--------------+ +----------------+ +--------------+
| No Context | <---> | Static Context | <---> | Full Context |
+--------------+ +----------------+ +--------------+
Initially, while working in the "No Context" state, the decompressor has not yet successfully decompressed a packet. Once a packet has been decompressed correctly (for example, upon reception of an initialization packet with static and dynamic information), the decompressor can transit all the way to the "Full Context" state, and only upon repeated failures will it transit back to lower states. However, when that happens it first transits back to the "Static Context" state. There, reception of any packet sent in the FO state is normally sufficient to enable transition to the "Full Context" state again. Only when decompression of several packets sent in the FO state fails in the "Static Context" state will the decompressor go all the way back to the "No Context" state.
「いいえ文脈」状態での作業中に最初は、デコンプレッサは、まだパケットを正常に解凍されていません。パケットは（例えば、静的および動的情報を初期化パケットの受信時に）正しく解凍された後、缶「フルコンテキスト」状態に遷移するすべての方法を、そしてだけ繰り返し失敗時のデコンプレッサは、下に戻すことがトランジット意志状態。しかし、それが起こるとき、それは最初に戻って、「静的コンテキスト」状態に遷移します。そこでは、FO状態で送信されたパケットの受信が再び「完全なコンテキスト」状態への遷移を可能にするために、通常は十分です。 FO状態で送信されたいくつかのパケットの解凍には「静的コンテキスト」状態で故障した場合にのみ、デコンプレッサは、すべての帰り「いいえ文脈」の状態になります。
When state transitions are performed is explained in detail in chapter 5.
状態遷移が行われた場合、第5章で詳しく説明されています。
The ROHC scheme has three modes of operation, called Unidirectional, Bidirectional Optimistic, and Bidirectional Reliable mode.
ROHC方式は、単方向、双方向楽観と呼ばれる3つの動作モードを、持っている、と双方向の信頼モード。
It is important to understand the difference between states, as described in the previous chapter, and modes. These abstractions are orthogonal to each other. The state abstraction is the same for all modes of operation, while the mode controls the logic of state transitions and what actions to perform in each state.
前の章、およびモードで説明したように、状態の違いを理解することが重要です。これらの抽象化は、互いに直交しています。モードは、状態遷移のロジックを制御し、どのようなアクションを各状態で実行するようにしながら、状態の抽象化は、すべての動作モードについても同様です。
+----------------------+
| Unidirectional Mode |
| +--+ +--+ +--+ |
| |IR| |FO| |SO| |
| +--+ +--+ +--+ |
+----------------------+
^ ^
/ \
/ \
v v
+----------------------+ +----------------------+
| Optimistic Mode | | Reliable Mode |
| +--+ +--+ +--+ | | +--+ +--+ +--+ |
| |IR| |FO| |SO| | <--------------> | |IR| |FO| |SO| |
| +--+ +--+ +--+ | | +--+ +--+ +--+ |
+----------------------+ +----------------------+
The optimal mode to operate in depends on the characteristics of the environment of the compression protocol, such as feedback abilities, error probabilities and distributions, effects of header size variation, etc. All ROHC implementations MUST implement and support all three modes of operation. The three modes are briefly described in the following subsections.
で動作するように最適なモードは、すべてのROHC実装は動作の3つのすべてのモードを実装し、サポートしなければならない等のフィードバック能力、エラー確率と分布、ヘッダサイズの変化の影響、などの圧縮プロトコルの環境の特性に依存します。三つのモードを簡単に以下のサブセクションで説明されています。
Detailed descriptions of the three modes of operation regarding compression and decompression logic are given in chapter 5. The mode transition mechanisms, too, are described in chapter 5.
圧縮伸長ロジックに関する3つの動作モードの詳細な説明は、モード遷移機構が、あまりにも、第5章に記載されている第5章に記載されています。
When in the Unidirectional mode of operation, packets are sent in one direction only: from compressor to decompressor. This mode therefore makes ROHC usable over links where a return path from decompressor to compressor is unavailable or undesirable.
場合の動作の単方向モードでは、パケットは一方向のみに送信される。コンプレッサから解凍装置へ。このモードは、従って、解凍器から圧縮機への戻り経路が利用できない、または望ましくないリンク上でROHCが使用可能となります。
In U-mode, transitions between compressor states are performed only on account of periodic timeouts and irregularities in the header field change patterns in the compressed packet stream. Due to the periodic refreshes and the lack of feedback for initiation of error recovery, compression in the Unidirectional mode will be less efficient and have a slightly higher probability of loss propagation compared to any of the Bidirectional modes.
Uモードにおいては、コンプレッサ状態間の遷移のみが圧縮されたパケットストリームのヘッダフィールドの変化パターンの周期的なタイムアウト及び凹凸のために行われます。周期的なリフレッシュおよびエラー回復の開始のためのフィードバックの欠如のために、単方向モードでの圧縮は、あまり効率的であろうと双方向モードのいずれかと比較して、損失伝播のわずかに高い確率を有します。
Compression with ROHC MUST start in the Unidirectional mode. Transition to any of the Bidirectional modes can be performed as soon as a packet has reached the decompressor and it has replied with a feedback packet indicating that a mode transition is desired (see chapter 5).
ROHCでの圧縮は単方向モードで起動する必要があります。双方向モードのいずれかへの遷移は、パケットがデコンプレッサに到達しており、それは、モード遷移が（第5章を参照のこと）が望まれることを示すフィードバックパケットで返信したとすぐに行うことができます。
The Bidirectional Optimistic mode is similar to the Unidirectional mode. The difference is that a feedback channel is used to send error recovery requests and (optionally) acknowledgments of significant context updates from decompressor to compressor (not, however, for pure sequence number updates). Periodic refreshes are not used in the Bidirectional Optimistic mode.
双方向楽観モードは単方向モードに似ています。差は、フィードバックチャネルが圧縮機に解凍器から有意なコンテキスト更新のエラー回復要求と（任意に）確認応答を送信するために使用されることである（ない、しかし、純粋なシーケンス番号の更新のために）。定期的なリフレッシュが双方向楽観モードでは使用されません。
O-mode aims to maximize compression efficiency and sparse usage of the feedback channel. It reduces the number of damaged headers delivered to the upper layers due to residual errors or context invalidation. The frequency of context invalidation may be higher than for R-mode, in particular when long loss/error bursts occur. Refer to section 4.7 for more details.
Oモードは、圧縮効率とフィードバックチャネルのまばらな使用を最大化することを目指しています。それにより残留誤差またはコンテキスト無効に上位レイヤに送達破損ヘッダの数を減少させます。長い損失/エラー・バーストが発生したときにコンテキスト無効の周波数は、特に、Rモードの場合よりも高くてもよいです。詳細については、セクション4.7を参照してください。
The Bidirectional Reliable mode differs in many ways from the previous two. The most important differences are a more intensive usage of the feedback channel and a stricter logic at both the compressor and the decompressor that prevents loss of context synchronization between compressor and decompressor except for very high residual bit error rates. Feedback is sent to acknowledge all context updates, including updates of the sequence number field. However, not every packet updates the context in Reliable mode.
双方向信頼モードでは、前の2から多くの点で異なります。最も重要な違いは、圧縮機と、非常に高い残留ビット誤り率を除いコンプレッサとデコンプレッサとの間のコンテキスト同期の損失を防止する減圧装置の両方でフィードバックチャネルと厳格ロジックのより集中的な使用です。フィードバックは、シーケンス番号フィールドの更新を含む、すべてのコンテキストの更新を確認するために送信されます。しかし、すべてのパケットが信頼できるモードでコンテキストを更新しません。
R-mode aims to maximize robustness against loss propagation and damage propagation, i.e., minimize the probability of context invalidation, even under header loss/error burst conditions. It may have a lower probability of context invalidation than O-mode, but a larger number of damaged headers may be delivered when the context actually is invalidated. Refer to section 4.7 for more details.
Rモードは損失伝播と損傷の伝播に対するロバスト性を最大化することを目的とする、すなわち、ヘッダの損失/エラー条件バーストも下で、コンテキスト無効化の確率を最小限に抑えます。これは、Oモードよりコンテキスト無効の低い確率を有することができるが、コンテキストが実際に無効にされたときに破損ヘッダのより多くを送達することができます。詳細については、セクション4.7を参照してください。
This chapter describes the encoding methods used for header fields. How the methods are applied to each field (e.g., values of associated parameters) is specified in section 5.7.
この章では、ヘッダフィールドに使用される符号化方法が記載されています。方法は、各フィールドに適用される方法（例えば、関連するパラメータの値）セクション5.7で指定されています。
Least Significant Bits (LSB) encoding is used for header fields whose values are usually subject to small changes. With LSB encoding, the k least significant bits of the field value are transmitted instead of the original field value, where k is a positive integer. After receiving k bits, the decompressor derives the original value using a previously received value as reference (v_ref).
最下位ビット（LSB）符号化は、その値が通常小さな変更の対象となるヘッダフィールドのために使用されます。 LSB符号化を用いて、フィールド値のk個の最下位ビットではなく、kは正の整数であり、元のフィールド値の送信されます。 kビットを受信した後、減圧装置は、基準（V_REF）として以前に受信された値を使用して元の値を導出します。
The scheme is guaranteed to be correct if the compressor and the decompressor each use interpretation intervals
スキームは、コンプレッサとデコンプレッサ各々が解釈インターバルを使用する場合、正しいことが保証され
1) in which the original value resides, and
1）元の値が存在し、ここで
2) in which the original value is the only value that has the exact same k least significant bits as those transmitted.
2）において、元の値は、送信されたものと全く同じk個の最下位ビットを有する唯一の値です。
The interpretation interval can be described as a function f(v_ref, k). Let
解釈インターバルは、関数f（V_REF、K）として記載することができます。してみましょう
f(v_ref, k) = [v_ref - p, v_ref + (2^k - 1) - p]
F（V_REF、K）= [V_REF - P、V_REF +（2 ^ K - 1） - P]
where p is an integer.
pは整数です。
<------- interpretation interval (size is 2^k) ------->
|-------------+---------------------------------------|
v_ref - p v_ref v_ref + (2^k-1) - p
The function f has the following property: for any value k, the k least significant bits will uniquely identify a value in f(v_ref, k).
関数fは、以下の性質を有する：任意の値kに対して、k個の最下位ビットが一意F（V_REF、K）の値を特定します。
The parameter p is introduced so that the interpretation interval can be shifted with respect to v_ref. Choosing a good value for p will yield a more efficient encoding for fields with certain characteristics. Below are some examples:
解釈インターバルはV_REFに対してシフトすることができるように、パラメータpを導入します。 Pのための良好な値を選択すると、特定の特性を持つフィールドのためのより効率的な符号化をもたらします。以下にいくつかの例は以下のとおりです。
a) For field values that are expected always to increase, p can be set to -1. The interpretation interval becomes [v_ref + 1, v_ref + 2^k].
a）は、常に増加すると予想されているフィールドの値については、pが-1に設定することができます。解釈インターバルは、[V_REF + 1、V_REF + 2 ^ K]となります。
b) For field values that stay the same or increase, p can be set to 0. The interpretation interval becomes [v_ref, v_ref + 2^k - 1].
b）は、同じ又は増加留まるフィールド値について、pが解釈インターバルとなる0に設定することができる[V_REF、V_REF + 2 ^ K - 1]。
c) For field values that are expected to deviate only slightly from a constant value, p can be set to 2^(k-1) - 1. The interpretation interval becomes [v_ref - 2^(k-1) + 1, v_ref + 2^(k-1)].
1.解釈インターバルは、[V_REFなる - - 2 ^（K-1）+ 1、V_REF C）は一定値からわずかしか逸脱することが予想されるフィールド値について、pが2 ^（K-1）に設定することができます+ 2 ^（K-1）]。
d) For field values that are expected to undergo small negative changes and larger positive changes, such as the RTP TS for video, or RTP SN when there is misordering, p can be set to 2^(k-2) - 1. The interval becomes [v_ref - 2^(k-2) + 1, v_ref + 3 * 2^(k-2)], i.e., 3/4 of the interval is used for positive changes.
D）小さい負の変化を受けることが予想され、誤った順序が存在する場合、より大きな正のようなビデオのためのRTP TSなどの変更、またはRTP SNは、pが2 ^（K-2）に設定することができるフィールド値については - 1。間隔[V_REFを - 2 ^（K-2）+ 1、V_REF + 3 * 2 ^（K-2）]となる、すなわち、間隔の3/4が正変更するために使用されます。
The following is a simplified procedure for LSB compression and decompression; it is modified for robustness and damage propagation protection in the next subsection:
以下は、LSB圧縮と解凍のために単純化された手順です。それは、次のサブセクションで堅牢性と損害伝播保護のために変更されます。
1) The compressor (decompressor) always uses v_ref_c (v_ref_d), the last value that has been compressed (decompressed), as v_ref;
1）圧縮機（減圧装置）が常にv_ref_c（v_ref_d）、V_REFとして、（解凍）圧縮された最後の値を使用します。
2) When compressing a value v, the compressor finds the minimum value of k such that v falls into the interval f(v_ref_c, k). Call this function k = g(v_ref_c, v). When only a few distinct values of k are possible, for example due to limitations imposed by packet formats (see section 5.7), the compressor will instead pick the smallest k that puts v in the interval f(v_ref_c, k).
値vを圧縮するとき2）、圧縮機は、vがインターバルF（v_ref_c、K）に該当するように、kの最小値を求めます。この関数k = G（v_ref_c、V）を呼び出します。 kのごく少数の異なる値（セクション5.7を参照）により、パケットフォーマットによって課される制限のために、例えば、可能である場合、圧縮機は、代わりに間隔F（v_ref_c、K）におけるVを置く最小のkを選ぶであろう。
3) When receiving m LSBs, the decompressor uses the interpretation interval f(v_ref_d, m), called interval_d. It picks as the decompressed value the one in interval_d whose LSBs match the received m bits.
m個のLSBを受信した場合3）、減圧装置はinterval_dと呼ばれる解釈インターバルF（v_ref_d、m）を、使用します。これは、伸張値として、そのLSBを受信したmビットと一致interval_d内の1つを選びます。
Note that the values to be encoded have a finite range; for example, the RTP SN ranges from 0 to 0xFFFF. When the SN value is close to 0 or 0xFFFF, the interpretation interval can straddle the wraparound boundary between 0 and 0xFFFF.
符号化される値は、有限の範囲を有することに留意されたいです。例えば、RTP SNは0〜0xFFFFの範囲にあります。 SN値が0か0xFFFFのに近い場合、解釈間隔が0と0xFFFFの間のラップアラウンド境界をまたぐことができます。
The scheme is complicated by two factors: packet loss between the compressor and decompressor, and transmission errors undetected by the lower layer. In the former case, the compressor and decompressor will lose the synchronization of v_ref, and thus also of the interpretation interval. If v is still covered by the intersection(interval_c, interval_d), the decompression will be correct. Otherwise, incorrect decompression will result. The next section will address this issue further.
下位レイヤによって検出されないコンプレッサとデコンプレッサとの間のパケットロス、および伝送エラー：スキームは、二つの要因によって複雑になります。前者の場合、コンプレッサとデコンプレッサはV_REFの同期を失い、ひいては、解釈インターバルのであろう。 vはまだ交差点（interval_c、interval_d）で覆われている場合は、減圧は正しくなります。それ以外の場合は、不正確な減圧が発生します。次のセクションでは、さらにこの問題に対処します。
In the case of undetected transmission errors, the corrupted LSBs will give an incorrectly decompressed value that will later be used as v_ref_d, which in turn is likely to lead to damage propagation. This problem is addressed by using a secure reference, i.e., a reference value whose correctness is verified by a protecting CRC. Consequently, the procedure 1) above is modified as follows:
未検出の伝送エラーの場合には、破損のLSBは、後の順番に損傷伝播につながる可能性があるv_ref_d、として使用される間違って伸張値を与えます。この問題は、安全基準、すなわち、その正当性保護CRCにより確認された基準値を用いてアドレス指定されます。次のようにその結果、上記の手順1）が変更されます。
1) a) the compressor always uses as v_ref_c the last value that has been compressed and sent with a protecting CRC. b) the decompressor always uses as v_ref_d the last correct value, as verified by a successful CRC.
1）a）の圧縮機は、常に圧縮され、保護CRCと共に送信された最後の値v_ref_cとして使用します。成功したCRCによって検証としてb）のデコンプレッサは、常に、最後の正しい値v_ref_dとして使用しています。
Note that in U/O-mode, 1) b) is modified so that if decompression of the SN fails using the last verified SN reference, another decompression attempt is made using the last but one verified SN reference. This procedure mitigates damage propagation when a small CRC fails to detect a damaged value. See section 5.3.2.2.3 for further details.
SNの減圧が最後の確認SN基準を使用して失敗した場合、別の復元の試みが前々回検証SN基準を使用して行われるようにU / Oモードでなお、1）b）に修正されます。小さなCRCが破損した値を検出できない場合は、この手順では、損傷の伝播を軽減します。詳細については、セクション5.3.2.2.3を参照してください。
This section describes how to modify the simplified algorithm in 4.5.1 to achieve robustness.
このセクションでは、堅牢性を実現するために4.5.1に簡略化されたアルゴリズムを変更する方法について説明します。
The compressor may not be able to determine the exact value of v_ref_d that will be used by the decompressor for a particular value v, since some candidates for v_ref_d may have been lost or damaged. However, by using feedback or by making reasonable assumptions, the compressor can limit the candidate set. The compressor then calculates k such that no matter which v_ref_d in the candidate set the decompressor uses, v is covered by the resulting interval_d.
圧縮機は、v_ref_dのためのいくつかの候補が紛失または破損している可能性があるので、特定の値vために減圧装置によって使用されるv_ref_dの正確な値を決定することができないかもしれません。しかしながら、フィードバックを使用することによって、または合理的な仮定を行うことで、圧縮機は、候補セットを制限することができます。圧縮機は、次に、減圧装置用途を候補セットにv_ref_dかかわらずは、Vが得interval_dによって覆われるようにKを算出します。
Since the decompressor always uses as the reference the last received value where the CRC succeeded, the compressor maintains a sliding window containing the candidates for v_ref_d. The sliding window is initially empty. The following operations are performed on the sliding window by the compressor:
減圧装置が常に基準としてCRCが成功した最後に受信した値を使用するので、圧縮機は、v_ref_dの候補を含むスライディングウィンドウを維持します。スライディングウィンドウは、最初は空です。以下の操作は、圧縮機によってスライディングウィンドウ上で実行されます。
1) After sending a value v (compressed or uncompressed) protected by a CRC, the compressor adds v to the sliding window.
1）CRCによって保護値v（圧縮または非圧縮）を送信した後、圧縮機は、スライディングウィンドウにVを付加します。
2) For each value v being compressed, the compressor chooses k = max(g(v_min, v), g(v_max, v)), where v_min and v_max are the minimum and maximum values in the sliding window, and g is the function defined in the previous section.
2）圧縮され、Vの各値について、圧縮機は、V_MIN及びV_MAXはスライディングウィンドウの最小値と最大値であり、Gは、K = MAX（G（V_MIN、V）、G（V_MAX、V））を、選択しました前のセクションで定義された関数。
3) When the compressor is sufficiently confident that a certain value v and all values older than v will not be used as reference by the decompressor, the window is advanced by removing those values (including v). The confidence may be obtained by various means. In R-mode, an ACK from the decompressor implies that values older than the ACKed one can be removed from the sliding window. In U/O-mode there is always a CRC to verify correct decompression, and a sliding window with a limited maximum width is used. The window width is an implementation dependent optimization parameter.
圧縮機が一定値v及びvより古い全ての値は、デコンプレッサによって基準として使用されないことを十分に確信している場合3）、窓（）は、Vを含むこれらの値を除去することによって進められます。自信は様々な手段によって得ることができます。 Rモードでは、解凍装置からのACKはACKさよりも古い値がスライディングウィンドウから除去することができることを意味します。 U / Oモードであり、常に正しい解凍を検証するためのCRCであり、限られた最大幅を有するスライド窓が使用されます。ウィンドウ幅は、実装に依存する最適化パラメータです。
Note that the decompressor follows the procedure described in the previous section, except that in R-mode it MUST ACK each header received with a succeeding CRC (see also section 5.5).
デコンプレッサは、それが後続のCRCで受信された各ヘッダをACKしなければならないRモードでことを除いて、前のセクションで説明した手順に従うことに注意してください（セクション5.5を参照）。
The RTP Timestamp (TS) will usually not increase by an arbitrary number from packet to packet. Instead, the increase is normally an integral multiple of some unit (TS_STRIDE). For example, in the case of audio, the sample rate is normally 8 kHz and one voice frame may cover 20 ms. Furthermore, each voice frame is often carried in one RTP packet. In this case, the RTP increment is always n * 160 (= 8000 * 0.02), for some integer n. Note that silence periods have no impact on this, as the sample clock at the source normally keeps running without changing either frame rate or frame boundaries.
RTPタイムスタンプ（TS）は、通常、パケットごとに任意の数の増加はありません。その代わりに、増加は、通常、いくつかのユニット（TS_STRIDE）の整数倍です。例えば、オーディオの場合、サンプルレートは8kHzで20ミリ秒をカバーすることができる1つの音声フレームが通常です。さらに、各音声フレームは、多くの場合、1つのRTPパケットで運ばれます。この場合、RTP増分は、ある整数nに対して、常にN * 160（* 0.02 = 8000）です。ソースにおけるサンプル・クロックは、通常、フレームレートまたはフレーム境界のいずれかを変更することなく実行し続けるように無音期間が、これに影響を及ぼさないことに留意されたいです。
In the case of video, there is usually a TS_STRIDE as well when the video frame level is considered. The sample rate for most video codecs is 90 kHz. If the video frame rate is fixed, say, to 30 frames/second, the TS will increase by n * 3000 (= n * 90000 / 30) between video frames. Note that a video frame is often divided into several RTP packets to increase robustness against packet loss. In this case several RTP packets will carry the same TS.
ビデオ・フレーム・レベルを考慮した場合、ビデオの場合には、同様に通常TS_STRIDEがあります。ほとんどのビデオコーデックのサンプルレートは90 kHzです。ビデオフレームレートが固定されている場合、たとえば、30フレーム/秒、TSは、ビデオフレーム間のn * 3000（= N * 30分の90000）によって増加します。ビデオフレームは、多くの場合、パケット損失に対するロバスト性を高めるために、いくつかのRTPパケットに分割されることに注意してください。この場合、いくつかのRTPパケットが同じTSを運ぶでしょう。
When using scaled RTP Timestamp encoding, the TS is downscaled by a factor of TS_STRIDE before compression. This saves
スケーリングされたRTPタイムスタンプ符号化を使用する場合、TSは、圧縮前にTS_STRIDEの要因によって縮小されます。これは、保存されます
floor(log2(TS_STRIDE))
床（LOG2（TS_STRIDE））
bits for each compressed TS. TS and TS_SCALED satisfy the following equality:
各圧縮されたTSのためのビット。 TSとTS_SCALEDは、次の等式を満たします：
TS = TS_SCALED * TS_STRIDE + TS_OFFSET
TS = TS_SCALED * TS_STRIDE + TS_OFFSET
TS_STRIDE is explicitly, and TS_OFFSET implicitly, communicated to the decompressor. The following algorithm is used:
TS_STRIDEは、明示的である、とTS_OFFSET暗黙のうちに、解凍器に伝達します。次のアルゴリズムが使用されます。
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_STRIDEの値と、1つまたはいくつかのTSフィールドの絶対値を送信します。後者は（絶対値）モジュロTS_STRIDEにTS_OFFSETを初期化するために減圧装置によって使用されます。スケーリングされていない限り、TS値がラップアラウンドしないように、TS_OFFSETにかかわらず絶対値が使用されるのと同じであることに留意されたいです。下記の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_SCALEDの圧縮された値を受信すると、減圧装置は、第一オリジナルTS_SCALEDの値を導出します。オリジナルのRTP TSは、その後TS = TS_SCALED * TS_STRIDE + TS_OFFSETとして計算されます。
4. Offset at wraparound: Wraparound of the unscaled 32-bit TS will invalidate the current value of TS_OFFSET used in the 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
4.ラップアラウンドでオフセット：スケーリングされていない32ビットのTSのラップアラウンドは、上記の式で使用されるTS_OFFSETの現在の値が無効になります。たとえば、私たちはTS_STRIDE = 160 = 0xA0を、現在のTS = 0xFFFFFFF0を想定してみましょう。次のRTPのTS =を0x00000130（すなわち、増分が* 2 = 320 160である）場合= 80は次に、新しいTS_OFFSETは0x00000130モジュロ0xA0を= 0x90を= 144、圧縮機の再初期化するために必要とされないれるべきである0x50をTS_OFFSETは次にですラップアラウンドでTS_OFFSET。その代わりに、減圧装置は（自明である）スケーリングされていないTSの回り込みを検出しにTS_OFFSETを更新しなければなりません
TS_OFFSET = (Wrapped around unscaled TS) modulo TS_STRIDE
TS_OFFSET =（スケーリングされていないTSの周りに包まれた）を法TS_STRIDE
5. Interpretation interval at wraparound: Special rules are needed for the interpretation interval of the scaled TS at wraparound, since the maximum scaled TS, TSS_MAX, (0xFFFFFFFF / TS_STRIDE) may not have the form 2^m - 1. For example, when TS_STRIDE is 160, the scaled TS is at most 26843545 which has LSBs 10011001. The wraparound boundary between the TSS_MAX may thus not correspond to a natural boundary between LSBs.
ラップアラウンドにおける前記解釈インターバル：最大TS、TSS_MAX、（0xFFFFFFFFの/ TS_STRIDE）はフォーム2 ^ M有していなくてもよいスケーリングので、特別なルールは、ラップアラウンドでスケーリングされたTSの解釈インターバルのために必要とされている - 場合、例えば、1. TS_STRIDEは、スケーリングされたTSは、最大でのLSB 10011001.従ってLSBの間の自然な境界に対応しないことTSS_MAX間のラップアラウンド境界を有し26843545であり、160です。
interpretation interval
|<------------------------------>|
unused scaled TS
------------|--------------|---------------------->
TSS_MAX zero
When TSS_MAX is part of the interpretation interval, a number of unused values are inserted into it after TSS_MAX such that their LSBs follow naturally upon each other. For example, for TS_STRIDE = 160 and k = 4, values corresponding to the LSBs 1010 through 1111 are inserted. The number of inserted values depends on k and the LSBs of the maximum scaled TS. The number of valid values in the interpretation interval should be high enough to maintain robustness. This can be ensured by the following rule:
TSS_MAXが解釈インターバルの一部である場合、未使用の値の数は、それらのLSBが互いの上に自然に従うようTSS_MAX後に挿入されます。例えば、TS_STRIDE = 160であり、k = 4のために1111を介してのLSB 1010に対応する値が挿入されています。挿入された値の数がkと最大スケールTSのLSBに依存します。解釈間隔における有効な値の数は、堅牢性を維持するのに十分高くなければなりません。これは、次のルールにより確保することができます。
Let a be the number of LSBs needed if there was no
wraparound, and let b be the number of LSBs needed to
disambiguate between TSS_MAX and zero where the a LSBs of
TSS_MAX are set to zero. The number of LSB bits to send
while TSS_MAX or zero is part of the interpretation interval
is b.
This scaling method can be applied to many frame-based codecs. However, the value of TS_STRIDE might change during a session, for example as a result of adaptation strategies. If that happens, the unscaled TS is compressed until re-initialization of the new TS_STRIDE and TS_OFFSET is completed.
このスケーリング方法は、多くのフレームベースのコーデックにも適用することができます。しかし、TS_STRIDEの値は、適応戦略の結果として、例えば、セッション中に変更される可能性があります。その場合は、スケーリングされていないTSは新しいTS_STRIDEの再初期化まで圧縮され、TS_OFFSETが完成されます。
The RTP Timestamp [RFC 1889] is defined to identify the number of the first sample used to generate the payload. When 1) RTP packets carry payloads corresponding to a fixed sampling interval, 2) the sampling is done at a constant rate, and 3) packets are generated in lock-step with sampling, then the timestamp value will closely approximate a linear function of the time of day. This is the case for conversational media, such as interactive speech. The linear ratio is determined by the source sample rate. The linear pattern can be complicated by packetization (e.g., in the case of video where a video frame usually corresponds to several RTP packets) or frame rearrangement (e.g., B-frames are sent out-of-order by some video codecs).
RTPタイムスタンプ[RFC 1889]ペイロードを生成するために使用される最初のサンプルの数を識別するために定義されています。 1）RTPパケットは、固定のサンプリング間隔に対応するペイロードを運ぶ場合、2）サンプリングが一定の速度で行われ、3）パケットがサンプリングとロックステップで生成され、その後、タイムスタンプ値は、密接の線形関数を近似します時刻。これは、対話型の音声として会話のメディアのためのケースです。線形比率は、ソースサンプル・レートによって決定されます。線状パターン（例えば、Bフレームは、いくつかのビデオコーデックによりアウトオブオーダ送信される）またはフレーム再配列（ビデオ・フレームは、通常、いくつかのRTPパケットに対応するビデオの場合、例えば）パケットによって複雑にすることができます。
With a fixed sample rate of 8 kHz, 20 ms in the time domain is equivalent to an increment of 160 in the unscaled TS domain, and to an increment of 1 in the scaled TS domain with TS_STRIDE = 160.
8kHzでの固定サンプル・レートで、時間領域で20のMSはスケーリングされていないTSドメイン内の160の増分に相当し、TS_STRIDE = 160を有するスケールTSドメインにおける1の増加です。
As a consequence, the (scaled) TS of headers arriving at the decompressor will be a linear function of time of day, with some deviation due to the delay jitter (and the clock inaccuracies) between the source and the decompressor. In normal operation, i.e., no crashes or failures, the delay jitter will be bounded to meet the requirements of conversational real-time traffic. Hence, by using a local clock the decompressor can obtain an approximation of the (scaled) TS in the header to be decompressed by considering its arrival time. The approximation can then be refined with the k LSBs of the (scaled) TS carried in the header. The value of k required to ensure correct decompression is a function of the jitter between the source and the decompressor.
その結果、デコンプレッサに到着ヘッダの（スケーリング）TSは、ソースと解凍装置間の遅延ジッタに起因するいくつかの偏差（及びクロックの不正確さ）と、一日の時間の線形関数となります。通常の操作では、すなわち、何のクラッシュや故障、遅延ジッタは、会話リアルタイムトラフィックの要件を満たすように制限されません。したがって、ローカルクロックを使用して減圧装置は、その到着時間を考慮して解凍されるヘッダ内の（スケーリング）TSの近似値を得ることができます。近似は、ヘッダで運ば（スケーリング）TSのk個の最下位ビットを用いて精製することができます。正しい解凍を確保するために必要なkの値は、ソースと解凍器との間のジッタの関数です。
If the compressor knows the potential jitter introduced between compressor and decompressor, it can determine k by using a local clock to estimate jitter in packet arrival times, or alternatively it can use a fixed k and discard packets arriving too much out of time.
コンプレッサは、コンプレッサとデコンプレッサとの間に導入される可能性ジッタを知っている場合、それは、パケット到着時間のジッタを推定するために、ローカルクロックを使用してKを決定することができ、あるいはそれは、固定Kを使用し、時間外すぎる到着したパケットを破棄することができます。
The advantages of this scheme include:
この方式の利点は次のとおりです。
a) The size of the compressed TS is constant and small. In particular, it does NOT depend on the length of silence intervals. This is in contrast to other TS compression techniques, which at the beginning of a talkspurt require sending a number of bits dependent on the duration of the preceding silence interval.
A）圧縮TSの大きさが一定で小さいです。特に、無音区間の長さに依存しません。これは、有音部の開始時に、先行する無音区間の継続時間に依存するビットの数を送信する必要が他のTSの圧縮技術とは対照的です。
b) No synchronization is required between the clock local to the compressor and the clock local to the decompressor.
B）なしの同期は、圧縮機および減圧装置へのローカルクロックに対してローカルクロックとの間の必要とされません。
Note that although this scheme can be made to work using both scaled and unscaled TS, in practice it is always combined with scaled TS encoding because of the less demanding requirement on the clock resolution, e.g., 20 ms instead of 1/8 ms. Therefore, the algorithm described below assumes that the clock-based encoding scheme operates on the scaled TS. The case of unscaled TS would be similar, with changes to scale factors.
この方式は、実際には、両方のスケーリングおよびスケーリングされていないTSを使用して動作させることができるが、それが常にあるため、クロックの分解能にあまり厳しい要件のスケーリングされたTSのエンコーディングと組み合わされることに注意してください、例えば、20ミリ秒の代わりに1/8 MS。したがって、以下に説明するアルゴリズムは、時間ベース符号化方式は、スケーリングされたTSに動作することを前提としています。スケーリングされていないTSの場合は、要因をスケーリングする変更で、同様であろう。
The major task of the compressor is to determine the value of k. Its sliding window now contains not only potential reference values for the TS but also their times of arrival at the compressor.
圧縮機の主要なタスクは、kの値を決定することです。そのスライディングウィンドウが電位基準TSの値だけでなく、コンプレッサーの到着自分の時間だけでなく、含まれています。
1) The compressor maintains a sliding window
1）圧縮機は、スライディングウィンドウを維持します
{(T_j, a_j), for each header j that can be used as a reference},
{（T_J、a_j）、基準として使用することができ、各ヘッダjについて}
where T_j is the scaled TS for header j, and a_j is the arrival time of header j. The sliding window serves the same purpose as the W-LSB sliding window of section 4.5.2.
T_JはヘッダjのスケーリングされたTSであり、そしてa_jはヘッダjの到着時間です。スライディングウィンドウは、セクション4.5.2のW-LSBのスライディングウィンドウと同じ目的を果たします。
2) When a new header n arrives with T_n as the scaled TS, the compressor notes the arrival time a_n. It then calculates
2）新しいヘッダーnがスケールTSとしてT_Nで到着すると、圧縮機は、到着時間A_Nを指摘しています。その後、計算します
Max_Jitter_BC =
Max_Jitter_BC =
max {|(T_n - T_j) - ((a_n - a_j) / TIME_STRIDE)|, for all headers j in the sliding window},
マックス{|（T_N - T_J） - （（A_N - a_j）/ TIME_STRIDE）|、スライディングウィンドウ内のすべてのヘッダjについて}
where TIME_STRIDE is the time interval equivalent to one TS_STRIDE, e.g., 20 ms. Max_Jitter_BC is the maximum observed jitter before the compressor, in units of TS_STRIDE, for the headers in the sliding window.
TIME_STRIDE一のTS_STRIDE、例えば、20ミリ秒までの時間間隔と等価です。 Max_Jitter_BCは最大スライディングウィンドウのヘッダに、TS_STRIDEの単位で、コンプレッサ前のジッタが観察されます。
3) k is calculated as
3）ここで、kは次のように計算され
k = ceiling(log2(2 * J + 1),
K =天井（LOG2（2 * J + 1）、
where J = Max_Jitter_BC + Max_Jitter_CD + 2.
ここで、J = Max_Jitter_BC + Max_Jitter_CD + 2。
Max_Jitter_CD is the upper bound of jitter expected on the communication channel between compressor and decompressor (CD-CC). It depends only on the characteristics of CD-CC.
Max_Jitter_CDは、コンプレッサとデコンプレッサとの間の通信チャネル（CD-CC）で予想されるジッタの上限です。それが唯一のCD-CCの特性に依存します。
The constant 2 accounts for the quantization error introduced by the clocks at the compressor and decompressor, which can be +/-1.
+/- 1であることができるコンプレッサ及びデコンプレッサにおいてクロックにより導入される量子化誤差のための定数2つの占めます。
Note that the calculation of k follows the compression algorithm described in section 4.5.1, with p = 2^(k-1) - 1.
P = 2 ^（K-1）を用いて、kの計算は、セクション4.5.1で説明した圧縮アルゴリズムに従うことに注意 - 1。
4) The sliding window is subject to the same window operations as in section 4.5.2, 1) and 3), except that the values added and removed are paired with their arrival times.
4）スライディングウィンドウを追加および削除の値は、それらの到着時刻と対になっていることを除いて、セクション4.5.2と同じウィンドウ操作の対象となる、1）と3）。
Decompressor:
デコンプレッサ：
1) The decompressor uses as its reference header the last correctly (as verified by CRC) decompressed header. It maintains the pair (T_ref, a_ref), where T_ref is the scaled TS of the reference header, and a_ref is the arrival time of the reference header.
1）減圧装置は、基準ヘッダ最後に正しく（CRCにより確認されるように）解凍ヘッダとして使用します。これはT_ref、基準ヘッダのスケーリングされたTSである対（T_ref、a_ref）を、維持、及びa_ref基準ヘッダの到着時間です。
2) When receiving a compressed header n at time a_n, the approximation of the original scaled TS is calculated as:
時間A_Nにおける圧縮ヘッダnを受信した場合2）、元のスケーリングされたTSの近似値は次のように計算されます。
T_approx = T_ref + (a_n - a_ref) / TIME_STRIDE.
T_approx = T_ref +（A_N - a_ref）/ TIME_STRIDE。
3) The approximation is then refined by the k least significant bits carried in header n, following the decompression algorithm of section 4.5.1, with p = 2^(k-1) - 1.
3）近似は、次いで、P = 2 ^（K-1）を用いて、セクション4.5.1の解凍アルゴリズムに従って、ヘッダNで運ばのk個の最下位ビットによって精製される - 1。
Note: The algorithm does not assume any particular pattern in the packets arriving at the compressor, i.e., it tolerates reordering before the compressor and nonincreasing RTP Timestamp behavior.
注：このアルゴリズムは、すなわち、それは圧縮機及び非増加RTPタイムスタンプの動作の前に並べ替えを許容し、圧縮機に到着するパケット内の任意の特定のパターンを想定していません。
Note: Integer arithmetic is used in all equations above. If TIME_STRIDE is not equal to an integral number of clock ticks, time must be normalized such that TIME_STRIDE is an integral number of clock ticks. For example, if a clock tick is 20 ms and TIME_STRIDE is 30 ms, (a_n - a_ref) in 2) can be multiplied by 3 and TIME_STRIDE can have the value 2.
注：整数演算は、上記の全ての式に使用されます。 TIME_STRIDEクロックの整数倍に等しくない場合ダニ、時間がTIME_STRIDEクロックの整数ティックであるように正規化されなければなりません。クロックチックが20msであるとTIME_STRIDEが30ミリ秒である場合、例えば、（A_N - a_ref）2）を3で乗算することができ、TIME_STRIDEは値2を有することができます。
Note: The clock resolution of the compressor or decompressor can be worse than TIME_STRIDE, in which case the difference, i.e., actual resolution - TIME_STRIDE, is treated as additional jitter in the calculation of k.
注：圧縮または解凍器のクロックの分解能は、その場合の差、すなわち、実際の解像度で、TIME_STRIDEよりも悪いことができる - TIME_STRIDE、kの計算における付加的なジッタとして扱われます。
Note: The clock resolution of the decompressor may be communicated to the compressor using the CLOCK feedback option.
注：減圧装置のクロックの分解能は、クロックフィードバックオプションを使用して圧縮機に通信することができます。
Note: The decompressor may observe the jitter and report this to the compressor using the JITTER feedback option. The compressor may use this information to refine its estimate of Max_Jitter_CD.
注：解凍器は、ジッタを観察し、JITTERフィードバックオプションを使用して圧縮機にこれを報告することがあります。圧縮機はMax_Jitter_CDのその推定値を精緻化するためにこの情報を使用することができます。
As all IPv4 packets have an IP Identifier to allow for fragmentation, ROHC provides for transparent compression of this ID. There is no explicit support in ROHC for the IPv6 fragmentation header, so there is never a need to discuss IP IDs outside the context of IPv4.
すべてのIPv4パケットは断片化を可能にするために、IP識別子を持つように、ROHCは、このIDの透明な圧縮を提供します。 IPv6のフラグメンテーションヘッダーのためのROHCには明示的なサポートはありませんので、IPv4の文脈の外でIP IDを議論する必要は決してありません。
This section assumes (initially) that the IPv4 stack at the source host assigns IP-ID according to the value of a 2-byte counter which is increased by one after each assignment to an outgoing packet. Therefore, the IP-ID field of a particular IPv4 packet flow will increment by 1 from packet to packet except when the source has emitted intermediate packets not belonging to that flow.
このセクションでは、ソース・ホストのIPv4スタックが発信パケットにそれぞれ割り当てた後に1だけ増加される2バイトカウンタの値に応じてIP-IDを割り当てる（初期）を前提としています。したがって、特定のIPv4パケット・フローのIP-IDフィールドは、ソースはそのフローに属さない中間パケットが放出されたた場合を除き、パケット毎に1ずつ増加します。
For such IPv4 stacks, the RTP SN will increase by 1 for each packet emitted and the IP-ID will increase by at least the same amount. Thus, it is more efficient to compress the offset, i.e., (IP-ID - RTP SN), instead of IP-ID itself.
このようなIPv4のスタックのために、RTP SNは、放出されたパケットごとに1だけ増加し、IP-IDは、少なくとも同じ量だけ増加します。したがって、それは圧縮することがより効率的であるオフセット、即ち、（IP-ID - RTP SN）、代わりにIP-ID自体。
The remainder of section 4.5.5 describes how to compress/decompress the sequence of offsets using W-LSB encoding/decoding, with p = 0 (see section 4.5.1). All IP-ID arithmetic is done using unsigned 16-bit quantities, i.e., modulo 2^16.
セクション4.5.5の残りの部分は、p = 0とW-LSB符号化/復号化を、（セクション4.5.1を参照）を使用してオフセットのシーケンスを解凍/圧縮する方法について説明します。すべてのIP-IDの演算は、符号なし16ビット量、すなわち、モジュロ2 ^ 16を使用して行われます。
Compressor:
コンプレッサー：
The compressor uses W-LSB encoding (section 4.5.2) to compress a sequence of offsets
圧縮機は、オフセットのシーケンスを圧縮するためにW-LSB符号化（セクション4.5.2）を使用し
Offset_i = ID_i - SN_i,
Offset_i = ID_i - SN_i、
where ID_i and SN_i are the values of the IP-ID and RTP SN of header i. The sliding window contains such offsets and not the values of header fields, but the rules for adding and deleting offsets from the window otherwise follow section 4.5.2.
ここID_iとSN_iヘッダのIP-IDとRTP SN、iの値です。スライディングウィンドウは、そのようなオフセットはなく、ヘッダフィールドの値を含むが、窓からのオフセットを追加および削除するための規則は、他のセクション4.5.2に従います。
Decompressor:
デコンプレッサ：
The reference header is the last correctly (as verified by CRC) decompressed header.
（CRCにより確認されるように）ヘッダを解凍基準ヘッダは、最後に正しくです。
When receiving a compressed packet m, the decompressor calculates Offset_ref = ID_ref - SN_ref, where ID_ref and SN_ref are the values of IP-ID and RTP SN in the reference header, respectively.
値Id_refとSN_refは、それぞれ、基準ヘッダ内のIP-IDとRTP SNの値であるSN_ref、 - 圧縮されたパケットmを受信した場合、デコンプレッサはOffset_ref =値Id_refを算出します。
Then W-LSB decoding is used to decompress Offset_m, using the received LSBs in packet m and Offset_ref. Note that m may contain zero LSBs for Offset_m, in which case Offset_m = Offset_ref.
その後、W-LSBデコードは、パケットMとOffset_refで受信されたLSBを使用して、Offset_mを解凍するために使用されます。 mは、その場合Offset_m = Offset_refに、Offset_mゼロLSBを含んでいてもよいことに留意されたいです。
Finally, the IP-ID for packet m is regenerated as
最後に、パケットMのIP-IDは、以下のように再生されます
IP-ID for m = decompressed SN of packet m + Offset_m
MのためのIP-ID =パケットM + Offset_mの伸張SN
Network byte order:
ネットワークバイトオーダー：
Some IPv4 stacks do use a counter to generate IP ID values as described, but do not transmit the contents of this counter in network byte order, but instead send the two octets reversed. In this case, the compressor can compress the IP-ID field after swapping the bytes. Consequently, the decompressor also swaps the bytes of the IP-ID after decompression to regenerate the original IP-ID. This requires that the compressor and the decompressor synchronize on the byte order of the IP-ID field using the NBO or NBO2 flag (see section 5.7).
いくつかのIPv4スタックが説明したようにIP ID値を生成するカウンタを使うのですが、ネットワークバイトオーダーでこのカウンタの内容を送信することはありませんが、代わりに逆転の2つのオクテットを送ります。この場合、圧縮機は、バイトを交換した後にIP-IDフィールドを圧縮することができます。したがって、解凍装置は、元のIP-IDを再生成するために減圧した後、IP-IDのバイトをスワップ。これは、コンプレッサとデコンプレッサがNBOまたはNBO2フラグを使用してIP-IDフィールドのバイト順で同期をとる必要があり（セクション5.7を参照）。
Random IP Identifier:
ランダムIP識別子：
Some IPv4 stacks generate the IP Identifier values using a pseudo-random number generator. While this may provide some security benefits, it makes it pointless to attempt compressing the field. Therefore, the compressor should detect such random behavior of the field. After detection and synchronization with the decompressor using the RND or RND2 flag, the field is sent as-is in its entirety as additional octets after the compressed header.
いくつかのIPv4スタックは、擬似乱数生成器を用いて、IP識別子値を生成します。これは、いくつかのセキュリティ上の利点を提供し得るが、それはそれは無意味なフィールドを圧縮しようすることができます。したがって、圧縮機は、フィールドのランダム挙動を検出すべきです。 RNDまたはRND2フラグを使用して解凍器での検出及び同期の後、フィールドが圧縮されたヘッダーの後に追加のオクテットとしてその全体がそのまま送信されます。
The values of TS_STRIDE and a few other compression parameters can vary widely. TS_STRIDE can be 160 for voice and 90 000 for 1 f/s video. To optimize the transfer of such values, a variable number of octets is used to encode them. The number of octets used is determined by the first few bits of the first octet:
TS_STRIDEおよびいくつかの他の圧縮パラメータの値は、広く変えることができます。 TS_STRIDE 1のF / Sビデオの音声160 90 000であることができます。このような値の転送を最適化するために、オクテットの可変数は、それらを符号化するために使用されます。最初のオクテットの最初の数ビットによって決定され使用されるオクテットの数。
First bit is 0: 1 octet. 7 bits transferred. Up to 127 decimal. Encoded octets in hexadecimal: 00 to 7F
1オクテット：最初のビットは0です。 7ビットが転送されます。 127小数点以下まで。 16進数でエンコードされたオクテット：00 7Fへ
First bits are 10: 2 octets. 14 bits transferred. Up to 16 383 decimal. Encoded octets in hexadecimal: 80 00 to BF FF
2オクテット：最初のビットは10です。 14ビットが転送されます。 16 383小数点以下まで。 16進数で符号化されたオクテット：BF FF 80〜00
First bits are 110: 3 octets. 21 bits transferred. Up to 2 097 151 decimal. Encoded octets in hexadecimal: C0 00 00 to DF FF FF
3オクテット：最初のビットが110です。 21ビットが転送されます。 2 097 151小数点以下まで。 16進数でエンコードされたオクテット：C0 00 00 DF FF FFへ
First bits are 111: 4 octets. 29 bits transferred. Up to 536 870 911 decimal. Encoded octets in hexadecimal: E0 00 00 00 to FF FF FF FF
4オクテット：最初のビットが111です。 29ビットが転送されます。 536 870 911小数点以下まで。 16進数でエンコードされたオクテット：E0 00 00 00 FF FF FF FFへ
When a compressed header has an extension, pieces of an encoded value can be present in more than one field. When an encoded value is split over several fields in this manner, the more significant bits of the value are closer to the beginning of the header. If the number of bits available in compressed header fields exceeds the number of bits in the value, the most significant field is padded with zeroes in its most significant bits.
圧縮されたヘッダ拡張を有する場合、符号化された値の片が複数のフィールドに存在することができます。符号化された値がこのようにいくつかのフィールドに分割されている場合、値の上位ビットは、ヘッダの先頭に近いです。圧縮されたヘッダフィールドの利用可能なビットの数は、値のビット数を超えた場合、最も重要なフィールドは、その最上位ビットにゼロが埋め込まれています。
For example, an unscaled TS value can be transferred using an UOR-2 header (see section 5.7) with an extension of type 3. The Tsc bit of the extension is then unset (zero) and the variable length TS field of the extension is 4 octets, with 29 bits available for the TS (see section 4.5.6). The UOR-2 TS field will contain the three most significant bits of the unscaled TS, and the 4-octet TS field in the extension will contain the remaining 29 bits.
例えば、スケーリングされていないTS値はUOR-2ヘッダーを使用して転送することができる拡張ののTSCビットは、次に設定されていない（ゼロ）タイプ3の拡張子を持つ（セクション5.7を参照）と拡張の可変長TSフィールドでありますTSに利用可能な29ビットの4つのオクテット、（セクション4.5.6を参照）。 UOR-2 TSフィールドは、スケーリングされていないTSの3つの最上位ビットを含むであろう、そして拡張の4オクテットTSフィールドは、残りの29ビットを含むことになります。
ROHC is designed under the assumption that packets can be damaged between the compressor and decompressor, and that such damaged packets can be delivered to the decompressor ("residual errors").
ROHCは、パケットが圧縮器と解凍器との間に破損することができ、そのような損傷を受けたパケットをデコンプレッサ（「残差」）に送達することができるという仮定の下で設計されています。
Residual errors may damage the SN in compressed headers. Such damage will cause generation of a header which upper layers may not be able to distinguish from a correct header. When the compressed header contains a CRC, the CRC will catch the bad header with a probability dependent on the size of the CRC. When ROHC does not detect the bad header, it will be delivered to upper layers.
残留誤差は圧縮されたヘッダーでSNを損傷することがあります。そのような損傷は、上位レイヤが正しいヘッダと区別することができない場合があり、ヘッダの生成を引き起こします。圧縮されたヘッダーがCRCが含まれている場合、CRCは、CRCの大きさに依存確率で悪いヘッダをキャッチします。 ROHCが悪いヘッダを検出しない場合には、上位層に配信されます。
Damage is not confined to the SN:
ダメージはSNに限定されません。
a) Damage to packet type indication bits can cause a header to be interpreted as having a different packet type.
A）パケットタイプ指示ビットの損傷は、異なるパケットタイプを有するものとして解釈されるべきヘッダを引き起こす可能性があります。
b) Damage to CID information may cause a packet to be interpreted according to another context and possibly also according to another profile. Damage to CIDs will be more harmful when a large part of the CID space is being used, so that it is likely that the damaged CID corresponds to an active context.
B）CID情報への損傷は、他のプロファイルに従って、またおそらくは他の文脈に応じて解釈されるべきパケットを引き起こし得ます。 CID空間の大部分が使用されている場合、破損CIDがアクティブコンテキストに対応する可能性があるようなCIDへの損傷は、より有害であろう。
c) Feedback information can also be subject to residual errors, both when feedback is piggybacked and when it is sent in separate ROHC packets. ROHC uses sanity checks and adds CRCs to vital feedback information to allow detection of some damaged feedback.
C）フィードバック情報は、残留誤差を受けることができ、両方のフィードバックがピギーバックされたとき、それが別ROHCパケットで送信されるとき。 ROHCは、健全性チェックを使用し、いくつかの損傷を受けたフィードバックの検出を可能にするために重要なフィードバック情報にCRCを追加します。
Note that context damage can also result in generation of incorrect headers; section 4.7 elaborates further on this.
また、誤ったヘッダの生成につながることができ、そのコンテキストの損傷に注意してください。セクション4.7は、この上でさらに詳しく述べます。
Impairments to headers can be classified into the following types:
ヘッダーへの減損は、次のタイプに分類できます。
(1) the lower layer was not able to decode the packet and did not deliver it to ROHC,
（1）下部層が、パケットを復号することができなかったとROHCに配信しませんでした
(2) the lower layer was able to decode the packet, but discarded it because of a detected error,
（2）下位レイヤは、パケットを復号することができたが、なぜなら検出されたエラーのそれを廃棄し、
(3) ROHC detected an error in the generated header and discarded the packet, or
（3）ROHCは、生成されたヘッダでエラーを検出し、パケットを廃棄し、または
(4) ROHC did not detect that the regenerated header was damaged and delivered it to upper layers.
（4）ROHCが再生ヘッダが破損したことを検出して上位層にそれを配信しませんでした。
Impairments cause loss or damage of individual headers. Some impairment scenarios also cause context invalidation, which in turn results in loss propagation and damage propagation. Damage propagation and undetected residual errors both contribute to the number of damaged headers delivered to upper layers. Loss propagation and impairments resulting in loss or discarding of single packets both contribute to the packet loss seen by upper layers.
減損は、個々のヘッダの紛失や破損の原因となります。いくつかの障害シナリオはまた、損失の伝播とダメージの伝播における順番に結果コンテキストの無効化を引き起こします。損傷の伝搬と未検出残存誤りは、上位層に配信破損ヘッダの数に貢献の両方。損失伝播との両方が上位層によって見られるパケット損失に寄与する単一パケットの損失または廃棄を生じる障害。
Examples of context invalidating scenarios are:
コンテキスト無効シナリオの例は以下のとおりです。
(a) Impairment of type (4) on the forward channel, causing the decompressor to update its context with incorrect information;
（a）は、順方向チャネル上のタイプ（4）の減損を、減圧装置が誤った情報とそのコンテキストを更新させます。
(b) Loss/error burst of pattern update headers: Impairments of types (1),(2) and (3) on consecutive pattern update headers; a pattern update header is a header carrying a new pattern information, e.g., at the beginning of a new talk spurt; this causes the decompressor to lose the pattern update information;
（b）は、パターン更新ヘッダの損失/エラーバースト：タイプの減損（1）、（2）及び（3）の連続したパターンアップデートヘッダーにします。パターン更新ヘッダは新しいトーク・スパートの開始時に、例えば、新たなパターン情報を運ぶヘッダです。これは、デコンプレッサは、パターンファイルのアップデート情報を失うことになり、
(c) Loss/error burst of headers: Impairments of types (1),(2) and (3) on a number of consecutive headers that is large enough to cause the decompressor to lose the SN synchronization;
（c）はヘッダの損失/エラーバースト：タイプの減損（1）、（2）および（3）減圧装置がSN同期を失わせるのに十分な大きさの連続したヘッダの数に、
(d) Impairment of type (4) on the feedback channel which mimics a valid ACK and makes the compressor update its context;
（D）有効なACKを模倣し、圧縮機がそのコンテキストを更新させるフィードバック・チャネル上のタイプ（4）の減損。
(e) a burst of damaged headers (3) erroneously triggers the "k-out-of-n" rule for detecting context invalidation, which results in a NACK/update sequence during which headers are discarded.
（e）の破損ヘッダのバーストは、（3）誤ってヘッダが破棄され、その間NACK /更新シーケンスをもたらすコンテキストの無効化を検出するための「K-アウトオブN」ルールをトリガします。
Scenario (a) is mitigated by the CRC carried in all context updating headers. The larger the CRC, the lower the chance of context invalidation caused by (a). In R-mode, the CRC of context updating headers is always 7 bits or more. In U/O-mode, it is usually 3 bits and sometimes 7 or 8 bits.
シナリオ（A）は、すべてのコンテキスト更新ヘッダで運ばれたCRCによって緩和されます。より大きなCRC、（A）によって引き起こされるコンテキスト無効の低いチャンス。 Rモードでは、コンテキスト更新ヘッダのCRCは、常に7ビット以上です。 U / Oモードでは、通常、時には3ビット、7ビットまたは8ビットです。
Scenario (b) is almost completely eliminated when the compressor ensures through ACKs that no context updating headers are lost, as in R-mode.
圧縮無しコンテクストアップデートヘッダーはRモードのように、失われないことを保証するのACK介し場合シナリオ（B）はほぼ完全に排除されます。
Scenario (c) is almost completely eliminated when the compressor ensures through ACKs that the decompressor will always detect the SN wraparound, as in R-mode. It is also mitigated by the SN repair mechanisms in U/O-mode.
コンプレッサーが減圧装置が常にRモードのように、SNのラップアラウンドを検出することのACKを通じて保証場合シナリオ（c）はほぼ完全に排除されます。また、U / OモードでのSN修復メカニズムによって軽減されます。
Scenario (d) happens only when the compressor receives a damaged header that mimics an ACK of some header present in the W-LSB window, say ACK of header 2, while in reality header 2 was never received or accepted by the decompressor, i.e., header 2 was subject to impairment (1), (2) or (3). The damaged header must mimic the feedback packet type, the ACK feedback type, and the SN LSBs of some header in the W-LSB window.
すなわち、現実のヘッダ2が受信されなかったか、解凍器によって受け入れつつ、圧縮機はW-LSBウィンドウ内のいくつかのヘッダー本のACKを模倣破損ヘッダを受信した場合にのみ、シナリオ（d）が発生し、ヘッダ2のACKを言いますヘッダ2は、障害を受けた（1）、（2）又は（3）。損傷したヘッダは、フィードバックパケットタイプ、ACKフィードバックタイプ、およびW-LSBウィンドウ内のいくつかのヘッダのSNのLSBを模倣する必要があります。
Scenario (e) happens when a burst of residual errors causes the CRC check to fail in k out of the last n headers carrying CRCs. Large k and n reduces the probability of scenario (e), but also increases the number of headers lost or damaged as a consequence of any context invalidation.
残留誤差のバーストは、CRCチェックがCRCを運ぶ最後のnヘッダーからKに失敗したとき、シナリオ（e）が起こります。大きなkおよびnはシナリオ（E）の確率を減少させるだけでなく、どのようなコンテキスト無効化の結果として失われたまたは破損ヘッダの数を増加させます。
ROHC detects damaged headers using CRCs over the original headers. The smallest headers in this document either include a 3-bit CRC (U/O-mode) or do not include a CRC (R-mode). For the smallest headers, damage is thus detected with a probability of roughly 7/8 for U/O-mode. For R-mode, damage to the smallest headers is not detected.
ROHCは、オリジナルのヘッダーの上にCRCを使用して破損したヘッダを検出します。この文書に記載されている最小のヘッダはいずれかの3ビットのCRC（U / Oモード）を含むか、CRC（Rモード）を含みません。最小ヘッダため、損傷は、このように略7/8 U / Oモードのための確率で検出されます。 Rモードのために、最小のヘッダへの損傷が検出されません。
All other things (coding scheme at lower layers, etc.) being equal, the rate of headers damaged by residual errors will be lower when headers are compressed compared when they are not, since fewer bits are transmitted. Consequently, for a given ROHC CRC setup the rate of incorrect headers delivered to applications will also be reduced.
他のすべてのもの（下位層、等で符号化方式）が等しくそうでない場合より少ないビットが送信されるので、ヘッダーが、比較圧縮されたときに、残留エラーによって破損ヘッダの割合は低くなります。その結果、与えられたROHC CRCセットアップ用アプリケーションに配信間違ったヘッダの割合も減少します。
The above analysis suggests that U/O-mode may be more prone than R-mode to context invalidation. On the other hand, the CRC present in all U/O-mode headers continuously screens out residual errors coming from lower layers, reduces the number of damaged headers delivered to upper layers when context is invalidated, and permits quick detection of context invalidation.
上記の分析は、U / Oモードは、コンテキスト無効にRモードよりがちであることを示唆しています。一方、全てのU / OモードヘッダにおけるCRCの存在を連続的、下位層からの残留誤差を遮蔽コンテキストが無効化される上位層に配信破損ヘッダの数を減少させ、およびコンテキストの無効化の迅速な検出を可能にします。
R-mode always uses a stronger CRC on context updating headers, but no CRC in other headers. A residual error on a header which carries no CRC will result in a damaged header being delivered to upper layers (4). The number of damaged headers delivered to the upper layers depends on the ratio of headers with CRC vs. headers without CRC, which is a compressor parameter.
R-modeは常にヘッダを更新し、コンテキストに強いCRCを使用しませんが、他のヘッダにはCRC。何CRCを運ぶないヘッダ上の残留誤差は、上位層（4）に配信さ破損ヘッダをもたらすであろう。上位レイヤに送達損傷ヘッダの数は、圧縮機パラメータであるCRC、無しCRC対ヘッダーとヘッダーの比に依存します。
The ROHC protocol is based on a number of parameters that form part of the negotiated channel state and the per-context state. This section describes some of this state information in an abstract way. Implementations can use a different structure for and representation of this state. In particular, negotiation protocols that set up the per-channel state need to establish the information that constitutes the negotiated channel state, but it is not necessary to exchange it in the form described here.
ROHCプロトコルはネゴシエートチャネル状態ごとのコンテキスト状態の一部を形成するパラメータの数に基づいています。このセクションでは、抽象的な方法でこの状態情報のいくつかを説明します。実装は、この状態の異なる構造と表現を使用することができます。具体的には、チャンネルごとの状態を設定する交渉プロトコルが交渉されたチャネル状態を構成する情報を確立する必要があるが、ここで説明する形でそれを交換する必要はありません。
MAX_CID: Nonnegative integer; highest context ID number to be used by the compressor (note that this parameter is not coupled to, but in effect further constrained by, LARGE_CIDS).
MAX_CID：非負の整数;圧縮機によって使用される最高コンテキストID番号（このパラメータが結合されていないことに注意し、その効果にさらにLARGE_CIDS、によって制約）。
LARGE_CIDS: Boolean; if false, the short CID representation (0 bytes or 1 prefix byte, covering CID 0 to 15) is used; if true, the embedded CID representation (1 or 2 embedded CID bytes covering CID 0 to 16383) is used.
LARGE_CIDS：ブール。 falseの場合、短いCID表現（15 CID 0を覆う0バイトまたは1つのプレフィックスバイトは、）が使用されます。 trueの場合、埋め込まれたCID表現（16383にCID 0を覆う1又は2埋め込みCIDバイト）が使用されます。
PROFILES: Set of nonnegative integers, each integer indicating a profile supported by the decompressor. The compressor MUST NOT compress using a profile not in PROFILES.
プロファイル：非負の整数の集合、解凍装置によってサポートされるプロファイルを示す各整数。コンプレッサーは、プロファイルではないプロファイルを使用して圧縮してはなりません。
FEEDBACK_FOR: Optional reference to a channel in the reverse direction. If provided, this parameter indicates which channel any feedback sent on this channel refers to (see 5.7.6.1).
FEEDBACK_FOR：逆方向のチャネルへのオプション参照。提供される場合、このパラメータは、このチャネル上で送信されたフィードバックは（5.7.6.1を参照）を意味するチャネルを示します。
MRRU: Maximum reconstructed reception unit. This is the size of the largest reconstructed unit in octets that the decompressor is expected to reassemble from segments (see 5.2.5). Note that this size includes the CRC. If MRRU is negotiated to be 0, no segment headers are allowed on the channel.
MRRU：最大再構成された受信ユニット。これは、デコンプレッサは、セグメント（5.2.5を参照）から再構築することが予想されるオクテットで最大の再構成されたユニットのサイズです。このサイズは、CRCが含まれていることに注意してください。 MRRUが0であることがネゴシエートされている場合、セグメント・ヘッダはチャネル上で許可されていません。
Per-context parameters are established with IR headers (see section 5.2.3). An IR header contains a profile identifier, which determines how the rest of the header is to be interpreted. Note that the profile parameter determines the syntax and semantics of the packet type identifiers and packet types used in conjunction with a specific context. This document describes profiles 0x0000, 0x0001, 0x0002, and 0x0003; further profiles may be defined when ROHC is extended in the future.
単位のコンテキストパラメータは、IRヘッダ（セクション5.2.3を参照）との間で確立されています。 IRヘッダは、ヘッダの残りを解釈する方法を決定するプロファイル識別子を含んでいます。プロファイルパラメータは、特定のコンテキストに関連して使用されるパケットタイプ識別子とパケットタイプの構文及びセマンティクスを決定することに留意されたいです。この文書では、プロファイル0000、0x0001に、0×0002、および0x0003を記述する。 ROHCは、将来的に拡張した場合、さらにプロファイルが定義されてもよいです。
Profile 0x0000 is for sending uncompressed IP packets. See section 5.10.
プロファイル0000は圧縮されていないIPパケットを送信するためです。セクション5.10を参照してください。
Profile 0x0001 is for RTP/UDP/IP compression, see sections 5.3 through 5.9.
プロファイルは0x0001は5.9経由のセクション5.3を参照して、RTP / UDP / IP圧縮のためです。
Profile 0x0002 is for UDP/IP compression, i.e., compression of the first 12 octets of the UDP payload is not attempted. See section 5.11.
0×0002がUDP / IP圧縮、即ちためされているプロファイル、UDPペイロードの最初の12オクテットの圧縮が試みられていません。セクション5.11を参照してください。
Profile 0x0003 is for ESP/IP compression, i.e., compression of the header chain up to and including the first ESP header, but not subsequent subheaders. See section 5.12.
0x0003は、ESP / IP圧縮、すなわち、最大ヘッダ鎖の圧縮及び第ESPヘッダを含むではなく、後続のサブヘッダのためされているプロファイル。セクション5.12を参照してください。
Initially, all contexts are in no context state, i.e., all packets referencing this context except IR packets are discarded. If defined by a "ROHC over X" document, per-channel negotiation can be used to pre-establish state information for a context (e.g., negotiating profile 0x0000 for CID 15). Such state information can also be marked read-only in the negotiation, which would cause the decompressor to discard any IR packet attempting to modify it.
最初に、すべてのコンテキストがないコンテキスト状態、すなわち、IRパケットを除いて、このコンテキストを参照するすべてのパケットが破棄されています。 「ROHC Xオーバー」ドキュメントによって定義されている場合、チャネルごとのネゴシエーションは、コンテキストの状態情報を事前に確立するために使用することができる（例えば、CID 15のプロファイル0000を交渉します）。このような状態情報はまた、読み取り専用のデコンプレッサは、それを修正しようとするすべてのIRパケットを破棄させるような交渉、でマークすることができます。
Associated with each compressed flow is a context, which is the state compressor and decompressor maintain in order to correctly compress or decompress the headers of the packet stream. Contexts are identified by a context identifier, CID, which is sent along with compressed headers and feedback information.
各圧縮されたフローに関連する状態の圧縮機であり、デコンプレッサ正しくパケットストリームのヘッダーを圧縮または圧縮解除するために維持するコンテキストです。コンテキストは、圧縮されたヘッダーとフィードバック情報と共に送信されるコンテキスト識別子、CIDによって識別されます。
The CID space is distinct for each channel, i.e., CID 3 over channel A and CID 3 over channel B do not refer to the same context, even if the endpoints of A and B are the same nodes. In particular, CIDs for any pairs of forward and reverse channels are not related (forward and reverse channels need not even have CID spaces of the same size).
CID空間は、AとBのエンドポイントが同じノードであっても、同じコンテキストを参照していないチャネルBの上に、チャネルA及びCID 3上、すなわち、CID 3チャネルごとに異なっています。具体的には、前方の任意のペアのためのCID及び逆方向チャネルは（順方向および逆方向チャネルも必要はない同じサイズのCID空間を有する）関連していません。
Context information is conceptually kept in a table. The context table is indexed using the CID which is sent along with compressed headers and feedback information. The CID space can be negotiated to be either small, which means that CIDs can take the values 0 through 15, or large, which means that CIDs take values between 0 and 2^14 - 1 = 16383. Whether the CID space is large or small is negotiated no later than when a channel is established.
コンテキスト情報は、概念的に、テーブルに保存されます。コンテキストテーブルは、圧縮されたヘッダーとフィードバック情報と共に送信されるCIDを使用して索引付けされます。 CID空間が大きいかどうか1 = 16383 - CID空間がのCIDは、0から2 ^ 14の間の値をとることを意味する、のCID 15を介して値0をとることができることを意味し、小さい、または大きいのいずれかであることをネゴシエートすることができます小さなは遅くともチャネルが確立されたときよりも交渉されていません。
A small CID with the value 0 is represented using zero bits. A small CID with a value from 1 to 15 is represented by a four-bit field in place of a packet type field (Add-CID) plus four more bits. A large CID is represented using the encoding scheme of section 4.5.6, limited to two octets.
値0を持つ小さなCIDは、ゼロのビットを用いて表現されます。 1から15までの値を有する小さいCIDは、4ビットのパケットタイプフィールドの代わりにフィールド（ADD-CID）を加えてさらに4ビットで表現されます。大きいCIDは2つのオクテットに限定セクション4.5.6の符号化方式を使用して表されます。
The packet type indication scheme for ROHC has been designed under the following constraints:
ROHCのためのパケットタイプの表示方式は、以下の制約の下で設計されています：
a) it must be possible to use only a limited number of packet sizes;
b) it must be possible to send feedback information in separate ROHC
packets as well as piggybacked on forward packets;
c) it is desirable to allow elimination of the CID for one packet
stream when few packet streams share a channel;
d) it is anticipated that some packets with large headers may be
larger than the MTU of very constrained lower layers.
These constraints have led to a design which includes
これらの制約は、デザインにつながっています
- optional padding, - a feedback packet type, - an optional Add-CID octet which provides 4 bits of CID, and - a simple segmentation and reassembly mechanism.
- オプションのパディング、 - フィードバックパケットタイプ、 - 単純なセグメント化および再組立機構 - CIDの4ビットを提供し、任意のAdd-CIDオクテット。
A ROHC packet has the following general format (in the diagram, colons ":" indicate that the part is optional):
ROHCパケットは、以下の一般形式は（図中、コロン「：」の部分がオプションであることを示しています）。
--- --- --- --- --- --- --- ---
: Padding : variable length
--- --- --- --- --- --- --- ---
: Feedback : 0 or more feedback elements
--- --- --- --- --- --- --- ---
: Header : variable, with CID information
--- --- --- --- --- --- --- ---
: Payload :
--- --- --- --- --- --- --- ---
Padding is any number (zero or more) of padding octets. Either of Feedback or Header must be present.
パディングは、パディングオクテットの任意の数（ゼロ以上）です。フィードバックやヘッダーのいずれかが存在している必要があります。
Feedback elements always start with a packet type indication. Feedback elements carry internal CID information. Feedback is described in section 5.2.2.
フィードバック要素は、常にパケットタイプ指示で始まります。フィードバック要素は、内部CID情報を運びます。フィードバックは、セクション5.2.2に記載されています。
Header is either a profile-specific header or an IR or IR-DYN header (see sections 5.2.3 and 5.2.4). Header either
ヘッダは、プロファイル固有のヘッダーまたはIRまたはIR-DYNヘッダー（セクション5.2.3および5.2.4を参照）のいずれかです。どちらかのヘッダー
1) does not carry any CID information (indicating CID zero), or 2) includes one Add-CID Octet (see below), or 3) contains embedded CID information of length one or two octets.
1）任意のCID情報（CIDゼロを示す）を有していない、または2）一方がオクテット（下記参照）-CIDを追加する、または3）の長さが1又は2つのオクテットの埋め込まれたCID情報を含ん含みます。
Alternatives 1) and 2) apply only to compressed headers in channels where the CID space is small. Alternative 3) applies only to compressed headers in channels where the CID space is large.
代替1）と2）はCID空間が小さいチャネルに圧縮されたヘッダーにのみ適用されます。代替3）はCID空間が大きいチャネルで圧縮されたヘッダーにのみ適用されます。
Padding Octet
パディングオクテット
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 0 0 0 0 |
+---+---+---+---+---+---+---+---+
Add-CID Octet
追加-CIDオクテット
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | CID |
+---+---+---+---+---+---+---+---+
CID: 0x1 through 0xF indicates CIDs 1 through 15.
CID：0xFの通じ0x1のは、CIDを1〜15を示しています。
Note: The Padding Octet looks like an Add-CID octet for CID 0.
注意：パディングオクテットはCID 0のAdd-CIDオクテットのように見えます。
Header either starts with a packet type indication or has a packet type indication immediately following an Add-CID Octet. All Header packet types have the following general format (in the diagram, slashes "/" indicate variable length):
パケットタイプ指示で始まるか、すぐにアドインCIDオクテットを、次のパケットタイプの表示を持っているいずれかのヘッダです。全ヘッダパケットタイプは以下の一般的なフォーマットを有する（図中、「/」可変長を示すスラッシュ）。
0 x-1 x 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if (CID 1-15) and (small CIDs)
+---+--- --- --- ---+--- --- ---+
| type indication | body | 1 octet (8-x bits of body)
+---+--- ---+---+---+--- --- ---+
: :
/ 0, 1, or 2 octets of CID / 1 or 2 octets if (large CIDs)
: :
+---+---+---+---+---+---+---+---+
/ body / variable length
+---+---+---+---+---+---+---+---+
The large CID, if present, is encoded according to section 4.5.6.
大きいCIDは、存在する場合、セクション4.5.6に従って符号化されます。
Feedback carries information from decompressor to compressor. The following principal kinds of feedback are supported. In addition to the kind of feedback, other information may be included in profile-specific feedback information.
フィードバックは、圧縮機への減圧装置からの情報を運びます。フィードバックの次の主要な種類がサポートされています。フィードバックの種類に加えて、他の情報は、プロファイル固有のフィードバック情報に含まれていてもよいです。
ACK : Acknowledges successful decompression of a packet, which means that the context is up-to-date with a high probability.
ACKは：コンテキストが高い確率で最新であることを意味し、パケットの解凍の成功を、認めています。
NACK : Indicates that the dynamic context of the decompressor is out of sync. Generated when several successive packets have failed to be decompressed correctly.
NACK：解凍器の動的コンテキストが同期していることを示します。いくつかの連続したパケットが正しく解凍することに失敗したときに生成。
STATIC-NACK : Indicates that the static context of the decompressor is not valid or has not been established.
STATIC-NACK：解凍器の静的コンテキストが有効でないか、または確立されていないことを示します。
It is anticipated that feedback to the compressor can be realized in many ways, depending on the properties of the particular lower layer. The exact details of how feedback is realized is to be specified in a "ROHC over X" document, for each lower layer X in question. For example, feedback might be realized using
圧縮機へのフィードバックが特定の下位層の特性に応じて、多くの方法で実現することができると予想されます。フィードバックを実現する方法の正確な詳細は、問題の各下位層Xのために、「ROHC Xオーバー」文書で指定されます。例えば、フィードバックを用いて実現される可能性があります
1) lower-layer specific mechanisms
1）下層固有のメカニズム
2) a dedicated feedback-only channel, realized for example by the lower layer providing a way to indicate that a packet is a feedback packet
2）専用のフィードバックチャネルのみが、パケットがフィードバックパケットであることを示すための方法を提供する下位層によって、例えば実現しました
3) a dedicated feedback-only channel, where the timing of the feedback provides information about which compressed packet caused the feedback
3）フィードバックのタイミング情報を提供する専用のフィードバックチャネルのみが、どの圧縮されたパケットは、フィードバックを引き起こし
4) interspersing of feedback packets among normal compressed packets going in the same direction as the feedback (lower layers do not indicate feedback)
4）（下位層がフィードバックを示していない）フィードバックと同じ方向に進んで通常の圧縮されたパケットのうち、フィードバックパケットの散在
5) piggybacking of feedback information in compressed packets going in the same direction as the feedback (this technique may reduce the per-feedback overhead)
フィードバックと同じ方向に進んで圧縮されたパケットに、フィードバック情報の5）ピギーバック（この技術はあたりのフィードバックオーバーヘッドを低減することができます）
6) interspersing and piggybacking on the same channel, i.e., both 4) and 5).
6）散在と同じチャネル上でピギーバック、すなわち、両方4）及び5）。
Alternatives 1-3 do not place any particular requirements on the ROHC packet type scheme. Alternatives 4-6 do, however. The ROHC packet type scheme has been designed to allow alternatives 4-6 (these may be used for example over PPP):
代替1-3はROHCパケットタイプ計画上の任意の特定の要件を置かないでください。代替4-6はしかし、行います。 ROHCパケットタイプスキームは代替4-6（これらはPPP上の例のために使用することができる）できるように設計されています。
a) The ROHC scheme provides a feedback packet type. The packet type is able to carry variable-length feedback information.
A）ROHC方式はフィードバックパケットタイプを提供します。パケットタイプは、可変長のフィードバック情報を搬送することができます。
b) The feedback information sent on a particular channel is passed to, and interpreted by, the compressor associated with feedback on that channel. Thus, the feedback information must contain CID information if the associated compressor can use more than one context. The ROHC feedback scheme requires that a channel carries feedback to at most one compressor. How a compressor is associated with feedback on a particular channel needs to be defined in a "ROHC over X" document.
特定のチャネル上で送信B）フィードバック情報に渡され、そのチャネル上のフィードバックに関連付けられている圧縮機によって解釈されます。したがって、フィードバック情報は、関連する圧縮機は、複数のコンテキストを使用できるかどうかCID情報を含まなければなりません。 ROHCのフィードバック方式は、チャネルは最大1つの圧縮機にフィードバックを運ぶことが必要です。圧縮機は、特定のチャネル上のフィードバックに関連付けられている方法は、「ROHC Xオーバー」文書で定義する必要があります。
c) The ROHC feedback information format is octet-aligned, i.e., starts at an octet boundary, to allow using the format over a dedicated feedback channel, 2).
C）ROHCフィードバック情報のフォーマットは、オクテット整列され、すなわち、専用フィードバック・チャネル、2）上フォーマットを使用可能にするために、オクテットの境界で始まります。
d) To allow piggybacking, 5), it is possible to deduce the length of feedback information by examining the first few octets of the feedback. This allows the decompressor to pass piggybacked feedback information to the associated same-side compressor without understanding its format. The length information decouples the decompressor from the compressor in the sense that the decompressor can process the compressed header immediately without waiting for the compressor to hand it back after parsing the feedback information.
d）に便乗できるようにするには、5）、フィードバックの最初の数オクテットを調べることによってフィードバック情報の長さを推定することが可能です。これは、デコンプレッサは、その形式を理解することなく、関連する同じ側圧縮機にピギーバックフィードバック情報を渡すことができます。長さ情報は、解凍器がフィードバック情報を解析した後、それを手の甲圧縮機を待たずに直ちに圧縮されたヘッダを処理することができるという意味で、圧縮機からデコンプレッサを切り離します。
Feedback sent on a ROHC channel consists of one or more concatenated feedback elements, where each feedback element has the following format:
ROHCチャネル上で送信されたフィードバックは、各フィードバック要素には、以下のフォーマットを有する一つまたはそれ以上の連結フィードバック要素からなります：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | Code | feedback type octet
+---+---+---+---+---+---+---+---+
: Size : if Code = 0
+---+---+---+---+---+---+---+---+
/ feedback data / variable length
+---+---+---+---+---+---+---+---+
Code: 0 indicates that a Size octet is present. 1-7 indicates the size of the feedback data field in octets.
コード：0サイズオクテットが存在することを示します。 1-7オクテットにフィードバックデータフィールドのサイズを示します。
Size: Optional octet indicating the size of the feedback data field in octets.
サイズ：オクテットにフィードバックデータフィールドのサイズを示すオプションのオクテット。
feedback data: Profile-specific feedback information. Includes CID information.
フィードバックデータ：プロファイル固有のフィードバック情報。 CID情報を含んでいます。
The total size of the feedback data field is determinable upon reception by the decompressor, by inspection of the Code field and possibly the Size field. This explicit length information allows piggybacking and also sending more than one feedback element in a packet.
フィードバックデータフィールドの合計サイズは、コードフィールドの検査及びおそらくサイズフィールドによって、解凍装置によって受信時に決定することができます。この明示的な長さ情報をピギーバックし、またパケットに複数のフィードバック要素を送信することができます。
When the decompressor has determined the size of the feedback data field, it removes the feedback type octet and the Size field (if present) and hands the rest to the same-side associated compressor together with an indication of the size. The feedback data received by the compressor has the following structure (feedback sent on a dedicated feedback channel MAY also use this format):
減圧装置がフィードバックデータフィールドのサイズを決定した場合には、フィードバック方式のオクテットとサイズフィールド（存在する場合）と手のサイズの指示と共に同じ側関連コンプレッサーに残りの部分を除去します。圧縮機によって受信されたフィードバックデータ（このフォーマットを使用するかもしれ専用フィードバックチャネル上で送信されたフィードバック）以下の構造を有します：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
: :
/ large CID (4.5.6 encoding) / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
/ feedback /
+---+---+---+---+---+---+---+---+
The large CID, if present, is encoded according to section 4.5.6. CID information in feedback data indicates the CID of the packet stream for which feedback is sent. Note that the LARGE_CIDS parameter that controls whether a large CID is present is taken from the channel state of the receiving compressor's channel, NOT from that of the channel carrying the feedback.
大きいCIDは、存在する場合、セクション4.5.6に従って符号化されます。フィードバックデータにおけるCID情報は、フィードバックが送信されたパケットストリームのCIDを示しています。大CIDが存在するかどうかを制御LARGE_CIDSパラメータが受信コンプレッサーのチャネルのチャネル状態から、NOTフィードバックを運ぶチャネルとから取られることに留意されたいです。
It is REQUIRED that the feedback field have either of the following two formats:
フィードバック・フィールドは、次の2つの形式のいずれかを持っていることが必要とされます。
FEEDBACK-1
FEEDBACK-1
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| profile specific information | 1 octet
+---+---+---+---+---+---+---+---+
FEEDBACK-2
FEEDBACK-2
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| |
+---+---+ profile specific / at least 2 octets
/ information |
+---+---+---+---+---+---+---+---+
Acktype: 0 = ACK 1 = NACK 2 = STATIC-NACK 3 is reserved (MUST NOT be used. Otherwise unparseable.)
Acktype：0 = ACK 1 = NACK 2 = STATIC-NACK 3に予約されている（そうでなければ解析できない使用してはいけません。）。
The compressor can use the following logic to parse the feedback field.
コンプレッサーは、フィードバックフィールドを解析するために、次のロジックを使用することができます。
1) If for large CIDs, the feedback will always start with a CID encoded according to section 4.5.6. If the first bit is 0, the CID uses one octet. If the first bit is 1, the CID uses two octets.
1）大型のCIDのために、フィードバックは、常にセクション4.5.6に従って符号化されたCIDで開始された場合。最初のビットが0の場合、CIDは1つのオクテットを使用しています。最初のビットが1の場合、CIDは2つのオクテットを使用しています。
2) If for small CIDs, and the size is one octet, the feedback is a FEEDBACK-1.
2）小のCIDのための場合、サイズは、フィードバックはFEEDBACK-1であり、1つのオクテットです。
3) If for small CIDs, and the size is larger than one octet, and the feedback starts with the two bits 11, the feedback starts with an Add-CID octet. If the size is 2, it is followed by FEEDBACK-1. If the size is larger than 2, the Add-CID is followed by FEEDBACK-2.
小規模のCID、及びサイズについて1つのオクテットよりも大きい場合、フィードバックは、2つのビット11で始まる場合3）、フィードバックは、Add-CIDオクテットから始まります。サイズが2である場合、それはFEEDBACK-1が続いています。サイズが2より大きい場合は、アドインCIDはFEEDBACK-2が続いています。
4) Otherwise, there is no Add-CID octet, and the feedback starts with a FEEDBACK-2.
4）そうでなければ、そこにはアドインCIDオクテットはなく、フィードバックはFEEDBACK-2で始まります。
The IR header associates a CID with a profile, and typically also initializes the context. It can typically also refresh (parts of) the context. It has the following general format.
IRヘッダは、プロファイルとCIDを関連付け、そして典型的には、コンテキストを初期化します。それは、典型的には、コンテキスト（の一部）を更新することができます。これは、次の一般的な形式があります。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 | x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile specific information / variable length
| |
+---+---+---+---+---+---+---+---+
x: Profile specific information. Interpreted according to the profile indicated in the Profile field.
X：特定の情報のプロファイルを作成します。プロファイルフィールドに示されたプロファイルに従って解釈。
Profile: The profile to be associated with the CID. In the IR packet, the profile identifier is abbreviated to the 8 least significant bits. It selects the highest-number profile in the channel state parameter PROFILES that matches the 8 LSBs given.
プロフィール：CIDに関連付けするプロファイル。 IRパケットに、プロファイル識別子は、8つの最下位ビットと略記します。それは、与えられた8つのLSBと一致したチャネル状態パラメータプロファイルにおける最高数のプロファイルを選択します。
CRC: 8-bit CRC computed using the polynomial of section 5.9.1. Its coverage is profile-dependent, but it MUST cover at least the initial part of the packet ending with the Profile field. Any information which initializes the context of the decompressor should be protected by the CRC.
CRC：8ビットCRCは、セクション5.9.1の多項式を用いて計算しました。その適用範囲は、プロファイルに依存しますが、それはProfileフィールドで終わるパケットの少なくとも最初の部分をカバーしなければなりません。伸張器のコンテクストを初期化し、任意の情報はCRCによって保護されるべきです。
Profile specific information: The contents of this part of the IR packet are defined by the individual profiles. Interpreted according to the profile indicated in the Profile field.
特定の情報をプロフィール：IRパケットのこの部分の内容は、個々のプロファイルによって定義されます。プロファイルフィールドに示されたプロファイルに従って解釈。
In contrast to the IR header, the IR-DYN header can never initialize an uninitialized context. However, it can redefine what profile is associated with a context, see for example 5.11 (ROHC UDP) and 5.12 (ROHC ESP). Thus the type needs to be reserved at the framework level. The IR-DYN header typically also initializes or refreshes parts of a context, typically the dynamic part. It has the following general format:
IRヘッダとは対照的に、IR-DYNヘッダーは初期化されていないコンテキストを初期化することはできません。しかし、それは、コンテキストに関連付けられているものプロファイルを再定義例5.11（ROHC UDP）および5.12（ROHC ESP）のために見ることができます。こうしてタイプは、フレームワークレベルで予約する必要があります。 IR-DYNヘッダーは、典型的には、初期化またはコンテキスト、典型的には、動的部分の部分をリフレッシュ。これは、次の一般的な形式になっています。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 0 | IR-DYN type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile specific information / variable length
| |
+---+---+---+---+---+---+---+---+
Profile: The profile to be associated with the CID. This is abbreviated in the same way as with IR packets.
プロフィール：CIDに関連付けするプロファイル。これは、IRパケットと同様に省略されます。
CRC: 8-bit CRC computed using the polynomial of section 5.9.1. Its coverage is profile-dependent, but it MUST cover at least the initial part of the packet ending with the Profile field. Any information which initializes the context of the decompressor should be protected by the CRC.
CRC：8ビットCRCは、セクション5.9.1の多項式を用いて計算しました。その適用範囲は、プロファイルに依存しますが、それはProfileフィールドで終わるパケットの少なくとも最初の部分をカバーしなければなりません。伸張器のコンテクストを初期化し、任意の情報はCRCによって保護されるべきです。
Profile specific information: This part of the IR packet is defined by individual profiles. It is interpreted according to the profile indicated in the Profile field.
特定の情報をプロフィール：IRパケットのこの部分は、個々のプロファイルで定義されています。これは、プロファイルフィールドに示されたプロファイルに従って解釈されます。
Some link layers may provide a much more efficient service if the set of different packet sizes to be transported is kept small. For such link layers, these sizes will normally be chosen to transport frequently occurring packets efficiently, with less frequently occurring packets possibly adapted to the next larger size by the addition of padding. The link layer may, however, be limited in the size of packets it can offer in this efficient mode, or it may be desirable to request only a limited largest size. To accommodate the occasional packet that is larger than that largest size negotiated, ROHC defines a simple segmentation protocol.
搬送される異なるパケットサイズのセットが小さく維持されている場合、一部のリンク層は、はるかに効率的なサービスを提供することができます。このようなリンク層のために、これらのサイズは、通常、おそらくパディングを添加することにより次のより大きなサイズに適合あまり頻繁に発生するパケットと、効率的にパケットを発生頻繁に輸送するために選択されます。リンク層は、しかし、この効率的なモードで提供することができるパケットのサイズが制限されてもよく、または限られた最大サイズを要求することが望ましい場合があります。ネゴシエートその最大サイズよりも大きい時折パケットを収容するために、ROHCは、単純なセグメント化プロトコルを定義しています。
The segmentation protocol defined in ROHC is not particularly efficient. It is not intended to replace link layer segmentation functions; these SHOULD be used whenever available and efficient for the task at hand.
ROHCで定義されたセグメンテーション・プロトコルは特に効率的ではありません。リンク層のセグメンテーション機能に代わるものではありません。これらは、当面の作業のためにいつでも利用でき、効率的な使用されるべきです。
ROHC segmentation should only be used for occasional packets with sizes larger than what is efficient to accommodate, e.g., due to exceptionally large ROHC headers. The segmentation scheme was designed to reduce packet size variations that may occur due to outliers in the header size distribution. In other cases, segmentation should be done at lower layers. The segmentation scheme should only be used for packet sizes that are larger than the maximum size in the allowed set of sizes from the lower layers.
ROHCセグメントのみによる例外的に大きなROHCヘッダーに、例えば、対応するために効率的であるものよりも大きいサイズの臨時のパケットのために使用されるべきです。セグメンテーションスキームは、ヘッダサイズ分布における外れ値のため発生する可能性があり、パケットサイズのばらつきを低減するように設計しました。他の場合において、セグメンテーションは、下位層で行われるべきです。セグメンテーションスキームは、下位層からのサイズの許容セットの最大サイズより大きいパケットサイズのために使用されるべきです。
In summary, ROHC segmentation should be used with a relatively low frequency in the packet flow. If this cannot be ensured, segmentation should be performed at lower layers.
要約すると、ROHC分割は、パケットフローの比較的低い周波数で使用されるべきです。これが確保できない場合は、セグメンテーションは、下位層で実行する必要があります。
Segment Packet
セグメントパケット
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 1 | F |
+---+---+---+---+---+---+---+---+
/ Segment / variable length
+---+---+---+---+---+---+---+---+
F: Final bit. If set, it indicates that this is the last segment of a reconstructed unit.
F：最終ビット。設定した場合、これは、再構成ユニットの最後のセグメントであることを示しています。
The segment header may be preceded by padding octets and/or feedback. It never carries a CID.
セグメント・ヘッダは、パディングオクテット及び/又はフィードバックによって先行されてもよいです。これは、CIDを運ぶことはありません。
All segment header packets for one reconstructed unit have to be sent consecutively on a channel, i.e., any non-segment-header packet following a nonfinal segment header aborts the reassembly of the current reconstructed unit and causes the decompressor to discard the nonfinal segments received on this channel so far. When a final segment header is received, the decompressor reassembles the segment carried in this packet and any nonfinal segments that immediately preceded it into a single reconstructed unit, in the order they were received. The reconstructed unit has the format:
1つの再構成されたユニットのヘッダーパケットがチャネル上で連続送信しなければならないすべてのセグメント、すなわち、任意の非セグメントヘッダーパケットは、非最終セグメント・ヘッダは、現在の再構成ユニットの再組み立てを中止し、非最終セグメントを廃棄する減圧装置が、受信した原因以下これまでにこのチャンネル。最終セグメント・ヘッダが受信されると、減圧装置はこのパケットで運ばれたセグメントとすぐに、それらが受信された順に、単一の再構成ユニットにそれを先行任意の非最終セグメントを再構築します。再構成ユニットは、フォーマットを有します。
Reconstructed Unit
再構成されたユニット
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| |
/ Reconstructed ROHC packet / variable length
| |
+---+---+---+---+---+---+---+---+
/ CRC / 4 octets
+---+---+---+---+---+---+---+---+
The CRC is used by the decompressor to validate the reconstructed unit. It uses the FCS-32 algorithm with the following generator polynomial: 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 [HDLC]. If the reconstructed unit is 4 octets or less, or if the CRC fails, or if it is larger than the channel parameter MRRU (see 5.1.1), the reconstructed unit MUST be discarded by the decompressor.
CRCは、再構成ユニットを検証するために解凍装置により使用されます。これは、次の生成多項式とFCS-32アルゴリズムを使用：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 [HDLC]。再構成ユニットは、4つのオクテット以下である場合、またはCRCが失敗した場合、またはそれが（5.1.1を参照）チャネルパラメータMRRUより大きい場合、再構成ユニットは、解凍装置によって廃棄されなければなりません。
If the CRC succeeds, the reconstructed ROHC packet is interpreted as a ROHC Header, optionally followed by a payload. Note that this means that there can be no padding and no feedback in the reconstructed unit, and that the CID is derived from the initial octets of the reconstructed unit.
CRCが成功した場合、再構成されたROHCパケットは、任意のペイロードが続く、ROHCヘッダとして解釈されます。これは、パディングと再構成されたユニットでないフィードバックが存在しないことができること、およびCIDを再構成ユニットの最初のオクテットから誘導されることを意味することに留意されたいです。
(It should be noted that the ROHC segmentation protocol was inspired by SEAL by Steve Deering et al., which later became ATM AAL5. The same arguments for not having sequence numbers in the segments but instead providing a strong CRC in the reconstructed unit apply here as well. Note that, as a result of this protocol, there is no way in ROHC to make any use of a segment that has residual bit errors.)
（これは、ROHC分割プロトコルはスティーブデアリングら、後でATM AAL5になったことにより、シールによって触発されたことに留意すべきである。れないセグメントのシーケンス番号を有する代わりに、再構成ユニットに強いCRCを提供するための同じ議論がここで適用します同様に、このプロトコルの結果として、残留ビットエラーを有するセグメントのいずれかを利用するためにROHCに方法がない、ということに注意してください。）
The following packet types are reserved at the framework level in the ROHC scheme:
次のパケットタイプがROHC方式におけるフレームワーク・レベルで予約されています。
1110: Padding or Add-CID octet 11110: Feedback 11111000: IR-DYN packet 1111110: IR packet 1111111: Segment
1110：パディングまたは追加-CIDオクテット11110：フィードバック11111000：IR-DYNパケット1111110：IRパケット1111111：セグメント
Other packet types can be used at will by individual profiles.
他のパケットタイプは、個々のプロファイルで自由に使用することができます。
The following steps is an outline of initial decompressor processing which upon reception of a ROHC packet can determine its contents.
次の手順は、ROHCパケットを受信すると、その内容を決定することができる最初の解凍処理の概要です。
1) If the first octet is a Padding Octet (11100000), strip away all initial Padding Octets and goto next step.
1）最初のオクテットはパディングオクテット（11100000）である場合、すべての初期パディングオクテットとジャンプ次のステップを剥ぎ取ります。
2) If the first remaining octet starts with 1110, it is an Add-CID octet:
最初の残りのオクテットは1110で始まる場合2）、それは、Add-CIDオクテットであります：
remember the Add-CID octet; remove the octet.
アドインCIDのオクテットを覚えています。オクテットを削除します。
3) If the first remaining octet starts with 11110, and an Add-CID octet was found in step 2),
3）第一の残りのオクテットは、11110から始まり、そしてアドインCIDオクテットステップ2で見つかった場合）、
an error has occurred; the header MUST be discarded without
further action.
4) If the first remaining octet starts with 11110, and an Add-CID octet was not found in step 2), this is feedback:
最初の残りのオクテットは、11110から始まり、そしてアドインCIDオクテット）がステップ2で見つからなかった場合4）、これはフィードバックです。
find the size of the feedback data, call it s;
remove the feedback type octet;
remove the Size octet if Code is 0;
send feedback data of length s to the same-side associated
compressor;
if packet exhausted, stop; otherwise goto 2).
5) If the first remaining octet starts with 1111111, this is a segment:
最初の残りオクテットが1111111で始まる場合5）、これはセグメントです。
attempt reconstruction using the segmentation protocol
(5.2.5). If a reconstructed packet is not produced, this
finishes the processing of the original packet. If a
reconstructed packet is produced, it is fed into step 1)
above. Padding, segments, and feedback are not allowed in
reconstructed packets, so when processing them, steps 1),
4), and 5) are modified so that the packet is discarded
without further action when their conditions match.
6) Here, it is known that the rest is forward information (unless the header is damaged).
6）ここで、ヘッダが破損している場合を除き、残り）は（フォワード情報であることが知られています。
7) If the forward traffic uses small CIDs, there is no large CID in the packet. If an Add-CID immediately preceded the packet type (step 2), it has the CID of the Add-CID; otherwise it has CID 0.
前方のトラフィックが小さなCIDを使用している場合は7）、パケットには大きなCIDはありません。アドインCIDは直ちにパケットタイプ（ステップ2）に先行した場合、それは、Add-CIDのCIDを有します。それ以外の場合は、CID 0を持っています。
8) If the forward traffic uses large CIDs, the CID starts with the second remaining octet. If the first bit(s) of that octet are not 0 or 10, the packet MUST be discarded without further action. If an Add-CID octet immediately preceded the packet type (step 2), the packet MUST be discarded without further action.
順方向トラフィックが大きいCIDを使用する場合8）、CIDは、第二の残りのオクテットから始まります。そのオクテットの最初のビット（S）が0または10でない場合、パケットは、さらなる動作なしで捨てなければなりません。アドインCIDのオクテットが直ちにパケットタイプ（ステップ2）に先行した場合、パケットは、さらなる動作なしで捨てなければなりません。
9) Use the CID to find the context.
9）コンテキストを見つけるために、CIDを使用してください。
10) If the packet type is IR, the profile indicated in the IR packet determines how it is to be processed. If the CRC fails to verify the packet, it MUST be discarded. If a profile is indicated in the context, the logic of that profile determines what, if any, feedback is to be sent. If no profile is noted in the context, no further action is taken.
パケットタイプがIR場合10）、IRパケットに示されたプロファイルは、それが処理される方法を決定します。 CRCは、パケットを検証するために失敗した場合、それを捨てなければなりません。プロファイルは文脈に示されている場合、そのプロファイルのロジックがある場合、フィードバックが送信されるもの、を判定する。プロファイルが文脈に注意されていない場合は、さらなる行動を全く取りません。
11) If the packet type is IR-DYN, the profile indicated in the IR-DYN packet determines how it is to be processed.
パケットタイプは、IR-DYNの場合11）、IR-DYNパケットに示されたプロファイルは、それが処理される方法を決定します。
a) If the CRC fails to verify the packet, it MUST be discarded. If a profile is indicated in the context, the logic of that profile determines what, if any, feedback is to be sent. If no profile is noted in the context, no further action is taken.
CRCは、パケットの検証に失敗した場合a）は、それを捨てなければなりません。プロファイルは文脈に示されている場合、そのプロファイルのロジックがある場合、フィードバックが送信されるもの、を判定する。プロファイルが文脈に注意されていない場合は、さらなる行動を全く取りません。
b) If the context has not been initialized by an IR packet, the packet MUST be discarded. The logic of the profile indicated in the IR-DYN header (if verified by the CRC), determines what, if any, feedback is to be sent.
文脈がIRパケットによって初期化されていない場合b）に、パケットを捨てなければなりません。 （CRCにより確認した場合）IR-DYNヘッダーに示されたプロファイルの論理は、もしあれば、フィードバックが送信されるもの、を判定する。
12) Otherwise, the profile noted in the context determines how the rest of the packet is to be processed. If the context has not been initialized by an IR packet, the packet MUST be discarded without further action.
12）それ以外の場合は、文脈で述べたプロファイルは、パケットの残りの部分が処理される方法を決定します。文脈がIRパケットによって初期化されていない場合、パケットはさらにアクションなしで捨てなければなりません。
The procedure for finding the size of the feedback data is as follows:
次のようにフィードバックデータのサイズを見つけるための手順は次のとおりです。
Examine the three bits which immediately follow the feedback packet type. When these bits are 1-7, the size of the feedback data is given by the bits; 0, a Size octet, which explicitly gives the size of the feedback data, is present after the feedback type octet.
すぐにフィードバックパケットタイプに続く3ビットを調べます。これらのビットが1-7である場合に、フィードバックデータのサイズをビットで与えられます。 0、明示的フィードバックデータのサイズを与えるサイズのオクテットは、フィードバック型のオクテットの後に存在しています。
ROHC RTP uses three packet types to identify compressed headers, and two for initialization/refresh. The format of a compressed packet can depend on the mode. Therefore a naming scheme of the form
ROHC RTP圧縮ヘッダを識別するために3つのパケットタイプを使用し、初期化/更新のための2つの。圧縮されたパケットのフォーマットは、モードに依存することができます。フォームのための命名体系
<modes format is used in>-<packet type number>-<some property>
<いくつかのプロパティ> - <パケットタイプ番号> - <モードフォーマットがで使用され>
is used to uniquely identify the format when necessary, e.g., UOR-2, R-1. For exact formats of the packet types, see section 5.7.
例えば、UOR-2、R-1、必要なときに一意の形式を識別するために使用されます。パケットタイプの正確な形式については、5.7節を参照してください。
Packet type zero: R-0, R-0-CRC, UO-0.
パケットタイプゼロ：R-0、R-0-CRC、UO-0。
This, the minimal, packet type is used when parameters of all SN-functions are known by the decompressor, and the header to be compressed adheres to these functions. Thus, only the W-LSB encoded RTP SN needs to be communicated.
全てSN-関数のパラメータは、解凍器によって知られているとき、これは、最小の、パケットタイプが使用され、ヘッダは、これらの機能に付着を圧縮します。したがって、唯一のW-LSBエンコードされたRTP SNは通信する必要があります。
R-mode: Only if a CRC is present (packet type R-0-CRC) may the header be used as a reference for subsequent decompression.
Rモード：CRCが存在する場合にのみは、（パケットタイプR-0-CRC）ヘッダは、後続の復元のための基準として使用することができます。
U-mode and O-mode: A small CRC is present in the UO-0 packet.
UモードおよびOモード：小さいCRCはUO-0パケット内に存在します。
Packet type 1: R-1, R-1-ID, R-1-TS, UO-1, UO-1-ID, UO-1-TS.
パケットタイプ1：R-1、R-1-ID、R-1-TS、UO-1、UO-1-ID、UO-1-TS。
This packet type is used when the number of bits needed for the SN exceeds those available in packet type zero, or when the parameters of the SN-functions for RTP TS or IP-ID change.
SNのために必要なビットの数は、パケットタイプゼロ、またはで入手可能なものを超えたときに、このパケットタイプが使用される場合、RTP TSまたはIP-ID変更のSN-関数のパラメータ。
R-mode: R-1-* packets are not used as references for subsequent decompression. Values for other fields than the RTP TS or IP-ID can be communicated using an extension, but they do not update the context.
R-モード：R-1 - *パケットは、その後の解凍のための参照として使用されていません。 RTP TSまたはIP-ID以外のフィールドの値は、拡張機能を使用して通信することができますが、それらはコンテキストを更新しません。
U-mode and O-mode: Only the values of RTP SN, RTP TS and IP-ID can be used as references for future compression. Nonupdating values can be provided for other fields using an extension (UO-1-ID).
UモードおよびOモード：RTP SN、RTP TS及びIP-IDの値のみが、将来の圧縮のためのリファレンスとして使用することができます。 Nonupdating値が拡張子（UO-1-ID）を用いて、他のフィールドのために提供することができます。
Packet type 2: UOR-2, UOR-2-ID, UOR-2-TS
パケットタイプ2：UOR-2、UOR-2-ID、UOR-2-TS
This packet type can be used to change the parameters of any SN-function, except those for most static fields. Headers of packets transferred using packet type 2 can be used as references for subsequent decompression.
このパケットタイプは、ほとんどの静的フィールドのものを除き、すべてのSN-関数のパラメータを変更するために使用することができます。パケットタイプ2を使用して転送されるパケットのヘッダは、後続の減圧のための参照として使用することができます。
Packet type: IR
パケットタイプ：IR
This packet type communicates the static part of the context, i.e., the value of the constant SN-functions. It can optionally also communicate the dynamic part of the context, i.e., the parameters of the nonconstant SN-functions.
このパケットタイプは文脈の静的な部分、すなわち、一定のSN-関数の値を通信します。それはまた、任意のコンテキストの動的部分を通信することができる、すなわち、非定数SN-関数のパラメータ。
Packet type: IR-DYN
パケットタイプ：IR-DYN
This packet type communicates the dynamic part of the context, i.e., the parameters of nonconstant SN-functions.
このパケットタイプは文脈、即ち、非定数SN-関数のパラメータの動的部分を通信します。
The packet types IR (with dynamic information), IR-DYN, and UOR-2 are common for all modes. They can carry a mode parameter which can take the values U = Unidirectional, O = Bidirectional Optimistic, and R = Bidirectional Reliable.
パケットタイプIR（動的情報とともに）、IR-DYN及びUOR-2は、すべてのモードのために共通です。彼らは、値U =単方向、O =双方向楽観、及びR =双方向の信頼性を取ることができるモードパラメータを運ぶことができます。
Feedback of types ACK, NACK, and STATIC-NACK carry sequence numbers, and feedback packets can also carry a mode parameter indicating the desired compression mode: U, O, or R.
U、O、又はR.：タイプACK、NACK及びSTATIC-NACKキャリーシーケンス番号、およびフィードバックパケットのフィードバックは、所望の圧縮モードを示すモードパラメータを運ぶことができます
As a shorthand, the notation PACKET(mode) is used to indicate which mode value a packet carries. For example, an ACK with mode parameter R is written ACK(R), and an UOR-2 with mode parameter O is written UOR-2(O).
略記として、表記パケット（モード）は、パケットが担持するモード値を示すために使用されます。例えば、モードパラメータOとACK（R）書き込まれ、UOR-2であるモードパラメータRとACKはUOR-2（O）が書き込まれます。
Below is the state machine for the compressor in Unidirectional mode. Details of the transitions between states and compression logic are given subsequent to the figure.
以下は、単方向モードでの圧縮機のためのステートマシンがあります。州と圧縮ロジック間の移行の詳細については、図の後に与えられています。
Optimistic approach
+------>------>------>------>------>------>------>------>------+
| |
| Optimistic approach Optimistic approach |
| +------>------>------+ +------>------>------+ |
| | | | | |
| | v | v v
+----------+ +----------+ +----------+
| IR State | | FO State | | SO State |
+----------+ +----------+ +----------+
^ ^ | ^ | |
| | Timeout | | Timeout / Update | |
| +------<------<------+ +------<------<------+ |
| |
| Timeout |
+------<------<------<------<------<------<------<------<------+
The transition logic for compression states in Unidirectional mode is based on three principles: the optimistic approach principle, timeouts, and the need for updates.
楽観的なアプローチ原則、タイムアウト、およびアップデートの必要性：単方向モードでの圧縮状態の遷移ロジックは、3つの原則に基づいています。
Transition to a higher compression state in Unidirectional mode is carried out according to the optimistic approach principle. This means that the compressor transits to a higher compression state when it is fairly confident that the decompressor has received enough information to correctly decompress packets sent according to the higher compression state.
単方向モードでのより高い圧縮状態への遷移は、楽観的なアプローチ原則に従って行われます。減圧装置が正常より高い圧縮状態に応じて送信されたパケットを解凍するのに十分な情報を受信したことをかなり確信より高い圧縮状態に圧縮遷移するときことを意味します。
When the compressor is in the IR state, it will stay there until it assumes that the decompressor has correctly received the static context information. For transition from the FO to the SO state, the compressor should be confident that the decompressor has all parameters needed to decompress according to a fixed pattern.
コンプレッサーがIR状態にあるとき、それは解凍器が静的コンテクスト情報を正しく受信していることを前提としてまで、それはそこに滞在します。 SO状態へFOからの移行のために、圧縮器は、解凍器は、固定パターンに応じて解凍するために必要なすべてのパラメータを持っていることを確信しなければなりません。
The compressor normally obtains its confidence about decompressor status by sending several packets with the same information according to the lower compression state. If the decompressor receives any of these packets, it will be in sync with the compressor. The number of consecutive packets to send for confidence is not defined in this document.
圧縮機は、通常、低い圧縮状態に応じて、同じ情報を複数のパケットを送信することによって、解凍器の状態についてその信頼度を取得します。減圧装置がこれらのパケットのいずれかを受信した場合、それは、圧縮機と同期であろう。自信のために送信するための連続したパケットの数は、この文書で定義されていません。
When the optimistic approach is taken as described above, there will always be a possibility of failure since the decompressor may not have received sufficient information for correct decompression. Therefore, the compressor MUST periodically transit to lower compression states. Periodic transition to the IR state SHOULD be carried out less often than transition to the FO state. Two different timeouts SHOULD therefore be used for these transitions. For an example of how to implement periodic refreshes, see [IPHC] chapters 3.3.1-3.3.2.
上記のように楽観的アプローチが取られるときに減圧装置が正しい減圧のための十分な情報を受信していないかもしれないので、常に故障の可能性が存在することになります。したがって、圧縮機は、低い圧縮状態に定期的に通過する必要があります。 IR状態への周期的な遷移がFO状態への遷移よりもしばしば行われるべきです。二つの異なるタイムアウトは、したがって、これらの遷移のために使用されるべきです。定期的なリフレッシュを実装する方法の例については、[IPHC]章3.3.1-3.3.2を参照。
In addition to the downward state transitions carried out due to periodic timeouts, the compressor must also immediately transit back to the FO state when the header to be compressed does not conform to the established pattern.
周期的なタイムアウトに行わ下方の状態遷移に加えて、圧縮機はまた、バックヘッダが圧縮されるFO状態に直ちに遷移が確立されたパターンに従わないしなければなりません。
The compressor chooses the smallest possible packet format that can communicate the desired changes, and has the required number of bits for W-LSB encoded values.
圧縮機は、必要な変更を通信することができる最小の可能なパケットフォーマットを選択し、W-LSB符号化された値のために必要なビット数を有しています。
The Unidirectional mode of operation is designed to operate over links where a feedback channel is not available. If a feedback channel is available, however, the decompressor MAY send an acknowledgment of successful decompression with the mode parameter set to U (send an ACK(U)). When the compressor receives such a message, it MAY disable (or increase the interval between) periodic IR refreshes.
運転の単方向モードは、フィードバック・チャネルが利用可能でないリンク上で動作するように設計されています。フィードバック・チャネルが利用可能である場合、しかし、デコンプレッサは、U（ACK（U）を送信する）に設定されたモードパラメータを使用して成功した減圧の肯定応答を送信することができます。圧縮機は、そのようなメッセージを受信すると、無効（または間隔増加）周期的なIRリフレッシュをMAY。
Below is the state machine for the decompressor in Unidirectional mode. Details of the transitions between states and decompression logic are given subsequent to the figure.
以下は、単方向モードでのデコンプレッサのためのステートマシンがあります。州と解凍ロジック間の移行の詳細については、図の後に与えられています。
Success
+-->------>------>------>------>------>--+
| |
No Static | No Dynamic Success | Success
+-->--+ | +-->--+ +--->----->---+ +-->--+
| | | | | | | | |
| v | | v | v | v
+--------------+ +----------------+ +--------------+
| No Context | | Static Context | | Full Context |
+--------------+ +----------------+ +--------------+
^ | ^ |
| k_2 out of n_2 failures | | k_1 out of n_1 failures |
+-----<------<------<-----+ +-----<------<------<-----+
Successful decompression will always move the decompressor to the Full Context state. Repeated failed decompression will force the decompressor to transit downwards to a lower state. The decompressor does not attempt to decompress headers at all in the No Context and Static Context states unless sufficient information is included in the packet itself.
解凍の成功は、常に完全なコンテキスト状態にデコンプレッサを移動します。繰り返し失敗した減圧は、より低い状態に遷移下方にデコンプレッサを強制します。デコンプレッサは、十分な情報がパケット自体に含まれていない限り、コンテキストおよび静的コンテキスト状態なしでのすべてのヘッダを解凍しようとしません。
Decompression in Unidirectional mode is carried out following three steps which are described in subsequent sections.
単方向モードでの伸張は、後続のセクションで説明される3つの手順に従って行われます。
In Full Context state, decompression may be attempted regardless of what kind of packet is received. However, for the other states decompression is not always allowed. In the No Context state only IR packets, which carry the static information fields, may be decompressed. Further, when in the Static Context state, only packets carrying a 7- or 8-bit CRC can be decompressed (i.e., IR, IR-DYN, or UOR-2 packets). If decompression may not be performed the packet is discarded, unless the optional delayed decompression mechanism is used, see section 6.1.
完全なコンテキスト状態で、減圧は関係なく、受信したパケットの種類を試みたことがあります。しかし、他の州のための減圧は常に許可されていません。静的情報フィールドを運ぶなしコンテキスト状態のみIRパケットに、解凍することができます。さらに、場合静的コンテクスト状態でのみ7-または8-ビットCRCを搬送するパケット（すなわち、IR、IR-DYN、またはUOR-2パケット）解凍することができます。減圧を行うことができない場合、パケットは、オプションの遅延減圧機構はセクション6.1を参照して、使用されていない限り、破棄されます。
When reconstructing the header, the decompressor takes the header information already stored in the context and updates it with the information received in the current header. (If the reconstructed header fails the CRC check, these updates MUST be undone.)
ヘッダを再構築するとき、デコンプレッサは、既にコンテキストに格納されたヘッダ情報を取得し、現在のヘッダ内の受信された情報とを更新します。 （再構成されたヘッダがCRCチェックに失敗した場合、これらの更新を元に戻す必要があります。）
The sequence number is reconstructed by replacing the sequence number LSBs in the context with those received in the header. The resulting value is then verified to be within the interpretation interval by comparison with a previously reconstructed reference value v_ref (see section 4.5.1). If it is not within this interval, an adjustment is applied by adding N x interval_size to the reconstructed value so that the result is brought within the interpretation interval. Note that N can be negative.
シーケンス番号は、ヘッダで受信されたものに関連して、シーケンス番号のLSBを置き換えることによって再構成される。得られた値は、次いで、以前に再構成された基準値V_REFとの比較によって解釈インターバル内にあることが確認される（セクション4.5.1を参照）。それはこの間隔内にない場合、調整結果が解釈インターバル内になるように再構成された値にN個のx interval_sizeを添加することによって適用されます。 Nが負になることに注意してください。
If RTP Timestamp and IP Identification fields are not included in the received header, they are supposed to be calculated from the sequence number. The IP Identifier usually increases by the same delta as the sequence number and the timestamp by the same delta times a fixed value. See chapters 4.5.3 and 4.5.5 for details about how these fields are encoded in compressed headers.
RTPタイムスタンプとIP識別フィールドを受信したヘッダに含まれていない場合、それらはシーケンス番号から計算されるようになっています。 IP識別子は、通常、同じデルタ時間固定値によって、シーケンス番号とタイムスタンプと同じデルタによって増加します。各章にこれらのフィールドが圧縮ヘッダでエンコードされている方法の詳細は、4.5.3と4.5.5を参照してください。
When working in Unidirectional mode, all compressed headers carry a CRC which MUST be used to verify decompression.
単方向モードで動作するとき、全ての圧縮ヘッダが解凍を検証するために使用されなければならないCRCを運びます。
This section is written so that it is applicable to all modes.
それはすべてのモードに適用されるように、このセクションでは、書かれています。
A mismatch in the CRC can be caused by one or more of:
CRCの不一致は、のいずれかの方法で発生する可能性があります。
3. many consecutive packets being lost between compressor and decompressor (this may cause the LSBs of the SN in compressed packets to be interpreted wrongly, because the decompressor has not moved the interpretation interval for lack of input -- in essence, a kind of context damage).
3.多くの連続したパケットは、コンプレッサとデコンプレッサとの間に失われる（デコンプレッサは、入力がないために解釈インターバルを移動していないので、これは、誤って解釈されるべき圧縮されたパケットにSNのLSBを引き起こす可能性が - 本質的に、コンテキストの種類をダメージ）。
(Cases 2 and 3 do not apply to IR packets; case 3 does not apply to IR-DYN packets.) The 3-bit CRC present in some header formats will eventually detect context damage reliably, since the probability of undetected context damage decreases exponentially with each new header processed. However, residual bit errors in the current header are only detected with good probability, not reliably.
（事例2及び3は、IRパケットには適用されない。ケース3は、IR-DYNパケットには適用されない。）未検出コンテキスト損傷の確率が指数関数的に減少するため、いくつかのヘッダフォーマットの3ビットのCRC存在は、最終的に、確実にコンテキストの損傷を検出します各新しいヘッダで処理。しかし、現在のヘッダ内の残留ビットエラーだけではない確実、良好な確率で検出されます。
When a CRC mismatch is caused by residual bit errors in the current header (case 1 above), the decompressor should stay in its current state to avoid unnecessary loss of subsequent packets. On the other hand, when the mismatch is caused by a damaged context (case 2), the decompressor should attempt to repair the context locally. If the local repair attempt fails, it must move to a lower state to avoid delivering incorrect headers. When the mismatch is caused by prolonged loss (case 3), the decompressor might attempt additional decompression attempts. Note that case 3 does not occur in R-mode.
CRCの不一致が現在のヘッダ（上記ケース1）の残留ビットエラーに起因する場合、デコンプレッサは、後続のパケットの不必要な損失を回避するために、その現在の状態に留まるべきです。ミスマッチが損傷コンテキスト（ケース2）によるものである場合一方、減圧装置は、ローカルコンテキストを修復することを試みるべきです。地元の修復に失敗した場合、それは間違ったヘッダを提供しないようするために、より低い状態に移行しなければなりません。ミスマッチが長期間損失（ケース3）によって引き起こされるとき、減圧装置は、追加の伸長試みを試みるかもしれません。 Rモードでは発生しない場合注3。
The following actions MUST be taken when a CRC check fails:
CRCチェックが失敗した場合、以下の操作を行う必要があります。
First, attempt to determine whether SN LSB wraparound (case 3) is likely, and if so, attempt a correction. For this, the algorithm of section 5.3.2.2.4 MAY be used. If another algorithm is used, it MUST have at least as high a rate of correct repairs as the one in 5.3.2.2.4. (This step is not applicable to R-mode.)
まず、試みはSN LSBラップアラウンド（ケース3）の可能性があるかどうかを決定し、もしそうであれば、補正を試みます。このため、セクション5.3.2.2.4のアルゴリズムを使用することができます。別のアルゴリズムを使用する場合は、5.3.2.2.4での一つとして正しい修理の少なくとも同じ高レートを持たなければなりません。 （このステップはRモードには適用されません。）
Second, if the previous step did not attempt a correction, a repair should be attempted under the assumption that the reference SN has been incorrectly updated. For this, the algorithm of section 5.3.2.2.5 MAY be used. If another algorithm is used, it MUST have at least as high a rate of correct repairs as the one in 5.3.2.2.5. (This step is not applicable to R-mode.)
前のステップで補正をしようとしていなかった場合は、2番目、修理、基準SNが誤って更新されているという仮定の下で試みるべきです。このため、セクション5.3.2.2.5のアルゴリズムを使用することができます。別のアルゴリズムを使用する場合は、5.3.2.2.5での一つとして正しい修理の少なくとも同じ高レートを持たなければなりません。 （このステップはRモードには適用されません。）
If both the above steps fail, additional decompression attempts SHOULD NOT be made. There are two possible reasons for the CRC failure: case 1 or unrecoverable context damage. It is impossible to know for certain which of these is the actual cause. The following rules are to be used:
上記の手順の両方が失敗した場合、追加の解凍試みがなされるべきではありません。ケース1または回復不能なコンテキストダメージ：CRCの故障のための2つの理由が考えられます。実際の原因であるこれらのどの特定のために知っておくことは不可能です。以下の規則が使用されることになります。
a. When CRC checks fail only occasionally, assume residual errors in the current header and simply discard the packet. NACKs SHOULD NOT be sent at this time.
A。 CRCチェックがたまにしか失敗した場合、現在のヘッダ内の残留誤りを仮定し、単にパケットを捨てます。 NACKは、この時点で送るべきではありません。
b. In the Full Context state: When the CRC check of k_1 out of the last n_1 decompressed packets have failed, context damage SHOULD be assumed and a NACK SHOULD be sent in O- and R-mode. The decompressor moves to the Static Context state and discards all packets until an update (IR, IR-DYN, UOR-2) which passes the CRC check is received.
B。フルコンテキスト状態で：最後N_1のうちK_1のCRCチェックパケットが失敗した解凍、コンテキストの損傷が想定されるべきであり、NACKは、O-およびRモードで送信されるべきです。更新まで静的コンテクスト状態と廃棄すべてのパケットをデコンプレッサへ移動（IR、IR-DYN、UOR-2）CRCチェックが受信される渡します。
c. In the Static Context state: When the CRC check of k_2 out of the last n_2 updates (IR, IR-DYN, UOR-2) have failed, static context damage SHOULD be assumed and a STATIC-NACK is sent in O- and R-mode. The decompressor moves to the No Context state.
C。静的コンテクスト状態で：最後N_2更新（IR、IR-DYN、UOR-2）のうちK_2のCRCチェックが失敗した場合、静的コンテクスト損傷が想定されるべきであり、STATIC-NACKはO-及びRで送信されます-モード。デコンプレッサはありませんContext状態に移行します。
d. In the No Context state: The decompressor discards all packets until a static update (IR) which passes the CRC check is received. (In O-mode and R-mode, feedback is sent according to sections 5.4.2.2 and 5.5.2.2, respectively.)
D。いいえコンテキスト状態で：減圧装置は、CRCチェックが受信される通過静的更新（IR）まで、すべてのパケットを廃棄します。 （Oモード及びRモードでは、フィードバックは、セクションそれぞれ5.4.2.2と5.5.2.2、に従って送信されます。）
Note that appropriate values for k_1, n_1, k_2, and n_2, are related to the residual error rate of the link. When the residual error rate is close to zero, k_1 = n_1 = k_2 = n_2 = 1 may be appropriate.
K_1、N_1、K_2、及びN_2、適切な値は、リンクの残留誤り率に関連していることに留意されたいです。残留誤り率がゼロに近い場合、K_1 = N_1 = K_2 = N_2 = 1が適切であり得ます。
When many consecutive packets are lost there will be a risk of sequence number LSB wraparound, i.e., the SN LSBs being interpreted wrongly because the interpretation interval has not moved for lack of input. The decompressor might be able to detect this situation and avoid context damage by using a local clock. The following algorithm MAY be used:
多くの連続したパケットは、シーケンス番号LSBラップアラウンドの危険性があるだろうが失われた場合、解釈間隔は入力の不足のために移動していないため、すなわち、SN LSBが誤って解釈されます。デコンプレッサは、この状況を検出し、ローカルクロックを使用してコンテキストの損傷を避けることができるかもしれません。以下のアルゴリズムが使用されることがあります。
a. The decompressor notes the arrival time, a(i), of each incoming packet i. Arrival times of packets where decompression fails are discarded.
A。デコンプレッサは、私は、各着信パケットの到着時刻、（i）を指摘しています。解凍に失敗したパケットの到着時間が破棄されています。
b. When decompression fails, the decompressor computes INTERVAL = a(i) - a(i - 1), i.e., the time elapsed between the arrival of the previous, correctly decompressed packet and the current packet.
B。減圧が失敗した場合、デコンプレッサは、間隔は（i）を計算する= - （I - 1）、すなわち、前、正しく解凍パケットの到着と現在のパケット間の経過時間。
c. If wraparound has occurred, INTERVAL will correspond to at least 2^k inter-packet times, where k is the number of SN bits in the current header. On the basis of an estimate of the packet inter-arrival time, obtained for example using a moving average of arrival times, TS_STRIDE, or TS_TIME, the decompressor judges if INTERVAL can correspond to 2^k inter-packet times.
C。ラップアラウンドが発生した場合、間隔は、kは現在のヘッダ内のSNビットの数は少なくとも2 ^ kのパケット間時間に対応することになります。到着時間の移動平均を使用して、例えば、取得したパケット間到着時間の推定値に基づいて、TS_STRIDE、またはTS_TIME、デコンプレッサ判断INTERVALが2 ^ kのパケット間時間に対応することができる場合。
d. If INTERVAL is judged to be at least 2^k packet inter-arrival times, the decompressor adds 2^k to the reference SN and attempts to decompress the packet using the new reference SN.
D。 INTERVALが少なくとも2 ^ kのパケット到着間の時間であると判定された場合、デコンプレッサは、基準SNに2 ^ Kを加算して新しい基準SNを使用してパケットを解凍することを試みます。
e. If this decompression succeeds, the decompressor updates the context but SHOULD NOT deliver the packet to upper layers. The following packet is also decompressed and updates the context if its CRC succeeds, but SHOULD be discarded. If decompression of the third packet using the new context also succeeds, the context repair is deemed successful and this and subsequent decompressed packets are delivered to the upper layers.
電子。この解凍が成功した場合、デコンプレッサは、コンテキストを更新しますが、上位層にパケットを届けるべきではありません。次のパケットも解凍され、そのCRCが成功した場合、コンテキストを更新しますが、廃棄すべきです。新しいコンテキストを使用して第3のパケットの解凍が成功すると、コンテキストの修復は成功したとみなされ、これとその後の解凍パケットが上位レイヤに送達されます。
f. If any of the three decompression attempts in d. and e. fails, the decompressor discards the packets and acts according to rules a) through c) of section 5.3.2.2.3.
F。 dは3つの解凍の試みのいずれかの場合。そしてe。デコンプレッサセクション5.3.2.2.3のCスルールールA））に従ってパケットを廃棄し、作用、失敗。
Using this mechanism, the decompressor may be able to repair the context after excessive loss, at the expense of discarding two packets.
このメカニズムを使用して、解凍装置は2つのパケットを破棄を犠牲にし、過剰な損失の後にコンテキストを修復することができるかもしれません。
The CRC can fail to detect residual errors in the compressed header because of its limited length, i.e., the incorrectly decompressed packet can happen to have the same CRC as the original uncompressed packet. The incorrect decompressed header will then update the context. This can lead to an erroneous reference SN being used in W-LSB decoding, as the reference SN is updated for each successfully decompressed header of certain types.
CRCが原因すなわち、その制限された長さの圧縮ヘッダ内の残留誤りを検出するために失敗することがあり、誤って減圧パケットは、元の非圧縮パケットと同じCRCを有するように起こることができます。不正確な解凍ヘッダは、コンテキストを更新します。これは、基準SNが特定のタイプの各正常解凍ヘッダに対して更新されるように、W-LSB復号化に使用されている誤った基準SNにつながる可能性があります。
In this situation, the decompressor will detect the incorrect decompression of the following packet with high probability, but it does not know the reason for the failure. The following mechanism allows the decompressor to judge if the context was updated incorrectly by an earlier packet and, if so, to attempt a repair.
このような状況では、デコンプレッサは、高い確率で、次のパケットの不正確な解凍を検出しますが、それは失敗の理由を知りません。以下のメカニズムはそう、修復を試行する場合、コンテキストは、以前のパケットが誤って更新された場合のデコンプレッサが判断することができます。
a. The decompressor maintains two decompressed sequence numbers: the last one (ref 0) and the one before that (ref -1).
A。最後の1（REF 0）と、その前に1（参考-1）：デコンプレッサは2つの解凍シーケンス番号を維持します。
b. When receiving a compressed header the SN (SN curr1) is decompressed using ref 0 as the reference. The other header fields are decompressed using this decompressed SN curr1. (This is part of the normal decompression procedure prior to any CRC test failures.)
B。圧縮されたヘッダを受信した場合SN（SNのCURR1）を基準としてREF 0を使用して解凍されます。他のヘッダフィールドは、この伸長SNのCURR1を使用して解凍されます。 （これは、任意のCRC検査が失敗する前に、通常の減圧手順の一部です。）
c. If the decompressed header generated in b. passes the CRC test, the references are shifted as follows:
C。解凍ヘッダがBで発生した場合。次のようにCRCテストに合格し、参照がシフトしています。
ref -1 = ref 0
ref 0 = SN curr1.
d. If the header generated in b. does not pass the CRC test, and the SN (SN curr2) generated when using ref -1 as the reference is different from SN curr1, an additional decompression attempt is performed based on SN curr2 as the decompressed SN.
D。ヘッダは、Bで発生した場合。 CRCテストに合格し、REFを使用する場合SN（SNのCURR2）が発生-1基準SNのCURR1異なるようにない、付加的な減圧試みは減圧SNとしてSNのCURR2に基づいて行われます。
e. If the decompressed header generated in b. does not pass the CRC test and SN curr2 is the same as SN curr1, an additional decompression attempt is not useful and is not attempted.
電子。解凍ヘッダがBで発生した場合。 CRCテストに合格し、SNのCURR2はSNのCURR1と同じではありません、追加減圧試みは有用ではないので、試されていません。
f. If the decompressed header generated in d. passes the CRC test, ref -1 is not changed while ref 0 is set to SN curr2.
F。解凍ヘッダはDで発生した場合。 REF 0 SNのCURR2に設定されているCRCテスト、refは-1変化しない渡します。
g. If the decompressed header generated in d. does not pass the CRC test, the decompressor acts according to rules a) through c) of section 5.3.2.2.3.
グラム。解凍ヘッダはDで発生した場合。 CRCテストに合格しない、解凍器は、セクション5.3.2.2.3のC）を介してルールA）に従って作用します。
The purpose of this algorithm is to repair the context. If the header generated in d. passes the CRC test, the references are updated according to f., but two more headers MUST also be successfully decompressed before the repair is deemed successful. Of the three successful headers, the first two SHOULD be discarded and only the third delivered to upper layers. If decompression of any of the three headers fails, the decompressor MUST discard that header and the previously generated headers, and act according to rules a) through c) of section 5.3.2.2.3.
このアルゴリズムの目的は、コンテキストを修復することです。ヘッダは、Dで発生した場合。 CRCテスト合格、参照が。Fに応じて更新されますが、修復が成功したとみなされる前に、2つの以上のヘッダも成功裏に解凍されなければなりません。 3つの成功したヘッダの最初の2つは破棄されるべきであり、唯一の第三は、上位層に配信します。 3つのヘッダーのいずれかの伸長に失敗した場合、デコンプレッサは、ヘッダと、以前に生成されたヘッダを捨て、セクション5.3.2.2.3のC）を介してA）の規則に従って行動しなければなりません。
To improve performance for the Unidirectional mode over a link that does have a feedback channel, the decompressor MAY send an acknowledgment when decompression succeeds. Setting the mode parameter in the ACK packet to U indicates that the compressor is to stay in Unidirectional mode. When receiving an ACK(U), the compressor should reduce the frequency of IR packets since the static information has been correctly received, but it is not required to stop sending IR packets. If IR packets continue to arrive, the decompressor MAY repeat the ACK(U), but it SHOULD NOT repeat the ACK(U) continuously.
解凍が成功した場合、フィードバックチャネルを持っているリンク上の単方向モードのパフォーマンスを向上させるために、デコンプレッサは、確認応答を送信することができます。 UへのACKパケットモードのパラメータを設定すると、コンプレッサーが単方向モードに滞在していることを示しています。 ACK（U）を受信した場合、圧縮機は、静的情報が正しく受信されたので、IRパケットの頻度を減らす必要があり、IRパケットの送信を停止する必要はありません。 IRパケットが到着し続けた場合、デコンプレッサは、ACK（U）を繰り返す事ができるが、それは継続的にACK（U）を繰り返してはいけない（SHOULD NOT）。
Below is the state machine for the compressor in Bidirectional Optimistic mode. The details of each state, state transitions, and compression logic are given subsequent to the figure.
以下は、双方向楽観モードでの圧縮機のためのステートマシンがあります。各状態、状態遷移、及び圧縮ロジックの詳細は、図に続いて与えられます。
Optimistic approach / ACK
+------>------>------>------>------>------>------>------>------+
| |
| Optimistic appr. / ACK Optimistic appr. /ACK ACK |
| +------>------>------+ +------>--- -->-----+ +->--+
| | | | | | |
| | v | v | v
+----------+ +----------+ +----------+
| IR State | | FO State | | SO State |
+----------+ +----------+ +----------+
^ ^ | ^ | |
| | STATIC-NACK | | NACK / Update | |
| +------<------<------+ +------<------<------+ |
| |
| STATIC-NACK |
+------<------<------<------<------<------<------<------<------+
The transition logic for compression states in Bidirectional Optimistic mode has much in common with the logic of the Unidirectional mode. The optimistic approach principle and transitions occasioned by the need for updates work in the same way as described in chapter 5.3.1. However, in Optimistic mode there are no timeouts. Instead, the Optimistic mode makes use of feedback from decompressor to compressor for transitions in the backward direction and for OPTIONAL improved forward transition.
双方向楽観モードでの圧縮状態の遷移ロジックは、単方向モードの論理に多くの共通点を持っています。アップデートの必要性によって引き起こさ楽観的なアプローチ原則と遷移は章5.3.1で説明したのと同じ方法で動作します。しかし、楽観モードでnoタイムアウトはありません。代わりに、楽観モードは逆方向の遷移およびOPTIONAL遷移を順方向改善するための圧縮機に解凍器からのフィードバックを利用します。
Negative acknowledgments (NACKs), also called context requests, obviate the periodic updates needed in Unidirectional mode. Upon reception of a NACK the compressor transits back to the FO state and sends updates (IR-DYN, UOR-2, or possibly IR) to the decompressor. NACKs carry the SN of the latest packet successfully decompressed, and this information MAY be used by the compressor to determine what fields need to be updated.
また、コンテキスト要求と呼ばれる否定応答（NACKのは）、単方向モードで必要な定期的な更新を未然に防ぐ。コンプレッサ遷移バックFO状態へとNACKを受信すると解凍器に更新（IR-DYN、UOR-2、又はおそらくIR）を送信します。 NACKが正常に解凍最新のパケットのSNを運び、そしてこの情報は、フィールドを更新する必要があるかを判断するための圧縮機で使用されるかもしれません。
Similarly, reception of a STATIC-NACK packet makes the compressor transit back to the IR state.
同様に、STATIC-NACKパケットの受信は、背面IR状態に圧縮遷移を行います。
In addition to NACKs, positive feedback (ACKs) MAY also be used for UOR-2 packets in the Bidirectional Optimistic mode. Upon reception of an ACK for an updating packet, the compressor knows that the decompressor has received the acknowledged packet and the transition to a higher compression state can be carried out immediately. This functionality is optional, so a compressor MUST NOT expect to get such ACKs initially.
NACKに加えて、正のフィードバック（ACKが）、双方向楽観モードでUOR-2パケットのために使用されるかもしれません。更新パケットに対するACKを受信すると、圧縮機は、減圧装置が即座に行うことができる確認応答パケットとより高い圧縮状態への遷移を受信したことを知ります。この機能はオプションであり、圧縮機は、最初に、このようなACKを得ると予想してはいけません。
The compressor MAY use the following algorithm to determine when to expect ACKs for UOR-2 packets. Let an update event be when a sequence of UOR-2 headers are sent to communicate an irregularity in the packet stream. When ACKs have been received for k_3 out of the last n_3 update events, the compressor will expect ACKs. A compressor which expects ACKs will repeat updates (possibly not in every packet) until an ACK is received.
UOR-2パケットに対してACKを期待するときに圧縮を判断するために、次のアルゴリズムを使用することができます。 UOR-2ヘッダーのシーケンスは、パケットストリームに凹凸を通信するために送信されたときに更新イベントがあるとします。 ACKが最後n_3更新イベントのうち、K_3のために受信されたとき、コンプレッサーはACKを期待しています。 ACKが受信されるまで（すべてのパケットにおそらくない）ACKが更新を繰り返すことを期待圧縮機。
The compression logic is the same for the Bidirectional Optimistic mode as for the Unidirectional mode (see section 5.3.1.2).
圧縮ロジックは、一方向モード（セクション5.3.1.2を参照）のような双方向楽観モードについても同様です。
The decompression states and the state transition logic are the same as for the Unidirectional case (see section 5.3.2). What differs is the decompression and feedback logic.
減圧状態及び状態遷移ロジックは、一方向の場合（セクション5.3.2を参照）と同じです。どのような違いは、解凍し、フィードバックロジックです。
In Bidirectional mode (or if there is some other way for the compressor to obtain the decompressor's clock resolution and the link's jitter), timer-based timestamp decompression may be used to improve compression efficiency when RTP Timestamp values are proportional to wall-clock time. The mechanisms used are those described in 4.5.4.
双方向モード（又は減圧装置のクロックの分解能とリンクのジッタを得るための圧縮機のためのいくつかの他の方法がある場合）において、タイマベースのタイムスタンプ減圧は、RTPタイムスタンプ値は、壁時計時間に比例する場合、圧縮効率を向上させるために使用されてもよいです。使用されるメカニズムは、4.5.4に記載されているものです。
The feedback logic defines what feedback to send due to different events when operating in the various states. As mentioned above, there are three principal kinds of feedback; ACK, NACK and STATIC-NACK. Further, the logic described below will refer to different kinds of packets that can be received by the decompressor; Initialization and Refresh (IR) packets, IR packets without static information (IR-DYN) and type 2 packets (UOR-2), or type 1 (UO-1) and type 0 packets (UO-0). A type 0 packet carries a packet header compressed according to a fixed pattern, while type 1, 2 and IR-DYN packets are used when this pattern is broken.
フィードバック論理は、様々な状態で動作しているときにフィードバックが原因異なるイベントに送信するかを定義します。上述したように、フィードバックの三つの主要な種類があります。 ACK、NACK及びSTATIC-NACK。さらに、以下に説明する論理は、解凍器によって受信することができるパケットの異なる種類を参照します。初期化および更新（IR）パケット、IRパケット静的情報がない（IR-DYN）とタイプ2のパケット（UOR-2）、またはタイプ1（UO-1）とタイプ0パケット（UO-0）。このパターンが壊れているときにタイプ1、2及びIR-DYNパケットが使用されるがタイプ0パケットは、固定されたパターンに従って圧縮されたパケットのヘッダを運びます。
Below, rules are defined stating which feedback to use when. If the optional feedback is used once, the decompressor is REQUIRED to continue to send optional feedback for the lifetime of the packet stream.
以下に、ルールをするときに使用するフィードバック述べ定義されています。オプションのフィードバックが一度使用されている場合、デコンプレッサは、パケットストリームの存続期間オプションのフィードバックを送信するために継続するために必要とされます。
State Actions
状態アクション
NC: - When an IR packet passes the CRC check, send an ACK(O). - When receiving a type 0, 1, 2 or IR-DYN packet, or an IR packet has failed the CRC check, send a STATIC-NACK(O), subject to the considerations at the beginning of section 5.7.6.
NC： - IRパケットがCRCチェックを通過すると、ACK（O）を送ります。 - タイプ0、1、2又はIR-DYNパケットを受信、またはIRパケットがCRCチェックに失敗した場合、セクション5.7.6の冒頭に考慮の対象STATIC-NACK（O）を送ります。
SC: - When an IR packet is correctly decompressed, send an ACK(O). - When a type 2 or an IR-DYN packet is correctly decompressed, optionally send an ACK(O). - When a type 0 or 1 packet is received, treat it as a mismatching CRC and use the logic of section 5.3.2.2.3 to decide if a NACK(O) should be sent.
SC： - IRパケットが正しく解凍された場合、ACKを送信する（O）。 - タイプ2またはIR-DYNパケットが正しく解凍されると、必要に応じてACKを送信する（O）。 - タイプ0または1のパケットを受信した場合、ミスマッチCRCとして扱い、NACK（O）が送信されるべきかどうかを決定するセクション5.3.2.2.3のロジックを使用。
- When decompression of a type 2 packet, an IR-DYN packet or an
IR packet has failed, use the logic of section 5.3.2.2.3 to
decide if a STATIC-NACK(O) should be sent.
FC: - When an IR packet is correctly decompressed, send an ACK(O). - When a type 2 or an IR-DYN packet is correctly decompressed, optionally send an ACK(O). - When a type 0 or 1 packet is correctly decompressed, no feedback is sent. - When any packet fails the CRC check, use the logic of 5.3.2.2.3 to decide if a NACK(O) should be sent.
FC： - IRパケットが正しく解凍された場合、ACKを送信する（O）。 - タイプ2またはIR-DYNパケットが正しく解凍されると、必要に応じてACKを送信する（O）。 - タイプ0または1パケットが正しく解凍されると、何のフィードバックは送信されません。 - すべてのパケットがCRCチェックに失敗した場合、NACK（O）が送られるべきであるかどうかを決定するための5.3.2.2.3のロジックを使用します。
Below is the state machine for the compressor in Bidirectional Reliable mode. The details of each state, state transitions, and compression logic are given subsequent to the figure.
以下は、双方向の信頼モードでの圧縮機のためのステートマシンがあります。各状態、状態遷移、及び圧縮ロジックの詳細は、図に続いて与えられます。
ACK
+------>------>------>------>------>------>------>------+
| |
| ACK ACK | ACK
| +------>------>------+ +------>------>------+ +->-+
| | | | | | |
| | v | v | v
+----------+ +----------+ +----------+
| IR State | | FO State | | SO State |
+----------+ +----------+ +----------+
^ ^ | ^ | |
| | STATIC-NACK | | NACK / Update | |
| +------<------<------+ +------<------<------+ |
| |
| STATIC-NACK |
+------<------<------<------<------<------<------<------<------+
The transition logic for compression states in Reliable mode is based on three principles: the secure reference principle, the need for updates, and negative acknowledgments.
安全な参照原則、アップデートの必要性、および否定応答：信頼性の高いモードでの圧縮状態の遷移ロジックは、3つの原則に基づいています。
The upwards transition is determined by the secure reference principle. The transition procedure is similar to the one described in section 5.3.1.1.1, with one important difference: the compressor
上方遷移は、セキュアリファレンス原理によって決定されます。移行手順は、一つの重要な違いで、セクション5.3.1.1.1に記載されたものと同様である。コンプレッサ
bases its confidence only on acknowledgments received from the decompressor. This ensures that the synchronization between the compression context and decompression context will never be lost due to packet losses.
唯一の解凍器から受信確認応答への信頼を基づか。これは、圧縮コンテキストと解凍コンテキスト間の同期が原因パケットロスのために失われないことを保証します。
Downward transitions are triggered by the need for updates or by negative acknowledgment (NACKs and STATIC_NACKs), as described in section 5.3.1.1.3 and 5.4.1.1.1, respectively. Note that NACKs should rarely occur in R-mode because of the secure reference used (see fourth paragraph of next section).
それぞれ、セクション5.3.1.1.3と5.4.1.1.1に記載されているように下方遷移は、更新の必要性によって、または否定応答（NACKのとSTATIC_NACKs）によってトリガされます。 NACKはほとんどため使用されるセキュアリファレンス（次のセクションの4番目の段落を参照）Rモードでは発生しないように注意してください。
The compressor starts in the IR state by sending IR packets. It transits to the FO state once it receives a valid ACK for an IR packet sent (an ACK can only be valid if it refers to an SN sent earlier). In the FO state, it sends the smallest packets that can communicate the changes, according to W-LSB or other encoding rules. Those packets could be of type R-1*, UOR-2, or even IR-DYN.
圧縮機は、IRパケットを送信することにより、IR状態で開始されます。それが送られたIRパケット（それが以前送っSNを参照する場合ACKのみ有効であることができます）のための有効なACKを受信すると、それはFO状態に遷移します。 FO状態では、W-LSB又は他の符号化規則に従って、変更を通信することができる最小のパケットを送信します。これらのパケットは、タイプR-1 *、UOR-2、あるいはIR-DYNのものであってもよいです。
The compressor will transit to the SO state after it has determined the presence of a string (see section 2), while also being confident that the decompressor has the string parameters. The confidence can be based on ACKs. 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. In the SO state, R-0* packets will be sent.
また、デコンプレッサは、文字列パラメータを持っていることを確信しながら、それは、（セクション2を参照）は、文字列の存在を決定した後にSO状態へ圧縮意志トランジット。自信がACKのに基づくことができます。勾配が以前に減圧装置によって確立されている場合、例えば、文字列パターンは非SNフィールドの形式= SN *スロープ+オフセットを有する典型的なケースでは、一方ACKは十分である（すなわち、唯一の新しいは、必要があるオフセット）同期させます。デコンプレッサは、新しいスロープとオフセットの新しいの両方を学ぶために2つのヘッダを必要とするのでそれ以外の場合は、2つのACKが必要とされています。 SO状態では、R-0 *パケットが送信されます。
Note that a direct transition from the IR state to the SO state is possible.
SO状態へのIR状態から直接遷移が可能であることに留意されたいです。
The secure reference principle is enforced in both compression and decompression logic. The principle means that only a packet carrying a 7- or 8-bit CRC can update the decompression context and be used as a reference for subsequent decompression. Consequently, only field values of update packets need to be added to the encoding sliding windows (see 4.5) maintained by the compressor.
安全な参照原理は、圧縮と解凍ロジックの両方に適用されます。原理は、7-または8-ビットCRCを搬送するパケットのみが解凍コンテキストを更新することができ、その後の解凍のための基準として使用されることを意味します。これにより、更新パケットの唯一のフィールド値は、圧縮機によって維持エンコーディングスライディングウィンドウ（4.5を参照）に追加する必要があります。
Reasons for the compressor to send update packets include:
更新パケットを送信するために、コンプレッサの理由は、次のとおりです。
1) The update may lead to a transition to higher compression efficiency (meaning either a higher compression state or smaller packets in the same state).
1）アップデートは、同じ状態で、より高い圧縮状態または小さいパケットのいずれかを意味するより高い圧縮効率（）への移行をもたらし得ます。
2) It is desirable to shrink sliding windows. Windows are only shrunk when an ACK is received.
2）スライディングウィンドウを縮小することが望ましいです。 ACKを受信したときに、Windowsにのみ収縮します。
The generation of a CRC is infrequent since it is only needed for an update packet.
それが唯一のアップデートパケットのために必要とされるため、CRCの生成はまれです。
One algorithm for sending update packets could be:
更新パケットを送信するための一つのアルゴリズムは以下のようになります。
* Let pRTT be the number of packets that are sent during one round-trip time. In the SO state, when (64 - pRTT) headers have been sent since the last acked reference, the compressor will send m1 consecutive R-0-CRC headers, then send (pRTT - m1) R-0 headers. After these headers have been sent, if the compressor has not received an ACK to at least one of the previously sent R0-CRC, it sends R-0-CRC headers continuously until it receives a corresponding ACK. m1 is an implementation parameter, which can be as large as pRTT.
* pRTTは1ラウンドトリップ時間中に送信されるパケットの数とします。 （64 - pRTT）SO状態で、ヘッダが最後のACKさ基準以来送信されてきた、圧縮機は、M1の連続するR-0-CRCヘッダーを送信し、次いで、（pRTT - M1）を送信R-0ヘッダー。これらのヘッダが送信された後、圧縮機は、以前に送信されたR0-CRCの少なくとも一つにACKを受信していない場合、それは、対応するACKを受信するまで継続R0-CRCヘッダーを送信します。 m1はpRTT限り大きくすることができる実装パラメータです。
* In the FO state, m2 UOR-2 headers are sent when there is a pattern change, after which the compressor sends (pRTT - m2) R-1-* headers. m2 is an implementation parameter, which can be as large as pRTT. At that time, if the compressor has not received enough ACKs to the previously sent UOR-2 packets in order to transit to SO state, it can repeat the cycle with the same m2, or repeat the cycle with a larger m2, or send UOR-2 headers continuously (m2 = pRTT). The operation stops when the compressor has received enough ACKs to make the transition.
R-1- *ヘッダ - 圧縮機が送信した後のパターンの変化、（M2 pRTT）がある場合* FO状態では、M2 UOR-2ヘッダが送信されます。 M2はpRTT限り大きくすることができる実装パラメータです。このとき、圧縮機が以前にSO状態、それは同じM2とのサイクルを繰り返し、以上M2とのサイクルを繰り返し、またはUORを送信することができるために通過するためにUOR-2パケットを送信するために十分なACKを受信していない場合連続-2ヘッダ（M2 = pRTT）。コンプレッサーは、移行を行うために十分なACKを受信したときの動作が停止します。
An algorithm for processing ACKs could be:
処理のACKのためのアルゴリズムは以下のようになります。
* Upon reception of an ACK, the compressor first derives the complete SN (see section 5.7.6.1). Then it searches the sliding window for an update packet that has the same SN. If found, that packet is the one being ACKed. Otherwise, the ACK is invalid and MUST be discarded.
* ACKを受信すると、圧縮機は、最初の完全なSN（セクション5.7.6.1を参照）を導出します。そして、それは同じSNを持つ更新パケットのためのスライディングウィンドウを検索します。見つかった場合、そのパケットは、ACKされているものです。それ以外の場合、ACKは無効であり、捨てなければなりません。
* It is possible, although unlikely, that residual errors on the reverse channel could cause a packet to mimic a valid ACK feedback. The compressor may use a local clock to reduce the probability of processing such a mistaken ACK. After finding the update packet as described above, the compressor can check the time elapsed since the packet was sent. If the time is longer than RTT_U, or shorter than RTT_L, the compressor may choose to discard the ACK. RTT_U and RTT_L correspond to an upper bound and lower bound of the RTT, respectively. (These bounds should be chosen appropriately to allow some variation of RTT.) Note that the only side effect of discarding a good ACK is slightly reduced compression efficiency.
*これは、逆方向チャネル上の残留誤差は、パケットが有効ACKフィードバックを模倣する可能性がありますことを、けれどもそう可能です。圧縮機は、このような誤ったACKを処理する可能性を低減するためにローカルクロックを使用してもよいです。上記のように更新パケットを見つけた後、圧縮機は、パケットが送信されてからの経過時間を確認することができます。時間がRTT_LよりRTT_Uよりも長い、または短い場合は、コンプレッサーはACKを破棄することもできます。 RTT_UとRTT_Lは、それぞれ、RTTの下限上限とに対応します。 （これらの境界は、RTTのいくつかの変化を可能にするように適切に選択されるべきである。）、良好なACKを廃棄するだけ副作用がわずかに圧縮効率が低下することに留意されたいです。
The decompression states and the state transition logic are the same as for the Unidirectional case (see section 5.3.2). What differs is the decompression and feedback logic.
減圧状態及び状態遷移ロジックは、一方向の場合（セクション5.3.2を参照）と同じです。どのような違いは、解凍し、フィードバックロジックです。
The rules for when decompression is allowed are the same as for U-mode. Although the acking scheme in R-mode guarantees that non-decompressible packets are never sent by the compressor, residual errors can cause delivery of unexpected packets for which decompression should not be attempted.
減圧が許可されている場合のルールは、Uモードの場合と同じです。 R-モードでの肯定応答（ACK）方式が非減圧可能なパケットが圧縮装置によって送信されることはありませんことを保証しますが、残留誤差は解凍を試みてはならないため、予期せぬパケットの配送を引き起こす可能性があります。
Decompression MUST follow the secure reference principle as described in 5.5.1.2.
5.5.1.2で説明したように解凍は、安全な参照原則に従わなければなりません。
CRC verification is infrequent since only update packets carry CRCs. A CRC mismatch can only occur due to 1) residual bit errors in the current header, and/or 2) a damaged context due to residual bit errors in previous headers or feedback. Although it is impossible to determine which is the actual cause, case 1 is more likely, as a previous header reconstructed according to a damaged packet is unlikely to pass the 7- or 8-bit CRC, and damaged packets are unlikely to result in feedback that damages the context. The decompressor SHOULD act according to section 5.3.2.2.3 when CRCs fail, except that no local repair is performed. Note that all the parameter numbers, k_1, n_1, k_2, and n_2, are applied to the update packets only (i.e., exclude R-0, R-1*).
唯一のアップデートパケットはCRCを運ぶため、CRC検証はまれです。 CRCの不一致のみによる前ヘッダーまたはフィードバックの残留ビット誤りに起因1）残留ビット現在のヘッダ内のエラー、及び/又は2）破損コンテキストに起こり得ます。実際の原因であるかを決定することは不可能であるが、損傷したパケットに応じて再構成前のヘッダは7-または8-ビットCRCを通過しにくくなり、破損したパケットは、フィードバックをもたらす可能性は低いように、ケース1は、より可能性が高いです被害状況という。 CRCが失敗したときにデコンプレッサは、ローカル修復が実行されないことを除いて、セクション5.3.2.2.3に従って行動しなければなりません。すべてのパラメータ番号、K_1、N_1、K_2、及びN_2は、（すなわち、R-0、R-1 *を除外する）のみ更新パケットに適用されることに留意されたいです。
The feedback logic for the Bidirectional Reliable mode is as follows:
次のように双方向信頼モードのフィードバックロジックは次のとおりです。
- When an updating packet (i.e., a packet carrying a 7- or 8-bit CRC) is correctly decompressed, send an ACK(R), subject to the sparse ACK mechanism described below.
- 更新パケット（すなわち、7-または8-ビットCRCを搬送するパケット）が正しく解凍されると、以下に説明疎ACKメカニズムに従うACK（R）を、送信します。
- When context damage is detected, send a NACK(R) if in Full Context state, or a STATIC-NACK(R) if in Static Context state.
- コンテキストの損傷が検出されると、完全なコンテキスト状態、又はSTATIC-NACK（R）静的コンテクスト状態における場合であればNACK（R）を送信します。
- In No Context state, send a STATIC-NACK(R) when receiving a non-IR packet, subject to the considerations at the beginning of section 5.7.6. The decompressor SHOULD NOT send STATIC-NACK(R) when receiving an IR packet that fails the CRC check, as the compressor will stay in IR state and thus continue sending IR packets until a valid ACK is received (see section 5.5.1.2).
- セクション5.7.6の冒頭に考慮の対象に非IRパケットを受信したときなしコンテキスト状態で、STATIC-NACK（R）を送信します。 CRCチェックに失敗したIRパケットを受信したときに圧縮機がIR状態にとどまり、従って、有効なACKが受信されるまで、IRパケットを送信し続けるように減圧装置は（セクション5.5.1.2を参照）、STATIC-NACK（R）を送るべきではありません。
- Feedback is never sent for packets not updating the context (i.e., packets that do not carry a CRC)
- フィードバックは、コンテキスト（CRCを運ばない、すなわち、パケット）を更新していないパケットのために送信されることはありません
A mechanism called "Sparse ACK" can be applied to reduce the feedback overhead caused by a large RTT. For a sequence of ACK-triggering events, a minimal set of ACKs MUST be sent:
「スパースACK」と呼ばれるメカニズムは、オーバーヘッド大きいRTTによって引き起こされるフィードバックを低減するために適用することができます。 ACK-トリガイベントのシーケンスのために、ACKの最小セットを送らなければなりません。
1) For a sequence of R-0-CRC packets, the first one MUST be ACKed.
1）R-0-CRCパケットのシーケンスについて、最初のものは、ACKされなければなりません。
2) For a sequence of UOR-2, IR, or IR-DYN packets, the first N of them MUST be ACKEd, where N is the number of ACKs needed to give the compressor confidence that the decompressor has acquired the new string parameters (see second paragraph of 5.5.1.2). In case the decompressor cannot determine the value of N, the default value 2 SHOULD be used. If the subsequently received packets continue the same change pattern of header fields, sparse ACK can be applied. Otherwise, each new pattern MUST be treated as a new sequence, i.e., the first N packets that exhibit a new pattern MUST be ACKed.
2）UOR-2、IRまたはIR-DYNパケットのシーケンスについては、それらの最初のNは、Nは、減圧装置が新しい文字列パラメータを取得した圧縮機の信頼を与えるために必要なACKの数（ここで、ACKされなければなりません）5.5.1.2の第二段落を参照してください。場合解凍器はNの値を決定することができない、デフォルト値2を使用すべきです。続いて、受信したパケットは、ヘッダフィールドの同じ変化パターンを続けると、スパースACKを適用することができます。そうでなければ、それぞれの新しいパターン、すなわち、新たなパターンを示す最初のNパケットがACKされなければならない、新しい配列として扱わなければなりません。
After sending these minimal ACKs, the decompressor MAY choose to ACK only k subsequent packets per RTT ("Sparse ACKs"), where k is an implementation parameter. To achieve robustness against loss of ACKs, k SHOULD be at least 1.
これらの最小のACKを送信した後、解凍装置はACKのみkが実装パラメータであるRTT（「スパースのACK」）ごと後続パケットをkに選ぶかもしれ。 ACKの損失に対するロバスト性を達成するために、kは少なくとも1であるべきです。
To avoid ambiguity at the compressor, the decompressor MUST use the feedback format whose SN field length is equal to or larger than the one in the compressed packet that triggered the feedback.
圧縮機に曖昧さを回避するために、デコンプレッサは、そのSNフィールドの長さに等しいか、またはフィードバックをトリガ圧縮されたパケット内の1よりも大きいフィードバック形式を使用しなければなりません。
Context damage is detected according to the principles in 5.3.2.2.3.
コンテキストの損傷が5.3.2.2.3における原理に従って検出されます。
When the decompressor is capable of timer-based compression of the RTP Timestamp (e.g., it has access to a clock with sufficient resolution, and the jitter introduced internally in the receiving node is sufficiently small) it SHOULD signal that it is ready to do timer-based compression of the RTP Timestamp. The compressor will then make a decision based on its knowledge of the channel and the observed properties of the packet stream.
デコンプレッサがRTPタイムスタンプのタイマベースの圧縮が可能である場合、タイマーを行う準備ができていることを知らせるべきである（例えば、十分な分解能を有するクロックにアクセスすることが、受信ノードの内部に導入ジッタが十分に小さいです） RTPタイムスタンプのベースの圧縮。コンプレッサーは、そのチャネルの知識とパケットストリームの観察された特性に基づいた意思決定を行います。
The decision to move from one compression mode to another is taken by the decompressor and the possible mode transitions are shown in the figure below. Subsequent chapters describe how the transitions are performed together with exceptions for the compression and decompression functionality during transitions.
もう1つの圧縮モードから移動するという決定は、減圧装置によって取られ、可能なモード遷移は、以下の図に示されています。以降の章では、遷移は遷移中に圧縮と解凍機能の例外と一緒に実行されている方法について説明します。
+-------------------------+
| Unidirectional (U) mode |
+-------------------------+
/ ^ \ ^
/ / Feedback(U) \ \ Feedback(U)
/ / \ \
/ / \ \
Feedback(O) / / Feedback(R) \ \
v / v \
+---------------------+ Feedback(R) +-------------------+
| Optimistic (O) mode | ----------------> | Reliable (R) mode |
| | <---------------- | |
+---------------------+ Feedback(O) +-------------------+
The following sections assume that, for each context, the compressor and decompressor maintain a variable whose value is the current compression mode for that context. The value of the variable controls, for the context in question, which packet types to use, which actions to be taken, etc.
以下のセクションでは、各コンテキスト、コンプレッサーと減圧のためにその値がそのコンテキストの現在の圧縮モードで変数を維持する、と仮定する。実行するアクションのパケットタイプは、使用する問題の文脈、、、などのための変数のコントロールの値は、
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. A mode transition MUST NOT be initiated by feedback which is not protected by a CRC.
残留エラーに対する安全装置として、モード遷移中に送信されたすべてのフィードバック、すなわち、CRCオプションを使用する必要があり、CRCによって保護されなければなりません。モード遷移はCRCによって保護されていないフィードバックによって開始してはいけません。
The subsequent subsections define exactly when to change the value of the MODE variable. When ROHC transits between compression modes, there are several cases where the behavior of compressor or decompressor must be restricted during the transition phase. These restrictions are defined by exception parameters that specify which restrictions to apply. The transition descriptions in subsequent chapters refer to these exception parameters and defines when they are set and to what values. All mode related parameters are listed below together with their possible values, with explanations and restrictions:
以降のサブセクションでは、ときMODE変数の値を変更するには、正確に定義します。 ROHCは、圧縮モードの間で遷移するときに、圧縮または解凍器の挙動は、遷移段階中に制限されなければならないいくつかの場合があります。これらの制限は適用するためにどの制限を指定した例外のパラメータによって定義されています。以降の章で遷移の説明は、これらの例外パラメータを参照し、それらが設定され、どのような値とされている場合に定義しています。すべてのモード関連のパラメータを説明し、制限付きで、可能な値と一緒に、以下のとおりです。
Parameters for the compressor side:
コンプレッサ側のパラメータ：
- C_MODE: Possible values for the C_MODE parameter are (U)NIDIRECTIONAL, (O)PTIMISTIC and (R)ELIABLE. C_MODE MUST be initialized to U.
- C_MODE：C_MODEのパラメータに指定できる値は、（単方向、（OPTIMISTICと（信頼できるC_MODEがUに初期化しなければなりませんされています。
- C_TRANS: Possible values for the C_TRANS parameter are (P)ENDING and (D)ONE. C_TRANS MUST be initialized to D. When C_TRANS is P, it is REQUIRED
- C_TRANS：C_TRANSパラメータの可能な値は、（P）終了し、（D）ONEです。 C_TRANSがPである、それが必要なときC_TRANSはD.に初期化されなければなりません
1) that the compressor only use packet formats common to all modes,
1）圧縮機は、すべてのモードに共通のパケット・フォーマットを使用すること、
2) that mode information is included in packets sent, at least periodically,
2）そのモード情報は、少なくとも定期的に、送信されたパケットに含まれます、
3) that the compressor not transit to the SO state,
3）そのSO状態に圧縮しないトランジット、
4) that new mode transition requests be ignored.
4）新しいモード遷移要求が無視されていること。
Parameters for the decompressor side:
解凍器側のパラメータ：
- D_MODE: Possible values for the D_MODE parameter are (U)NIDIRECTIONAL, (O)PTIMISTIC and (R)ELIABLE. D_MODE MUST be initialized to U.
- D_MODE：D_MODEのパラメータに指定できる値は、（単方向、（OPTIMISTICと（信頼できるDMODEがUに初期化しなければなりませんされています。
- D_TRANS: Possible values for the D_TRANS parameter are (I)NITIATED, (P)ENDING and (D)ONE. D_TRANS MUST be initialized to D. 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 received packet.
- D_TRANS：D_TRANSパラメータの可能な値は、（I）NITIATED、（P）終了し、（D）ONE。 D_TRANSはD_TRANSがDである場合にのみ、モード遷移がD_TRANSがIであるが、デコンプレッサは、それぞれについてCRCオプションを運ぶNACKまたはACKを送信開始することができるD.に初期化しなければならないパケットを受信しました。
When there is a feedback channel available, the decompressor may at any moment decide to initiate transition from Unidirectional to Bidirectional Optimistic mode. Any feedback packet carrying a CRC can be used with the mode parameter set to O. The decompressor can then directly start working in Optimistic mode. The compressor transits from Unidirectional to Optimistic mode as soon as it receives any feedback packet that has the mode parameter set to O and that passes the CRC check. The transition procedure is described below:
使用可能なフィードバックチャネルが存在する場合、デコンプレッサはいつでも双方向楽観モードへの一方向からの移行を開始することを決定することができます。 CRCを運ぶ任意のフィードバックパケットは、Oに減圧装置を設定モードパラメータと共に使用することができ、直接楽観モードで作業を開始することができます。すぐにそれがOに設定されたモードパラメータを持っており、それがCRCチェックをパスどんなフィードバックパケットを受信すると楽観モードへの単方向からの圧縮機遷移します。移行手順について説明します。
Compressor Decompressor
----------------------------------------------
| |
| ACK(O)/NACK(O) +-<-<-<-| D_MODE = O
| +-<-<-<-<-<-<-<-+ |
C_MODE = O |-<-<-<-+ |
| |
If the feedback packet is lost, the compressor will continue to work in Unidirectional mode, but as soon as any feedback packet reaches the compressor it will transit to Optimistic mode.
フィードバックパケットが失われた場合、コンプレッサーは、すぐに任意のフィードバックパケットは楽観モードにコンプレッサー、それは意志トランジットに達したとして、単方向モードで動作し続けますが、します。
Transition from Optimistic to Reliable mode is permitted only after at least one packet has been correctly decompressed, which means that at least the static part of the context is established. An ACK(R) or a NACK(R) feedback packet carrying a CRC is sent to initiate the mode transition. The compressor MUST NOT use packet types 0 or 1 during transition. The transition procedure is described below:
楽観から信頼性の高いモードへの移行は、コンテキストの少なくとも静的な部分が確立されることを意味し、少なくとも1つのパケットが正しく解凍された後にのみ許可されます。 ACK（R）又はCRCを運ぶNACK（R）フィードバックパケットは、モード遷移を開始するために送信されます。圧縮機は、移行中のパケットタイプ0または1を使用してはいけません。移行手順について説明します。
Compressor Decompressor
----------------------------------------------
| |
| ACK(R)/NACK(R) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = R | |
|->->->-+ IR/IR-DYN/UOR-2(SN,R) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. | D_MODE = R
| ACK(SN,R) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ R-0*, R-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
As long as the decompressor has not received an UOR-2, IR-DYN, or IR packet with the mode transition parameter set to R, it must stay in Optimistic mode. The compressor must not send packet types 1 or 0 while C_TRANS is P, i.e., not until it has received an ACK for a UOR-2, IR-DYN, or IR packet sent with the mode transition parameter set to R. When the decompressor receives packet types 0 or 1, after having ACKed an UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.
限り減圧装置がRに設定されたモード移行パラメータでUOR-2、IR-DYN、またはIRパケットを受信していないとして、それは楽観モードに滞在しなければなりません。 C_TRANS、すなわち、Pでありながら、減圧装置Rに設定されたモード移行パラメータで送信されたUOR-2、IR-DYN、またはIRパケットに対するACKを受信しないまで圧縮機は、パケットタイプ1または0を送信してはなりませんパケットタイプ0か1を受信し、UOR-2、IR-DYN、またはIRパケットをACKさた後、それはDにD_TRANSを設定します
The transition from Unidirectional to Reliable mode follows the same transition procedure as defined in section 5.6.3 above.
上記セクション5.6.3で定義されるように信頼性の高いモードへ一方向からの遷移は、同じ遷移手順に従います。
Either the ACK(O) or the NACK(O) feedback packet is used to initiate the transition from Reliable to Optimistic mode and the compressor MUST always run in the FO state during transition. The transition procedure is described below:
いずれかのACK（O）またはNACK（O）フィードバックパケットは楽観モードへの信頼性からの移行を開始するために使用され、圧縮機が常に移行中FO状態で実行する必要があります。移行手順について説明します。
Compressor Decompressor
----------------------------------------------
| |
| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = O | |
|->->->-+ IR/IR-DYN/UOR-2(SN,O) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_MODE = O
|->-.. |
| ACK(SN,O) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
As long as the decompressor has not received an UOR-2, IR-DYN, or IR packet with the mode transition parameter set to O, it must stay in Reliable mode. The compressor must not send packet types 0 or 1 while C_TRANS is P, i.e., not until it has received an ACK for an UOR-2, IR-DYN, or IR packet sent with the mode transition parameter set to O. When the decompressor receives packet types 0 or 1, after having ACKed the UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.
限り減圧装置がOに設定されたモード移行パラメータでUOR-2、IR-DYN、またはIRパケットを受信していないとして、それが信頼できるモードに滞在しなければなりません。 C_TRANS、すなわち、Pでありながら、デコンプレッサOに設定されたモード移行パラメータで送信されたUOR-2、IR-DYN、またはIRパケットに対するACKを受信しないまで圧縮機は、パケットタイプ0または1を送信してはなりませんパケットタイプ0か1を受信し、UOR-2、IR-DYN、またはIRパケットをACKさた後、それはDにD_TRANSを設定します
The decompressor can force a transition back to Unidirectional mode if it desires to do so. Regardless of which mode this transition starts from, a three-way handshake MUST be carried out to ensure correct transition on the compressor side. The transition procedure is described below:
それはそうすることを望む場合にデコンプレッサは、バック単方向モードへの移行を強制することができます。かかわらず、この遷移から開始するモード、スリーウェイハンドシェイクは、コンプレッサ側の正しい遷移を確実にするために行わなければなりません。移行手順について説明します。
Compressor Decompressor
----------------------------------------------
| |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = U | |
|->->->-+ IR/IR-DYN/UOR-2(SN,U) |
| +->->->->->->->-+ |
|->-.. +->->->-|
|->-.. |
| ACK(SN,U) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D, D_MODE= U
After ACKing the first UOR-2(U), IR-DYN(U), or IR(U), the decompressor MUST continue to send feedback with the Mode parameter set to U until it receives packet types 0 or 1.
それはパケットタイプ0か1を受信するまで、第1 UOR-2（U）の肯定応答（ACK）後、IR-DYN（U）、又はIR（U）、減圧装置はUに設定されたモードパラメータを用いてフィードバックを送信し続けなければなりません。
The following notation is used in this section:
以下の表記は、このセクションで使用されています。
bits(X) = the number of bits for field X present in the compressed header (including extension).
ビット（X）は、（拡張子を含む）、圧縮ヘッダ内に存在するフィールドXのビット数を=。
field(X) = the value of field X in the compressed header.
フィールド（X）は、圧縮されたヘッダ内のフィールドXの値を=。
context(X) = the value of field X as established in the context.
コンテキスト（X）は、文脈で確立さフィールドXの値を=。
value(X) = field(X) if X is present in the compressed header; = context(X) otherwise.
値（X）=フィールド（X）Xは、圧縮されたヘッダーに存在する場合。 =コンテキスト（X）さもなければ。
hdr(X) = the value of field X in the uncompressed or decompressed header.
HDR（X）は、非圧縮または解凍ヘッダのフィールドXの値を=。
Updating properties: Lists the fields in the context that are directly updated by processing the compressed header. Note that there may be dependent fields that are implicitly also updated (e.g., an update to context(SN) often updates context(TS) as well). See also section 5.2.7.
プロパティの更新：直接圧縮ヘッダを処理することによって更新されたコンテキスト内のフィールドを一覧表示します。 （例えば、コンテキスト（SN）へのアップデートは、多くの場合だけでなくコンテクスト（TS）を更新）暗黙的にも更新されている依存フィールドがあるかもしれないことに注意してください。また、セクション5.2.7を参照してください。
The following fields occur in several headers and extensions:
次のフィールドは、いくつかのヘッダーと拡張で発生します。
SN: The compressed RTP Sequence Number.
SN：圧縮されたRTPシーケンス番号。
Compressed with W-LSB. The interpretation intervals, see section
4.5.1, are defined as follows:
p = 1 if bits(SN) <= 4
p = 2^(bits(SN)-5) - 1 if bits(SN) > 4
IP-ID: A compressed IP-ID field.
IP-ID：圧縮されたIP-IDフィールド。
IP-ID fields in compressed base headers carry the compressed IP-ID of the innermost IPv4 header whose corresponding RND flag is not 1. The rules below assume that the IP-ID is for the innermost IP header. If it is for an outer IP header, the RND2 and NBO2 flags are used instead of RND and NBO.
圧縮されたベースヘッダーのIP-IDフィールドは、対応するRNDフラグ最も内側のIPv4ヘッダの圧縮されたIP-IDが1ではない運ぶ以下の規則がIP-IDは、最も内側のIPヘッダのためのものであると仮定する。それは外側のIPヘッダのためのものである場合、RND2とNBO2フラグが代わりRNDとNBOのに使用されます。
If value(RND) = 0, hdr(IP-ID) is compressed using Offset IP-ID encoding (see section 4.5.5) using p = 0 and default-slope(IP-ID offset) = 0.
値（RND）= 0、HDR（IP-ID）がオフセットIP-IDの符号化を使用して圧縮されている場合は使用して、P = 0、デフォルトスロープ（セクション4.5.5を参照）（IP-IDは、オフセット）= 0。
If value(RND) = 1, IP-ID is the uncompressed hdr(IP-ID). IP-ID is then passed as additional octets at the end of the compressed header, after any extensions.
値（RND）を1 =場合、IP-IDは、非圧縮HDR（IP-ID）です。 IP-IDは、次に任意の拡張後に、圧縮されたヘッダの終わりに追加のオクテットとして渡されます。
If value(NBO) = 0, the octets of hdr(IP-ID) are swapped before compression and after decompression. The value of NBO is ignored when value(RND) = 1.
値（NBO）は= 0場合、HDR（IP-ID）のオクテットは圧縮前及び圧縮解除後に交換されます。値（RND）は1 =ときNBOの値は無視されます。
TS: The compressed RTP Timestamp value.
TS：圧縮されたRTPタイムスタンプ値。
If value(TIME_STRIDE) > 0, timer-based compression of the RTP Timestamp is used (see section 4.5.4).
値（TIME_STRIDE）> 0、RTPタイムスタンプのタイマベースの圧縮が使用される場合（セクション4.5.4を参照）。
If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before compression (see section 4.5.3), and default-slope(TS) = 1.
値（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).
値（TSC）は= 0場合、タイムスタンプ値をそのまま圧縮され、デフォルトスロープ（TS）=値（TS_STRIDE）。
The interpretation intervals, see section 4.5.1, are defined as follows:
次のように解釈間隔、セクション4.5.1を参照してくださいには、定義されています。
p = 2^(bits(TS)-2) - 1
P = 2 ^（ビット（TS）-2） - 1
CRC: The CRC over the original, uncompressed, header.
CRC：オリジナルの、圧縮されていない、ヘッダ上CRC。
For 3-bit CRCs, the polynomial of section 5.9.2 is used. For 7-bit CRCs, the polynomial of section 5.9.2 is used. For 8-bit CRCs, the polynomial of section 5.9.1 is used.
3ビットのCRCのために、セクション5.9.2の多項式が使用されます。 7ビットのCRCのために、セクション5.9.2の多項式が使用されます。 8ビットのCRCのために、セクション5.9.1の多項式が使用されます。
M: RTP Marker bit.
M：RTPマーカービット。
Context(M) is initially zero and is never updated. value(M) = 1 only when field(M) = 1.
コンテキスト（M）は、最初はゼロになり、更新されることはありません。値（M）= 1のときにのみフィールド（M）= 1。
The general format for a compressed RTP header is as follows:
次のように圧縮されたRTPヘッダの一般的な形式は次のとおりです。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and CID 1-15
+---+---+---+---+---+---+---+---+
| first octet of base header | (with type indication)
+---+---+---+---+---+---+---+---+
: :
/ 0, 1, or 2 octets of CID / 1-2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
/ remainder of base header / variable number of bits
+---+---+---+---+---+---+---+---+
: :
/ Extension (see 5.7.5) / extension, if X = 1 in base header
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of outer IPv4 header + 2 octets, if value(RND2) = 1
: :
--- --- --- --- --- --- --- ---
/ AH data for outer list / variable (see 5.8.4.2)
--- --- --- --- --- --- --- ---
: :
+ GRE checksum (see 5.8.4.4) + 2 octets, if GRE flag C = 1
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of inner IPv4 header + 2 octets, if value(RND) = 1
: :
--- --- --- --- --- --- --- ---
/ AH data for inner list / variable (see 5.8.4.2)
--- --- --- --- --- --- --- ---
: :
+ GRE checksum (see 5.8.4.4) + 2 octets, if GRE flag C = 1
: :
--- --- --- --- --- --- --- ---
: :
+ UDP Checksum + 2 octets,
: : if context(UDP Checksum) != 0
--- --- --- --- --- --- --- ---
Note that the order of the fields following the optional extension is the same as the order between the fields in an uncompressed header.
オプションの拡張次のフィールドの順序は、解凍されたヘッダー内のフィールドの順序と同じであることに留意されたいです。
In subsequent sections, the position of the large CID in the diagrams is indicated using this notation:
以降のセクションでは、図の大CIDの位置は、この表記法を使用して示されています。
+===+===+===+===+===+===+===+===+
＋＝＝＝＋＝＝＝＋＝＝＝＋＝＝＝＋＝＝＝＋＝＝＝＋＝＝＝＋＝＝＝＋
Whether the UDP Checksum field is present or not is controlled by the value of the UDP Checksum in the context. If nonzero, the UDP Checksum is enabled and sent along with each packet. If zero, the UDP Checksum is disabled and not sent. Should hdr(UDP Checksum) be nonzero when context(UDP Checksum) is zero, the header cannot be compressed. It must be sent uncompressed or the context reinitialized using an IR packet. Context(UDP Checksum) is updated only by IR or IR-DYN headers, never by UDP checksums sent in headers of type 2, 1, or 0.
UDPチェックサムフィールドが存在するか否かは、コンテキスト内のUDPチェックサムの値によって制御されます。ゼロ以外の場合は、UDPチェックサムが有効になっていると、各パケットと共に送信します。ゼロの場合は、UDPチェックサムを無効にして送信されません。コンテキスト（UDPチェックサム）がゼロのときゼロでないこと（UDPチェックサム）をHDRべき、ヘッダを圧縮することができません。これは、圧縮されていない送信されなければならないか、文脈がIRパケットを使用して再初期化。コンテキスト（UDPチェックサム）は決してタイプ2,1、またはヘッダで送信UDPチェックサムによって、IRまたはIR-DYNヘッダーによってのみ更新される0。
When an IPv4 header is present in the static context, for which the corresponding RND flag has not been established to be 1, the packet types R-1 and UO-1 MUST NOT be used.
IPv4ヘッダは、対応するRNDフラグが1であることが確立されていないため、静的なコンテキストで存在する場合、パケットタイプR-1及びUO-1を使用してはいけません。
When no IPv4 header is present in the static context, or the RND flags for all IPv4 headers in the context have been established to be 1, the packet types R-1-ID, R-1-TS, UO-1-ID, and UO-1-TS MUST NOT be used.
何IPv4ヘッダは、静的コンテキスト内に存在しない場合、またはコンテキスト内のすべてのIPv4ヘッダーのRNDフラグが1であることが確立されている、パケットタイプR-1-ID、R-1-TS、UO-1-ID、そしてUO-1-TSを使用してはいけません。
While in the transient state in which an RND flag is being established, the packet types R-1-ID, R-1-TS, UO-1-ID, and UO-1-TS MUST NOT be used. This implies that the RND flag(s) of the Extension 3 may have to be inspected before the format of a base header carrying an Extension 3 can be determined.
RNDフラグは、パケットタイプR-1-ID、R-1-TSを、UO-1-IDが確立され、及びUO-1-TSを使用してはいけませんする過渡状態にある間。これは、エクステンション3を担持するベースヘッダのフォーマットを決定することができる前に、エクステンション3のRNDフラグ（S）が検査されなければならないことを意味します。
Packet type 0 is indicated by the first bit being 0:
パケットタイプ0は、最初のビットが0であることによって示されています。
R-0
R-0
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 0 | SN |
+===+===+===+===+===+===+===+===+
Updating properties: R-0 packets do not update any part of the context.
プロパティの更新：R-0パケットは文脈のどの部分を更新しません。
R-0-CRC
Ｒー０ーＣＲＣ
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 1 | SN |
+===+===+===+===+===+===+===+===+
|SN | CRC |
+---+---+---+---+---+---+---+---+
Note: The SN field straddles the CID field.
注意：SNフィールドは、CIDフィールドをまたぎます。
Updating properties: R-0-CRC packets update context(RTP Sequence Number).
更新特性：R-0-CRCパケット更新コンテキスト（RTPシーケンス番号）。
UO-0
ウオー０
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | SN | CRC |
+===+===+===+===+===+===+===+===+
Updating properties: UO-0 packets update the current value of context(RTP Sequence Number).
プロパティの更新：UO-0パケットは文脈（RTPシーケンス番号）の現在の値を更新します。
Packet type 1 is indicated by the first bits being 10:
パケットタイプ1は、10である第1ビットによって示されます。
R-1
R-1
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 | SN |
+===+===+===+===+===+===+===+===+
| M | X | TS |
+---+---+---+---+---+---+---+---+
Note: R-1 cannot be used if the context contains at least one IPv4 header with value(RND) = 0. This disambiguates it from R-1-ID and R-1-TS.
注：コンテキストこれはR-1-ID及びR-1-TSからそれを曖昧性を除去少なくとも1つのIPv4値（RND）とヘッダ= 0が含まれている場合、R-1を使用することができません。
R-1-ID
R-1-ID
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 | SN |
+===+===+===+===+===+===+===+===+
| M | X |T=0| IP-ID |
+---+---+---+---+---+---+---+---+
Note: R-1-ID cannot be used if there is no IPv4 header in the context or if value(RND) and value(RND2) are both 1.
注：IPv4ヘッダの値コンテキストで場合や存在しない場合、R-1-IDを使用することができない（RND）と値（RND2）が両方とも1です。
R-1-TS
R-1-TS
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 | SN |
+===+===+===+===+===+===+===+===+
| M | X |T=1| TS |
+---+---+---+---+---+---+---+---+
Note: R-1-TS cannot be used if there is no IPv4 header in the context or if value(RND) and value(RND2) are both 1.
注：R-1-TSないIPv4ヘッダ値コンテキストで場合や存在しない場合に使用できません（RND）と値（RND2）が両方とも1です。
X: X = 0 indicates that no extension is present; X = 1 indicates that an extension is present.
X：X = 0拡張子がないことを示しています。 X = 1は、拡張が存在することを示します。
T: T = 0 indicates format R-1-ID; T = 1 indicates format R-1-TS.
Tは、T = 0の形式はR-1-IDを示します。 T = 1の形式R-1-TSを示しています。
Updating properties: R-1* headers do not update any part of the context.
更新特性：R-1 *ヘッダーコンテキストのどの部分を更新しません。
UO-1
ウオー１
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 | TS |
+===+===+===+===+===+===+===+===+
| M | SN | CRC |
+---+---+---+---+---+---+---+---+
Note: UO-1 cannot be used if the context contains at least one IPv4 header with value(RND) = 0. This disambiguates it from UO-1-ID and UO-1-TS.
注：コンテキストこれはUO-1-ID及びUO-1-TSからそれを曖昧性を除去少なくとも1つのIPv4値（RND）とヘッダ= 0が含まれている場合、UO-1を使用することができません。
UO-1-ID
UO-1-ID
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 |T=0| IP-ID |
+===+===+===+===+===+===+===+===+
| X | SN | CRC |
+---+---+---+---+---+---+---+---+
Note: UO-1-ID cannot be used if there is no IPv4 header in the context or if value(RND) and value(RND2) are both 1.
注：IPv4の値（RND）文脈における場合、またはヘッダと値（RND2）の両方が1であるがない場合UO-1-IDを使用することができません。
UO-1-TS
UO-1-TS
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 |T=1| TS |
+===+===+===+===+===+===+===+===+
| M | SN | CRC |
+---+---+---+---+---+---+---+---+
Note: UO-1-TS cannot be used if there is no IPv4 header in the context or if value(RND) and value(RND2) are both 1.
注：IPv4ヘッダの値コンテキストで場合や存在しない場合UO-1-TSを使用することができない（RND）と値（RND2）が両方とも1です。
X: X = 0 indicates that no extension is present; X = 1 indicates that an extension is present.
X：X = 0拡張子がないことを示しています。 X = 1は、拡張が存在することを示します。
T: T = 0 indicates format UO-1-ID; T = 1 indicates format UO-1-TS.
Tは、T = 0の形式UO-1-IDを示します。 T = 1の形式UO-1-TSを示しています。
Updating properties: UO-1* packets update context(RTP Sequence Number). UO-1 and UO-1-TS packets update context(RTP Timestamp). UO-1-ID packets update context(IP-ID). Values provided in extensions, except those in other SN, TS, or IP-ID fields, do not update the context.
プロパティの更新：UO-1 *パケット更新コンテキスト（RTPシーケンス番号）。 UO-1及びUO-1-TSパケット更新コンテキスト（RTPタイムスタンプ）。 UO-1-IDは、更新コンテキスト（IP-ID）をパケット。他のSN、TS、またはIP-IDフィールドのものを除き、拡張で提供される値は、コンテキストを更新しません。
Packet type 2 is indicated by the first bits being 110:
パケットタイプ2が110である第1ビットによって示されます。
UOR-2
フルオロ-2-
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 | TS |
+===+===+===+===+===+===+===+===+
|TS | M | SN |
+---+---+---+---+---+---+---+---+
| X | CRC |
+---+---+---+---+---+---+---+---+
Note: UOR-2 cannot be used if the context contains at least one IPv4 header with value(RND) = 0. This disambiguates it from UOR-2-ID and UOR-2-TS.
注：コンテキストこれはUOR-2-ID及びUOR-2-TSからそれを曖昧性を除去少なくとも1つのIPv4値（RND）とヘッダ= 0が含まれている場合、UOR-2を使用することができません。
Note: The TS field straddles the CID field.
注意：TSフィールドは、CIDフィールドをまたぎます。
UOR-2-ID
UOR-2-ID
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 | IP-ID |
+===+===+===+===+===+===+===+===+
|T=0| M | SN |
+---+---+---+---+---+---+---+---+
| X | CRC |
+---+---+---+---+---+---+---+---+
Note: UOR-2-ID cannot be used if there is no IPv4 header in the context or if value(RND) and value(RND2) are both 1.
注：IPv4の値（RND）文脈における場合、またはヘッダと値（RND2）の両方が1であるがない場合UOR-2-IDを使用することができません。
UOR-2-TS
UOR-2-TS
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 | TS |
+===+===+===+===+===+===+===+===+
|T=1| M | SN |
+---+---+---+---+---+---+---+---+
| X | CRC |
+---+---+---+---+---+---+---+---+
Note: UOR-2-TS cannot be used if there is no IPv4 header in the context or if value(RND) and value(RND2) are both 1.
注：IPv4ヘッダの値コンテキストで場合や存在しない場合にUOR-2-TSを使用することができない（RND）と値（RND2）が両方とも1です。
X: X = 0 indicates that no extension is present; X = 1 indicates that an extension is present.
X：X = 0拡張子がないことを示しています。 X = 1は、拡張が存在することを示します。
T: T = 0 indicates format UOR-2-ID; T = 1 indicates format UOR-2-TS.
Tは、T = 0の形式UOR-2-IDを示します。 T = 1の形式UOR-2-TSを示しています。
Updating properties: All values provided in UOR-2* packets update the context, unless explicitly stated otherwise.
プロパティの更新：特に明記しない限り、UOR-2 *パケットで提供されるすべての値は、コンテキストを更新します。
(Note: the term extension as used for additional information contained in the ROHC headers does not bear any relationship to the term extension header used in IP.)
（注：期間延長をIPで使用される用語の拡張ヘッダに任意の関係を結ばないROHCヘッダに含まれる付加情報のために使用されます。）
Fields in extensions are concatenated with the corresponding field in the base compressed header, if there is one. Bits in an extension are less significant than bits in the base compressed header (see section 4.5.7).
存在する場合の拡張内のフィールドは、ベース圧縮ヘッダの対応するフィールドと連結されています。拡張中のビットは、ベース圧縮ヘッダのビットよりも下位である（セクション4.5.7を参照）。
The TS field is scaled in all extensions, as it is in the base header, except optionally when using Extension 3 where the Tsc flag can indicate that the TS field is not scaled. Value(TS_STRIDE) is used as the scale factor when scaling the TS field.
それは基本ヘッダにあるようにTSフィールドは、任意のTSCフラグはTSフィールドはスケーリングされていないことを示すことができるエクステンション3を使用する場合を除いて、すべての拡張機能にスケーリングされます。 TSフィールドをスケーリングするときに値（TS_STRIDE）がスケールファクタとして使用されます。
In the following three extensions, the interpretation of the fields depends on whether there is a T-bit in the base compressed header, and if so, on the value of that field. When there is no T-bit, +T and -T both mean TS. This is the case when there are no IPv4 headers in the static context, and when all IPv4 headers in the static context have their corresponding RND flag set (i.e., RND = 1).
次の三つの拡張では、フィールドの解釈は、ベース圧縮ヘッダにおけるTビットがあるかどうかに依存し、もしそうであれば、そのフィールドの値に。何のTビットが存在しない場合は、+ Tおよび-Tの両方がTSを意味します。これは、静的なコンテキストにはIPv4のヘッダが存在しない場合である、静的コンテキスト内のすべてのIPv4ヘッダーがそれらの対応するRNDフラグが設定されている場合（すなわち、RND = 1）。
If there is a T-bit,
Tビットがある場合は、
T = 1 indicates that +T is TS, and -T is IP-ID;
T = 1 + TはTSであり、かつ-Tは、IP-IDであることを示しています。
T = 0 indicates that +T is IP-ID, and -T is TS.
T = 0 + TのIP-IDであることを示し、かつ-TはTSです。
Extension 0:
拡張0：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 0 | SN | +T |
+---+---+---+---+---+---+---+---+
Extension 1:
拡張1：
+---+---+---+---+---+---+---+---+
| 0 1 | SN | +T |
+---+---+---+---+---+---+---+---+
| -T |
+---+---+---+---+---+---+---+---+
Extension 2:
拡張2：
+---+---+---+---+---+---+---+---+
| 1 0 | SN | +T |
+---+---+---+---+---+---+---+---+
| +T |
+---+---+---+---+---+---+---+---+
| -T |
+---+---+---+---+---+---+---+---+
Extension 3 is a more elaborate extension which can give values for fields other than SN, TS, and IP-ID. Three optional flag octets indicate changes to IP header(s) and RTP header, respectively.
拡張3はSN、TS、およびIP-ID以外のフィールドに値を与えることができ、より複雑な拡張機能です。 3つのオプションフラグオクテットは、それぞれ、IPヘッダ（S）及びRTPヘッダへの変更を示します。
Extension 3:
拡張3：
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 1 | S |R-TS | Tsc | I | ip | rtp | (FLAGS)
+-----+-----+-----+-----+-----+-----+-----+-----+
| Inner IP header flags | ip2 | if ip = 1
..... ..... ..... ..... ..... ..... ..... .....
| Outer IP header flags | if ip2 = 1
..... ..... ..... ..... ..... ..... ..... .....
| SN | if S = 1
..... ..... ..... ..... ..... ..... ..... .....
/ TS (encoded as in section 4.5.6) / 1-4 octets,
..... ..... ..... ..... ..... ..... ..... ..... if R-TS = 1
| |
/ Inner IP header fields / variable,
| | if ip = 1
..... ..... ..... ..... ..... ..... ..... .....
| IP-ID | 2 octets, if I = 1
..... ..... ..... ..... ..... ..... ..... .....
| |
/ Outer IP header fields / variable,
| | if ip2 = 1
..... ..... ..... ..... ..... ..... ..... .....
| |
/ RTP header flags and fields / variable,
| | if rtp = 1
..... ..... ..... ..... ..... ..... ..... .....
S, R-TS, I, ip, rtp, ip2: Indicate presence of fields as shown to the right of each field above.
S、R-TSは、I、IP、RTP、IP2は、上記各フィールドの右側に示すように、フィールドの存在を示します。
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は、TSがスケーリングされていないことを示しています。 TSC = 1は、TS値（TS_STRIDE）を使用して、セクション4.5.3に従ってスケーリングされることを示しています。コンテキスト（TSC）は、スケーリングが望まれていない場合、圧縮機はTS_STRIDE = 1を確立する常に1です。
SN: See the beginning of section 5.7.
SN：セクション5.7の始まりを参照してください。
TS: Variable number of bits of TS, encoded according to section 4.5.6. See the beginning of section 5.7.
TS：TSの可変ビット数、セクション4.5.6に従って符号化されました。セクション5.7の始まりを参照してください。
IP-ID: See the beginning of section 5.7.
IP-ID：セクション5.7の始まりを参照してください。
Inner IP header flags
内側のIPヘッダーフラグ
These correspond to the inner IP header if there are two, and the single IP header otherwise.
これらは、二つがある場合、内側IPヘッダに対応し、そうでなければ単一のIPヘッダ。
0 1 2 3 4 5 6 7 ..... ..... ..... ..... ..... ..... ..... ..... | TOS | TTL | DF | PR | IPX | NBO | RND | ip2 | if ip = 1 ..... ..... ..... ..... ..... ..... ..... .....
0 1 2 3 4 5 6 7 ..... ..... ..... ..... ..... ..... ..... ..... | TOS | TTL | DF | PR | IPX | NBO | RND | IP2 |場合は、IP = 1 ..... ..... ..... ..... ..... ..... ..... .....
TOS, TTL, PR, IPX: Indicates presence of fields as shown to the right of the field in question below.
TOS、TTL、PR、IPXは：以下の質問に、フィールドの右側に示すように、フィールドの存在を示します。
DF: Don't Fragment bit of IP header.
DFは：IPヘッダのビットを断片化しないでください。
NBO: Indicates whether the octets of hdr(IP identifier) of this IP header are swapped before compression and after decompression.
NBO：このIPヘッダのHDRのオクテット（IP識別子）は圧縮前及び圧縮解除後に交換されるかどうかを示します。
NBO = 1 indicates that the octets need not be swapped. NBO = 0 indicates that the octets are to be swapped. See section 4.5.5.
NBO = 1オクテットが交換する必要がないことを示しています。 NBO = 0は、オクテットが交換されることを示します。セクション4.5.5を参照してください。
RND: Indicates whether hdr(IP identifier) is not to be compressed but instead sent as-is in compressed headers.
RND：HDR（IP識別子）圧縮代わりとして、ある圧縮ヘッダで送信されるべきではないかどうかを示します。
IP2: Indicates presence of Outer IP header fields. Unless the static context contains two IP headers, IP2 is always zero.
IP2は：外側のIPヘッダフィールドの存在を示します。静的コンテキストは、2つのIPヘッダーが含まれていない限り、IP2は常にゼロです。
Inner IP header fields
内側のIPヘッダフィールド
..... ..... ..... ..... ..... ..... ..... ..... | Type of Service/Traffic Class | if TOS = 1 ..... ..... ..... ..... ..... ..... ..... ..... | Time to Live/Hop Limit | if TTL = 1 ..... ..... ..... ..... ..... ..... ..... ..... | Protocol/Next Header | if PR = 1 ..... ..... ..... ..... ..... ..... ..... ..... / IP extension headers / variable, ..... ..... ..... ..... ..... ..... ..... ..... if IPX = 1
..... ..... ..... ..... ..... ..... ..... ..... |サービス/トラフィッククラスの種類| TOSの場合= 1 ..... ..... ..... ..... ..... ..... ..... ..... | /ホップ制限を生存時間| TTLの場合= 1 ..... ..... ..... ..... ..... ..... ..... ..... |プロトコル/次のヘッダー| PRの場合= 1 ..... ..... ..... ..... ..... ..... ..... ..... / IP拡張ヘッダ/変数、..... ..... ..... ..... ..... ..... ..... ..... IPX = 1の場合
Type of Service/Traffic Class: That field in the uncompressed IP header (absolute value).
サービス/トラフィッククラスの種類：非圧縮IPヘッダ（絶対値）でそのフィールド。
Time to Live/Hop Limit: That field in the uncompressed IP header.
生存時間/ホップリミット：非圧縮IPヘッダ内のそのフィールド。
Protocol/Next Header: That field in the uncompressed IP header.
プロトコル/次のヘッダー：非圧縮IPヘッダ内のそのフィールド。
IP extension header(s): According to section 5.8.5.
IP拡張ヘッダ（S）：セクション5.8.5によります。
Outer IP header flags
外側のIPヘッダーフラグ
The fields in this part of the Extension 3 header refer to the outermost IP header:
拡張ヘッダ3のこの部分のフィールドは、最も外側のIPヘッダを参照してください。
0 1 2 3 4 5 6 7 ..... ..... ..... ..... ..... ..... ..... ..... | TOS2| TTL2| DF2 | PR2 |IPX2 |NBO2 |RND2 | I2 | if ip2 = 1 ..... ..... ..... ..... ..... ..... ..... .....
0 1 2 3 4 5 6 7 ..... ..... ..... ..... ..... ..... ..... ..... | TOS2 | TTL2 | DF2 | PR2 | IPX2 | NBO2 | RND2 | I2 |もしIP2 = 1 ..... ..... ..... ..... ..... ..... ..... .....
These flags are the same as the Inner IP header flags, but refer to the outer IP header instead of the inner IP header. The following flag, however, has no counterpart in the Inner IP header flags:
これらのフラグは、内側のIPヘッダフラグと同じであるが、外側のIPヘッダの代わりに内部IPヘッダを指します。以下のフラグは、しかしながら、内側のIPヘッダフラグには対応を有していません。
I2: Indicates presence of the IP-ID field.
I2は：IP-IDフィールドが存在することを示します。
Outer IP header fields
外側のIPヘッダフィールド
..... ..... ..... ..... ..... ..... ..... ..... | Type of Service/Traffic Class | if TOS2 = 1 ..... ..... ..... ..... ..... ..... ..... ..... | Time to Live/Hop Limit | if TTL2 = 1 ..... ..... ..... ..... ..... ..... ..... ..... | Protocol/Next Header | if PR2 = 1 ..... ..... ..... ..... ..... ..... ..... ..... / IP extension header(s) / variable, ..... ..... ..... ..... ..... ..... ..... ..... if IPX2 = 1 | IP-ID | 2 octets, ..... ..... ..... ..... ..... ..... ..... ..... if I2 = 1
..... ..... ..... ..... ..... ..... ..... ..... |サービス/トラフィッククラスの種類| TOS2の場合= 1 ..... ..... ..... ..... ..... ..... ..... ..... | /ホップ制限を生存時間| TTL2場合= 1 ..... ..... ..... ..... ..... ..... ..... ..... |プロトコル/次のヘッダー| PR2もし= 1 ..... ..... ..... ..... ..... ..... ..... ..... / IP拡張ヘッダ（S ）/変数、..... ..... ..... ..... ..... ..... ..... .....場合IPX2 = 1 | IP-ID | 2つのオクテット、..... ..... ..... ..... ..... ..... ..... ..... I2の場合= 1
The fields in this part of Extension 3 are as for the Inner IP header fields, but they refer to the outer IP header instead of the inner IP header. The following field, however, has no counterpart among the Inner IP header fields:
エクステンション3のこの部分のフィールドは、内側のIPヘッダフィールドの場合と同様であるが、外側のIPヘッダの代わりに内部IPヘッダを指します。以下のフィールドには、しかし、インナーIPヘッダフィールドの間には対応していません。
IP-ID: The IP Identifier field of the outer IP header, unless the inner header is an IPv6 header, in which case I2 is always zero.
IP-ID：外側IPヘッダのIP識別子フィールド、内部ヘッダは、I2は常にゼロである場合には、IPv6ヘッダ、でない限り。
RTP header flags and fields
RTPヘッダフラグおよびフィールド
0 1 2 3 4 5 6 7 ..... ..... ..... ..... ..... ..... ..... ..... | Mode |R-PT | M | R-X |CSRC | TSS | TIS | if rtp = 1 ..... ..... ..... ..... ..... ..... ..... ..... | R-P | RTP PT | if R-PT = 1 ..... ..... ..... ..... ..... ..... ..... ..... / Compressed CSRC list / if CSRC = 1 ..... ..... ..... ..... ..... ..... ..... ..... / TS_STRIDE / 1-4 oct if TSS = 1 ..... ..... ..... ..... ..... ..... ..... .... / TIME_STRIDE (milliseconds) / 1-4 oct if TIS = 1 ..... ..... ..... ..... ..... ..... ..... .....
0 1 2 3 4 5 6 7 ..... ..... ..... ..... ..... ..... ..... ..... |モード| R-PT | M | R-X | CSRC | TSS | TIS |もし、RTP = 1 ..... ..... ..... ..... ..... ..... ..... ..... | R-P | RTP PT | R-PT = 1 ..... ..... ..... ..... ..... ..... ..... ..... /圧縮CSRCリストなら/ IF CSRC = 1 ..... ..... ..... ..... ..... ..... ..... ..... / TS_STRIDE / 1- 10月4日TSSなら= 1 ..... ..... ..... ..... ..... ..... ..... .... / TIME_STRIDE（ミリ秒） / 1-4 10月TISなら= 1 ..... ..... ..... ..... ..... ..... ..... .....
Mode: Compression mode. 0 = Reserved, 1 = Unidirectional, 2 = Bidirectional Optimistic, 3 = Bidirectional Reliable.
モード：圧縮モード。 0 =予約済み、1 =単方向、2 =双方向楽観、3 =双方向信頼できます。
R-PT, CSRC, TSS, TIS: Indicate presence of fields as shown to the right of each field above.
R-PT、CSRC、TSS、TIS：上記各フィールドの右側に示すように、フィールドの存在を示します。
R-P: RTP Padding bit, absolute value (presumed zero if absent).
R-P：（存在しない場合はゼロと推定）のRTPパディングビット、絶対値。
R-X: RTP eXtension bit, absolute value.
R-X：RTP拡張ビット、絶対値。
M: See the beginning of section 5.7.
M：セクション5.7の始まりを参照してください。
RTP PT: Absolute value of RTP Payload type field.
RTP PT：RTPペイロードタイプフィールドの絶対値。
Compressed CSRC list: See section 5.8.1.
圧縮されたCSRCリスト：セクション5.8.1を参照してください。
TS_STRIDE: Predicted increment/decrement of the RTP Timestamp field when it changes. Encoded as in section 4.5.6.
TS_STRIDE：それは変わるRTPタイムスタンプフィールドの予測増加/減少。セクション4.5.6のようにエンコードされました。
TIME_STRIDE: Predicted time interval in milliseconds between changes in the RTP Timestamp. Also an indication that the compressor desires to perform timer-based compression of the RTP Timestamp field: see section 4.5.4. Encoded as in section 4.5.6.
TIME_STRIDE：RTPタイムスタンプの変化との間にミリ秒単位で予測時間間隔。コンプレッサがRTPタイムスタンプフィールドのタイマベースの圧縮を実行することを望むことも指示：セクション4.5.4を参照。セクション4.5.6のようにエンコードされました。
The values of the RND and RND2 flags are changed by sending UOR-2 headers with Extension 3, or IR-DYN headers, where the flag(s) have their new values. The establishment procedure of the flags is the normal one for the current mode, i.e., in U-mode and O-mode the values are repeated several times to ensure that the decompressor receives at least one. In R-mode, the flags are sent until an acknowledgment for a packet with the new RND flag values is received.
RNDとRND2フラグの値フラグ（S）はそれらの新しい値を持つ拡張3、またはIR-DYNヘッダーと共にUOR-2ヘッダーを送信することによって変更されます。フラグの確立手順、すなわち、UモードおよびOモードの値が減圧装置が少なくとも一つを受け取ることを保証するために数回繰り返され、現在のモードのために正常です。 Rモードでは、フラグは、新しいRNDフラグ値を持つパケットに対する肯定応答が受信されるまで送信されます。
The decompressor updates the values of its RND and RND2 flags whenever it receives an UOR-2 with Extension 3 carrying values for RND or RND2, and the UOR-2 CRC verifies successful decompression.
それはRNDまたはRND2の値を保持する拡張3とUOR-2を受信するたびにデコンプレッサはRNDとRND2フラグの値を更新し、UOR-2 CRCが成功した解凍を検証します。
When an IPv4 header for which the corresponding RND flag has not been established to be 1 is present in the static context, the packet types R-1 and UO-1 MUST NOT be used.
対応するRNDフラグが1であることが確立されていないため、IPv4ヘッダは、静的文脈中に存在する場合、パケットタイプR-1及びUO-1を使用してはいけません。
When no IPv4 header is present in the static context, or the RND flags for all IPv4 headers in the context have been established to be 1, the packet types R-1-ID, R-1-TS, UO-1-ID, and UO-1-TS MUST NOT be used.
何IPv4ヘッダは、静的コンテキスト内に存在しない場合、またはコンテキスト内のすべてのIPv4ヘッダーのRNDフラグが1であることが確立されている、パケットタイプR-1-ID、R-1-TS、UO-1-ID、そしてUO-1-TSを使用してはいけません。
While in the transient state in which an RND flag is being established, the packet types R-1-ID, R-1-TS, UO-1-ID, and UO-1-TS MUST NOT be used. This implies that the RND flag(s) of Extension 3 may have to be inspected before the exact format of a base header carrying an Extension 3 can be determined, i.e., whether a T-bit is present or not.
RNDフラグは、パケットタイプR-1-ID、R-1-TSを、UO-1-IDが確立され、及びUO-1-TSを使用してはいけませんする過渡状態にある間。これは、エクステンション3を担持するベースヘッダの正確なフォーマットは、Tビットが存在するか否か、すなわち、決定することができる前に、エクステンション3のRNDフラグ（S）が検査されなければならないことを意味します。
Some flags and fields in Extension 3 need to be maintained in the context of the decompressor. Their values are established using the mechanism appropriate to the compression mode, unless otherwise indicated in the table below and in referred sections.
いくつかのフラグと拡張3のフィールドは、デコンプレッサのコンテキスト内に維持する必要があります。そうでない場合は、以下の表にと呼ばれるセクションに示されない限り、それらの値は、圧縮モードへの適切なメカニズムを使用して確立されます。
Flag/Field Initial value Comment
---------------------------------------------------------------------
Mode Unidirectional See section 5.6
NBO 1 See section 4.5.5 RND 0 See sections 4.5.5, 5.7.5.1
NBO 1つのを参照してくださいセクション4.5.5 RND 0を参照してくださいセクション4.5.5、5.7.5.1
NBO2 1 As NBO, but for outer header RND2 0 As RND, but for outer header
NBOとして、しかし外側のヘッダのNBO2 1 RND2 0 RNDとして、しかしアウターヘッダの
TS_STRIDE 1 See section 4.5.3 TIME_STRIDE 0 See section 4.5.4 Tsc 1 Tsc is always 1 in context; can be 0 only when an Extension 3 is present. See the discussion of the TS field in the beginning of section 5.7.
TS_STRIDE 1を参照してくださいセクション4.5.3 TIME_STRIDE 0を参照してくださいセクション4.5.4 Tscの1 TSCは、常に文脈で1です。エクステンション3が存在する場合にのみ0であってもよいです。 5.7節の冒頭でTSフィールドの説明を参照してください。
When the round-trip time between compressor and decompressor is large, several packets can be in flight concurrently. Therefore, several packets may be received by the decompressor after feedback has been sent and before the compressor has reacted to feedback. Moreover, decompression may fail due to residual errors in the compressed header.
コンプレッサとデコンプレッサとの間の往復時間が大きい場合、いくつかのパケットが同時に飛行中であってもよいです。したがって、いくつかのパケットは、フィードバックが送信された後に解凍装置により受信されてもよいし、圧縮前のフィードバックに反応しました。また、減圧は、圧縮ヘッダ内の残留誤差に起因する失敗する可能性があります。
Therefore,
そのため、
a) in O-mode, the decompressor SHOULD limit the rate at which
feedback on successful decompression is sent (if it is sent at
all);
b) when decompression fails, feedback SHOULD be sent only when
decompression of several consecutive packets has failed, and when
this occurs, the feedback rate SHOULD be limited;
c) when packets are received which belong to a rejected packet
stream, the feedback rate SHOULD be limited.
A decompressor MAY limit the feedback rate by sending feedback only for one out of every k packets provoking the same (kind of) feedback. The appropriate value of k is implementation dependent; k might be chosen such that feedback is sent 1-3 times per link round-trip time.
デコンプレッサは、同じ（種類の）フィードバックを誘発毎K個のパケットのうちのためのフィードバックを送信することによって、フィードバック・レートを制限することができます。 kの適切な値は実装依存です。 kは、フィードバックは、リンクのラウンドトリップ時間あたり1〜3回送信されるように選択される可能性があります。
See section 5.2.2 for a discussion concerning ways to provide feedback information to the compressor.
圧縮機にフィードバック情報を提供するための方法に関する議論についてはセクション5.2.2を参照してください。
This section describes the format for feedback information in ROHC RTP. See also 5.2.2.
このセクションでは、ROHC RTPにおけるフィードバック情報のフォーマットを説明しています。また、5.2.2を参照してください。
Several feedback formats carry a field labeled SN. The SN field contains LSBs of an RTP Sequence Number. The sequence number to use is the sequence number of the header which caused the feedback information to be sent. If that sequence number cannot be determined, for example when decompression fails, the sequence number to use is that of the last successfully decompressed header. If no sequence number is available, the feedback MUST carry a SN-NOT-VALID option. Upon reception, the compressor matches valid SN LSBs with the most recent header sent with a SN with matching LSBs. The decompressor must ensure that it sends enough SN LSBs in its feedback that this correlation does not become ambiguous; e.g., if an 8-bit SN LSB field could wrap around within a round-trip time, the FEEDBACK-1 format cannot be used.
いくつかのフィードバック形式は、SNラベルされたフィールドを運びます。 SNフィールドは、RTPシーケンス番号のLSBが含まれています。使用するシーケンス番号は、フィードバック情報が送信される原因となったヘッダのシーケンス番号です。減圧が失敗した場合、そのシーケンス番号は、例えば、決定できない場合、使用するシーケンス番号が最後に正常に解凍ヘッダのものです。シーケンス番号が利用できない場合は、フィードバックはSN-有効でないオプションを運ばなければなりません。受信すると、圧縮機は、一致のLSBとSNと送信最新のヘッダを持つ有効なSNのLSBを一致します。デコンプレッサは、この相関関係があいまいにならないように、そのフィードバックで十分なSNのLSBを送信していることを確認する必要があります。 8ビットのSN LSBフィールドは、ラウンドトリップ時間以内にラップアラウンドすることができれば、例えば、FEEDBACK-1フォーマットを使用することはできません。
FEEDBACK-1
FEEDBACK-1
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| SN |
+---+---+---+---+---+---+---+---+
A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK, FEEDBACK-2 must be used. FEEDBACK-1 does not contain any mode information; FEEDBACK-2 must be used when mode information is required.
FEEDBACK-1がACKです。 NACK又はSTATIC-NACKを送信するために、FEEDBACK-2を使用しなければなりません。 FEEDBACK-1は、任意のモード情報が含まれていません。モード情報が必要な場合にFEEDBACK-2を使用する必要があります。
FEEDBACK-2
FEEDBACK-2
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| Mode | SN |
+---+---+---+---+---+---+---+---+
| SN |
+---+---+---+---+---+---+---+---+
/ Feedback options /
+---+---+---+---+---+---+---+---+
Acktype: 0 = ACK 1 = NACK 2 = STATIC-NACK 3 is reserved (MUST NOT be used for parseability)
Acktype：0 = ACK 1 = NACK 2 = STATIC-NACK 3（parseabilityのために使用してはいけません）予約されています
Mode: 0 is reserved 1 = Unidirectional mode 2 = Bidirectional Optimistic mode 3 = Bidirectional Reliable mode
モード：0 1 =単方向モード2 =双方向楽観モード3 =双方向信頼できるモードを予約されています
Feedback options: A variable number of feedback options, see section 5.7.6.2. Options may appear in any order.
フィードバックオプション：フィードバックオプションの可変数は、セクション5.7.6.2を参照してください。オプションは任意の順序で表示されることがあります。
A ROHC RTP Feedback option has variable length and the following general format:
ROHC RTPフィードバックオプションは、可変長と以下の一般的な形式になっています。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type | Opt Len |
+---+---+---+---+---+---+---+---+
/ option data / Opt Len octets
+---+---+---+---+---+---+---+---+
Sections 5.7.6.3-9 describe the currently defined ROHC RTP feedback options.
セクション5.7.6.3-9現在定義されてROHC RTPのフィードバックオプションについて説明します。
The CRC option contains an 8-bit CRC computed over the entire feedback payload, without the packet type and code octet, but including any CID fields, using the polynomial of section 5.9.1. If the CID is given with an Add-CID octet, the Add-CID octet immediately precedes the FEEDBACK-1 or FEEDBACK-2 format. For purposes of computing the CRC, the CRC fields of all CRC options are zero.
CRCオプションは、セクション5.9.1の多項式を用いて、パケットタイプとコードオクテットことなく、全体のフィードバックペイロードにわたって計算さ8ビットのCRCを含むが、任意のCIDフィールドを含みます。 CIDは、アドインCIDのオクテットで指定された場合、アドインCIDオクテットは直ちにFEEDBACK-1またはFEEDBACK-2フォーマットに先行します。 CRCを計算する目的のために、すべてのCRCオプションのCRCフィールドがゼロです。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 1 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| CRC |
+---+---+---+---+---+---+---+---+
When receiving feedback information with a CRC option, the compressor MUST verify the information by computing the CRC and comparing the result with the CRC carried in the CRC option. If the two are not identical, the feedback information MUST be ignored.
CRCオプションでフィードバック情報を受信した場合、圧縮機は、CRCを計算し、CRCオプションで運ばCRCとの結果を比較することにより、情報を検証しなければなりません。 2が同一でない場合は、フィードバック情報を無視しなければなりません。
The REJECT option informs the compressor that the decompressor does not have sufficient resources to handle the flow.
REJECTオプションは、デコンプレッサは、フローを処理するのに十分なリソースを持っていないコンプレッサーを通知します。
+---+---+---+---+---+---+---+---+
| Opt Type = 2 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
When receiving a REJECT option, the compressor stops compressing the packet stream, and should refrain from attempting to increase the number of compressed packet streams for some time. Any FEEDBACK packet carrying a REJECT option MUST also carry a CRC option.
REJECTオプションを受信すると、コンプレッサーはパケットストリームを圧縮停止し、いくつかの時間のために圧縮されたパケットストリームの数を増やすしようとするお控えください。 REJECTオプションを運ぶどれFEEDBACKパケットもCRCオプションを運ばなければなりません。
The SN-NOT-VALID option indicates that the SN of the feedback is not valid. A compressor MUST NOT use the SN of the feedback to find the corresponding sent header when this option is present.
SN-有効でないオプションは、フィードバックのSNが有効でないことを示しています。圧縮機は、このオプションが存在する場合、対応する送信されたヘッダを見つけるために、フィードバックのSNを使用してはいけません。
+---+---+---+---+---+---+---+---+
| Opt Type = 3 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
The SN option provides 8 additional bits of SN.
SNオプションは、SNの8つの追加ビットを提供します。
+---+---+---+---+---+---+---+---+
| Opt Type = 4 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| SN |
+---+---+---+---+---+---+---+---+
The CLOCK option informs the compressor of the clock resolution of the decompressor. This is needed to allow the compressor to estimate the jitter introduced by the clock of the decompressor when doing timer-based compression of the RTP Timestamp.
CLOCKオプションは減圧器のクロックの分解能のコンプレッサーを知らせます。これは、圧縮機は、RTPタイムスタンプのタイマーベースの圧縮を行う際にデコンプレッサのクロックによって導入されたジッタを推定することを可能にするために必要とされます。
+---+---+---+---+---+---+---+---+
| Opt Type = 5 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| clock resolution (ms) |
+---+---+---+---+---+---+---+---+
The smallest clock resolution which can be indicated is 1 millisecond. The value zero has a special meaning: it indicates that the decompressor cannot do timer-based compression of the RTP Timestamp. Any FEEDBACK packet carrying a CLOCK option SHOULD also carry a CRC option.
示すことができる最小のクロックの分解能は1ミリ秒です。値ゼロは特別な意味を持っている：それは、デコンプレッサがRTPタイムスタンプのタイマーベースの圧縮を行うことができないことを示しています。 CLOCKオプションを運ぶどれFEEDBACKパケットもCRCオプションを運ぶべきです。
The JITTER option allows the decompressor to report the maximum jitter it has observed lately, using the following formula which is very similar to the formula for Max_Jitter_BC in section 4.5.4.
JITTERオプションは、デコンプレッサは、それはセクション4.5.4でMax_Jitter_BCための式と非常に類似している以下の式を用いて、最近観察された最大ジッタを報告することを可能にします。
Let observation window i contain the decompressor's best approximation of the sliding window of the compressor (see section 4.5.4) when header i is received.
iが受信した場合、ヘッダ（セクション4.5.4を参照）iは、圧縮機のスライディングウィンドウのデコンプレッサの最良近似を含む観察窓をしましょう。
Max_Jitter_i =
Max_Jitter_i =
max {|(T_i - T_j) - ((a_i - a_j) / TIME_STRIDE)|,
for all headers j in observation window i}
Max_Jitter =
Max_Jitter =
max { Max_Jitter_i, for a large number of recent headers i }
マックス{Max_Jitter_i、最近ヘッダの多数のI}
This information may be used by the compressor to refine the formula for determining k when doing timer-based compression of the RTP Timestamp.
この情報は、RTPタイムスタンプのタイマベースの圧縮を行う際のkを求めるための式を絞り込み、圧縮機によって使用されてもよいです。
+---+---+---+---+---+---+---+---+
| Opt Type = 6 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| Max_Jitter |
+---+---+---+---+---+---+---+---+
The decompressor MAY ignore the oldest observed values of Max_Jitter_i. Thus, the reported Max_Jitter may decrease. Robustness will be reduced if the compressor uses a jitter estimate which is too small. Therefore, a FEEDBACK packet carrying a JITTER option SHOULD also carry a CRC option. Moreover, the compressor MAY ignore decreasing Max_Jitter values.
デコンプレッサはMax_Jitter_iの最も古い観測値を無視するかもしれません。したがって、報告されたMax_Jitterが低下することがあります。コンプレッサーが小さすぎるジッタ推定値を使用している場合、堅牢性が低下します。したがって、JITTERオプションを運ぶFEEDBACKパケットもCRCオプションを運ぶべきです。また、圧縮機はMax_Jitter値を減少させる無視してもよいです。
The LOSS option allows the decompressor to report the largest observed number of packets lost in sequence. This information MAY be used by the compressor to adjust the size of the reference window used in U- and O-mode.
LOSSオプションは、デコンプレッサが順番に失われたパケットの最大観測された数を報告することができます。この情報は、UおよびOモードで使用される参照ウィンドウのサイズを調整するために圧縮機によって使用されてもよいです。
+---+---+---+---+---+---+---+---+
| Opt Type = 7 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| longest loss event (packets) |
+---+---+---+---+---+---+---+---+
The decompressor MAY choose to ignore the oldest loss events. Thus, the value reported may decrease. Since setting the reference window too small can reduce robustness, a FEEDBACK packet carrying a LOSS option SHOULD also carry a CRC option. The compressor MAY choose to ignore decreasing loss values.
デコンプレッサは、最古の損失事象を無視することを選択するかもしれません。したがって、値が低下することが報告されました。堅牢性を減らすことができ小さすぎる参照ウィンドウを設定しているので、LOSSオプションを運ぶFEEDBACKパケットもCRCオプションを運ぶべきです。コンプレッサーは、損失値を下げる無視することを選択するかもしれません。
If an option type unknown to the compressor is encountered, it must continue parsing the rest of the FEEDBACK packet, which is possible since the length of the option is explicit, but MUST otherwise ignore the unknown option.
圧縮機への未知のオプションタイプが検出された場合は、オプションの長さが明示的であるので、可能であるフィードバックパケットの残りの部分を解析し続けなければならないが、それ以外は未知のオプションを無視しなければなりません。
Feedback for CID 8 indicating an ACK for SN 17 and Bidirectional Reliable mode can have the following formats.
SN 17と双方向信頼できるモードのACKを示すCID 8のフィードバックは、次の形式を有することができます。
Assuming small CIDs:
小さなCIDを仮定すると：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | 0 1 1 | feedback packet type, Code = 3
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | 1 0 0 0 | Add-CID octet with CID = 8
+---+---+---+---+---+---+---+---+
| 0 0 | 1 1 | SN MSB = 0 | AckType = ACK, Mode = Reliable
+---+---+---+---+---+---+---+---+
| SN LSB = 17 |
+---+---+---+---+---+---+---+---+
The second, third, and fourth octet are handed to the compressor.
第二、第三、および第四オクテットは、圧縮機に渡されます。
The FEEDBACK-1 format may also be used. Assuming large CIDs:
FEEDBACK-1フォーマットを使用してもよいです。大きなCIDを仮定すると：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | 0 1 0 | feedback packet type, Code = 2
+---+---+---+---+---+---+---+---+
| 0 0 0 0 1 0 0 0 | large CID with value 8
+---+---+---+---+---+---+---+---+
| SN LSB = 17 |
+---+---+---+---+---+---+---+---+
The second and third octet are handed to the compressor.
第二及び第三のオクテットは、圧縮機に渡されます。
Assuming small CIDs:
小さなCIDを仮定すると：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | 0 1 0 | feedback packet type, Code = 2
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | 1 0 0 0 | Add-CID octet with CID = 8
+---+---+---+---+---+---+---+---+
| SN LSB = 17 |
+---+---+---+---+---+---+---+---+
The second and third octet are handed to the compressor.
第二及び第三のオクテットは、圧縮機に渡されます。
Assuming small CIDs and CID 0 instead of CID 8:
小型のCID、代わりにCID 8のCID 0と仮定すると：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | 0 0 1 | feedback packet type, Code = 1
+---+---+---+---+---+---+---+---+
| SN LSB = 17 |
+---+---+---+---+---+---+---+---+
The second octet is handed to the compressor.
第2オクテットは、圧縮機に渡されます。
The subheaders which are compressible are split into a STATIC part and a DYNAMIC part. These parts are defined in sections 5.7.7.3 through 5.7.7.7.
圧縮されサブヘッダは、静的部分と動的部分に分割されます。これらの部品は5.7.7.7経由のセクション5.7.7.3で定義されています。
The structure of a chain of subheaders is determined by each header having a Next Header, or Protocol, field. This field identifies the type of the following header. Each Static part below that is followed by another Static part contains the Next Header/Protocol field and allows parsing of the Static chain; the Dynamic chain, if present, is structured analogously.
サブヘッダの鎖の構造は、次ヘッダ、またはプロトコル、フィールドを有する各ヘッダによって決定されます。このフィールドは、次のヘッダのタイプを識別する。その下に各固定部が別の静的部分に続いて次のヘッダー/プロトコルフィールドを含み、静的鎖の解析を可能にします。ダイナミックなチェーンは、存在する場合、同様に構成されています。
IR and IR-DYN packets will cause a packet to be delivered to upper layers if and only if the payload is non-empty. This means that an IP/UDP/RTP packet where the UDP length indicates a UDP payload of size 12 octets cannot be represented by an IR or IR-DYN packet. Such packets can instead be represented using the UNCOMPRESSED profile (section 5.10).
IR及びIR-DYNパケットは、パケットが上位層に配信される原因となる場合とペイロードが空の場合のみ。これは、UDPの長さは12個のオクテットがIRまたはIR-DYNパケットによって表すことができないサイズのUDPペイロードを示してIP / UDP / RTPパケットのことを意味します。そのようなパケットは、代わりUNCOMPRESSEDプロファイル（セクション5.10）を用いて表すことができます。
This packet type communicates the static part of the context, i.e., the values of the constant SN functions. It can optionally also communicate the dynamic part of the context, i.e., the parameters of nonconstant SN functions. It can also optionally communicate the payload of an original packet, if any.
このパケットタイプは文脈の静的な部分を伝える、すなわち、一定のSN関数の値。それはまた、任意のコンテキスト、すなわち、非定数SN機能のパラメータの動的な部分を通信することができます。いかなる場合にも必要に応じて、元のパケットのペイロードを通信することができます。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
| Add-CID octet | if for small CIDs and CID != 0
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 | D |
+---+---+---+---+---+---+---+---+
| |
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
| |
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
| Static chain | variable length
| |
+---+---+---+---+---+---+---+---+
| |
| Dynamic chain | present if D = 1, variable length
| |
- - - - - - - - - - - - - - - -
| |
| Payload | variable length
| |
- - - - - - - - - - - - - - - -
D: D = 1 indicates that the dynamic chain is present.
D：D = 1は、動的鎖が存在することを示します。
Profile: Profile identifier, abbreviated as defined in section 5.2.3.
プロフィール：セクション5.2.3で定義されるように略記プロファイル識別子、。
CRC: 8-bit CRC, computed according to section 5.9.1.
CRC：8ビットCRCは、セクション5.9.1に従って計算します。
Static chain: A chain of static subheader information.
静的チェーン：静的サブヘッダ情報の連鎖。
Dynamic chain: A chain of dynamic subheader information. What dynamic information is present is inferred from the Static chain.
ダイナミックチェーン：動的なサブヘッダ情報の連鎖。静的チェーンから推測される動的などのような情報が存在します。
Payload: The payload of the corresponding original packet, if any. The presence of a payload is inferred from the packet length.
ペイロード：対応するオリジナルのパケットのペイロード（もしあれば）。ペイロードの存在は、パケット長から推論されます。
This packet type communicates the dynamic part of the context, i.e., the parameters of nonconstant SN functions.
このパケットタイプはコンテキストの動的部分を通信する、即ち、非定数SN関数のパラメータ。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and CID != 0
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 0 | IR-DYN packet type
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Dynamic chain / variable length
| |
+---+---+---+---+---+---+---+---+
: :
/ Payload / variable length
: :
- - - - - - - - - - - - - - - -
Profile: Profile identifier, abbreviated as defined in section 5.2.3.
プロフィール：セクション5.2.3で定義されるように略記プロファイル識別子、。
CRC: 8-bit CRC, computed according to section 5.9.1.
CRC：8ビットCRCは、セクション5.9.1に従って計算します。
NOTE: As the CRC checks only the integrity of the header itself, an acknowledgment of this header does not signify that previous changes to the static chain in the context are also acknowledged. In particular, care should be taken when IR packets that update an existing context are followed by IR-DYN packets.
注：CRCはヘッダ自体の唯一の整合性をチェックするように、このヘッダの確認応答も認められている文脈において静的鎖への以前の変更を意味するものではありません。既存のコンテキストを更新IRパケットがIR-DYNパケットが続いている場合、特に注意が払われるべきです。
Dynamic chain: A chain of dynamic subheader information. What dynamic information is present is inferred from the Static chain of the context.
ダイナミックチェーン：動的なサブヘッダ情報の連鎖。コンテキストの静的なチェーンから推論されるダイナミックどのような情報が存在します。
Payload: The payload of the corresponding original packet, if any. The presence of a payload is inferred from the packet length.
ペイロード：対応するオリジナルのパケットのペイロード（もしあれば）。ペイロードの存在は、パケット長から推論されます。
Note: The static and dynamic chains of IR or IR-DYN packets for profile 0x0001 (ROHC RTP) MUST end with the static and dynamic parts of an RTP header. If not, the packet MUST be discarded and the context MUST NOT be updated.
注：プロファイルは0x0001（ROHC RTP）のためにIRまたはIR-DYNパケットの静的および動的鎖がRTPヘッダの静的及び動的な部分で終了する必要があります。そうでない場合、パケットは捨てなければなりませんし、コンテキストが更新されてはなりません。
Note: The static or dynamic chains of IR or IR-DYN packets for profile 0x0002 (ROHC UDP) MUST end with the static and dynamic parts of a UDP header. If not, the packet MUST be discarded and the context MUST NOT be updated.
注：プロファイル0×0002（ROHC UDP）のためにIRまたはIR-DYNパケットの静的または動的な鎖がUDPヘッダの静的及び動的な部分で終了する必要があります。そうでない場合、パケットは捨てなければなりませんし、コンテキストが更新されてはなりません。
Note: The static or dynamic chains of IR or IR-DYN packets for profile 0x0003 (ROHC ESP) MUST end with the static and dynamic parts of an ESP header. If not, the packet MUST be discarded and the context MUST NOT be updated.
注：プロフィール0x0003（ROHC ESP）用のIRまたはIR-DYNパケットの静的または動的な鎖がESPヘッダの静的及び動的な部分で終了する必要があります。そうでない場合、パケットは捨てなければなりませんし、コンテキストが更新されてはなりません。
Static part:
静的な部分：
+---+---+---+---+---+---+---+---+
| Version = 6 |Flow Label(msb)| 1 octet
+---+---+---+---+---+---+---+---+
/ Flow Label (lsb) / 2 octets
+---+---+---+---+---+---+---+---+
| Next Header | 1 octet
+---+---+---+---+---+---+---+---+
/ Source Address / 16 octets
+---+---+---+---+---+---+---+---+
/ Destination Address / 16 octets
+---+---+---+---+---+---+---+---+
Dynamic part:
ダイナミックパート：
+---+---+---+---+---+---+---+---+
| Traffic Class | 1 octet
+---+---+---+---+---+---+---+---+
| Hop Limit | 1 octet
+---+---+---+---+---+---+---+---+
/ Generic extension header list / variable length
+---+---+---+---+---+---+---+---+
Eliminated:
排除：
Payload Length
ペイロード長
Extras:
エクストラ：
Generic extension header list: Encoded according to section 5.8.6.1, with all header items present in uncompressed form.
一般的な拡張ヘッダリスト：圧縮されていない形態で存在するすべてのヘッダ項目と、セクション5.8.6.1に従ってエンコード。
CRC-DYNAMIC: Payload Length field (octets 5-6).
CRC-DYNAMIC：ペイロード長フィールド（オクテット5-6）。
CRC-STATIC: All other fields (octets 1-4, 7-40).
CRC-STATIC：他のすべてのフィールド（オクテット1-4、7-40）。
CRC coverage for extension headers is defined in section 5.8.7.
拡張ヘッダのCRCの適用範囲は、セクション5.8.7で定義されています。
Note: The Next Header field indicates the type of the following header in the static chain, rather than being a copy of the Next Header field of the original IPv6 header. See also section 5.7.7.8.
注：次のヘッダフィールドではなく、オリジナルのIPv6ヘッダの次ヘッダフィールドのコピーであるよりも、静的チェーン内の次のヘッダの種類を示します。また、セクション5.7.7.8を参照してください。
Static part:
静的な部分：
Version, Protocol, Source Address, Destination Address.
バージョン、プロトコル、送信元アドレス、宛先アドレス。
+---+---+---+---+---+---+---+---+
| Version = 4 | 0 |
+---+---+---+---+---+---+---+---+
| Protocol |
+---+---+---+---+---+---+---+---+
/ Source Address / 4 octets
+---+---+---+---+---+---+---+---+
/ Destination Address / 4 octets
+---+---+---+---+---+---+---+---+
Dynamic part:
ダイナミックパート：
Type of Service, Time to Live, Identification, DF, RND, NBO, extension header list.
サービス、生存時間、識別、DF、RND、NBO、拡張ヘッダーリストのタイプ。
+---+---+---+---+---+---+---+---+
| Type of Service |
+---+---+---+---+---+---+---+---+
| Time to Live |
+---+---+---+---+---+---+---+---+
/ Identification / 2 octets
+---+---+---+---+---+---+---+---+
| DF|RND|NBO| 0 |
+---+---+---+---+---+---+---+---+
/ Generic extension header list / variable length
+---+---+---+---+---+---+---+---+
Eliminated:
排除：
IHL (IP Header Length, must be 5) Total Length (inferred in decompressed packets) MF flag (More Fragments flag, must be 0) Fragment Offset (must be 0) Header Checksum (inferred in decompressed packets) Options, Padding (must not be present)
IHL（IPヘッダの長さ、5なければならない）全長（解凍パケットに推測）MFフラグ（モアフラグメントフラグ、0でなければならない）オフセットフラグメント（0でなければならない）ヘッダチェックサム（解凍パケットに推測）オプション、パディング（いけません）に存在すること
Extras:
エクストラ：
RND, NBO See section 5.7.
RNDは、NBOは、セクション5.7を参照してください。
Generic extension header list: Encoded according to section 5.8.6.1, with all header items present in uncompressed form.
一般的な拡張ヘッダリスト：圧縮されていない形態で存在するすべてのヘッダ項目と、セクション5.8.6.1に従ってエンコード。
CRC-DYNAMIC: Total Length, Identification, Header Checksum (octets 3-4, 5-6, 11-12).
CRC-DYNAMIC：全長、識別、ヘッダーチェックサム（オクテット3-4、5-6、11-12）。
CRC-STATIC: All other fields (octets 1-2, 7-10, 13-20)
CRC-STATIC：他のすべてのフィールド（オクテット1-2、7-10、13-20）
CRC coverage for extension headers is defined in section 5.8.7.
拡張ヘッダのCRCの適用範囲は、セクション5.8.7で定義されています。
Note: The Protocol field indicates the type of the following header in the static chain, rather than being a copy of the Protocol field of the original IPv4 header. See also section 5.7.7.8.
注：プロトコル・フィールドではなく、元のIPv4ヘッダのプロトコルフィールドのコピーであるよりも、静的チェーン内の次のヘッダの種類を示します。また、セクション5.7.7.8を参照してください。
Static part:
静的な部分：
+---+---+---+---+---+---+---+---+
/ Source Port / 2 octets
+---+---+---+---+---+---+---+---+
/ Destination Port / 2 octets
+---+---+---+---+---+---+---+---+
Dynamic part:
ダイナミックパート：
+---+---+---+---+---+---+---+---+
/ Checksum / 2 octets
+---+---+---+---+---+---+---+---+
Eliminated:
排除：
Length
長さ
The Length field of the UDP header MUST match the Length field(s) of the preceding subheaders, i.e., there must not be any padding after the UDP payload that is covered by the IP Length.
UDPヘッダの長さフィールドが先行サブヘッダの長さフィールド（複数可）と一致する必要があり、すなわち、IP長によって覆われているUDPペイロードの後に、任意のパディングがあってはなりません。
CRC-DYNAMIC: Length field, Checksum (octets 5-8).
CRC-DYNAMIC：長さフィールド、チェックサム（オクテット5-8）。
CRC-STATIC: All other fields (octets 1-4).
CRC-STATIC：他のすべてのフィールド（オクテット1-4）。
Static part:
静的な部分：
SSRC.
SSRC。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
/ SSRC / 4 octets
+---+---+---+---+---+---+---+---+
Dynamic part:
ダイナミックパート：
P, X, CC, PT, M, sequence number, timestamp, timestamp stride, CSRC identifiers.
P、X、CC、PT、M、シーケンス番号、タイムスタンプ、タイムスタンプストライド、CSRC識別子。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| V=2 | P | RX| CC | (RX is NOT the RTP X bit)
+---+---+---+---+---+---+---+---+
| M | PT |
+---+---+---+---+---+---+---+---+
/ RTP Sequence Number / 2 octets
+---+---+---+---+---+---+---+---+
/ RTP Timestamp (absolute) / 4 octets
+---+---+---+---+---+---+---+---+
/ Generic CSRC list / variable length
+---+---+---+---+---+---+---+---+
: Reserved | X | Mode |TIS|TSS: if RX = 1
+---+---+---+---+---+---+---+---+
: TS_Stride : 1-4 octets, if TSS = 1
+---+---+---+---+---+---+---+---+
: Time_Stride : 1-4 octets, if TIS = 1
+---+---+---+---+---+---+---+---+
Eliminated:
排除：
Nothing.
何もありません。
Extras:
エクストラ：
RX: Controls presence of extension.
RX：延長のControls存在。
Mode: Compression mode. 0 = Reserved, 1 = Unidirectional, 2 = Bidirectional Optimistic, 3 = Bidirectional Reliable.
モード：圧縮モード。 0 =予約済み、1 =単方向、2 =双方向楽観、3 =双方向信頼できます。
X: Copy of X bit from RTP header (presumed 0 if RX = 0)
X：RTPヘッダ（RX = 0の場合は0を推定）からXビットのコピー
Reserved: Set to zero when sending, ignored when received.
予約：受信時に無視され、送信時にゼロに設定してください。
Generic CSRC list: CSRC list encoded according to section 5.8.6.1, with all CSRC items present.
ジェネリックCSRCリスト：CSRCリストに存在する全てのCSRC項目と、セクション5.8.6.1に従って符号化されました。
CRC-DYNAMIC: Octets containing M-bit, sequence number field, and timestamp (octets 2-8).
CRC-DYNAMIC：Mビットが含まれているオクテット、シーケンス番号フィールド、およびタイムスタンプ（オクテット2-8）。
CRC-STATIC: All other fields (octets 1, 9-12, original CSRC list).
CRC-STATIC：他のすべてのフィールド（オクテット1、9-12、元CSRCリスト）。
This is for the case when the NULL encryption algorithm [NULL] is NOT being used with ESP, so that subheaders after the ESP header are encrypted (see 5.12). See 5.8.4.3 for compression of the ESP header when NULL encryption is being used.
これは、（5.12を参照）ESPヘッダの後サブヘッダは暗号化されるように、NULL暗号化アルゴリズム[NULL]は、ESPで使用されていない場合です。 NULL暗号化が使用されているとき、ESPヘッダの圧縮のための5.8.4.3を参照してください。
Static part:
静的な部分：
+---+---+---+---+---+---+---+---+
/ SPI / 4 octets
+---+---+---+---+---+---+---+---+
Dynamic part:
ダイナミックパート：
+---+---+---+---+---+---+---+---+
/ Sequence Number / 4 octets
+---+---+---+---+---+---+---+---+
Eliminated:
排除：
Other fields are encrypted, and can neither be located nor compressed.
他のフィールドは暗号化され、位置もなく、圧縮することもできません。
CRC-DYNAMIC: Sequence number (octets 5-8)
CRC-DYNAMIC：シーケンス番号（オクテット5-8）
CRC-STATIC: All other octets.
CRC-STATIC：他のすべてのオクテット。
Note: No encrypted data is considered to be part of the header for purposes of computing the CRC, i.e., octets after the eight octet are not considered part of the header.
注：暗号化されたデータは、CRCを計算する目的のためにヘッダの一部であるとみなされていない、即ち、オクテットは8つのオクテットの後にヘッダの一部とは見なされません。
Headers not explicitly listed in previous subsections can be compressed only by making them part of an extension header chain following an IPv4 or IPv6 header, see section 5.8.
明示的に前のサブセクションに記載されていないヘッダは、セクション5.8を参照して、IPv4またはIPv6ヘッダに続くそれらに拡張ヘッダチェーンの一部を行うことによって圧縮することができます。
Header information from the packet stream to be compressed can be structured as an ordered list, which is largely constant between packets. The generic structure of such a list is as follows.
圧縮されるパケットストリームからヘッダ情報は、パケット間のほぼ一定である順序付けられたリストとして構成することができます。次のようなリストの一般的な構造です。
+--------+--------+--...--+--------+
list: | item 1 | item 2 | | item n |
+--------+--------+--...--+--------+
This section describes the compression scheme for such information. The basic principles of list-based compression are the following:
このセクションでは、このような情報のための圧縮方式を説明しています。リストベースの圧縮の基本的な原則は次のとおりです。
1) While the list is constant, no information about the list is sent in compressed headers.
リストが一定であるが1）、リストに関する情報は、圧縮されたヘッダーで送信されません。
2) Small changes in the list are represented as additions (Insertion scheme), or deletions (Removal scheme), or both (Remove Then Insert scheme).
2）リスト内の小さな変化は、付加（挿入方式）、または欠失（除去方式）として表され、またはその両方（）次に挿入スキームを削除します。
3) The list can also be sent in its entirety (Generic scheme).
3）リストには、その全体（一般スキーム）に送信することができます。
There are two kinds of lists: CSRC lists in RTP packets, and extension header chains in IP packets (both IPv4 and IPv6).
IPパケット内のRTPパケット内CSRCリスト、および拡張ヘッダ鎖（IPv4とIPv6の両方）のリストの2種類があります。
IPv6 base headers and IPv4 headers cannot be part of an extension header chain. Headers which can be part of extension header chains include
IPv6の基本ヘッダとIPv4ヘッダは、拡張ヘッダチェーンの一部であることはできません。ヘッダ鎖が含まれる拡張の一部とすることができるヘッダ
a) the AH header b) the null ESP header c) the minimal encapsulation header [RFC2004, section 3.1] d) the GRE header [GRE1, GRE2] e) IPv6 extension headers.
a）AHヘッダB）ヌルESPヘッダC）最小限のカプセル化ヘッダ[RFC2004、セクション3.1] D）GREヘッダー[GRE1、GRE2] E）のIPv6拡張ヘッダ。
The table-based item compression scheme (5.8.1), which reduces the size of each item, is described first. Then it is defined which reference list to use in the insertion and removal schemes (5.8.2). List encoding schemes are described in section 5.8.3, and a few special cases in section 5.8.4. Finally, exact formats are described in sections 5.8.5-5.8.6.
各項目のサイズを縮小テーブルベースの項目圧縮方式（5.8.1）は、最初に記載されています。挿入および除去スキーム（5.8.2）で使用する参照リストに定義されています。リスト符号化方式は、セクション5.8.3、およびセクション5.8.4でいくつかの特殊な例で説明されています。最後に、正確なフォーマットはセクション5.8.5-5.8.6に記載されています。
The Table-based item compression scheme is a way to compress individual items sent in compressed lists. The compressor assigns each item in a list a unique identifier Index. The compressor conceptually maintains a table with all items, indexed by Index. The (Index, item) pair is sent together in compressed lists until the compressor gains enough confidence that the decompressor has observed the mapping between the item and its Index. Such confidence is obtained by receiving an acknowledgment from the decompressor in R-mode, and in U/O-mode by sending L (Index, item) pairs (not necessarily consecutively). After that, the Index alone is sent in compressed lists to indicate the corresponding item. The compressor may reassign an existing Index to a new item, and then needs to re-establish the mapping in the same manner as above.
表ベースの項目圧縮方式は、圧縮されたリストに送信された個々の項目を圧縮する方法です。圧縮機は、リスト、一意の識別子索引の各項目を割り当てます。コンプレッサーは概念的にインデックスがインデックスを作成したすべての項目でテーブルを維持しています。 （インデックス、項目）対がデコンプレッサは、アイテムとそのインデックスとの間のマッピングを観察したことをコンプレッサ・ゲイン十分に信頼まで圧縮リストに一緒に送信されます。そのような信頼は、Rモードでのデコンプレッサから肯定応答を受信することによって得られ、L（インデックス、項目）対（必ずしも連続的に）送信することによって、U / Oモードにされます。その後、単独の指数は、該当する項目を示すために、圧縮されたリストに送信されます。圧縮機は、新しいアイテムに既存のインデックスを再割り当てし、その後上記と同様に再確立マッピングする必要ができます。
The decompressor conceptually maintains a table that contains all (Index, item) pairs it knows about. The table is updated whenever an (Index, item) pair is received (and decompression is verified by a CRC). The decompressor retrieves the item from the table whenever an Index without an accompanying item is received.
デコンプレッサは、概念的には、それは知っているすべての（インデックス、項目）組を含むテーブルを維持します。 （インデックス、項目）組が受信される（そして減圧はCRCにより確認される）たびに、テーブルが更新されます。デコンプレッサは、添付の項目なしでインデックスが受信されるたびに、テーブルから項目を検索します。
At the compressor side, an entry in the Translation Table has the following structure.
圧縮機側で、変換テーブル内のエントリは、以下の構造を有しています。
+-------+------+---------------+
Index i | Known | item | SN1, SN2, ... |
+-------+------+---------------+
The Known flag indicates whether the mapping between Index i and item has been established, i.e., if Index i alone can be sent in compressed lists. Known is initially zero. It is also set to zero whenever Index i is assigned to a new item. Known is set to one when the corresponding (Index, item) pair is acknowledged. Acknowledgments are based on the RTP Sequence Number, so a list of RTP Sequence Numbers of all packets which contain the (Index, item) pair is included in the translation table. When a packet with a sequence number in the sequence number list is acknowledged, the Known flag is set, and the sequence number list can be discarded.
既知のフラグはインデックスのみiは、圧縮リストに送信することができればインデックスiとアイテムとの間のマッピングは、即ち、確立されているか否かを示します。既知の最初はゼロです。インデックスiは新しい項目に割り当てられている時はいつでもそれはまたゼロに設定されています。対応する（インデックス、項目）ペアが確認されたときに知られているが1に設定されています。肯定応答は、RTPシーケンス番号に基づいているので（インデックス、項目）ペアを含むすべてのパケットのRTPシーケンス番号のリストは、変換テーブルに含まれています。シーケンス番号リスト内のシーケンス番号を持つパケットが確認されると、既知のフラグがセットされ、シーケンス番号リストを破棄することができます。
Each entry in the Translation Table at the decompressor side has the following structure:
減圧装置側で変換テーブル内の各エントリは、以下の構造を有します。
+-------+------+
Index i | Known | item |
+-------+------+
All Known fields are initialized to zero. Whenever the decompressor receives an (Index, item) pair, it inserts item into the table at position Index and sets the Known flag in that entry to one. If an index without an accompanying item is received for which the Known flag is zero, the header MUST be discarded and a NACK SHOULD be sent.
すべての既知のフィールドはゼロに初期化されています。解凍装置は（インデックス、項目）組を受信するたびに、それが位置インデックスでテーブルに項目を挿入したものと、そのエントリで知られているフラグを設定します。添付項目無しインデックスは既知のフラグがゼロであるために受信される場合、ヘッダーは捨てなければならないとNACKが送信されるべきです。
At the compressor side, each entry in the Translation Table has the following structure:
圧縮機側で、変換テーブル内の各エントリは、以下の構造を有します。
+-------+------+---------+
Index | Known | item | Counter |
+-------+------+---------+
The Index, Known, and item fields have the same meaning as in section 5.8.1.1.
既知のインデックス、および項目フィールドはセクション5.8.1.1と同じ意味を持ちます。
Known is set when the (Index, item) pair has been sent in L compressed lists (not necessarily consecutively). The Counter field keeps track of how many times the pair has been sent. Counter is set to 0 for each new entry added to the table, and whenever Index is assigned to a new item. Counter is incremented by 1 whenever an (Index, item) pair is sent. When the counter reaches L, the Known field is set and after that only the Index needs to be sent in compressed lists.
（インデックス、項目）組がL圧縮リスト（必ずしも連続）で送信されたときに知られているが設定されています。カウンターフィールドは、ペアが送信された回数を追跡します。カウンタは、テーブルに追加される各新しいエントリのために0に設定され、インデックスは、新しい項目に割り当てられているときはいつでも。 （インデックス、項目）組が送信されるたびにカウンタは1だけインクリメントされます。カウンターがLに到達すると、既知のフィールドが設定され、その後にのみインデックスが圧縮されたリストに送信される必要があります。
At the decompressor side, the Translation Table is the same as the Translation Table defined in R-mode.
減圧装置側では、変換テーブルがRモードで定義された変換テーブルと同じです。
In reference based compression schemes (i.e., addition or deletion based schemes), compression and decompression of a list (curr_list) are based on a reference list (ref_list) which is assumed to be present in the context of both compressor and decompressor. The compressed list is an encoding of the differences between curr_list and ref_list. Upon reception of a compressed list, the decompressor applies the differences to its reference list in order to obtain the original list.
参照ベースの圧縮方式（すなわち、追加又は削除ベースのスキーム）において、リスト（curr_list）の圧縮及び解凍は圧縮と減圧の両方のコンテキストで存在することが想定される参照リスト（ref_list）に基づいています。圧縮されたリストは、curr_listとref_list間の違いのエンコーディングです。圧縮されたリストを受信すると、解凍装置は、元のリストを取得するために、その参照リストに違いを適用します。
To identify the reference list (to be) used, each compressed list carries an identifier (ref_id). The reference list is established by different methods in R-mode and U/O-mode.
参照リストを識別するために使用される（べき）は、各圧縮されたリストは、識別子（ref_id）を運びます。参照リストはRモードおよびU / Oモードで異なる方法によって確立されます。
In R-mode, the choice of reference list is based on acknowledgments, i.e., the compressor uses as ref_list the latest list which has been acknowledged by the decompressor. The ref_list is updated only upon receiving an acknowledgment. The least significant bits of the RTP Sequence Number of the acknowledged packet are used as the ref_id.
Rモードでは、参照リストの選択は肯定応答に基づいており、すなわち、圧縮機は、減圧装置によって承認された最新のリストref_listとして使用します。 ref_listだけ確認応答を受信したときに更新されます。確認応答パケットのRTPシーケンス番号の最下位ビットはref_idとして使用されます。
In U/O-mode, a sequence of identical lists are considered as belonging to the same generation and are all assigned the same generation identifier (gen_id). Gen_id increases by 1 each time the list changes and is carried in compressed and uncompressed lists that are candidates for being used as reference lists. Normally, Gen_id must have been repeated in at least L headers before the list can be used as a ref_list. However, some acknowledgments may be sent in O-mode (and also in U-mode), and whenever an acknowledgment for a header is received, the list of that header is considered known and need not be repeated further. The least significant bits of the Gen_id is used as the ref_id in U/O-mode.
U / Oモードでは、同一のリストの配列が同じ世代に属するものとしてみなされ、全て同じ世代識別子（GEN_ID）が割り当てられます。 GEN_ID 1だけ増加するたびにリストの変更とは、参照リストとして使用されるための候補である圧縮と非圧縮のリストに運ばれます。リストはref_listとして使用することができます前に、通常、GEN_IDは、少なくともLヘッダーで繰り返されている必要があります。しかし、いくつかの肯定応答は、（また、U-モード）Oモードで送信されてもよく、ヘッダの確認応答が受信されるたびに、そのヘッダのリストが知らみなされ、さらに繰り返す必要はありません。 GEN_IDの最下位ビットはU / Oモードでref_idとして使用されます。
The logic of the compressor and decompressor for reference based list compression is similar to that for SN and TS. The principal difference is that the decompressor maintains a sliding window with candidates for ref_list, and retrieves ref_list from the sliding window using the ref_id of the compressed list.
参照ベースのリスト圧縮用のコンプレッサとデコンプレッサのロジックは、SNとTSの場合と同様です。主な違いは、減圧装置がref_listの候補とのスライディングウィンドウを維持し、圧縮されたリストのref_idを用いてスライディングウインドウからref_listを取得することです。
Logic of compressor:
コンプレッサーの論理：
a) In the IR state, the compressor sends Generic lists (see 5.8.5) containing all items of the current list in order to establish or refresh the context of the decompressor.
A）IR状態では、圧縮は、デコンプレッサのコンテキストを確立またはリフレッシュするために現在のリストのすべての項目を含む（5.8.5を参照）一般的なリストを送信します。
In R-mode, such Generic lists are sent until a header is acknowledged. The list of that header can be used as a reference list to compress subsequent lists.
Rモードでは、そのような一般的なリストは、ヘッダが確認されるまで送信されます。そのヘッダのリストは、後続のリストを圧縮するために参照リストとして使用することができます。
In U/O-mode, the compressor sends generation identifiers with the Generic lists until
U / Oモードでは、圧縮機は、汎用までリストを生成識別子を送信します
1) a generation identifier has been repeated L times, or
1）世代識別子がL回繰り返し、またはされてい
2) an acknowledgment for a header carrying a generation identifier has been received.
2）世代の識別子を運ぶヘッダの確認応答が受信されています。
The repeated (1) or acknowledged (2) list can be used as a reference list to compress subsequent lists and is kept together with its generation identifier.
（1）反復または肯定応答（2）リストは、後続のリストを圧縮するために参照リストとして使用することができ、その世代識別子と共に保持されます。
b) When not in the IR state, the compressor moves to the FO state when it observes a difference between curr_list and the previous list. It sends compressed lists based on ref_list to update the context of the decompressor. (However, see d).)
b）の場合ではないIR状態で、それはcurr_listと前のリストとの間の差を観測FO状態に圧縮移動します。これは、デコンプレッサのコンテキストを更新するためにref_listに基づいて圧縮されたリストを送信します。 （ただし、Dを参照）。）
In R-mode, the compressor keeps sending compressed lists using the same reference until it receives an acknowledgment for a packet containing the newest list. The compressor may then move to the SO state with regard to the list.
Rモードでは、コンプレッサは、それが最新のリストを含むパケットに対する肯定応答を受信するまで同じ基準を使用して圧縮されたリストを送信し続けます。圧縮機は、リストに関してSO状態に移動することができます。
In U/O-mode, the compressor keeps sending compressed lists with generation identifiers until
U / Oモードでは、圧縮機が発生するまでの識別子に圧縮リストを送信し続けます
1) a generation identifier has been repeated L times, or
1）世代識別子がL回繰り返し、またはされてい
2) an acknowledgment for a header carrying the latest generation identifier has been received.
2）最新世代の識別子を運ぶヘッダの確認応答が受信されています。
The repeated or acknowledged list is used as the future reference list. The compressor may move to the SO state with regard to the list.
反復または認めリストは、将来の参照リストとして使用されています。コンプレッサーはリストに関してSO状態に移動することができます。
c) In R-mode, the compressor maintains a sliding window containing the lists which have been sent to update the context of the decompressor and have not yet been acknowledged. The sliding window shrinks when an acknowledgment arrives: all lists sent before the acknowledged list are removed. The compressor may use the Index to represent items of lists in the sliding window.
C）Rモードでは、圧縮機は、減圧装置のコンテキストを更新するために送信され、まだ確認されていないリストを含むスライディングウィンドウを維持します。確認応答が到着したときにスライディングウィンドウが縮小：定評のリストの前に送信されたすべてのリストが削除されます。コンプレッサーは、スライディングウィンドウにリストの項目を表現するためにインデックスを使用することができます。
In U/O-mode, the compressor needs to store
U / Oモードでは、圧縮機が格納する必要があります
1) the reference list and its generation identifier, and
1）参照リスト及びその生成識別子、及び
2) if the current generation identifier is different from the reference generation, the current list and the sequence numbers with which the current list has been sent.
2）現在の世代識別子が基準生成、現在のリストと現在のリストが送信されたとシーケンス番号と異なる場合。
(2) is needed to determine if an acknowledgment concerns the latest generation. It is not needed in U-mode.
（2）は、確認応答が最新世代に関係するかどうかを判断するために必要とされます。これは、U-モードでは必要ありません。
d) In U/O-mode, the compressor may choose to not send a generation identifier with a compressed list. Such lists without generation identifiers are not assigned a new generation identifier and must not be used as future reference lists. They do not update the context. This feature is useful when a new list is repeated few times and the list then reverts back to its old value.
D）U / Oモードでは、圧縮機は、圧縮リストを生成識別子を送信しないことを選択することができます。世代識別子のないこのようなリストは、新世代の識別子を割り当てられていないと、将来の参照リストとして使用することはできません。彼らは、コンテキストを更新しません。新しいリストが数回繰り返され、リストには、その古い値に戻りますと、この機能は便利です。
Logic of decompressor:
解凍器の論理：
e) In R-mode, the decompressor acknowledges all received uncompressed or compressed lists which establish or update the context. (Such compressed headers contain a CRC.)
E）Rモードでは、デコンプレッサは、確立またはコンテキストを更新し、すべての受信した非圧縮又は圧縮されたリストを認めます。 （このような圧縮されたヘッダはCRCを含みます。）
In O-mode, the decompressor MAY acknowledge a list with a new generation identifier, see section 5.4.2.2.
Oモードでは、デコンプレッサは、セクション5.4.2.2を参照して、新世代の識別子のリストを確認してもよいです。
In U-mode, the decompressor MAY acknowledge a list sent in an IR packet, see section 5.3.2.3.
U-モードでは、デコンプレッサは、セクション5.3.2.3を参照して、IRパケットで送信されたリストを確認してもよいです。
f) The decompressor maintains a sliding window which contains the lists that may be used as reference lists.
F）減圧装置は参照リストとして使用することができるリストが含まれているスライディングウィンドウを維持します。
In R-mode, the sliding window contains lists which have been acknowledged but not yet used as reference lists.
Rモードでは、スライディングウィンドウは認めまだ参照リストとして使用していないれたリストを含んでいます。
In U/O-mode, the sliding window contains at most one list per generation. It contains all generations seen by the decompressor newer than the last generation used as a reference.
U / Oモードでは、スライディングウィンドウが生成につき最大1つのリストを含みます。なお、基準として使用された最後の世代よりも新しいデコンプレッサから見たすべての世代が含まれています。
g) When the decompressor receives a compressed list, it retrieves the proper ref_list from the sliding window based on the ref_id, and decompresses the compressed list obtaining curr_list.
G減圧装置が圧縮されたリストを受信した場合）、それはref_idに基づいて、スライディングウィンドウから適切ref_listを取得し、curr_listを得る圧縮されたリストを解凍します。
In R-mode, curr_list is inserted into the sliding window if an acknowledgment is sent for it. The sliding window is shrunk by removing all lists received before ref_list.
肯定応答がそれのために送信される場合Rモードでは、curr_listは、スライディングウィンドウ内に挿入されます。スライディングウィンドウはref_list前に受信したすべてのリストを削除することによって縮小されます。
In U/O-mode, curr_list is inserted into the sliding window together with its generation identifier if the compressed list had a generation identifier and the sliding window does not contain a list with that generation identifier. All lists with generations older than ref_id are removed from the sliding window.
U / Oモードでは、圧縮されたリストが生成識別子を有する場合curr_listは、その世代識別子と共にスライディングウィンドウに挿入され、スライディングウィンドウが生成識別子のリストを含んでいません。 ref_idよりも古い世代とのすべてのリストは、スライディングウィンドウから削除されます。
Four encoding schemes for the compressed list are described here. The exact formats of the compressed CSRC list and compressed IP extension header list using these encoding schemes are described in sections 5.8.5-5.8.6.
圧縮されたリストのための四つの符号化方式は、ここで説明されています。これらの符号化方式を用いて圧縮CSRCリスト及び圧縮IP拡張ヘッダリストの正確な形式はセクション5.8.5-5.8.6に記載されています。
Generic scheme
一般的なスキーム
In contrast to subsequent schemes, this scheme does not rely on a reference list having been established. The entire list is sent, using table based compression for each individual item. The generic scheme is always used when establishing the context of the decompressor and may also be used at other times, as the compressor sees fit.
その後のスキームとは対照的に、この方式が確立された参照リストには依存しません。リスト全体は、個々の項目のテーブルベースの圧縮を使用して、送信されます。一般的なスキームは、デコンプレッサのコンテキストを確立するときに常に使用され、コンプレッサーが適当と考えるように、他の回でも使用することができます。
Insertion Only scheme
挿入スキームのみ
When the new list can be constructed from ref_list by adding items, a list of the added items is sent (using table based compression), along with the positions in ref_list where the new items will be inserted. An insertion bit mask indicates the insertion positions in ref_list.
新しいリスト項目を追加することによってref_listから構築することができる場合に、追加された項目のリストは、新しいアイテムが挿入されるref_listの位置とともに、（テーブルベースの圧縮を使用して）送信されます。挿入ビットマスクはref_listにおける挿入位置を示します。
Upon reception of a list compressed according to the Insertion Only scheme, curr_list is obtained by scanning the insertion bit mask from left to right. When a '0' is observed, an item is copied from the ref_list. When a '1' is observed, an item is copied from the list of added items. If a '1' is observed when the list of added items has been exhausted, an error has occurred and decompression fails: The header MUST NOT be delivered to upper layers; it should be discarded, and MUST NOT be acknowledged nor used as a reference.
挿入のみ方式に従って圧縮されたリストを受信すると、curr_listは、左から右へ挿入ビットマスクをスキャンすることによって得られます。 「0」を観察すると、アイテムがref_listからコピーされます。 「1」を観察すると、アイテムが追加されたアイテムのリストからコピーされます。追加された項目のリストが使い果たされたときに「1」が観察された場合、エラーが発生したと減圧が失敗：ヘッダは上位層に配信されてはいけません。それは破棄されなければならない、と認めてもリファレンスとして使用してはいけません。
To construct the insertion bit mask and the list of added items, the compressor MAY use the following algorithm:
挿入ビットマスクと追加された項目のリストを構築するために、圧縮機は、以下のアルゴリズムを使用することがあります。
1) An empty bit list and an empty Inserted Item list are generated as the starting point.
1）空のビットリストおよび空の挿入項目リストは、出発点として生成されます。
2) Start by considering the first item of curr_list and ref_list.
2）curr_listとref_listの最初の項目を考慮して起動します。
3) If curr_list has a different item than ref_list,
curr_listがref_list異なる項目を有する3）場合、
a set bit (1) is appended to the bit list;
the first item in curr_list (represented using table-based
item compression) is appended to the Inserted Item list;
advance to the next item of curr_list;
otherwise,
そうでなければ、
a zero bit (0) is appended to the bit list;
ゼロ・ビット（0）は、ビットリストに追加されます。
advance to the next item of curr_list; advance to the next item of ref_list.
curr_listの次の項目に進みます。 ref_listの次の項目に進みます。
4) Repeat 3) until curr_list has been exhausted.
curr_listが消耗されるまで4））3を繰り返します。
5) If the length of the bit list is less than the required bit mask length, append additional zeroes.
ビットリストの長さが必要とされるビットマスクの長さよりも小さい場合5）、追加のゼロを追加します。
Removal Only scheme
取り外しスキームのみ
This scheme can be used when curr_list can be obtained by removing some items in ref_list. The positions of the items which are in ref_list, but not in curr_list, are sent as a removal bit mask.
curr_listはref_listにいくつかの項目を除去することにより得ることができる場合にこのスキームを使用することができます。 ref_listではなく、curr_listにあるアイテムの位置は、除去ビットマスクとして送信されます。
Upon reception of the compressed list, the decompressor obtains curr_list by scanning the removal bit mask from left to right. When a '0' is observed, the next item of ref_list is copied into curr_list. When a '1' is observed, the next item of ref_list is skipped over without being copied. If a '0' is observed when ref_list has been exhausted, an error has occurred and decompression fails: The header MUST NOT be delivered to upper layers; it should be discarded, and MUST NOT be acknowledged nor used as a reference.
圧縮されたリストを受信すると、減圧装置は、左から右に除去ビットマスクをスキャンすることによってcurr_listを取得します。 「0」を観察すると、ref_listの次の項目はcurr_listにコピーされます。 「1」を観察すると、ref_listの次の項目がコピーされずにスキップされます。 ref_listが使い果たされたときに「0」が観察された場合、エラーが発生したと減圧が失敗：ヘッダは上位層に配信されてはいけません。それは破棄されなければならない、と認めてもリファレンスとして使用してはいけません。
To construct the removal bit mask and the list of added items, the compressor MAY use the following algorithm:
除去のビットマスクと追加された項目のリストを構築するために、コンプレッサーは次のアルゴリズムを使用することもできます。
1) An empty bit list is generated as the starting point.
1）空のビットリストを起点として生成されます。
2) Start by considering the first item of curr_list and ref_list.
2）curr_listとref_listの最初の項目を考慮して起動します。
3) If curr_list has a different item than ref_list,
curr_listがref_list異なる項目を有する3）場合、
a set bit (1) is appended to the bit list;
advance to the next item of ref_list;
otherwise,
そうでなければ、
a zero bit (0) is appended to the bit list;
advance to the next item of curr_list;
advance to the next item of ref_list.
4) Repeat 3) until curr_list has been exhausted.
curr_listが消耗されるまで4））3を繰り返します。
5) If the length of the bit list is less than the required bit mask length, append additional ones.
ビットリストの長さが必要とされるビットマスクの長さよりも小さい場合5）、付加的なものを追加します。
Remove Then Insert scheme
その後、削除スキームを挿入
In this scheme, curr_list is obtained by first removing items from ref_list, and then inserting items into the resulting list. A removal bit mask, an insertion bit mask, and a list of added items are sent.
この方式では、curr_list最初ref_listから項目を除去し、次いで得られたリストにアイテムを挿入することによって得られます。除去ビットマスク、挿入ビットマスク、および追加項目のリストが送信されます。
Upon reception of the compressed list, the decompressor processes the removal bit mask as in the Removal Only scheme. The resulting list is then used as the reference list when the insertion bit mask and the list of added items are processed, as in the Insertion Only scheme.
圧縮されたリストを受信すると、減圧装置は取り外しスキームのみと除去のビットマスクを処理します。挿入ビットマスクと追加項目のリストを挿入するだけの方式のように、処理されたときに得られたリストは、次いで、参照リストとして使用されます。
In CSRC list compression, each CSRC is assigned an index. In contrast, in IP extension header list compression an index is usually associated with a type of extension header. When there is more than one IP header, there is more than one list of extension headers. An index per type per list is then used.
CSRCリスト圧縮では、各CSRCは、インデックスが割り当てられます。対照的に、IP拡張ヘッダリスト圧縮インデックスは、通常、拡張ヘッダのタイプに関連付けられています。複数のIPヘッダがある場合、拡張ヘッダの複数のリストがあります。リストごとの種類ごとのインデックスは、使用されています。
The association with a type means that a new index need not always be used each time a field in an IP extension header changes. However, when a field in an extension header changes, the mapping between the index and the new value of the extension header needs to be established, except in the special handling cases defined in the following subsections.
タイプとの関連付けは、新しいインデックスは常にIP拡張ヘッダの変更の各時間フィールドを使用する必要がないことを意味します。しかし、拡張ヘッダの変更のフィールドは、インデックスと拡張ヘッダの新しい値との間のマッピングは、以下のサブセクションで定義された特別な取り扱い場合を除いて、確立される必要があります。
The next header field in an IP header or extension header changes whenever the type of the immediately following header changes, e.g., when a new extension header is inserted after it, when the immediate subsequent extension header is removed from the list, or when the order of extension headers is changed. Thus it may not be uncommon that, for a given header, the next header field changes while the remaining fields do not change.
IPヘッダまたは拡張ヘッダの次ヘッダフィールドが変更されるたびに、直ちに次のヘッダーの変更の種類、例えば、新しい拡張ヘッダが、それの後に挿入されたときに、即時後続の拡張ヘッダをリスト、またはから削除されたときときに順拡張ヘッダの変更されました。したがって、所与のヘッダは、次ヘッダフィールドの変更は、残りのフィールドは変化しないが、珍しいことではないかもしれません。
Therefore, in the case that only the next header field changes, the extension header is considered to be unchanged and rules for special treatment of the change in the next header field are defined below.
したがって、その唯一の次ヘッダフィールドが変更場合、拡張ヘッダは不変であるとみなされ、次のヘッダフィールドの変更の特別な処理のための規則を以下に定義します。
All communicated uncompressed extension header items indicate their own type in their Next Header field. Note that the rules below explain how to treat the Next Header fields while showing the conceptual reference list as an exact recreation of the original uncompressed extension header list.
全て伝え圧縮されていない拡張ヘッダ項目は、その次ヘッダフィールドに自分のタイプを示します。以下の規則は、元の圧縮されていない拡張ヘッダリストの正確なレクリエーションとして概念的な参照リストを示しながら次ヘッダフィールドを処理する方法を説明することに留意されたいです。
a) When a subsequent extension header is removed from the list, the new value of the next header field is obtained from the reference extension header list. For example, assume that the reference header list (ref_list) consists of headers A, B and C (ref_ext_hdr A, B, C), and the current extension header list (curr_list) only consists of extension headers A and C (curr_ext_hdr A, C). The order and value of the next header fields of these extension headers are as follows.
その後の拡張ヘッダがリストから削除されると、A）、次ヘッダフィールドの新しい値は、基準拡張ヘッダリストから得られます。例えば、基準ヘッダリスト（ref_list）がヘッダーA、B及びC（ref_ext_hdr A、B、C）からなると仮定し、現在の拡張ヘッダリスト（curr_listは）のみ拡張ヘッダA及びC（curr_ext_hdr Aから成りC）。次のように、これらの拡張ヘッダの次ヘッダフィールドの順序および値です。
ref_list:
+--------+-----+ +--------+-----+ +--------+-----+
| type B | | | type C | | | type D | |
+--------+ | +--------+ | +--------+ |
| | | | | |
+--------------+ +--------------+ +--------------+
ref_ext_hdr A ref_ext_hdr B ref_ext_hdr C
curr_list:
+--------+-----+ +--------+-----+
| type C | | | type D | |
+--------+ | +--------+ |
| | | |
+--------------+ +--------------+
curr_ext_hdr A curr_ext_hdr C
Comparing the curr_ext_hdr A in curr_list and the ref_ext_hdr A in ref_list, the value of next header field is changed from "type B" to "type C" because of the removal of extension header B. The new value of the next header field in curr_ext_hdr A, i.e., "type C", does not need to be sent to the decompressor. Instead, it is retrieved from the next header field of the removed ref_ext_hdr B.
curr_listとref_listでref_ext_hdr Aのcurr_ext_hdr Aと比較すると、次のヘッダフィールドの値が「タイプC」を「B型」に変更されるので、拡張ヘッダBの除去curr_ext_hdrの次ヘッダフィールドの新しい値、すなわち、「タイプC」、解凍器に送信する必要はありません。その代わりに、それを除去ref_ext_hdr Bの次ヘッダフィールドから取得され
b) When a new extension header is inserted after an existing extension header, the next header field in the communicated item will carry the type of itself, rather than the type of the header that follows. For example, assume that the reference header list (ref_list) consists of headers A and C (ref_ext_hdr A, C), and the current header list (curr_list) consists of headers A, B and C (curr_ext_hdr A, B, C). The order and the value of the next header fields of these extension headers are as follows.
新しい拡張ヘッダが既存の拡張ヘッダの後に挿入されると、B）、通信さアイテムの次のヘッダフィールドは、それ自体の種類ではなく、次のヘッダのタイプを運ぶであろう。例えば、基準ヘッダリスト（ref_list）がヘッダーAとC（ref_ext_hdr A、C）、および現在のヘッダリスト（curr_list）からなると仮定すると、ヘッダA、B及びC（curr_ext_hdr A、B、C）からなります。次のように順序およびこれらの拡張ヘッダの次ヘッダフィールドの値です。
ref_list:
+--------+-----+ +--------+-----+
| type C | | | type D | |
+--------+ | +--------+ |
| | | |
+--------------+ +--------------+
ref_ext_hdr A ref_ext_hdr C
curr_list:
+--------+-----+ +--------+-----+ +--------+-----+
| type B | | | type C | | | type D | |
+--------+ | +--------+ | +--------+ |
| | | | | |
+--------------+ +--------------+ +--------------+
curr_ext_hdr A curr_ext_hdr B curr_ext_hdr C
Comparing the curr_list and the ref_list, the value of the next header field in extension header A is changed from "type C" to "type B".
curr_listとref_listを比較すると、拡張ヘッダAの次のヘッダフィールドの値は、「タイプC」を「タイプB」に変更されます。
The uncompressed curr_ext_hdr B is carried in the compressed header list. However, it carries "type B" instead of "type C" in its next header field. When the decompressor inserts a new header after curr_ext_hdr A, the next header field of A is taken from the new header, and the next header field of the new header is taken from ref_ext_hdr A.
非圧縮curr_ext_hdr Bは、圧縮されたヘッダリストに搬送されます。しかし、代わりに次のヘッダフィールド内の「タイプC」の「タイプB」運びます。減圧装置がcurr_ext_hdr Aの後、新たなヘッダを挿入すると、Aの次ヘッダフィールドは、新しいヘッダから取り出され、そして新たなヘッダの次ヘッダフィールドはref_ext_hdr Aから取られ
c) Some headers whose compression is defined in this document do not contain Next Header fields or do not have their Next Header field in the standard position (first octet of the header). The GRE and ESP headers are such headers. When sent as uncompressed items in lists, these headers are modified so that they do have a Next Header field as their first octet (see 5.8.4.3 and 5.8.4.4). This is necessary to enable the decompressor to decode the item.
C）その圧縮本書で定義されているいくつかのヘッダが次ヘッダフィールドを含まない又は基準位置での次ヘッダフィールド（ヘッダの最初のオクテット）を持っていません。 GREとESPヘッダは、そのようなヘッダです。リストで圧縮されていない項目として送信する場合、これらのヘッダは、彼らは彼らの最初のオクテットとして次ヘッダフィールドを持っているように改変されている（5.8.4.3と5.8.4.4を参照）。これは、アイテムを復号するために減圧装置を有効にする必要があります。
The sequence number field in the AH [AH] contains a monotonically increasing counter value for a security association. Therefore, when comparing curr_list with ref_list, if the sequence number in AH changes and SPI field does not change, the AH is not considered as changed.
AH [AH]のシーケンス番号フィールドは、セキュリティアソシエーションのために単調に増加するカウンタ値を含みます。 AHの変更及びSPIフィールドのシーケンス番号が変化しない場合、ref_listとcurr_listを比較するときに変更したがって、AHは考慮されていません。
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のシーケンス番号を再構築するために、線形外挿を適用します。
Otherwise, a compressed sequence number is included in the IPX compression field in an Extension 3 of an UOR-2 header.
そうでない場合には、圧縮されたシーケンス番号はUOR-2ヘッダの拡張3にIPX圧縮分野に含まれます。
The authentication data field in AH changes from packet to packet and is sent as-is. If the uncompressed AH is sent, the authentication data field is sent inside the uncompressed AH; otherwise, it is sent after the compressed IP/UDP/RTP and IPv6 extension headers and before the payload. See beginning of section 5.7.
AHでの認証データフィールドは、パケット毎に変更し、そのまま送信されます。圧縮されていないAHが送信されると、認証データフィールドは圧縮されていないAHの内側に送信されます。それ以外の場合は、圧縮されたIP / UDP / RTPとIPv6拡張ヘッダーの後とペイロードの前に送信されます。セクション5.7の始まりを参照してください。
Note: The payload length field of the AH uses a different notion of length than other IPv6 extension headers.
注：AHのペイロード長フィールドは、他のIPv6拡張ヘッダよりも長さの異なる概念を使用します。
When the Encapsulating Security Payload Header (ESP) [ESP] is present and an encryption algorithm other than NULL is being used, the UDP and RTP headers are both encrypted and cannot be compressed. The ESP header thus ends the compressible header chain. The ROHC ESP profile defined in section 5.12 MAY be used for the stream in this case.
カプセル化セキュリティペイロードヘッダ（ESP）は[ESP]存在しNULL以外の暗号化アルゴリズムが使用されている場合、UDP及びRTPヘッダが両方暗号化され、圧縮することができません。 ESPヘッダは、このように圧縮ヘッダチェーンを終了します。セクション5.12で定義されたROHC ESPプロファイルは、この場合のストリームのために使用されるかもしれません。
A special case is when the NULL encryption algorithm is used. This is the case when the ESP header is used for authentication only, and not for encryption. The payload is not encrypted by the NULL encryption algorithm, so compression of the rest of the header chain is possible. The rest of this section describes compression of the ESP header when the NULL encryption algorithm is used with ESP.
NULL暗号化アルゴリズムを使用する場合、特殊なケースがあります。これは、ESPヘッダのみではなく、暗号化の認証に使用される場合です。ペイロードはNULL暗号化アルゴリズムによって暗号化されたので、ヘッダ鎖の残りの圧縮が可能であるれていません。 NULL暗号化アルゴリズムがESPで使用される場合、このセクションの残りの部分は、ESPヘッダの圧縮を記載します。
It is not possible to determine whether NULL encryption is used by inspecting a header in the stream, this information is present only at the encryption endpoints. However, a compressor may attempt compression under the assumption that the NULL encryption algorithm is being used, and later abort compression when the assumption proves to be false.
これは、NULL暗号化がストリームにヘッダを調べることによって使用されているかどうかを決定することができない、この情報は、暗号化エンドポイントに存在します。しかし、コンプレッサーは、NULL暗号化アルゴリズムが使用されているという仮定の下での圧縮を試みることができ、および仮定が偽であることが分かったときに、後で圧縮を中止します。
The compressor may, for example, inspect the Next Header fields and the header fields supposed to be static in subsequent headers in order to determine if NULL encryption is being used. If these change unpredictably, an encryption algorithm other than NULL is probably being used and compression of subsequent headers SHOULD be aborted. Compression of the stream is then either discontinued, or a profile that compresses only up to the ESP header may be used (see 5.12). While attempting to compress the header, the compressor should use the SPI of the ESP header together with the destination IP address as the defining fields for determining which packets belong to the stream.
圧縮機は、例えば、次のヘッダフィールドとNULL暗号化が使用されているかどうかを決定するために、後続のヘッダに静的であると仮定ヘッダフィールドを検査することができます。これらは予測できない変更した場合は、NULL以外の暗号化アルゴリズムは、おそらく使用されていると、後続のヘッダーの圧縮が中止されるべきです。ストリームの圧縮は、（5.12を参照）をいずれか中止するか、またはだけESPヘッダまで圧縮プロファイルが使用されてもよいです。ヘッダを圧縮しようとしたとき、圧縮機は、パケットが流れに属しているかを決定するための定義フィールドとして宛先IPアドレスと共にESPヘッダのSPIを使用する必要があります。
In the ESP header [ESP, section 2], the fields that can be compressed are the SPI, the sequence number, the Next Header, and the padding bytes if they are in the standard format defined in [ESP]. (As always, the decompressor reinserts these fields based on the information in the context. Care must be taken to correctly reinsert all the information as the Authentication Data must be verified over the exact same information it was computed over.)
彼らは[ESP]で定義された標準フォーマットである場合、ESPヘッダ[ESP、セクション2]においては、圧縮可能なフィールドは、SPI、シーケンス番号、次ヘッダ、パディングバイトです。 （いつものように、デコンプレッサは、コンテキスト内の情報に基づいて、これらのフィールドを再挿入。ケアが正しく認証データは、それが終わって計算された正確な同じ情報を介して確認する必要がありますように、すべての情報を再挿入するために注意する必要があります。）
ESP header [ESP, section 2]:
ESPヘッダ[ESP、セクション2]：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data (variable) |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data |
+ (variable length, but assumed to be 12 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SPI: Static. If it changes, it needs to be reestablished.
SPI：静的。それが変化した場合、それが再確立する必要があります。
Sequence Number: Not sent when the offset from the sequence number of the compressed header is constant. When the offset is not constant, the sequence number may be compressed by sending LSBs. See 5.8.4.
配列番号：圧縮ヘッダのシーケンス番号からのオフセット一定であるとき送信されません。オフセットが一定でない場合、シーケンス番号はLSBを送信することによって圧縮することができます。 5.8.4を参照してください。
Payload Data: This is where subsequent headers are to be found. Parsed according to the Next Header field.
ペイロードデータ：以降のヘッダが見られる場所です。次ヘッダフィールドに基づいて解析されました。
Padding: The padding octets are assumed to be as defined in [ESP], i.e., to take the values 1, 2, ..., k, where k = Pad Length. If the padding in the static context has this pattern, padding in compressed headers is assumed to have this pattern as well and is removed. If padding in the static context does not have this pattern, the padding is not removed.
パディング：K =パッド長[ESP]、すなわち、値1を取るために、2、...、K、で定義されるようにパディングオクテットがあると仮定されます。静的文脈におけるパディングは、このパターンを持っている場合、圧縮ヘッダ内のパディングは、同様に、このパターンを持っていると仮定され、除去されます。静的コンテキスト内のパディングは、このパターンを持っていない場合、パディングは削除されません。
Pad Length: Dynamic. Always sent. 14th octet from end of packet.
パッドの長さ：ダイナミック。常に送信。パケットの終わりから14番目のオクテット。
Next Header: Static. 13th octet from end of packet.
次ヘッダ：静的。パケットの終わりから13番目のオクテット。
Authentication Data: Can have variable length, but when compression of NULL-encryption ESP header is attempted, it is assumed to have length 12 octets.
認証データ：変数の長さを持つことができますが、NULL暗号化ESPヘッダの圧縮が試みられたとき、長さ12個のオクテットを有するものとします。
The sequence number in ESP has the same behavior as the sequence number field in AH. When it increases linearly, it can be compressed to zero bits. When it does not increase linearly, a compressed sequence number is included in the IPX compression field in an Extension 3 of an UOR-2 header.
ESPのシーケンス番号は、AHのシーケンス番号フィールドと同じ動作をします。それは直線的に増加する場合、それはゼロビットに圧縮することができます。それは直線的に増加しない場合、圧縮されたシーケンス番号はUOR-2ヘッダの拡張3にIPX圧縮分野に含まれます。
The information which is part of an uncompressed item of a compressed list is the Next Header field, followed by the SPI and the Sequence Number. Padding, Pad Length, Next Header, and Authentication Data are sent as-is at the end of the packet. This means that the Next Header occurs in two places.
圧縮されたリストの圧縮されていない項目の一部である情報は、SPIとシーケンス番号に続いて、次のヘッダフィールドです。パディング、パディング長、次ヘッダ、及び認証データは、パケットの最後にそのまま送信されます。これは、次のヘッダーが2つの場所で発生していることを意味します。
Uncompressed ESP list item:
非圧縮ESPリスト項目：
+---+---+---+---+---+---+---+---+
| Next Header ! 1 octet (see section 5.8.4.1)
+---+---+---+---+---+---+---+---+
/ SPI / 4 octets
+---+---+---+---+---+---+---+---+
/ Sequence Number / 4 octets
+---+---+---+---+---+---+---+---+
When sending Uncompressed ESP list items, all ESP fields near the the end of the packet are left untouched (Padding, Pad Length, Next Header, Authentication Data).
非圧縮ESPのリスト項目を送信する場合、パケットの終わり近くに、すべてのESPフィールドは（パディング、パディング長、次ヘッダ、認証データ）放置されています。
A compressed item consists of a compressed sequence number. When an item is compressed, Padding (if it follows the 1, 2, ..., k pattern) and Next Header are removed near the end of the packet. Authentication Data and Pad Length remain as-is near the end of the packet.
圧縮されたアイテムは、圧縮されたシーケンス番号から成ります。アイテムが圧縮されると、パディング（それは1以下ならば、2、...、k個のパターン）、次のヘッダは、パケットの終わり近くに除去されます。認証データとパッドの長さはそのままで、パケットの終わり近くに残っています。
The GRE header is a set of flags, followed by a mandatory Protocol Type and optional parts as indicated by the flags.
GREヘッダは、フラグによって示されるように必須のプロトコルタイプおよび任意の部品に続くフラグのセットです。
The sequence number field in the GRE header contains a counter value for a GRE tunnel. Therefore, when comparing curr_list with ref_list, if the sequence number in GRE changes, the GRE is not considered as changed.
GREヘッダ内のシーケンス番号フィールドは、GREトンネルのカウンタ値を含みます。 ref_listとcurr_listを比較した場合GREにおけるシーケンス番号が変更された場合に変更したがって、、、GREは考慮されていません。
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ヘッダのシーケンス番号を再構築するために、線形外挿を適用します。
Otherwise, a compressed sequence number is included in the IPX compression field in an Extension 3 of an UOR-2 header.
そうでない場合には、圧縮されたシーケンス番号はUOR-2ヘッダの拡張3にIPX圧縮分野に含まれます。
The checksum data field in GRE, if present, changes from packet to packet and is sent as-is. If the uncompressed GRE header is sent, the checksum data field is sent inside the uncompressed GRE header; otherwise, if present, it is sent after the compressed IP/UDP/RTP and IPv6 extension headers and before the payload. See beginning of section 5.7.
GREのチェックサム・データ・フィールドは、存在する場合、パケットからの変更はパケットにかつそのまま送られます。圧縮されていないGREヘッダが送信される場合、チェックサム・データ・フィールドは圧縮されていないGREヘッダ内部送られます。そうでない場合は、存在する場合、それは、圧縮されたIP / UDP / RTPとIPv6拡張ヘッダーの後とペイロードの前に送信されます。セクション5.7の始まりを参照してください。
In order to allow simple parsing of lists of items, an uncompressed GRE header sent as an item in a list is modified from the original GRE header in the following manner: 1) the 16-bit Protocol Type field that encodes the type of the subsequent header using Ether types (see Ether types section in [ASSIGNED]) is removed. 2) A one-octet Next Header field is inserted as the first octet of the header. The value of the Next Header field corresponds to GRE (this value is 47 according to the Assigned Internet Protocol Number section of [ASSIGNED]) when the uncompressed item is to be inserted in a list, and to the type of the subsequent header when the uncompressed item is in a Generic list. Note that this implies that only GRE headers with Ether types that correspond to an IP protocol number can be compressed.
アイテムのリストの単純な解析を可能にするために、リスト内の項目として送信非圧縮GREヘッダーは次のように元のGREヘッダーから変更されている：1）以降のタイプを符号化する16ビットのプロトコルタイプフィールドイーサタイプを使用してヘッダが除去される（[ASSIGNED]中のエーテルタイプの項を参照します）。 2）1オクテット次ヘッダフィールドは、ヘッダの最初のオクテットとして挿入されます。圧縮されていない項目がリスト内、および場合、後続ヘッダの種類に挿入されるときに次ヘッダーフィールドの値（この値は[ASSIGNED]に割り当てられたインターネットプロトコル番号のセクションによれば47である）に対応するGRE圧縮されていない項目は、一般的なリストです。これはIPプロトコル番号に対応するイーサタイプでのみGREヘッダを圧縮することができることを意味することに留意されたいです。
Uncompressed GRE list item:
非圧縮GREリスト項目：
+---+---+---+---+---+---+---+---+
| Next Header ! 1 octet (see section 5.8.4.1)
+---+---+---+---+---+---+---+---+
/ C | | K | S | | Ver | 1 octet
+---+---+---+---+---+---+---+---+
/ Checksum / 2 octets, if C=1
+---+---+---+---+---+---+---+---+
/ Key / 4 octets, if K=1
+---+---+---+---+---+---+---+---+
/ Sequence Number / 4 octets, if S=1
+---+---+---+---+---+---+---+---+
The bits left blank in the second octet are set to zero when sending and ignored when received.
第2オクテットでブランクのままのビットは送信時にゼロに設定し、受信時に無視されています。
The fields Reserved0 and Reserved1 of the GRE header [GRE2] must be all zeroes; otherwise, the packet cannot be compressed by this profile.
フィールドReserved0とGREヘッダー[GRE2]のReserved1はすべてゼロでなければなりません。そうでない場合、パケットは、このプロファイルによって圧縮することができません。
In Extension 3 (section 5.7.5), there is a field called IP extension header(s). This section describes the format of that field.
拡張3（セクション5.7.5）において、IP拡張ヘッダ（S）と呼ばれるフィールドがあります。このセクションでは、そのフィールドのフォーマットを記述します。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| CL | ASeq| ESeq| Gseq| res | 1 octet
+-----+-----+-----+-----+-----+-----+-----+-----+
: compressed AH Seq Number, 1 or 4 octets : if ASeq = 1
----- ----- ----- ----- ----- ----- ----- -----
: compressed ESP Seq Number, 1 or 4 octets : if Eseq = 1
----- ----- ----- ----- ----- ----- ----- -----
: compressed GRE Seq Number, 1 or 4 octets : if Gseq = 1
----- ----- ----- ----- ----- ----- ----- -----
: compressed header list, variable length : if CL = 1
----- ----- ----- ----- ----- ----- ----- -----
ASeq: indicates presence of compressed AH Seq Number ESeq: indicates presence of compressed ESP Seq Number GSeq: indicates presence of compressed GRE Seq Number CL: indicates presence of compressed header list res: reserved; set to zero when sending, ignored when received
ASeq：圧縮AH配列番号ESEQの存在を示す：圧縮ESP配列番号GSEQの存在を示す：圧縮GRE配列番号CLの存在を示す：圧縮ヘッダリストRESの存在を示す：予約済み。受信時に無視され、送信時にゼロに設定
When Aseq, Eseq, or Gseq is set, the corresponding header item (AH, ESP, or GRE header) is compressed. When not set, the corresponding header item is sent uncompressed or is not present.
Aseq、ESEQ、又はGSEQが設定されている場合、対応するヘッダ項目（AH、ESP、またはGREヘッダ）が圧縮されます。設定されていない場合、対応するヘッダ項目は、圧縮されていない送信または存在しません。
The format of compressed AH, ESP and GRE Sequence Numbers can each be either of the following:
圧縮AH、ESPとGREシーケンス番号の形式は、それぞれ次のいずれかとすることができます。
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | LSB of sequence number | | 1 | |
+---+---+---+---+---+---+---+---+ +---+ +
| |
+ LSB of sequence number +
| |
+ +
| |
+---+---+---+---+---+---+---+---+
The format of the compressed header list field is described in section 5.8.6.
圧縮されたヘッダリストフィールドのフォーマットは、セクション5.8.6に記載されています。
The Compressed CSRC List field in the RTP header part of an Extension 3 (section 5.7.5) is as in section 5.8.6.
拡張3（セクション5.7.5）のRTPヘッダ部分に圧縮CSRCリストフィールドは、セクション5.8.6のようになります。
This section describes the format of compressed lists. The format is the same for CSRC lists and header lists. In CSRC lists, the items are CSRC identifiers; in header lists, they are uncompressed or compressed headers, as described in 5.8.4.2-4.
このセクションでは、圧縮されたリストの形式について説明します。フォーマットは、CSRCリストとヘッダリストについても同様です。 CSRCリストでは、項目は、CSRCの識別子です。 5.8.4.2-4に記載されているように、ヘッダリストに、それらは、非圧縮又は圧縮ヘッダです。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| ET=0 |GP |PS | CC = m |
+---+---+---+---+---+---+---+---+
: gen_id : 1 octet, if GP = 1
+---+---+---+---+---+---+---+---+
| XI 1, ..., XI m | m octets, or m * 4 bits
/ --- --- --- ---/
| : Padding : if PS = 0 and m is odd
+---+---+---+---+---+---+---+---+
| |
/ item 1, ..., item n / variable
| |
+---+---+---+---+---+---+---+---+
ET: Encoding type is zero.
ET：エンコーディングタイプはゼロです。
PS: Indicates size of XI fields: PS = 0 indicates 4-bit XI fields; PS = 1 indicates 8-bit XI fields.
PS：XIフィールドのサイズを示し：= 0 PSは、4ビットのXIフィールドを示します。 PS = 1は、8ビットXIフィールドを示しています。
GP: Indicates presence of gen_id field.
GPは：GEN_IDフィールドが存在することを示します。
CC: CSRC counter from original RTP header.
CC：元のRTPヘッダからCSRCカウンタ。
gen_id: Identifier for a sequence of identical lists. It is present in U/O-mode when the compressor decides that it may use this list as a future reference list.
GEN_ID：同じリストのシーケンスのための識別子。圧縮機は、それが将来の参照のリストとしてこのリストを使用してもよいと判断した場合には、U / Oモードで存在します。
XI 1, ..., XI m: m XI items. The format of an XI item is as follows:
XI 1、...、XIのM：MのXIアイテム。次のようにXI項目の形式は次のとおりです。
+---+---+---+---+
PS = 0: | X | Index |
+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
PS = 1: | X | Index |
+---+---+---+---+---+---+---+---+
X = 1 indicates that the item corresponding to the Index is sent in the item 0, ..., item n list. X = 0 indicates that the item corresponding to the Index is not sent.
X = 1のインデックスに対応する項目が項目0、...、N項目リストに送信されることを示しています。 X = 0のインデックスに対応する項目が送信されていないことを示しています。
When 4-bit XI items are used and m > 1, the XI items are placed in octets in the following manner:
4ビットのXI項目が使用され、mは> 1、XI項目は次のようにオクテットに置かれたとき。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| XI k | XI k + 1 |
+---+---+---+---+---+---+---+---+
Padding: A 4-bit padding field is present when PS = 0 and m is odd. The Padding field is set to zero when sending and ignored when receiving.
パディング：PS = 0、mが奇数の場合、4ビットのパディングフィールドが存在します。パディングフィールドは、送信時にゼロに設定し、受信時に無視されます。
Item 1, ..., item n:
アイテム1、...、項目nの：
Each item corresponds to an XI with X = 1 in XI 1, ..., XI m.
各項目は、X = XI 1 1、...、XI mにXIに相当します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| ET=1 |GP |PS | XI 1 |
+---+---+---+---+---+---+---+---+
: gen_id : 1 octet, if GP = 1
+---+---+---+---+---+---+---+---+
| ref_id |
+---+---+---+---+---+---+---+---+
/ insertion bit mask / 1-2 octets
+---+---+---+---+---+---+---+---+
| XI list | k octets, or (k - 1) * 4 bits
/ --- --- --- ---/
| : Padding : if PS = 0 and k is even
+---+---+---+---+---+---+---+---+
| |
/ item 1, ..., item n / variable
| |
+---+---+---+---+---+---+---+---+
Unless explicitly stated otherwise, fields have the same meaning and values as for encoding type 0.
特に明記しない限り、フィールドは、符号化タイプ0と同じ意味と価値観を持っています。
ET: Encoding type is one (1).
ET：エンコード・タイプが1である（1）。
XI 1: When PS = 0, the first 4-bit XI item is placed here. When PS = 1, the field is set to zero when sending, and ignored when receiving.
XI 1：PS = 0、最初の4ビットのXIアイテムがここに配置されています。場合PS = 1送信時に、フィールドがゼロに設定され、受信時に無視します。
ref_id: The identifier of the reference CSRC list used when the list was compressed. It is the 8 least significant bits of the RTP Sequence Number in R-mode and gen_id (see section 5.8.2) in U/O-mode.
ref_id：リストが圧縮されたときに使用される参照CSRCリストの識別子。それはRモードとGEN_IDでRTPシーケンス番号の8つの最下位ビットであるU / Oモードで（セクション5.8.2を参照）。
insertion bit mask: Bit mask indicating the positions where new items are to be inserted. See Insertion Only scheme in section 5.8.3. The bit mask can have either of the following two formats:
挿入ビットマスク：新しいアイテムが挿入される位置を示すビットマスク。セクション5.8.3で挿入スキームのみを参照してください。ビットマスクは、次の2つの形式のいずれかを持つことができます。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 7-bit mask | bit 1 is the first bit
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| 1 | | bit 1 is the first bit
+---+ 15-bit mask +
| | bit 7 is the last bit
+---+---+---+---+---+---+---+---+
XI list: XI fields for items to be inserted. When the insertion bit mask has k ones, the total number of XI fields is k. When PS = 1, all XI fields are in the XI list. When PS = 0, the first XI field is in the XI 1 field, and the remaining k - 1 XI fields are in the XI list.
XIリスト：挿入する項目のためのXI分野。挿入ビットマスクがKのものを持っている場合、XIフィールドの合計数がkです。 PS = 1は、すべてのXIフィールドがXIリストにある場合。 PS = 0、第XIフィールドがXI 1フィールドであり、残りのK場合 - 1つのXIフィールドがXIリストです。
Padding: Present when PS = 0 and k is even.
パディング：現在のPS = 0とkが偶数です。
item 1, ..., item n: One item for each XI field with the X bit set.
アイテム1、...、アイテムn：Xビットが設定された各XIフィールドの1つの項目。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| ET=2 |GP |res| Count |
+---+---+---+---+---+---+---+---+
: gen_id : 1 octet, if GP = 1
+---+---+---+---+---+---+---+---+
| ref_id |
+---+---+---+---+---+---+---+---+
/ removal bit mask / 1-2 octets
+---+---+---+---+---+---+---+---+
Unless explicitly stated otherwise, fields have the same meaning and values as in section 5.8.5.2.
特に明記しない限り、フィールドはセクション5.8.5.2と同じ意味と値を持っています。
ET: Encoding type is 2.
ET：エンコーディングタイプは2です。
res: Reserved. Set to zero when sending, ignored when received.
Res：予約。受信時に無視され、送信時にゼロに設定してください。
Count: Number of elements in ref_list.
カウント：ref_list内の要素の数を。
removal bit mask: Indicates the elements in ref_list to be removed in order to obtain the current list. See section 5.8.3. The removal bit mask has the same format as the insertion bit mask of section 5.8.6.3.
除去ビットマスクは：現在のリストを得るために除去するref_listの要素を示します。セクション5.8.3を参照してください。除去のビットマスクは、セクション5.8.6.3の挿入ビットマスクと同じフォーマットを有します。
See section 5.8.3 for a description of the Remove then insert
scheme.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| ET=3 |GP |PS | XI 1 |
+---+---+---+---+---+---+---+---+
: gen_id : 1 octet, if GP = 1
+---+---+---+---+---+---+---+---+
| ref_id |
+---+---+---+---+---+---+---+---+
/ removal bit mask / 1-2 octets
+---+---+---+---+---+---+---+---+
/ insertion bit mask / 1-2 octets
+---+---+---+---+---+---+---+---+
| XI list | k octets, or (k - 1) * 4 bits
/ --- --- --- ---/
| : Padding : if PS = 0 and k is even
+---+---+---+---+---+---+---+---+
| |
/ item 1, ..., item n / variable
| |
+---+---+---+---+---+---+---+---+
The fields in this header have the same meaning and formats as in section 5.8.5.2, except when explicitly stated otherwise below.
このヘッダのフィールドは、明示的に別段の下記の場合を除いて、セクション5.8.5.2と同じ意味及びフォーマットを有します。
ET: Encoding type is 3.
ET：エンコーディングタイプは3です。
removal bit mask: See section 5.8.6.3.
除去のビットマスク：セクション5.8.6.3を参照してください。
All fields of extension headers are CRC-STATIC, with the following exceptions which are CRC-DYNAMIC.
拡張ヘッダのすべてのフィールドは、CRC-DYNAMICをされている次の例外を除いて、CRC-STATICです。
1) Entire AH header. 2) Entire ESP header. 3) Sequence number in GRE, Checksum in GRE
1）全体AHヘッダ。 2）全体ESPヘッダ。 GRE、GREチェックサム3）シーケンス番号
This chapter describes how to calculate the CRCs used in packet headers defined in this document. (Note that another type of CRC is defined for reconstructed units in section 5.2.5.)
この章では、この文書で定義されたパケットのヘッダに使用されるCRCを計算する方法について説明します。 （CRCの別のタイプは、セクション5.2.5で再構成されたユニットのために定義されていることに注意してください。）
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. For purposes of computing the CRC, the CRC field in the header is set to zero.
IR及びIR-DYNパケット内のCRCは、ペイロードを除くCIDまたは任意のアドオンCIDオクテットを含む、全体IRまたはIR-DYNパケットにわたって計算されます。 CRCを計算する目的のために、ヘッダ内のCRCフィールドはゼロに設定されます。
The initial content of the CRC register is to be preset to all 1's.
CRCレジスタの初期の内容は、すべて1年代にプリセットされます。
The CRC polynomial to be used for the 8-bit CRC is:
8ビットのCRCに使用されるCRC多項式です。
C(x) = 1 + x + x^2 + x^8
C（x）= 1 + X + X ^ 2 + X ^ 8
The CRC in compressed headers is calculated over all octets of the entire original header, before compression, in the following manner.
圧縮ヘッダ内のCRCは、以下のように、圧縮前に、全体のオリジナルヘッダの全てのオクテットにわたって計算されます。
The octets of the header are classified as either CRC-STATIC or CRC-DYNAMIC, and the CRC is calculated over:
ヘッダのオクテットは、CRC-STATICまたはCRC-DYNAMICのいずれかとして分類され、そしてCRCをかけて計算されます。
1) the concatenated CRC-STATIC octets of the original header, placed in the same order as they appear in the original header, followed by
1）それらは元のヘッダーに現れるのと同じ順序で配置され、元のヘッダの連結CRC-STATICオクテット、続いて
2) the concatenated CRC-DYNAMIC octets of the original header, placed in the same order as they appear in the original header.
2）それらは元のヘッダーに現れるのと同じ順序で配置され、元のヘッダの連結CRC-DYNAMICオクテット。
The intention is that the state of the CRC computation after 1) will be saved. As long as the CRC-STATIC octets do not change, the CRC calculation will then only need to process the CRC-DYNAMIC octets.
その意図は、1後のCRC計算の状態）が保存されるということです。限りCRC-STATICオクテットが変化しないように、CRCの計算は、唯一のCRC-DYNAMICオクテットを処理する必要があります。
In a typical RTP/UDP/IPv4 header, 25 octets are CRC-STATIC and 15 are CRC-DYNAMIC. In a typical RTP/UDP/IPv6 header, 49 octets are CRC-STATIC and 11 are CRC-DYNAMIC. This technique will thus reduce the computational complexity of the CRC calculation by roughly 60% for RTP/UDP/IPv4 and by roughly 80% for RTP/UDP/IPv6.
典型的なRTP / UDP / IPv4ヘッダでは、25個のオクテットは、CRC-STATICであり、図15は、CRC-DYNAMICです。典型的なRTP / UDP / IPv6ヘッダーは、49個のオクテットはCRC-STATICであり、図11は、CRC-DYNAMICです。この技術は、このようにRTP / UDP / IPv4のおおよそ60％及びRTP / UDP / IPv6の約80％だけCRC演算の計算の複雑さを低減します。
Note: Whenever the CRC-STATIC fields change, the new saved CRC state after 1) is compared with the old state. If the states are identical, the CRC cannot catch the error consisting in the decompressor not having updated the static context. In U/O-mode the compressor SHOULD then for a while use packet types with another CRC length, for which there is a difference in CRC state, to ensure error detection.
注意：CRC-STATICフィールドを変更するたびに、1の後に新たに保存されたCRC状態は）古い状態と比較されます。状態が同一である場合、CRCは、静的コンテキストを更新したではない解凍器で構成されるエラーをキャッチすることはできません。 U / Oモードでは、圧縮機は、次に、CRCの状態の違いが存在するために別のCRCの長さを有する一方、使用パケットタイプ、のエラー検出を確実にするべきです。
The initial content of the CRC register is preset to all 1's.
CRCレジスタの初期の内容は、すべて1に設定されています。
The polynomial to be used for the 3 bit CRC is:
3ビットのCRCに使用される多項式です。
C(x) = 1 + x + x^3
C（x）= 1 + X + X ^ 3
The polynomial to be used for the 7 bit CRC is:
7ビットのCRCのために使用される多項式です。
C(x) = 1 + x + x^2 + x^3 + x^6 + x^7
C（x）= 1 + X + X ^ 2 + X ^ 3 + X ^ 6 + X ^ 7
The CRC in compressed headers is calculated over the entire original header, before compression.
圧縮ヘッダ内のCRCは圧縮前、全体オリジナルヘッダに対して計算されます。
In ROHC, compression has not been defined for all kinds of IP headers. Profile 0x0000 provides a way to send IP packets without compressing them. This can be used for IP fragments, RTCP packets, and in general for any packet for which compression of the header has not been defined, is not possible due to resource constraints, or is not desirable for some other reason.
ROHCでは、圧縮は、IPヘッダのすべての種類のために定義されていません。プロファイル0000は、それらを圧縮せずにIPパケットを送信する方法を提供します。これは、ヘッダの圧縮が定義されていない任意のパケットのIPフラグメント、RTCPパケットのため、一般的に使用することができ、原因リソースの制約することは不可能である、またはいくつかの他の理由のために望ましくありません。
After initialization, the only overhead for sending packets using Profile 0x0000 is the size of the CID. When uncompressed packets are frequent, Profile 0x0000 should be associated with a CID with size zero or one octet. There is no need to associate Profile 0x0000 with more than one CID.
初期化後、プロファイル0000を使用してパケットを送信するための唯一のオーバーヘッドは、CIDのサイズです。圧縮されていないパケットが頻繁である場合、プロファイル0000は、サイズ0または1オクテットとCIDと関連付けられなければなりません。複数のCIDとプロファイル0000を関連付ける必要はありません。
The initialization packet (IR packet) for Profile 0x0000 has the following format:
プロファイル0000の初期化パケット（IRパケット）は、以下のフォーマットを有します。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 |res|
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
: : (optional)
/ IP packet / variable length
: :
--- --- --- --- --- --- --- ---
res: Always zero.
RES：常にゼロ。
Profile: 0.
プロフィール：0。
CRC: 8-bit CRC, computed using the polynomial of section 5.9.1. The CRC covers the first octet of the IR packet through the Profile octet of the IR packet, i.e., it does not cover the CRC itself or the IP packet.
CRC：8ビットCRCは、セクション5.9.1の多項式を用いて計算しました。 CRCは、IRパケットのプロファイルオクテットを介してIRパケットの最初のオクテットをカバーする、すなわち、それはCRC自体又はIPパケットをカバーしていません。
IP packet: An uncompressed IP packet may be included in the IR packet. The decompressor determines if the IP packet is present by considering the length of the IR packet.
IPパケット：非圧縮IPパケットがIRパケットに含まれていてもよいです。 IPパケットがIRパケットの長さを考慮して存在する場合には、デコンプレッサを判定する。
A Normal packet is a normal IP packet plus CID information. When the channel uses small CIDs, and profile 0x0000 is associated with a CID > 0, an Add-CID octet is prepended to the IP packet. When the channel uses large CIDs, the CID is placed so that it starts at the second octet of the Normal packet.
通常のパケットは通常のIPパケットプラスCID情報です。チャンネルは小さなCIDを使用し、プロファイルは0x0000がCID> 0に関連付けられている場合、アドインCIDのオクテットは、IPパケットの先頭に付加されます。チャネルが大きいCIDを使用する場合、それは通常のパケットの第2オクテットから始まるように、CIDが配置されています。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| first octet of IP packet |
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| |
/ rest of IP packet / variable length
| |
+---+---+---+---+---+---+---+---+
Note that the first octet of the IP packet starts with the bit pattern 0100 (IPv4) or 0110 (IPv6). This does not conflict with any reserved packet types. Hence, no bits in addition to the CID are needed. The profile is reasonably future-proof since problems do not occur until IP version 14.
IPパケットの最初のオクテットは、ビットパターン0100（IPv4の）または0110（IPv6）の始まることに留意されたいです。これは、任意の予約パケットタイプと競合しません。したがって、CIDに加えて、何ビットが必要とされません。プロファイルは、合理的な問題は、IPバージョン14までは発生しないので、将来性です。
There are two modes in Profile 0x0000: Unidirectional mode and Bidirectional mode. In Unidirectional mode, the compressor repeats the IR packet periodically. In Bidirectional mode, the compressor never repeats the IR packet. The compressor and decompressor always start in Unidirectional mode. Whenever feedback is received, the compressor switches to Bidirectional mode.
単方向モードと双方向モード：プロファイル0000での2つのモードがあります。単方向モードでは、圧縮機は、定期的にIRパケットを繰り返します。双方向モードでは、コンプレッサーはIRパケットを繰り返したことがありません。コンプレッサーと減圧器は常に単方向モードで起動します。フィードバックが受信されるたびに、圧縮機は双方向モードに切り替わります。
The compressor can be in either of two states: the IR state or the Normal state. It starts in the IR state.
IR状態又は正常状態：圧縮機は、2つの状態のいずれかであることができます。これは、IR状態で起動します。
a) IR state: Only IR packets can be sent. After sending a small number of IR packets (only one when refreshing), the compressor switches to the Normal state.
a）のIRの状態：のみIRパケットを送信することができます。 IRパケットの少数の（一つだけリフレッシュ）、正常な状態に圧縮機のスイッチを送信した後。
b) Normal state: Only Normal packets can be sent. When in Unidirectional mode, the compressor periodically transits back to the IR state. The length of the period is implementation dependent, but should be fairly long. Exponential backoff may be used.
b）は通常の状態：のみ通常のパケットを送信することができます。場合単方向モードでは、圧縮機が定期的にIR状態に遷移します。期間の長さは実装依存であるが、かなり長くすべきです。指数バックオフを使用することができます。
c) When feedback is received in any state, the compressor switches to Bidirectional mode.
フィードバックがどのような状態で受信されると、C）、圧縮機は、双方向モードに切り替わります。
The decompressor can be in either of two states: NO_CONTEXT or FULL_CONTEXT. It starts in NO_CONTEXT.
NO_CONTEXTまたはFULL_CONTEXT：解凍器は、2つの状態のいずれかにすることができます。それはNO_CONTEXTで起動します。
d) When an IR packet is received in the NO_CONTEXT state, the decompressor first verifies the packet using the CRC. If the packet is OK, the decompressor 1) moves to the FULL_CONTEXT state, 2) delivers the IP packet to upper layers if present, 3) MAY send an ACK. If the packet is not OK, it is discarded without further action.
IRパケットはNO_CONTEXT状態で受信されると、D）、減圧装置は、第1のCRCを使用してパケットを検証します。パケットがOKである場合、デコンプレッサ1）が存在する場合2）上位層にIPパケットを配信し、FULL_CONTEXT状態に移行する、3）ACKを送信することができます。パケットがOKでない場合は、さらなる行動せずに破棄されます。
e) When any other packet is received in the NO_CONTEXT state, it is discarded without further action.
他のパケットはNO_CONTEXT状態で受信されると、E）、これをさらなる動作なしに廃棄されます。
f) When an IR packet is received in the FULL_CONTEXT state, the packet is first verified using the CRC. If OK, the decompressor 1) delivers the IP packet to upper layers if present, 2) MAY send an ACK. If the packet is not OK, no action is taken.
F）IRパケットはFULL_CONTEXT状態で受信されると、パケットは最初のCRCを使用して検証されます。存在するならばOK、デコンプレッサ1）上位層にIPパケットを配信する場合、2）ACKを送信することができます。パケットがOKでない場合は、何も起こりません。
g) When a Normal packet is received in the FULL_CONTEXT state, the CID information is removed and the IP packet is delivered to upper layers.
通常のパケットがFULL_CONTEXT状態で受信されるとg）は、CID情報が除去され、IPパケットが上位レイヤに送達されます。
The only kind of feedback in Profile 0x0000 is ACKs. Profile 0x0000 MUST NOT be rejected. Profile 0x0000 SHOULD be associated with at most one CID. ACKs use the FEEDBACK-1 format of section 5.2. The value of the profile-specific octet in the FEEDBACK-1 ACK is 0 (zero).
プロファイル0000におけるフィードバックの唯一の種類は、ACKのです。プロファイル0000は拒否してはなりません。プロファイル0000は、最大1つのCIDに関連付けられている必要があり。 ACKはセクション5.2のFEEDBACK-1フォーマットを使用します。 FEEDBACK-1 ACKでプロファイル固有のオクテットの値が0（ゼロ）です。
UDP/IP headers do not have a sequence number which is as well-behaved as the RTP Sequence Number. For UDP/IPv4, there is an IP-ID field which may be echoed in feedback information, but when no IPv4 header is present such feedback identification becomes problematic.
UDP / IPヘッダはRTPとしてシーケンス番号として行儀されたシーケンス番号を持っていません。 UDP / IPv4の場合、そこにフィードバック情報にエコーすることができるIP-IDフィールドがあるが、何のIPv4ヘッダが存在しない場合、このようなフィードバック識別が問題となります。
Therefore, in the ROHC UDP profile, the compressor generates a 16-bit sequence number SN which increases by one for each packet received in the packet stream. This sequence number is thus relatively well-behaved and can serve as the basis for most mechanisms described for ROHC RTP. It is called SN or UDP SN below. Unless stated otherwise, the mechanisms of ROHC RTP are used also for ROHC UDP, with the UDP SN taking the role of the RTP Sequence Number.
したがって、ROHC UDPプロファイルに、圧縮機は、パケットストリームで受信されたパケットごとに1ずつ増加する16ビットのシーケンス番号SNを生成します。このシーケンス番号は、比較的行儀であり、ROHC RTPについて記載ほとんどのメカニズムの基礎として役立つことができます。なお、以下SNまたはUDP SNと呼ばれています。特に明記しない限り、ROHC RTPのメカニズムは、UDP SNはRTPシーケンス番号の役割を取ると、ROHC UDPのためにも使用されています。
The ROHC UDP profile always uses p = -1 when interpreting the SN, since there will be no repetitions or reordering of the compressor-generated SN. The interpretation interval thus always starts with (ref_SN + 1).
ROHC UDPプロファイルは、常に= Pを使用しています-1 SNを解釈するとき、コンプレッサー、生成されたSNのない繰り返しや並べ替えがないからです。解釈間隔は、このように常に（ref_SN + 1）で始まります。
The static context for ROHC UDP streams can be initialized in either of two ways:
ROHC UDPストリームの静的コンテキストは、2つの方法のいずれかで初期化することができます。
1) By using an IR packet as in section 5.7.7.1, where the profile is two (2) and the static chain ends with the static part of an UDP packet. At the compressor, UDP SN is initialized to a random value when the IR packet is sent.
1）プロファイルは、2つ（2セクション5.7.7.1、同様にIRパケットを使用して）と静的チェーンはUDPパケットの静的部分で終わります。 IRパケットが送信されたときの圧縮機では、UDP SNは、ランダムな値に初期化されます。
2) By reusing an existing context where the existing static chain contains the static part of a UDP packet, e.g., the context of a stream compressed using ROHC RTP (profile 0x0001). This is done with an IR-DYN packet (section 5.7.7.2) identifying profile 0x0002, where the dynamic chain corresponds to the prefix of the existing static chain that ends with the UDP header. UDP SN is initialized to the RTP Sequence Number if the earlier profile was profile 0x0001, and to a random number otherwise.
2）既存の静的チェーンがUDPパケットの静的な部分を含む既存のコンテキストを再利用することによって、例えば、ROHC RTP（プロファイルは0x0001）を使用して圧縮ストリームの文脈。これは、動的鎖がUDPヘッダで終わる既存の静的鎖のプレフィックスに対応するプロファイル0×0002を識別するIR-DYNパケット（セクション5.7.7.2）を用いて行われます。以前のプロファイルは、プロファイルは0x0001で、それ以外の場合は乱数にあればUDP SNはRTPシーケンス番号に初期化されます。
For ROHC UDP, the dynamic part of a UDP packet is different from section 5.7.7.5: a two-octet field containing the UDP SN is added after the Checksum field. This affects the format of dynamic chains in IR and IR-DYN packets.
ROHC UDPのために、UDPパケットの動的部分は、セクション5.7.7.5異なる：UDP SNを含む2オクテットフィールドはチェックサムフィールドの後に付加されます。これは、IR及びIR-DYNパケットの動的チェーンの形式に影響を与えます。
Note: 2) can be used for packet streams which were initially assumed to be RTP streams, so that compression started with profile 0x0001, but were later found evidently not to be RTP streams.
注：その圧縮プロファイルは0x0001で開始するが、それ以降のRTPストリームではないと明らかに見出されたSO 2）、最初にRTPストリームであると仮定されたパケットストリームのために使用することができます。
ROHC UDP uses the same states and modes as ROHC RTP. Mode transitions and state logic are the same except when explicitly stated otherwise. Mechanisms dealing with fields in the RTP header (except the RTP SN) are not used. The decompressed UDP SN is never included in any header delivered to upper layers. The UDP SN is used in place of the RTP SN in feedback.
ROHC UDPはROHC RTPと同じ状態やモードを使用しています。モード遷移と状態論理は、特に明記する場合を除いて同じです。 （RTP SN除く）RTPヘッダ内のフィールドを扱うメカニズムが使用されません。解凍UDP SNは、上位層に配信任意のヘッダに含まれることはありません。 UDP SNはフィードバックでRTP SNの代わりに使用されます。
The general format of a ROHC UDP packet is the same as for ROHC RTP (see beginning of section 5.7). Padding and CIDs are the same, as is the feedback packet type (5.7.6.1) and the feedback. IR and IR-DYN packets (5.7.7) are changed as described in 5.11.1.
ROHC UDPパケットの一般的な形式はROHC RTP（セクション5.7の始まりを参照）と同じです。フィードバックパケットタイプ（5.7.6.1）とフィードバックされたようにパディングとのCIDは、同じです。 5.11.1に記載されるようにIR及びIR-DYNパケット（5.7.7）が変更されます。
The general format of compressed packets is also the same, but there are differences in specific formats and extensions as detailed below. The differences are caused by removal of all RTP specific information except the RTP SN, which is replaced by the UDP SN.
圧縮されたパケットの一般的な形式も同じであるが、以下に詳述するように特定のフォーマットと拡張子に違いがあります。違いは、UDP SNによって置き換えられるRTP SN以外のすべてのRTP具体的な情報を除去することによって引き起こされます。
Unless explicitly stated below, the packet formats are as in sections 5.7.1-6.
明示的に以下の記載がない限り、パケットフォーマットは、セクション5.7.1-6のようにしています。
R-1
R-1
The TS field is replaced by an IP-ID field. The M flag has become part of IP-ID. The X bit has moved. The formats R-1-ID and R-1- TS are not used.
TSフィールドは、IP-IDフィールドに置き換えられます。 Mフラグは、IP-IDの一部となっています。 Xビットが移動しました。フォーマットR-1-ID及びR -1- TSは使用されません。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 | SN |
+===+===+===+===+===+===+===+===+
| X | IP-ID |
+---+---+---+---+---+---+---+---+
UO-1
ウオー１
The TS field is replaced by an IP-ID field. The M flag has become part of SN. Formats UO-1-ID and UO-1-TS are not used.
TSフィールドは、IP-IDフィールドに置き換えられます。 Mフラグは、SNの一部となっています。フォーマットUO-1-IDとUO-1-TSは使用されません。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 | IP-ID |
+===+===+===+===+===+===+===+===+
| SN | CRC |
+---+---+---+---+---+---+---+---+
UOR-2
フルオロ-2-
New format:
新フォーマット：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 | SN |
+===+===+===+===+===+===+===+===+
| X | CRC |
+---+---+---+---+---+---+---+---+
Extensions are as in 5.7.5, with the following exceptions:
拡張機能には、以下の例外を除いて、5.7.5のように、次のとおりです。
Extension 0:
拡張0：
+---+---+---+---+---+---+---+---+
| 0 0 | SN | IP-ID |
+---+---+---+---+---+---+---+---+
Extension 1:
拡張1：
+---+---+---+---+---+---+---+---+
| 0 1 | SN | IP-ID |
+---+---+---+---+---+---+---+---+
| IP-ID |
+---+---+---+---+---+---+---+---+
Extension 2:
拡張2：
+---+---+---+---+---+---+---+---+
| 1 0 | SN | IP-ID2 |
+---+---+---+---+---+---+---+---+
| IP-ID2 |
+---+---+---+---+---+---+---+---+
| IP-ID |
+---+---+---+---+---+---+---+---+
IP-ID2: For outer IP-ID field.
IP-ID2：外側のIP-IDフィールドのために。
Extension 3 is the same as Extension 3 in section 5.7.5, with the following exceptions.
拡張3は、以下の例外を除いて、セクション5.7.5に拡張3と同じです。
1) The initial flag octet has the following format:
1）初期フラグオクテットは、次の形式を有します。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 1 | S | Mode | I | ip | ip2 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Mode: Replaces R-TS and Tsc of 5.7.5. Provides mode information as was earlier done in RTP header flags and fields.
モード：5.7.5のR-TSやTscのを置き換えます。以前のRTPヘッダフラグ及びフィールドで行われたようにモード情報を提供します。
ip2: Replaces rtp bit of 5.7.5. Moved here from the Inner IP header flags octet.
IP2は：5.7.5のRTPビットを置き換えます。インナーIPヘッダフラグオクテットからここに移動。
2) The bit which was the ip2 flag in the Inner IP header flags in 5.7.5 is reserved. It is set to zero when sending and ignored when receiving.
2）5.7.5内側IPヘッダフラグにIP2フラグたビットは予約されています。これは、送信時にゼロに設定し、受信時に無視されます。
Treated as in ROHC RTP, but the offset is from UDP SN.
ROHC RTPのように扱われますが、オフセットは、UDP SNからです。
Feedback is as for ROHC RTP with the following exceptions:
フィードバックは、以下の例外を除き、ROHC RTPのためのようです：
1) UDP SN replaces RTP SN in feedback. 2) The CLOCK option (5.7.6.6) is not used. 3) The JITTER option (5.7.6.7) is not used.
1）UDP SNはフィードバックにRTP SNを置き換えます。 2）CLOCKオプション（5.7.6.6）が使用されていません。 3）JITTERオプション（5.7.6.7）が使用されていません。
When the ESP header is being used with an encryption algorithm other than NULL, subheaders after the ESP header are encrypted and cannot be compressed. Profile 0x0003 is for compression of the chain of headers up to and including the ESP header in this case. When the NULL encryption algorithm is being used, other profiles can be used and could give higher compression rates. See section 5.8.4.3.
ESPヘッダはNULL以外の暗号化アルゴリズムで使用されている場合、ESPヘッダの後サブヘッダは暗号化され、圧縮することができません。プロフィール0x0003は、この場合にESPヘッダを含むの最大ヘッダの鎖の圧縮のためのものです。 NULL暗号化アルゴリズムが使用されている場合は、他のプロファイルを使用することができ、より高い圧縮率を与えることができます。セクション5.8.4.3を参照してください。
This profile is very similar to the ROHC UDP profile. It uses the ESP sequence number as the basis for compression instead of a generated number, but is otherwise very similar to ROHC UDP. The interpretation interval (value of p) for the ESP-based SN is as with ROHC RTP (profile 0x0001). Apart from this, unless stated explicitly below, mechanisms and formats are as for ROHC UDP.
このプロファイルは、ROHC UDPプロフィールと非常によく似ています。これは、圧縮の代わりに、生成された数の基礎として、ESPのシーケンス番号を使用しますが、そうでない場合はROHC UDPと非常によく似ています。 ESPベースSNのための解釈インターバル（Pの値）がROHC RTP（プロファイルは0x0001）と同様です。明示的に以下の記載がない限り、これとは別に、メカニズムやフォーマットはROHC UDPの場合と同様です。
The static context for ROHC ESP streams can be initialized in either of two ways:
ROHC ESPストリームの静的コンテキストは、2つの方法のいずれかで初期化することができます。
1) by using an IR packet as in section 5.7.7.1, where the profile is three (3) and the static chain ends with the static part of an ESP header.
1）プロファイル三（3セクション5.7.7.1）と静的チェーンのようにIRパケットを使用して、ESPヘッダの静的部分で終わります。
2) by reusing an existing context, where the existing static chain contains the static part of an ESP header. This is done with an IR-DYN packet (section 5.7.7.2) identifying profile 0x0003, where the dynamic chain corresponds to the prefix of the existing static chain that ends with the ESP header.
2）既存の静的チェーンがESPヘッダの静的部分を含む既存のコンテキストを、再利用することによって。これは、動的鎖はESPヘッダで終わる既存の静的鎖のプレフィックスに対応するプロファイル0x0003を識別するIR-DYNパケット（セクション5.7.7.2）を用いて行われます。
In contrast to ROHC UDP, no extra sequence number is added to the dynamic part of the ESP header: the ESP sequence number is the only element.
ROHC UDPとは対照的に、余分なシーケンス番号は、ESPヘッダの動的部分に付加されていない：ESPシーケンス番号が唯一の要素です。
Note: 2) can be used for streams where compression has been initiated under the assumption that NULL encryption was being used with ESP. When it becomes obvious that an encryption algorithm other than NULL is being used, the compressor may send an IR-DYN according to 2) to switch to profile 0x0003 without having to send an IR packet.
注意：2）圧縮はNULL暗号化はESPで使用されていたという仮定の下で開始されたストリームに使用することができます。それはNULL以外の暗号化アルゴリズムが使用されていることが明らかになった場合、圧縮機は、IRパケットを送信することなく、0x0003をプロファイルに切り替えるために2に係るIR-DYN）を送信することができます。
The packet types for ROHC ESP are the same as for ROHC UDP, except that the ESP sequence number is used instead of the generated sequence number of ROHC UDP. The ESP header is not part of any compressed list in ROHC ESP.
ESPのシーケンス番号ではなく、ROHC UDPの生成シーケンス番号を使用すること以外はROHC ESPのためのパケットタイプは、ROHC UDPの場合と同じです。 ESPヘッダがROHC ESP内の任意の圧縮されたリストの一部ではありません。
This document specifies mechanisms for the protocol and leaves many details on the use of these mechanisms to the implementers. This chapter is aimed to give guidelines, ideas and suggestions for implementing the scheme.
このドキュメントは、プロトコルのためのメカニズムを指定し、実装にこれらのメカニズムの使用に関する多くの詳細を残します。この章では、スキームを実装するためのガイドライン、アイデアや提案を与えることを目的としています。
This section describes an OPTIONAL decompressor operation to reduce the number of packets discarded due to an invalid context.
このセクションでは、無効なコンテキストに破棄されたパケットの数を減らすためにOPTIONALデコンプレッサの動作を説明します。
Once a context becomes invalid (e.g., when more consecutive packet losses than expected have occurred), subsequent compressed packets cannot immediately be decompressed correctly. Reverse decompression aims at decompressing such packets later instead of discarding them, by storing them until the context has been updated and validated and then attempting decompression.
コンテキストが（例えば、予想以上の連続したパケット損失が発生したとき）は無効になると、その後の圧縮されたパケットは、直ちに正しく解凍することができません。リバース減圧は、このようなパケットを解凍後に代わりのコンテキストが更新され、検証されるまで、それらを格納することで、それらを廃棄して、解凍をしようとすることを目指しています。
Let the sequence of stored packets be i, i + 1, ..., i + k, where i is the first packet and i + k is the last packet before the context was updated. The decompressor will attempt to recover the stored packets in reverse order, i.e., starting with i + k, and working back toward i. When a stored packet has been reconstructed, its correctness is verified using its CRC. Packets not carrying a CRC must not be delivered to upper layers. Packets where the CRC succeeds are delivered to upper layers in their original order, i.e., i, i + 1, ..., i + k.
格納されたパケットの順序iは、I + 1、...、私は最初のパケットであると私はkは+コンテキストが更新された前の最後のパケットであるkは、+することができます。減圧装置、すなわち、I + Kで始まる、私に向かって戻って作業を、逆の順序で格納されたパケットを回復しようと試みます。保存されたパケットが再構築された場合には、その正しさは、そのCRCを使用して検証されます。 CRCを運んでいないパケットは、上位層に配信されてはなりません。 CRCが成功したパケット、すなわち、iが、I + 1、...、iがkは+、元の順序で上位層に配信されます。
Note that this reverse decompression introduces buffering while waiting for the context to be validated and thereby introduces additional delay. Thus, it should be used only when some amount of delay is acceptable. For example, for video packets belonging to the same video frame, the delay in packet arrivals does not cause presentation time delay. Delay-insensitive streaming applications can also be tolerant of such delay. If the decompressor cannot determine whether the application can tolerate delay, it should not perform reverse decompression.
この逆減圧コンテキストを検証するのを待つ間、バッファリングを導入し、それによって追加の遅延を導入することに留意されたいです。これにより、遅延のある量が許容される場合にのみ使用されるべきです。例えば、同じビデオフレームに属するビデオパケットのために、パケットの到着の遅延は、プレゼンテーションの時間遅延が発生することはありません。遅延の影響を受けないストリーミングアプリケーションはまた、このような遅延の耐性ができます。デコンプレッサは、アプリケーションが遅延を許容できるかどうかを判断できない場合は、逆圧縮解除を行うべきではありません。
The following illustrates the decompression procedure in some detail:
以下は、いくつかの詳細に解凍手順を示しています。
1. The decompressor stores compressed packets that cannot be decompressed correctly due to an invalid context.
1.解凍店が無効なコンテキストに正しく解凍できないパケットを圧縮します。
2. When the decompressor has received a context updating packet and the context has been validated, it proceeds to recover the last packet stored. After decompression, the decompressor checks the correctness of the reconstructed header using the CRC.
2.解凍器がコンテキスト更新パケットを受信したコンテキストが検証された場合には、格納された最後のパケットを回復するために進みます。解凍後、解凍器は、CRCを用いて再構成されたヘッダの正当性をチェックします。
3. If the CRC indicates successful decompression, the decompressor stores the complete packet and attempts to decompress the preceding packet. In this way, the stored packets are recovered in reverse order until no compressed packets are left. For each packet, the decompressor checks the correctness of the decompressed headers using the header compression CRC.
前記CRCが成功した減圧を示している場合、デコンプレッサは、完全なパケットを格納し、前のパケットを復元することを試みます。全く圧縮されたパケットが残っていないまで、このようにして、格納されたパケットは、逆の順序で回収されます。各パケットに対して、デコンプレッサはヘッダ圧縮CRCを使用して解凍ヘッダの正当性をチェックします。
4. If the CRC indicates an incorrectly decompressed packet, the reverse decompression attempt MUST be terminated and all remaining uncompressed packets MUST be discarded.
4. CRCが誤って解凍パケットを示している場合、逆解凍試みが終了しなければなりません、そして、残りのすべての非圧縮パケットを捨てなければなりません。
5. Finally, the decompressor forwards all the correctly decompressed packets to upper layers in their original order.
5.最後に、減圧装置は、それらの元の順序で上位層に全て正しく解凍パケットを転送します。
RTCP is the RTP Control Protocol [RTP]. RTCP is based on periodic transmission of control packets to all participants in a session, using the same distribution mechanism as for data packets. Its primary function is to provide feedback from the data receivers on the quality of the data distribution. The feedback information may be used for issues related to congestion control functions, and directly useful for control of adaptive encodings.
RTCPは、RTP制御プロトコル[RTP]です。 RTCPは、データパケットと同じ配信メカニズムを使用して、セッションのすべての参加者に制御パケットの周期的な送信に基づいています。その主な機能は、データ配信の品質上のデータ受信機からのフィードバックを提供することです。フィードバック情報は、輻輳制御機能に関連する問題のために使用され、適応符号化の制御のために直接的に有用であり得ます。
In an RTP session there will be two types of packet streams: one with the RTP header and application data, and one with the RTCP control information. The difference between the streams at the transport level is in the UDP port numbers: the RTP port number is always even, the RTCP port number is that number plus one and therefore always odd [RTP, section 10]. The ROHC header compressor implementation has several ways at hand to handle the RTCP stream:
RTPヘッダおよびアプリケーションデータを有するもの、及びRTCP制御情報を有するもの：RTPセッションで2つのパケットストリームのタイプが存在することになります。トランスポート・レベルでストリームとの間の差は、UDPポート番号である：RTPポート番号が偶数常に、RTCPポート番号は、その番号プラスワンしたがって常に奇数[RTP、セクション10]です。 ROHCヘッダ圧縮の実装では、RTCPストリームを処理するために手で、いくつかの方法があります。
1. One compressor/decompressor entity carrying both types of streams on the same channel, using CIDs to distinguish between them. For sending a single RTP stream together with its RTCP packets on one channel, it is most efficient to set LARGE_CIDS to false, send the RTP packets with the implied CID 0 and use the Add-CID mechanism to send the RTCP packets.
それらを区別するためにCIDを使用して、同じチャネル上でストリームの両方のタイプを運ぶ1つ圧縮/伸張エンティティ。 1つのチャネル上のRTCPパケットと一緒に単一のRTPストリームを送信するために、falseにLARGE_CIDSを設定暗示CID 0でRTPパケットを送信し、RTCPパケットを送信するには、Add-CIDメカニズムを使用するのが最も効率的です。
2. Two compressor/decompressor entities, one for RTP and another one for RTCP, carrying the two types of streams on separate channels. This means that they will not share the same CID number space.
2つ圧縮/伸張エンティティ、RTPのための1つの独立したチャネルにストリームの二つのタイプを運ぶRTCPのための別の一つ。これは、彼らが同じCID番号空間を共有しないことを意味します。
RTCP headers may simply be sent uncompressed using profile 0x0000. More efficiently, ROHC UDP compression (profile 0x0002) can be used.
RTCPヘッダは単にプロファイル0000を用いて圧縮されていない送信されてもよいです。より効率的に、ROHC UDP圧縮（プロファイル0×0002）を使用することができます。
A ROHC implementation may have two kinds of parameters: configuration parameters that are mandatory and must be negotiated between compressor and decompressor peers, and implementation parameters that are optional and, when used, stipulate how a ROHC implementation is to operate.
必須であり、コンプレッサとデコンプレッサピア間でネゴシエートされ、使用される場合、任意であり、実装パラメータ、ROHC実装が動作する方法を規定しなければならない設定パラメータ：ROHC実装は、2種類のパラメータを有していてもよいです。
Configuration parameters are mandatory and must be negotiated between compressor and decompressor, so that they have the same values at both compressor and decompressor, see section 5.1.1.
設定パラメータは必須であり、彼らは、コンプレッサとデコンプレッサの両方で同じ値を持つように、セクション5.1.1を参照してください、コンプレッサーと減圧器との間で交渉しなければなりません。
Implementation parameters make it possible for an external entity to stipulate how an implementation of a ROHC compressor or decompressor should operate. Implementation parameters have local significance, are optional to use and are thus not necessary to negotiate between compressor and decompressor. Note that this does not preclude signaling or negotiating implementation parameters using lower layer functionality in order to set the way a ROHC implementation should operate. Some implementation parameters are valid only at either of compressor or decompressor. Implementation parameters may further be divided into parameters that allow an external entity to describe the way the implementation should operate and parameters that allow an external entity to trigger a specific event, i.e., signals.
実装のパラメータは、ROHC圧縮や解凍器の実装がどのように動作すべきか規定する外部エンティティのためにそれを可能にします。実装のパラメータは、ローカルな意味を持って使用するためのオプションであり、従って、コンプレッサとデコンプレッサとの間で交渉する必要はありません。このROHC実装が動作すべき方法を設定するために、下層の機能を使用してシグナリングまたは交渉実装パラメータを排除するものではないことに留意されたいです。いくつかの実装パラメータはコンプレッサーやデコンプレッサのいずれかで有効です。実装のパラメータは、さらに、外部エンティティは、外部エンティティは、特定のイベント、すなわち、信号をトリガすることを可能にする実装が動作すべき方法及びパラメータを記述することを可能にするパラメータに分割することができます。
CONTEXT_REINITIALIZATION -- signal This parameter triggers a reinitialization of the entire context at the decompressor, both the static and the dynamic part. The compressor MUST, when CONTEXT_REINITIALIZATION is triggered, back off to the IR state and fully reinitialize the context by sending IR packets with both the static and dynamic chains covering the entire uncompressed headers until it is reasonably confident that the decompressor contexts are reinitialized. The context reinitialization MUST be done for all contexts at the compressor. This parameter may for instance be used to do context relocation at, e.g., a cellular handover that results in a change of compression point in the radio access network.
CONTEXT_REINITIALIZATION - 静的及び動的部分の両方、このパラメータは、解凍器での全コンテキストの再初期化をトリガ信号。圧縮機は、CONTEXT_REINITIALIZATIONがトリガされたときに、バックオフIR状態へと完全にはデコンプレッサコンテキストが再初期化されていることを合理的に確信するまで、全体の未圧縮ヘッダを覆う静的および動的鎖の両方でIRパケットを送信することによって、コンテキストを再初期化しなければなりません。コンテキストの再初期化は、圧縮機ですべてのコンテキストのために行われなければなりません。このパラメータは、例えば、例えばにおけるコンテキストの再配置、無線アクセスネットワーク内の圧縮点の変化をもたらす細胞のハンドオーバを実行するために使用することができます。
NO_OF_PACKET_SIZES_ALLOWED -- value: positive integer This parameter may be set by an external entity to specify the number of packet sizes a ROHC implementation may use. However, the parameter may be used only if PACKET_SIZES is not used by an external entity. With this parameter set, the ROHC implementation at the compressor MUST NOT use more different packet sizes than the value this parameter stipulates. The ROHC implementation must itself be able to determine which packet sizes will be used and describe these to an external entity using PACKET_SIZES_USED. It should be noted that one packet size might be used for several header formats, and that the number of packet sizes can be reduced by employing padding and segmentation.
NO_OF_PACKET_SIZES_ALLOWED - 値：正の整数このパラメータは、パケットの数を指定するために外部のエンティティによって設定することができるがROHC実装が使用できるサイズ。しかし、パラメータはPACKET_SIZESが外部のエンティティによって使用されていない場合にのみ使用することができます。このパラメータを設定すると、コンプレッサーのROHCの実装は、このパラメータが規定値よりも多くの異なるパケットサイズを使用してはなりません。 ROHC実装は、それ自体が使用されるパケットサイズを決定し、PACKET_SIZES_USEDを使用して外部エンティティにこれらを記述することができなければなりません。 1つのパケット・サイズは、いくつかのヘッダ・フォーマットのために使用されるかもしれないこと、およびパケットサイズの数をパディングとセグメンテーションを使用することによって低減することができることに留意すべきです。
NO_OF_PACKET_SIZES_USED _- value: positive integer This parameter is set by the ROHC implementation to indicate how many packet sizes it will actually use. It can be set to a large value to indicate that no particular attempt is made to minimize that number.
NO_OF_PACKET_SIZES_USED _-値：正の整数このパラメータは、それが実際に使用するサイズをどのように多くのパケットを示すために、ROHC実装によって設定されています。特段の試みがその数を最小限に抑えるために行われていないことを示すために大きな値に設定することができます。
PACKET_SIZES_ALLOWED -- value: list of positive integers (bytes) This parameter, if set, governs which packet sizes in bytes may be used by the ROHC implementation. Thus, packet sizes not in the set of values for this parameter MUST NOT be used. Hence, an external entity can mandate a ROHC implementation to produce packet sizes that fit pre-configured lower layers better. If this parameter is used to stipulate which packet sizes a ROHC implementation can use, the following rules apply:
PACKET_SIZES_ALLOWED - 値：正の整数（バイト）のリストこのパラメータは、設定されている場合、バイト単位のサイズがROHC実装によって使用され得るパケット支配します。したがって、このパラメータの値のセットでパケットサイズではないが使用してはいけません。したがって、外部エンティティは、より良い事前に設定下位層に合うパケットサイズを生成するためにROHCの実装を強制することができます。このパラメータがROHCの実装が使用できるサイズどのパケット規定するために使用されている場合は、次の規則が適用されます。
- A packet large enough to hold the entire IR header (both static and dynamic chain) MUST be part of the set of sizes, unless MRRU is set to a large enough value to allow segmentation. - The packet size likely to be used most frequently in the SO state SHOULD be part of the set.
- MRRUをセグメント化を可能にするために十分に大きな値に設定されていない限り、全体IRヘッダを保持するのに十分な大きさ（静的および動的鎖の両方）のパケットは、サイズのセットの一部でなければなりません。 - SO状態で最も頻繁に使用される可能性が高いパケット・サイズは、セットの一部であるべきです。
- The packet size likely to be used most frequently in the FO state SHOULD be part of the set.
- FO状態で最も頻繁に使用される可能性が高いパケットサイズがセットの一部である必要があります。
PACKET_SIZES_USED -- values: set of positive integers (bytes) This parameter describes which packet sizes a ROHC implementation uses if NO_OF_PACKET_SIZES_ALLOWED or PACKET_SIZES_ALLOWED is used by an external entity to stipulate how many packet sizes a ROHC implementation should use. The information about used packet sizes (bytes) in this parameter, may then be used to configure lower layers.
PACKET_SIZES_USED - 値：正の整数（バイト）のセットこのパラメータは、NO_OF_PACKET_SIZES_ALLOWED又はPACKET_SIZES_ALLOWEDがROHC実装が使用する必要がどのように多くのパケットサイズを規定する外部のエンティティによって使用されている場合ROHC実装が使用サイズどのパケット記載されています。このパラメータに使用されるパケットサイズ（バイト）に関する情報は、次いで、下層を構成するために使用されてもよいです。
PAYLOAD_SIZES -_ values: set of positive integer values (bytes) This parameter is set by an external entity that wants to make use of the PACKET_SIZES_USED parameter to indicate which payload sizes can be expected.
PAYLOAD_SIZES -_値：正の整数値のセットは、（バイト）このパラメータは、ペイロードサイズが期待できるかを示すためにPACKET_SIZES_USEDパラメータを利用したい外部のエンティティによって設定されています。
When a ROHC implementation has a limited set of allowed packet sizes, and the most preferable header format has a size that is not part of the set, it has the following options:
ROHC実装が許容パケットサイズの限られたセットを有し、そして最も好ましくヘッダフォーマットがセットの一部ではない大きさを有する場合、それは次のオプションがあります。
- Choose the next larger header format from the allowed set. This is probably the most efficient choice. - Use the most preferable header format as if there were no restrictions on size, and then add padding octets to complete a packet of the next larger size in the allowed set. - Use segmentation to fragment the packet into pieces that would make up packets of sizes that are permissible (possibly after the addition of padding to the last segment).
- 許可されたセットから次に大きいヘッダフォーマットを選択します。これはおそらく最も効率的な選択です。 - 許可されたセット内の次の大きなサイズのパケットを完了するために、パディングオクテットを追加しサイズには制限がなかったかのように、最も好ましいヘッダ・フォーマットを使用し、そして。 - 使用セグメンテーションは許容される（おそらく最後のセグメントにパディングを加えた後）のサイズのパケットを構成することになる小片にパケットを断片化します。
It should be noted that even if the two last parameters introduce the possibility of restricting the number of packet sizes used, such restrictions will have a negative impact on compression performance.
2つの最後のパラメータが使用されるパケットサイズの数を制限する可能性を導入しても、そのような制限は、圧縮性能にマイナスの影響を与えることになることに留意すべきです。
MODE -- values: [U-mode, O-mode, R-mode] This parameter triggers a mode transition using the mechanism described in chapter 5 when the parameter changes value, i.e., to U-mode (Unidirectional mode), O-mode (Bidirectional Optimistic mode) or R-mode (Bidirectional Reliable mode). The mode transition is made from the current mode to the new mode as signaled by the implementation parameter. For example, if the current mode is Bidirectional Optimistic mode, MODE should have the value O-mode. If the MODE is changed to R-mode, a mode transition MUST be made from Bidirectional Optimistic mode to Bidirectional Reliable mode. MODE should not only serve as a trigger for mode transitions, but also make it visible which mode ROHC operates in.
MODE - 値：[Uモード、Oモード、Rモード]このパラメータは、パラメータはUモード（一方向モード）に、すなわち、値を変更するとき、第5章で説明されたメカニズムを使用してモード遷移をトリガO-モード（双方向楽観モード）またはRモード（双方向信頼できるモード）。モード遷移は、実装パラメータによって信号として新しいモードへの現在のモードから構成されています。現在のモードが双方向楽観モードである場合、例えば、MODEは値Oモードを有していなければなりません。 MODEは、R-モードに変更された場合、モード遷移は、双方向の信頼できるモード双方向楽観モードから行われなければなりません。 MODEはモード遷移のためのトリガーとして機能するだけでなく、ROHCがで動作するモード、それが見えるようにするべきではありません。
CLOCK_RESOLUTION -- value: nonnegative integer This parameter indicates the system clock resolution in units of milliseconds. A zero (0) value means that there is no clock available. If nonzero, this parameter allows the decompressor to use timer-based TS compression (section 4.5.4) and SN wraparound detection (section 5.3.2.2.4). In this case, its specific value is also significant for correctness of the algorithms.
CLOCK_RESOLUTION - 値：非負整数このパラメータは、ミリ秒の単位でシステムクロックの解像度を示します。ゼロ（0）の値は、利用可能なクロックがないことを意味します。ゼロ以外の場合、このパラメータは、解凍器は、タイマーベースのTS圧縮（セクション4.5.4）とSNのラップアラウンド検出（セクション5.3.2.2.4）を使用することができます。この場合には、その特定の値はまた、アルゴリズムの正しさのために重要です。
REVERSE_DECOMPRESSION_DEPTH -- value: nonnegative integer This parameter determines whether reverse decompression as described in section 6.1 should be used or not, and if used, to what extent. The value indicates the maximum number of packets that can be buffered, and thus possibly be reverse decompressed by the decompressor. A zero (0) value means that reverse decompression MUST NOT be used.
REVERSE_DECOMPRESSION_DEPTH - 値：非負整数このパラメータは、セクション6.1で説明したように逆減圧を使用すべきか否かを判定し、使用している場合、どの程度まで。値は、バッファリングすることができ、したがって、おそらく逆減圧装置で減圧されたパケットの最大数を示しています。ゼロ（0）の値は、逆圧縮解除を使用してはならないことを意味します。
In a point-to-point link, the two nodes can agree on the number of compressed sessions they are prepared to support for this link. It may, however, not be possible for the decompressor to accurately predict when it will run out of resources. ROHC allows the negotiated number of contexts to be larger than could be accommodated in the worst case. Then, as context resources are consumed, an attempt to set up a new context may be rejected by the decompressor, using the REJECT option of the feedback payload.
ポイントツーポイントリンクでは、2つのノードは、彼らがこのリンクをサポートする用意がある圧縮されたセッションの数に同意することができます。それはリソースを使い果たします際にデコンプレッサを正確に予測することは、しかし、できない場合があります。 ROHCは、コンテキストの交渉さ数は、最悪のケースに収納できるより大きいことができます。コンテキストのリソースが消費されるようそして、新しいコンテキストを設定しようとする試みは、フィードバックペイロードのREJECTオプションを使用して、解凍器によって拒否することができます。
Upon reception of a REJECT option, the compressor SHOULD wait for a while before attempting to compress additional streams destined for the rejecting node.
REJECTオプションを受信すると、圧縮機は、拒絶ノード宛の追加ストリームを圧縮する前に、しばらく待たなければなりません。
This section provides some explanatory material on data structures that a ROHC implementation will have to maintain in one form or another. It is not intended to constrain the implementations.
このセクションでは、ROHC実装が一の形態又は別に維持しなければならないデータ構造にいくつかの説明資料を提供します。実装を制約するものではありません。
The compressor context consists of a static part and a dynamic part. The content of the static part is the same as the static chain defined in section 5.7.7. The dynamic part consists of multiple elements which can be categorized into four types.
圧縮コンテキストは、静的部分と動的部分から成ります。静的部分の含有量は、セクション5.7.7で定義された静的鎖と同じです。動的部分は、4つのタイプに分類することができる複数の要素から構成されています。
a) Sliding Window (SW) b) Translation Table (TT) c) Flag d) Field
A）スライディングウィンドウ（SW）b）の変換テーブル（TT）C）フラグD）フィールド
These elements may be common to all modes or mode specific. The following table summarizes all these elements.
これらの要素は、すべてのモードやモードの特定に共通であってもよいです。次の表は、これらすべての要素をまとめたもの。
+--------+---------------------------+-------------+----------------+
| | Common to | Specific to | Specific to |
| | all modes | R-mode | U/O-mode |
+--------+---------------------------+-------------+----------------+
| SWs | GSW | R_CSW | UO_CSW |
| | | R_IESW | UO_IESW |
+--------+---------------------------+-------------+----------------+
| TTs | | R_CTT | UO_CTT |
| | | R_IETT | UO_IETT |
+--------+---------------------------+-------------+----------------+
| Flags | UDP Chksum | | ACKED |
| | TSS, TIS | | |
| | RND, RND2 | | |
| | NBO, NBO2 | | |
+--------+---------------------------+-------------+----------------+
| Fields | Profile | | CSRC_REF_ID |
| | C_MODE | | CSRC_GEN_ID |
| | C_STATE | | CSRC_GEN_COUNT |
| | C_TRANS | | IPEH_REF_ID |
| | TS_STRIDE (if TSS = 1) | | IPEH_GEN_ID |
| | TS_OFFSET (if TSS = 1) | | IPEH_GEN_COUNT |
| | TIME_STRIDE (if TIS = 1) | | |
| | CURR_TIME (if TIS = 1) | | |
| | MAX_JITTER_CD (if TIS = 1)| | |
| | LONGEST_LOSS_EVENT(O) | | |
| | CLOCK_RESOLUTION(O) | | |
| | MAX_JITTER(O) | | |
+--------+---------------------------+-------------+----------------+
1) GSW: Generic W_LSB Sliding Window
1）GSW：汎用W_LSBスライディングウィンドウ
Each element in GSW consists of all the dynamic fields in the dynamic chain (defined in section 5.7.7) plus the fields specified in a) but excluding the fields specified in b).
GSWの各要素は全て（セクション5.7.7で定義された）動的鎖の動的フィールドプラスで指定されたフィールドからなる）が、（b）に指定されたフィールドを除きます）。
a) Packet Arrival Time (if TIS = 1) Scaled RTP Time Stamp (if TSS = 1) (optional) Offset_i (if RND = 0) (optional)
a）は、パケット到着時間（IF TIS = 1）スケーリングRTPタイムスタンプ（もしTSS = 1）（オプション）Offset_i（IF RND = 0）（オプション）
b) UDP Checksum, TS Stride, CSRC list, IPv6 Extension Headers
b）のUDPチェックサム、TSストライド、CSRCリスト、IPv6拡張ヘッダー
2) R_CSW: CSRC Sliding Window in R-mode
2）R_CSW：RモードでCSRCスライディングウィンドウ
R_IESW: IPv6 Extension Header Sliding Window in R-mode
R_IESW：RモードでのIPv6拡張ヘッダスライディングウィンドウ
UO_CSW: CSRC Sliding Window in U/O-mode
UO_CSW：CSRCは、U / Oモードでスライディングウィンドウ
UO_IESW: IPv6 Extension Header Sliding Window in U/O-mode
UO_IESW：IPv6拡張ヘッダは、U / Oモードでスライディングウィンドウ
Each element in R_CSW, R_IESW, UO_CSW and UO_IESW is defined in section 6.5.3.
R_CSW、R_IESW、UO_CSWとUO_IESWの各要素は、セクション6.5.3で定義されています。
3) R_CTT: CSRC Translation Table in R-mode
3）R_CTT：RモードでCSRC変換テーブル
R_IETT: IPv6 Extension Header Translation Table in U/O-mode
R_IETT：U / OモードでのIPv6拡張ヘッダ変換テーブル
UO_CTT: CSRC Translation Table in U/O-mode
UO_CTT：U / OモードでCSRC変換テーブル
UO_IETT: IPv6 Extension Header Translation Table in U/O-mode
UO_IETT：U / OモードでのIPv6拡張ヘッダ変換テーブル
Each element in R_CTT and R_IETT is defined in section 5.8.1.1. Each element in UO_CTT and UO_IETT is defined in section 5.8.1.2.
R_CTTとR_IETTの各要素は、セクション5.8.1.1で定義されています。 UO_CTTとUO_IETTの各要素は、セクション5.8.1.2で定義されています。
4) ACKED: Indicates whether or not the decompressor has ever acked
4）ACKさは：デコンプレッサがこれまでにACKされているかどうかを示し
5) CURR_TIME: The current time value (used for context relocation when timer-based timestamp compression is used)
5）CURR_TIME：現在の時間値（タイマベースのタイムスタンプ圧縮が使用される場合、コンテキストの再配置のために使用されます）
6) All the other flags and fields are defined elsewhere in the ROHC document.
6）他のすべてのフラグとフィールドはROHCドキュメントの別の場所で定義されています。
The decompressor context consists of a static part and a dynamic part. The content of the static part is the same as the static chain defined in section 5.7.7. The dynamic part consists of multiple elements, one of which is the nonstatic reference header that includes all the nonstatic fields. These nonstatic fields are the fields in the dynamic chain defined in section 5.7.7, excluding UDP Checksum and TS_Stride. All the remaining elements can be categorized into four types:
デコンプレッサのコンテキストは、静的部分と動的部分から成ります。静的部分の含有量は、セクション5.7.7で定義された静的鎖と同じです。動的部分は、すべての非静的フィールドを含む非静的基準ヘッダで一方が複数の要素から成ります。これらの非静的フィールドは、UDPチェックサムとTS_STRIDEを除く、セクション5.7.7で定義されたダイナミックチェーン内のフィールドです。残りのすべての要素は、4つのタイプに分類できます。
a) Sliding Window (SW) b) Translation Table (TT) d) Flag e) Field
A）スライディングウィンドウ（SW）b）の変換テーブル（TT）D）フラグE）フィールド
These elements may be mode specific or common to all modes. The following table summarizes all these elements.
これらの要素は、すべてのモードに固有またはコモンモードかもしれません。次の表は、これらすべての要素をまとめたもの。
+--------+---------------------------+-------------+----------------+
| | Common to | Specific to | Specific to |
| | all modes | R-mode | U/O-mode |
+--------+---------------------------+-------------+----------------+
| SWs | | R_CSW | UO_CSW |
| | | R_IESW | UO_IESW |
+--------+---------------------------+-------------+----------------+
| TTs | | R_CTT | UO_CTT |
| | | R_IETT | UO_IETT |
+--------+---------------------------+-------------+----------------+
| Flags | UDP Checksum | | ACKED |
| | TSS, TIS | | |
| | RND, RND2 | | |
| | NBO, NBO2 | | |
+--------+---------------------------+-------------+----------------+
| Fields | Profile | | CSRC_GEN_ID |
| | D_MODE | | IPEH_GEN_ID |
| | D_STATE | | PRE_SN_V_REF |
| | D_TRANS | | |
| | TS_STRIDE (if TSS = 1) | | |
| | TS_OFFSET (if TSS = 1) | | |
| | TIME_STRIDE (if TIS = 1) | | |
| | PKT_ARR_TIME (if TIS = 1) | | |
| | LONGEST_LOSS_EVENT(O) | | |
| | CLOCK_RESOLUTION(O) | | |
| | MAX_JITTER(O) | | |
+--------+---------------------------+-------------+----------------+
1) ACKED: Indicates whether or not ACK has ever been sent.
1）ACKさ：ACKが今まで送られたかどうかを示します。
2) PKT_ARR_TIME: The arrival time of the packet that most recently decompressed and verified using CRC.
2）PKT_ARR_TIME：最近解凍し、CRCを用いて検証し、パケットの到着時間。
PRE_SN_V_REF: The sequence number of the packet verified before the most recently verified packet.
PRE_SN_V_REF：最近確認されたパケットの前に検証したパケットのシーケンス番号。
CSRC_GEN_ID: The CSRC gen_id of the most recently received packet.
CSRC_GEN_ID：最近受信したパケットのCSRCのGEN_ID。
IPEH_GEN_ID: The IPv6 Extension Header gen_id of the most recently received packet.
IPEH_GEN_ID：最近受信したパケットのIPv6拡張ヘッダGEN_ID。
3) The remaining elements are as defined in the compressor context.
圧縮コンテキストで定義されるように3）残りの要素です。
In R-mode list compression (see section 5.8.2.1), each entry in the sliding window, both at the compressor side and at the decompressor side, has the following structure:
Rモードリスト圧縮で（セクション5.8.2.1を参照）、圧縮機側と減圧側の両方スライディングウィンドウ内の各エントリは、以下の構造を有します。
+---------------------+--------+------------+
| RTP Sequence Number | icount | index list |
+---------------------+--------+------------+
The table index list contains a list of index. Each of these index corresponds to the item in the original list carried in the packet identified by the RTP Sequence Number. The mapping between the index and the item is identified in the translation table. The icount field carries the number of index in the following index list.
テーブルのインデックスリストは、インデックスのリストが含まれています。これらの指標の各々は、RTPシーケンス番号によって識別されるパケットで運ばれた元のリスト内の項目に対応します。インデックスと項目の間のマッピングは、変換テーブルで識別されます。 ICOUNTフィールドには、次のインデックスリストのインデックス数を運びます。
In U/O-mode list compression, each entry in the sliding window at both the compressor side and decompressor side has the following structure.
U / Oモードリスト圧縮では、圧縮機側と減圧側の両方でのスライディングウィンドウ内の各エントリは、以下の構造を有しています。
+--------+--------+------------+
| Gen_id | icount | index list |
+--------+--------+------------+
The icount and index list fields are the same as defined in R-mode. Instead of using the RTP Sequence Number to identify each entry, the Gen_id is included in the sliding window in U/O-mode.
ICOUNTインデックスリストフィールドは、R-モードで定義と同じです。代わりに、各エントリを識別するために、RTPシーケンス番号を使用する、GEN_IDは、U / Oモードにおけるスライディングウィンドウに含まれています。
Because encryption eliminates the redundancy that header compression schemes try to exploit, there is some inducement to forego encryption of headers in order to enable operation over low-bandwidth links. However, for those cases where encryption of data (and not headers) is sufficient, RTP does specify an alternative encryption method in which only the RTP payload is encrypted and the headers are left in the clear. That would still allow header compression to be applied.
暗号化は、ヘッダ圧縮スキームを活用しようという冗長性を排除しているため、低帯域幅のリンク上での動作を可能とするために、ヘッダの暗号化を見送るためにいくつかの誘因があります。しかし、データの暗号化（およびいないヘッダ）が十分であるような場合のために、RTPは、RTPペイロードが暗号化され、ヘッダは平文で放置された別の暗号化方式を指定しません。それはまだ、ヘッダ圧縮が適用されることを可能にします。
ROHC compression is transparent with regard to the RTP Sequence Number and RTP Timestamp fields, so the values of those fields can be used as the basis of payload encryption schemes (e.g., for computation of an initialization vector).
ROHC圧縮は、RTPシーケンス番号及びRTPタイムスタンプフィールドに関して透明であるので、これらのフィールドの値は、（初期化ベクトルの計算のために、例えば）ペイロードの暗号化方式の基礎として使用することができます。
A malfunctioning or malicious header compressor could cause the header decompressor to reconstitute packets that do not match the original packets but still have valid IP, UDP and RTP headers and possibly also valid UDP checksums. Such corruption may be detected with end-to-end authentication and integrity mechanisms which will not be affected by the compression. Moreover, this header compression scheme uses an internal checksum for verification of reconstructed headers. This reduces the probability of producing decompressed headers not matching the original ones without this being noticed.
誤動作や悪意のあるヘッダ圧縮器は、ヘッダ復元は、元のパケットに一致するが、まだ有効なIP、UDPおよびRTPヘッダと、おそらく、有効なUDPチェックサムを持っていないパケットを再構成する可能性があります。そのような破損は、圧縮によって影響されないエンドツーエンド認証および完全性機構を用いて検出することができます。また、このヘッダ圧縮方式は、再構成されたヘッダの検証のための内部のチェックサムを使用します。これは、これは気付かれずに元のものと一致しない解凍されたヘッダを生成する確率を低減します。
Denial-of-service attacks are possible if an intruder can introduce (for example) bogus STATIC, DYNAMIC or FEEDBACK packets onto the link and thereby cause compression efficiency to be reduced. However, an intruder having the ability to inject arbitrary packets at the link layer in this manner raises additional security issues that dwarf those related to the use of header compression.
侵入者は、（例えば）を導入リンクに偽STATIC、DYNAMICまたはフィードバックパケットとそれによって圧縮効率を低下させることができれば、サービス拒否攻撃が可能です。しかしながら、このように、リンク層で任意のパケットを注入する能力を有する侵入者は、ヘッダ圧縮の使用に関連するものを矮化追加のセキュリティ上の問題を提起します。
The ROHC profile identifier is a non-negative integer. In many negotiation protocols, it will be represented as a 16-bit value. Due to the way the profile identifier is abbreviated in ROHC packets, the 8 least significant bits of the profile identifier have a special significance: Two profile identifiers with identical 8 LSBs should be assigned only if the higher-numbered one is intended to supersede the lower-numbered one. To highlight this relationship, profile identifiers should be given in hexadecimal (as in 0x1234, which would for example supersede 0x0A34).
ROHCプロファイル識別子は非負の整数です。多くの交渉プロトコルでは、16ビットの値として表現されます。プロファイル識別子は、ROHCパケットに略記するように、プロファイル識別子の8つの最下位ビットは、特別な意味を持っている：同じ8つのLSBを有する2つのプロファイル識別子は、より高い番号のいずれかが下に取って代わることを意図されている場合にのみ割り当てられるべきです-numbered 1。この関係を強調するために、プロファイル識別子（例えば0x0A34に取って代わるであろう、0x1234のように）進数で与えられるべきです。
Following the policies outlined in [IANA-CONSIDERATIONS], the IANA policy for assigning new values for the profile identifier shall be Specification Required: values and their meanings must be documented in an RFC or in some other permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible. In the 8 LSBs, the range 0 to 127 is reserved for IETF standard-track specifications; the range 128 to 254 is available for other specifications that meet this requirement (such as Informational RFCs). The LSB value 255 is reserved for future extensibility of the present specification.
値とその意味は十分に詳細に、RFCまたは何らかの他の永久的かつ容易に入手可能な文献に文書化されなければならない：[IANA-考察]に概説された方針に従う、プロファイル識別子の新しい値を割り当てるためのIANAポリシーは、仕様が必要でなければなりません独立した実装の間の相互運用が可能です。 8個のLSBに、範囲は0〜127は、IETF標準トラック仕様のために予約されています。 254の範囲128は、（例えば、情報RFCとして）、この要件を満たす他の仕様のために利用可能です。 LSB値255は、本明細書の将来の拡張のために予約されています。
The following profile identifiers are already allocated:
次のプロファイル識別子が既に割り当てられています：
Profile Document Usage identifier
プロフィール文書利用識別子
0x0000 RFCthis ROHC uncompressed 0x0001 RFCthis ROHC RTP 0x0002 RFCthis ROHC UDP 0x0003 RFCthis ROHC ESP
0000 RFCthis ROHC圧縮されていない0x0001にRFCthis ROHC RTP 0×0002 RFCthis ROHC UDP 0x0003 RFCthis ROHC ESP
Earlier header compression schemes described in [CJHC], [IPHC], and [CRTP] have been important sources of ideas and knowledge.
以前のヘッダ圧縮方式は[IPHC]、[CJHC]に記載し、[CRTP]アイデアや知識の重要な供給源となっています。
The editor would like to extend his warmest thanks to Mikael Degermark, who actually did a lot of the editing work, and Peter Eriksson, who made a copy editing pass through the document, significantly increasing its editorial consistency. Of course, all remaining editorial problems have then been inserted by the editor.
エディタが大幅に編集一貫性を高め、文書を通じてパスを編集コピーを作成し、実際の編集作業の多くをしたミカエルDegermark、そしてピーター・エリクソン、と彼の暖かい感謝を拡張したいと思います。もちろん、残りのすべての社説の問題は、エディタによって挿入されています。
Thanks to Andreas Jonsson (Lulea University), who supported this work by his study of header field change patterns.
ヘッダフィールドの変化パターンの彼の研究によって、この作業をサポートアンドレアス・ヨンソン（ルーレオ大学）に感謝します。
Finally, this work would not have succeeded without the continual advice in navigating the IETF standards track, garnished with both editorial and technical comments, from the IETF transport area directors, Allison Mankin and Scott Bradner.
最後に、この作品は、IETFトランスポートエリアディレクター、アリソンマンキンとスコット・ブラッドナーから、編集と技術的なコメントの両方を添え、IETF標準トラックをナビゲートするには、継続的なアドバイスをすることなく、成功しなかったでしょう。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[UDP]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
【のIPv4]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6の]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RTP] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[RTP] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[HDLC] Simpson, W., "PPP in HDLC-like framing", STD 51, RFC 1662, July 1994.
、STD 51、RFC 1662、1994年7月[HDLC]シンプソン、W.、 "HDLC様のフレーミングにおけるPPP"。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998.
[ESP]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード"、RFC 2406、1998年11月。
[NULL] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With Ipsec", RFC 2410, November 1998.
[NULL]グレン、R.とS.ケント、 "NULL暗号化アルゴリズムおよびIPSecでの使用"、RFC 2410、1998年11月。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[MINE] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[MINE]パーキンス、C.、 "IP内の最小カプセル化"、RFC 2004、1996年10月。
[GRE1] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
【GRE1]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.とP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[GRE2] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, August 2000.
[GRE2] Dommety、G.、 "GREのキーと一連番号拡大"、RFC 2890、2000年8月。
[ASSIGNED] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[ASSIGNED]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月。
[VJHC] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[VJHC]ジェーコブソン、V.、 "圧縮TCP /低速シリアルリンクのIPヘッダ"、RFC 1144、1990年2月。
[IPHC] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[IPHC] Degermark、M.、Nordgren、B.とS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[CRTP] Casner、S.とV.ヤコブソン、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。
[CRTPC] Degermark, M., Hannu, H., Jonsson, L.E., Svanbro, K., "Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communication Magazine, Volume 7, number 4, pp. 20-25, August 2000.
【CRTPC] Degermark、M.、ハンヌ、H.、ジョンソン、LE、Svanbro、K.、 "セルラ無線ネットワーク上CRTP性能評価"、IEEEパーソナル通信誌、7巻、番号4、PP。20-25、 2000年8月。
[REQ] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, June 2001.
[REQ] Degermark、M.、 "ロバストIP / UDP / RTPヘッダ圧縮のための要件"、RFC 3096、2001年6月。
[LLG] Svanbro, K., "Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression", Work in Progress.
[LLG] Svanbro、K.、 "堅牢なRTP / UDP / IPヘッダ圧縮のための下位層のガイドライン" が進行中で働いています。
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA-考察] Alvestrand、H.、およびT. Narten氏、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
Carsten Bormann, Editor Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
カルステンボルマン、エディタUniversitaetブレーメンTZI POSTFACH 330440 D-28334ブレーメン、ドイツ
Phone: +49 421 218 7024 Fax: +49 421 218 7000 EMail: cabo@tzi.org
電話：+49 421 218 7024ファックス：+49 421 218 7000 Eメール：cabo@tzi.org
Carsten Burmeister Panasonic European Laboratories GmbH Monzastr. 4c 63225 Langen, Germany
カーステンBurmeisterパナソニックヨーロッパ研究所社Monzastr。図4c 63225ランゲン、ドイツ
Phone: +49-6103-766-263 Fax: +49-6103-766-166 EMail: burmeister@panasonic.de
電話：+ 49-6103-766-263ファックス：+ 49-6103-766-166 Eメール：burmeister@panasonic.de
Mikael Degermark The University of Arizona Dept of Computer Science P.O. Box 210077 Tucson, AZ 85721-0077, USA
コンピュータサイエンスのアリゾナ部門のマイケル・Degermark東京大学私書箱私書箱210077ツーソン、AZ 85721から0077、USA
Phone: +1 520 621-3498 Fax: +1 520 621-4642 EMail: micke@cs.arizona.edu
電話：+1 520 621-3498ファックス：+1 520 621-4642 Eメール：micke@cs.arizona.edu
Hideaki Fukushima Matsushita Electric Industrial Co., Ltd006, Kadoma, Kadoma City, Osaka, Japan
ひであき ふくしま まつした えぇｃｔりｃ いんづｓｔりあｌ こ。、 Ｌｔｄ００６、 かどま、 かどま しｔｙ、 おさか、 じゃぱん
Phone: +81-6-6900-9192 Fax: +81-6-6900-9193 EMail: fukusima@isl.mei.co.jp
電話：+ 81-6-6900-9192ファックス：+ 81-6-6900-9193 Eメール：fukusima@isl.mei.co.jp
Hans Hannu Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden
彼のハンヌボックス920 ErisoftエリクソンAB SE-971 28ルーレオ、スウェーデン
Phone: +46 920 20 21 84 Fax: +46 920 20 20 99 EMail: hans.hannu@ericsson.com
電話：+46 920 20 21 84ファックス：+46 920 20 20 99 Eメール：hans.hannu@ericsson.com
Lars-Erik Jonsson Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden
ラース・エリックジョンソンボックス920 ErisoftエリクソンAB SE-971 28ルーレオ、スウェーデン
Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 EMail: lars-erik.jonsson@ericsson.com
電話：+46 920 20 21 07ファックス：+46 920 20 20 99 Eメール：lars-erik.jonsson@ericsson.com
Rolf Hakenberg Panasonic European Laboratories GmbH Monzastr. 4c 63225 Langen, Germany
ロルフHakenbergパナソニックヨーロッパ研究所社Monzastr。図4c 63225ランゲン、ドイツ
Phone: +49-6103-766-162 Fax: +49-6103-766-166 EMail: hakenberg@panasonic.de
電話：+ 49-6103-766-162ファックス：+ 49-6103-766-166 Eメール：hakenberg@panasonic.de
Tmima Koren Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134, USA
Tmimaコレンシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134、USA
Phone: +1 408-527-6169 EMail: tmima@cisco.com
電話：+1 408-527-6169電子メール：tmima@cisco.com
Khiem Le 2-700 Mobile Networks Laboratory Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA
Khiemル2から700モバイルネットワーク研究所ノキア・リサーチセンター6000接続のドライブアーヴィング、TX 75039、USA
Phone: +1-972-894-4882 Fax: +1 972 894-4589 EMail: khiem.le@nokia.com
電話：+ 1-972-894-4882ファックス：+1 972 894-4589 Eメール：khiem.le@nokia.com
Zhigang Liu 2-700 Mobile Networks Laboratory Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA
志剛劉2から700モバイルネットワーク研究所ノキア・リサーチセンター6000接続のドライブアーヴィング、TX 75039、USA
Phone: +1 972 894-5935 Fax: +1 972 894-4589 EMail: zhigang.liu@nokia.com
電話：+1 972 894-5935ファックス：+1 972 894-4589 Eメール：zhigang.liu@nokia.com
Anton Martensson Ericsson Radio Systems AB Torshamnsgatan 23 SE-164 80 Stockholm, Sweden
アントンMartenssonからエリクソン無線システムAB Torshamnsgatan 23 SE-164 80ストックホルム、スウェーデン
Phone: +46 8 404 3881 Fax: +46 8 757 5550 EMail: anton.martensson@era.ericsson.se
電話：+46 8 404 3881ファックス：+46 8 757 5550 Eメール：anton.martensson@era.ericsson.se
Akihiro Miyazaki Matsushita Electric Industrial Co., Ltd 1006, Kadoma, Kadoma City, Osaka, Japan
あきひろ みやざき まつした えぇｃｔりｃ いんづｓｔりあｌ こ。、 Ｌｔｄ １００６、 かどま、 かどま しｔｙ、 おさか、 じゃぱん
Phone: +81-6-6900-9192 Fax: +81-6-6900-9193 EMail: akihiro@isl.mei.co.jp
電話：+ 81-6-6900-9192ファックス：+ 81-6-6900-9193 Eメール：akihiro@isl.mei.co.jp
Krister Svanbro Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden
クリスターSvanbroボックス920 ErisoftエリクソンAB SE-971 28ルーレオ、スウェーデン
Phone: +46 920 20 20 77 Fax: +46 920 20 20 99 EMail: krister.svanbro@ericsson.com
電話：+46 920 20 20 77ファックス：+46 920 20 20 99 Eメール：krister.svanbro@ericsson.com
Thomas Wiebke Panasonic European Laboratories GmbH Monzastr. 4c 63225 Langen, Germany
トーマスWiebkeパナソニックヨーロッパ研究所社Monzastr。図4c 63225ランゲン、ドイツ
Phone: +49-6103-766-161 Fax: +49-6103-766-166 EMail: wiebke@panasonic.de
電話：+ 49-6103-766-161ファックス：+ 49-6103-766-166 Eメール：wiebke@panasonic.de
Takeshi Yoshimura NTT DoCoMo, Inc. 3-5, Hikarinooka Yokosuka, Kanagawa, 239-8536, Japan
たけし よしむら んっｔ どこも、 いんｃ。 ３ー５、 ひかりのおか よこすか、 かながわ、 ２３９ー８５３６、 じゃぱん
Phone: +81-468-40-3515 Fax: +81-468-40-3788 EMail: yoshi@spg.yrp.nttdocomo.co.jp
電話：+ 81-468-40-3515ファックス：+ 81-468-40-3788 Eメール：yoshi@spg.yrp.nttdocomo.co.jp
Haihong Zheng 2-700 Mobile Networks Laboratory Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA
Haihong鄭2から700モバイルネットワーク研究所ノキア・リサーチセンター6000接続のドライブアーヴィング、TX 75039、USA
Phone: +1 972 894-4232 Fax: +1 972 894-4589 EMail: haihong.zheng@nokia.com
電話：+1 972 894-4232ファックス：+1 972 894-4589 Eメール：haihong.zheng@nokia.com
Appendix A. Detailed classification of header fields
ヘッダフィールドの付録A.詳細分類
Header compression is possible thanks to the fact that most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When designing a header compression scheme, it is of fundamental importance to understand the behavior of the fields in detail.
ヘッダ圧縮は、ほとんどのヘッダフィールドは、パケットからパケットにランダムに変化していないという事実のおかげで可能です。フィールドの多くは、多かれ少なかれ予測可能な方法で静的な動作や変化を示します。ヘッダ圧縮スキームを設計するとき、それは詳細フィールドの挙動を理解するために基本的に重要です。
In this appendix, all IP, UDP and RTP header fields are classified and analyzed in two steps. First, we have a general classification in A.1 where the fields are classified on the basis of stable knowledge and assumptions. The general classification does not take into account the change characteristics of changing fields because those will vary more or less depending on the implementation and on the application used. A less stable but more detailed analysis of the change characteristics is then done in A.2. Finally, A.3 summarizes this appendix with conclusions about how the various header fields should be handled by the header compression scheme to optimize compression and functionality.
この付録では、すべてのIP、UDPおよびRTPヘッダフィールドは2つの段階に分類され、分析されます。まず、フィールドが安定した知識や仮定に基づいて分類されているA.1での一般的な分類があります。これらは、実装上、使用用途に応じて、多かれ少なかれ変化しますので、一般的な分類は、アカウントに変化するフィールドの変化特性を取ることはありません。変化特性の少ない安定したが、より詳細な分析は、次いで、A.2で行われます。最後に、A.3は、様々なヘッダフィールドは、圧縮と機能性を最適化するために、ヘッダ圧縮方式によってどのように処理すべきかについての結論で、この付録をまとめました。
A.1. General classification
A.1。一般的分類
At a general level, the header fields are separated into 5 classes:
一般的なレベルでは、ヘッダフィールドは5つのクラスに分けられます：
INFERRED These fields contain values that can be inferred from other values, for example the size of the frame carrying the packet, and thus do not have to be handled at all by the compression scheme.
INFERREDこれらのフィールドは、例えば、パケットを運ぶフレームのサイズを他の値から推測することができる値を含むので、圧縮方式によって全く扱われなければなりません。
STATIC These fields are expected to be constant throughout the lifetime of the packet stream. Static information must in some way be communicated once.
STATICこれらのフィールドは、パケットストリームの存続期間を通じて一定であることが予想されます。静的情報は、何らかの方法で一度伝達されなければなりません。
STATIC-DEF STATIC fields whose values define a packet stream. They are in general handled as STATIC.
その値は、パケットストリームを定義するSTATIC-DEF STATICフィールド。彼らはSTATICとして扱わ一般的です。
STATIC-KNOWN These STATIC fields are expected to have well-known values and therefore do not need to be communicated at all.
STATIC-知られているこれらのSTATICフィールドは、よく知られた値を持っているため、すべてで通信する必要はありません期待されています。
CHANGING These fields are expected to vary in some way: randomly, within a limited value set or range, or in some other manner.
ランダムに、限られた値のセットまたは範囲内、または他の何らかの方法でこれらのフィールドを変更すると、いくつかの方法で変化することが予想されます。
In this section, each of the IP, UDP and RTP header fields is assigned to one of these classes. For all fields except those classified as CHANGING, the motives for the classification are also stated. In section A.2, CHANGING fields are further examined and classified on the basis of their expected change behavior.
このセクションでは、IP、UDP及びRTPヘッダフィールドのそれぞれは、これらのクラスの1つに割り当てられます。 CHANGINGとして分類されるものを除くすべてのフィールドについては、分類のための動機にも記載されています。セクションA.2では、変化するフィールドは、さらに彼らの期待変化挙動に基づいて検討し、分類されています。
A.1.1. IPv6 header fields
A.1.1。 IPv6ヘッダフィールド
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC |
| Traffic Class | 8 | CHANGING |
| Flow Label | 20 | STATIC-DEF |
| Payload Length | 16 | INFERRED |
| Next Header | 8 | STATIC |
| Hop Limit | 8 | CHANGING |
| Source Address | 128 | STATIC-DEF |
| Destination Address | 128 | STATIC-DEF |
+---------------------+-------------+----------------+
Version
版
The version field states which IP version is used. Packets with different values in this field must be handled by different IP stacks. All packets of a packet stream must therefore be of the same IP version. Accordingly, the field is classified as STATIC.
使用されているIPバージョンバージョンフィールド状態。この分野の異なる値を持つパケットは異なるIPスタックによって処理されなければなりません。パケットストリームのすべてのパケットは、したがって、同じIPバージョンでなければなりません。したがって、フィールドはSTATICとして分類されています。
Flow Label
フローラベル
This field may be used to identify packets belonging to a specific packet stream. If not used, the value should be set to zero. Otherwise, all packets belonging to the same stream must have the same value in this field, it being one of the fields that define the stream. The field is therefore classified as STATIC-DEF.
このフィールドは、特定のパケットストリームに属するパケットを識別するために使用することができます。使用されていない場合、値はゼロに設定する必要があります。それ以外の場合は、同じストリームに属するすべてのパケットが、それはストリームを定義する分野の一つであることは、このフィールドに同じ値を持つ必要があります。フィールドは、したがって、STATIC-DEFとして分類されています。
Payload Length
ペイロード長
Information about packet length (and, consequently, payload length) is expected to be provided by the link layer. The field is therefore classified as INFERRED.
パケット長（及び、従って、ペイロード長）に関する情報は、リンク層により提供されることが期待されます。フィールドには、そのためINFERREDとして分類されています。
Next Header
次のヘッダー
This field will usually have the same value in all packets of a packet stream. It encodes the type of the subsequent header. Only when extension headers are sometimes present and sometimes not, will the field change its value during the lifetime of the stream. The field is therefore classified as STATIC.
このフィールドは、通常、パケットストリームのすべてのパケットで同じ値を持つことになります。これは、後続ヘッダの種類を符号化します。拡張ヘッダが時々存在していると、時々ない場合にのみ、フィールドは、ストリームの存続期間中にその値を変更します。フィールドには、したがって、STATICとして分類されています。
Source and Destination addresses
送信元アドレスと宛先アドレス
These fields are part of the definition of a stream and must thus be constant for all packets in the stream. The fields are therefore classified as STATIC-DEF.
これらのフィールドは、ストリームの定義の一部であり、したがって、ストリーム内のすべてのパケットに対して一定でなければなりません。フィールドは、したがって、STATIC-DEFとして分類されています。
Total size of the fields in each class:
各クラスのフィールドの合計サイズ：
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 2 |
| STATIC | 1.5 |
| STATIC-DEF | 34.5 |
| CHANGING | 2 |
+--------------+--------------+
A.1.2. IPv4 header fields
A.1.2。 IPv4ヘッダフィールド
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC |
| Header Length | 4 | STATIC-KNOWN |
| Type Of Service | 8 | CHANGING |
| Packet Length | 16 | INFERRED |
| Identification | 16 | CHANGING |
| Reserved flag | 1 | STATIC-KNOWN |
| Don't Fragment flag | 1 | STATIC |
| More Fragments flag | 1 | STATIC-KNOWN |
| Fragment Offset | 13 | STATIC-KNOWN |
| Time To Live | 8 | CHANGING |
| Protocol | 8 | STATIC |
| Header Checksum | 16 | INFERRED |
| Source Address | 32 | STATIC-DEF |
| Destination Address | 32 | STATIC-DEF |
+---------------------+-------------+----------------+
Version
版
The version field states which IP version is used. Packets with different values in this field must be handled by different IP stacks. All packets of a packet stream must therefore be of the same IP version. Accordingly, the field is classified as STATIC.
使用されているIPバージョンバージョンフィールド状態。この分野の異なる値を持つパケットは異なるIPスタックによって処理されなければなりません。パケットストリームのすべてのパケットは、したがって、同じIPバージョンでなければなりません。したがって、フィールドはSTATICとして分類されています。
Header Length
ヘッダ長
As long no options are present in the IP header, the header length is constant and well known. If there are options, the fields would be STATIC, but it is assumed here that there are no options. The field is therefore classified as STATIC-KNOWN.
限りはオプションは、IPヘッダに存在しない、ヘッダの長さは一定でよく知られています。オプションがある場合は、フィールドがSTATICだろうが、それはここではオプションが存在しないと仮定されます。フィールドは、したがって、STATIC-知られているように分類されています。
Packet Length
パケット長
Information about packet length is expected to be provided by the link layer. The field is therefore classified as INFERRED.
パケット長に関する情報は、リンク層により提供されることが期待されます。フィールドには、そのためINFERREDとして分類されています。
Flags
国旗
The Reserved flag must be set to zero and is therefore classified as STATIC-KNOWN. The Don't Fragment (DF) flag will be constant for all packets in a stream and is therefore classified as STATIC.
予約フラグがゼロに設定する必要があり、従って、STATIC-公知のように分類されます。ないフラグメント（DF）フラグは、ストリーム内のすべてのパケットに対して一定であり、したがってSTATICとして分類されます。
Finally, the More Fragments (MF) flag is expected to be zero because fragmentation is NOT expected, due to the small packet size expected. The More Fragments flag is therefore classified as STATIC-KNOWN.
最後に、以上のフラグメント（MF）フラグが断片化が、予想小さなパケットサイズに起因すると予想されていないので、ゼロであると予想されます。モアフラグメントフラグが故にSTATIC-公知のように分類されます。
Fragment Offset
フラグメントオフセット
Under the assumption that no fragmentation occurs, the fragment offset is always zero. The field is therefore classified as STATIC-KNOWN.
フラグメンテーションが発生しないという仮定の下では、フラグメントオフセットは常にゼロです。フィールドは、したがって、STATIC-知られているように分類されています。
Protocol
プロトコル
This field will usually have the same value in all packets of a packet stream. It encodes the type of the subsequent header. Only when extension headers are sometimes present and sometimes not, will the field change its value during the lifetime of a stream. The field is therefore classified as STATIC.
このフィールドは、通常、パケットストリームのすべてのパケットで同じ値を持つことになります。これは、後続ヘッダの種類を符号化します。拡張ヘッダが時々存在していると、時々ない場合にのみ、フィールドは、ストリームの存続期間中にその値を変更します。フィールドには、したがって、STATICとして分類されています。
Header Checksum
ヘッダチェックサム
The header checksum protects individual hops from processing a corrupted header. When almost all IP header information is compressed away, there is no point in having this additional checksum; instead it can be regenerated at the decompressor side. The field is therefore classified as INFERRED.
ヘッダチェックサムが破損ヘッダを処理することから、個々のホップを保護します。ほぼすべてのIPヘッダ情報を離れる圧縮されたときに、この追加のチェックサムを有するにも意味がありません。その代わりに、デコンプレッサ側で再生することができます。フィールドには、そのためINFERREDとして分類されています。
Source and Destination addresses
送信元アドレスと宛先アドレス
These fields are part of the definition of a stream and must thus be constant for all packets in the stream. The fields are therefore classified as STATIC-DEF.
これらのフィールドは、ストリームの定義の一部であり、したがって、ストリーム内のすべてのパケットに対して一定でなければなりません。フィールドは、したがって、STATIC-DEFとして分類されています。
Total size of the fields in each class:
各クラスのフィールドの合計サイズ：
+--------------+----------------+
| Class | Size (octets) |
+--------------+----------------+
| INFERRED | 4 |
| STATIC | 1 oct + 5 bits |
| STATIC-DEF | 8 |
| STATIC-KNOWN | 2 oct + 3 bits |
| CHANGING | 4 |
+--------------+----------------+
A.1.3. UDP header fields
A.1.3。 UDPヘッダフィールド
+------------------+-------------+-------------+
| Field | Size (bits) | Class |
+------------------+-------------+-------------+
| Source Port | 16 | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF |
| Length | 16 | INFERRED |
| Checksum | 16 | CHANGING |
+------------------+-------------+-------------+
Source and Destination ports
送信元ポートと宛先ポート
These fields are part of the definition of a stream and must thus be constant for all packets in the stream. The fields are therefore classified as STATIC-DEF.
これらのフィールドは、ストリームの定義の一部であり、したがって、ストリーム内のすべてのパケットに対して一定でなければなりません。フィールドは、したがって、STATIC-DEFとして分類されています。
Length
長さ
This field is redundant and is therefore classified as INFERRED.
このフィールドは、冗長であり、従って、推測される分類されます。
Total size of the fields in each class:
各クラスのフィールドの合計サイズ：
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| INFERRED | 2 |
| STATIC-DEF | 4 |
| CHANGING | 2 |
+------------+---------------+
A.1.4. RTP header fields
A.1.4。 RTPヘッダフィールド
+-----------------+-------------+----------------+
| Field | Size (bits) | Class |
+-----------------+-------------+----------------+
| Version | 2 | STATIC-KNOWN |
| Padding | 1 | STATIC |
| Extension | 1 | STATIC |
| CSRC Counter | 4 | CHANGING |
| Marker | 1 | CHANGING |
| Payload Type | 7 | CHANGING |
| Sequence Number | 16 | CHANGING |
| Timestamp | 32 | CHANGING |
| SSRC | 32 | STATIC-DEF |
| CSRC | 0(-480) | CHANGING |
+-----------------+-------------+----------------+
Version
版
Only one working RTP version exists, namely version 2. The field is therefore classified as STATIC-KNOWN.
一つだけの作業RTPバージョン、すなわちバージョン2フィールドは従ってSTATIC-知られているように分類され、存在します。
Padding
パディング
The use of this field is application-dependent, but when payload padding is used it is likely to be present in all packets. The field is therefore classified as STATIC.
このフィールドの使用は、アプリケーションに依存するが、ペイロードのパディングが使用されるとき、すべてのパケット中に存在する可能性が高いです。フィールドには、したがって、STATICとして分類されています。
Extension
拡張
If RTP extensions are used by the application, these extensions are likely to be present in all packets (but the use of extensions is very uncommon). However, for safety's sake this field is classified as STATIC and not STATIC-KNOWN.
RTPの拡張がアプリケーションによって使用されている場合は、これらの拡張機能は、すべてのパケット中に存在する可能性がある（ただし、拡張子の使用は非常にまれです）。しかし、安全のため、この分野はSTATICとして分類され、STATIC知られていません。
SSRC
SSRC
This field is part of the definition of a stream and must thus be constant for all packets in the stream. The field is therefore classified as STATIC-DEF.
このフィールドは、ストリームの定義の一部であり、従って、ストリーム内のすべてのパケットに対して一定でなければなりません。フィールドは、したがって、STATIC-DEFとして分類されています。
Total size of the fields in each class:
各クラスのフィールドの合計サイズ：
+--------------+---------------+
| Class | Size (octets) |
+--------------+---------------+
| STATIC | 2 bits |
| STATIC-DEF | 4 |
| STATIC-KNOWN | 2 bits |
| CHANGING | 7.5(-67.5) |
+--------------+---------------+
A.1.5. Summary for IP/UDP/RTP
A.1.5。 IP / UDP / RTPのための概要
Summarizing this for IP/UDP/RTP one obtains
IP / UDP / RTP 1取得のためにこれをまとめます
+----------------+----------------+----------------+
| Class \ IP ver | IPv6 (octets) | IPv4 (octets) |
+----------------+----------------+----------------+
| INFERRED | 4 | 6 |
| STATIC | 1 oct + 6 bits | 1 oct + 7 bits |
| STATIC-DEF | 42.5 | 16 |
| STATIC-KNOWN | 2 bits | 2 oct + 5 bits |
| CHANGING | 11.5(-71.5) | 13.5(-73.5) |
+----------------+----------------+----------------+
| Total | 60(-120) | 40(-100) |
+----------------+----------------+----------------+
A.2. Analysis of change patterns of header fields
A.2。ヘッダーフィールドの変化パターンの分析
To design suitable mechanisms for efficient compression of all header fields, their change patterns must be analyzed. For this reason, an extended classification is done based on the general classification in A.1, considering the fields which were labeled CHANGING in that classification. Different applications will use the fields in different ways, which may affect their behavior. For the fields whose behavior is variable, typical behavior for conversational audio and video will be discussed.
全てのヘッダフィールドの効率的な圧縮のための適切な機構を設計するために、それらの変化パターンを分析しなければなりません。このため、拡張された分類は、その分類に変化する標識したフィールドを考慮すると、A.1での一般的な分類に基づいて行われます。異なるアプリケーションは彼らの行動に影響を与える可能性がある、さまざまな方法でフィールドを使用します。その行動変数であるフィールドでは、会話のオーディオおよびビデオのための典型的な動作について説明します。
The CHANGING fields are separated into five different subclasses:
変化するフィールドは、5つの異なるサブクラスに分けられます：
STATIC These are fields that were classified as CHANGING on a general basis, but are classified as STATIC here due to certain additional assumptions.
STATICこれらは一般的に変更するなど、分類されたが、原因特定の追加の前提条件に、ここでSTATICとして分類されているフィールドです。
SEMISTATIC These fields are STATIC most of the time. However, occasionally the value changes but reverts to its original value after a known number of packets.
半静的これらのフィールドは、ほとんどの時間をSTATICです。しかし、時には値の変化が、パケットの既知の数の後に元の値に戻ります。
RARELY-CHANGING (RC) These are fields that change their values occasionally and then keep their new values.
めったに変化（RC）これらは、時折、それらの値を変更して、その新しい値を保つフィールドです。
ALTERNATING These fields alternate between a small number of different values.
異なる値の数が少ないとの間の代替これらのフィールドを交互。
IRREGULAR These, finally, are the fields for which no useful change pattern can be identified.
これらのIRREGULAR、最終的には、有用な変化パターンを識別できないそのためのフィールドがあります。
To further expand the classification possibilities without increasing complexity, the classification can be done either according to the values of the field and/or according to the values of the deltas for the field.
さらに複雑さを増すことなく、分類の可能性を拡大するために、分類は、フィールドの値に応じて、および/またはフィールドの差分の値に応じていずれかで行うことができます。
When the classification is done, other details are also stated regarding possible additional knowledge about the field values and/or field deltas, according to the classification. For fields classified as STATIC or SEMISTATIC, the case could be that the value of the field is not only STATIC but also well KNOWN a priori (two states for SEMISTATIC fields). For fields with non-irregular change behavior, it could be known that changes usually are within a LIMITED range compared to the maximal change for the field. For other fields, the values are completely UNKNOWN.
分類が行われた場合、その他の詳細は、分類に従って、フィールド値および/またはフィールドデルタについての可能な追加の知識に関して記載されています。静的または半静的に分類フィールドの場合、ケースは、フィールドの値（半静的フィールドの二つの状態）、先験的STATICもよく知られていないだけであることとすることができます。非不規則な変化挙動を持つフィールドの場合は、変更は通常、フィールドの最大の変化と比べて限られた範囲内にあることが知られていることができました。他のフィールドの場合、値は完全に不明です。
Table A.1 classifies all the CHANGING fields on the basis of their expected change patterns, especially for conversational audio and video.
表A.1は、特に会話オーディオとビデオのために、彼らの期待される変化パターンに基づいて、すべての変化するフィールドを分類します。
+------------------------+-------------+-------------+-------------+
| Field | Value/Delta | Class | Knowledge |
+========================+=============+=============+=============+
| Sequential | Delta | STATIC | KNOWN |
| -----------+-------------+-------------+-------------+
| IPv4 Id: Seq. jump | Delta | RC | LIMITED |
| -----------+-------------+-------------+-------------+
| Random | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| IP TOS / Tr. Class | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| IP TTL / Hop Limit | Value | ALTERNATING | LIMITED |
+------------------------+-------------+-------------+-------------+
| Disabled | Value | STATIC | KNOWN |
| UDP Checksum: ---------+-------------+-------------+-------------+
| Enabled | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| No mix | Value | STATIC | KNOWN |
| RTP CSRC Count: -------+-------------+-------------+-------------+
| Mixed | Value | RC | LIMITED |
+------------------------+-------------+-------------+-------------+
| RTP Marker | Value | SEMISTATIC | KNOWN/KNOWN |
+------------------------+-------------+-------------+-------------+
| RTP Payload Type | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| RTP Sequence Number | Delta | STATIC | KNOWN |
+------------------------+-------------+-------------+-------------+
| RTP Timestamp | Delta | RC | LIMITED |
+------------------------+-------------+-------------+-------------+
| No mix | - | - | - |
| RTP CSRC List: -------+-------------+-------------+-------------+
| Mixed | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
Table A.1 : Classification of CHANGING header fields
表A.1：CHANGINGヘッダーフィールドの分類
The following subsections discuss the various header fields in detail. Note that table A.1 and the discussions below do not consider changes caused by loss or reordering before the compression point.
以下のサブセクションでは、詳細に、様々なヘッダフィールドを議論します。その表A.1に注意し、以下の議論は圧縮ポイントの前損失や並べ替えにより生じた変化を考慮していません。
A.2.1. IPv4 Identification
A.2.1。 IPv4の識別
The Identification field (IP ID) of the IPv4 header is there to identify which fragments constitute a datagram when reassembling fragmented datagrams. The IPv4 specification does not specify exactly how this field is to be assigned values, only that each packet should get an IP ID that is unique for the source-destination pair and protocol for the time the datagram (or any of its fragments) could be alive in the network. This means that assignment of IP ID values can be done in various ways, which we have separated into three classes.
IPv4ヘッダの識別フィールド（IP ID）が断片化されたデータグラムを再組み立ての際に、データグラムを構成するフラグメントを同定するために存在します。 IPv4の仕様では、各パケットは、時間グラム（またはそのフラグメントのいずれか）のための送信元と宛先のペアとプロトコルのためのユニークなIPのIDを取得する必要がありますだけで、このフィールドに値を割り当てられる方法を正確に指定していない可能性がありネットワークで生きています。これは、IP ID値の割り当ては、我々は3つのクラスに分けている様々な方法で行うことができることを意味します。
Sequential jump
シーケンシャルジャンプ
This is the most common assignment policy in today's IP stacks. A single IP ID counter is used for all packet streams. When the sender is running more than one packet stream simultaneously, the IP ID can increase by more than one between packets in a stream. The IP ID values will be much more predictable and require less bits to transfer than random values, and the packet-to-packet increment (determined by the number of active outgoing packet streams and sending frequencies) will usually be limited.
これは、今日のIPスタックで最も一般的な割り当てポリシーです。単一のIP IDカウンタは、すべてのパケットストリームのために使用されています。送信者が同時に複数のパケットストリームを実行している場合は、IP IDは、ストリーム内のパケットの間に複数のことで増やすことができます。 IP IDの値ははるかに予測可能と乱数値よりも転送するために少ないビットを必要とし、（アクティブ発信パケットストリームと送信周波数の数によって決定される）パケット間の増分は、通常、制限されるであろう。
Random
ランダム
Some IP stacks assign IP ID values using a pseudo-random number generator. There is thus no correlation between the ID values of subsequent datagrams. Therefore there is no way to predict the IP ID value for the next datagram. For header compression purposes, this means that the IP ID field needs to be sent uncompressed with each datagram, resulting in two extra octets of header. IP stacks in cellular terminals SHOULD NOT use this IP ID assignment policy.
一部のIPスタックは、擬似乱数生成器を使用してIP ID値を割り当てます。後続のデータグラムのID値の間には相関性が存在しません。したがって、次のデータグラムのIP ID値を予測する方法はありません。ヘッダ圧縮の目的のために、これはIP IDフィールドは、ヘッダの2つの余分なオクテットで、その結果、各データグラムを用いて圧縮されていない送信する必要があることを意味します。携帯端末でのIPスタックは、このIP IDの割り当てポリシーを使用しないでください。
Sequential
シーケンシャル
This assignment policy keeps a separate counter for each outgoing packet stream and thus the IP ID value will increment by one for each packet in the stream, except at wrap around. Therefore, the delta value of the field is constant and well known a priori. When RTP is used on top of UDP and IP, the IP ID value follows the RTP Sequence Number. This assignment policy is the most desirable for header compression purposes. However, its usage is not as common as it perhaps should be. The reason may be that it can be realized only when UDP and IP are implemented together so that UDP, which separates packet streams by the Port identification fields, can make IP use separate ID counters for each packet stream.
この割り当てポリシーは、各発信パケットストリームのための別々のカウンタを保持しますので、IPのID値は、ラップアラウンドを除き、ストリーム内の各パケットに対して1ずつ増加します。したがって、フィールドのデルタ値は一定でよく事前に知られています。 RTPは、UDPおよびIPの上で使用されている場合は、IP ID値は、RTPシーケンス番号に従います。この割り当てポリシーは、ヘッダ圧縮の目的のために最も望ましいです。しかし、その使用は、それはおそらくあるべきほど一般的ではありません。その理由は、ポート識別フィールドによって、パケットストリームを分離UDPは、IPは、各パケットストリームの別IDカウンタを使用することができるように、UDP及びIPが一緒に実装されている場合にのみ、それが実現できることとすることができます。
In order to avoid violating [IPv4], packets sharing the same IP address pair and IP protocol number cannot use the same IP ID values. Therefore, implementations of sequential policies must make the ID number spaces disjoint for packet streams of the same IP protocol going between the same pair of nodes. This can be done in a number of ways, all of which introduce occasional jumps, and thus makes the policy less than perfectly sequential. For header compression purposes less frequent jumps are preferred.
【のIPv4]を違反を回避するために、同一のIPアドレス対とIPプロトコル番号を共有するパケットが同じIP ID値を使用することはできません。したがって、連続的な政策の実装は、ノードの同じペアの間に行くのと同じIPプロトコルのパケットストリームのためのID番号スペースがばらばらにする必要があります。これは、時折ジャンプを導入し、これにより完全にシーケンシャルよりも政策少なくなり、すべてのそれらの多くの方法で行うことができます。ヘッダ圧縮のためにあまり頻繁にジャンプが好ましいです。
It should be noted that the ID is an IPv4 mechanism and is therefore not a problem for IPv6. For IPv4 the ID could be handled in three different ways. First, we have the inefficient but reliable solution where the ID field is sent as-is in all packets, increasing the compressed headers by two octets. This is the best way to handle the ID field if the sender uses random assignment of the ID field. Second, there can be solutions with more flexible mechanisms requiring less bits for the ID handling as long as sequential jump assignment is used. Such solutions will probably require even more bits if random assignment is used by the sender. Knowledge about the sender's assignment policy could therefore be useful when choosing between the two solutions above. Finally, even for IPv4, header compression could be designed without any additional information for the ID field included in compressed headers. To use such schemes, it must be known which assignment policy for the ID field is being used by the sender. That might not be possible to know, which implies that the applicability of such solutions is very uncertain. However, designers of IPv4 stacks for cellular terminals SHOULD use an assignment policy close to sequential.
IDがIPv4機構であるため、IPv6のための問題ではないことに留意すべきです。 IPv4のIDは、3つの異なる方法で処理することができます。まず、IDフィールドは2つのオクテットで圧縮されたヘッダを高め、すべてのパケットにそのまま送信される非効率的なが、信頼性の高いソリューションを持っています。これは、送信者がIDフィールドのランダムな割り当てを使用している場合、IDフィールドを処理するための最良の方法です。第二に、限り順次ジャンプ割り当てが使用されるIDの処理のために少ないビットを必要とする、より柔軟なメカニズムを有する溶液が存在し得ます。ランダムな割り当ては、送信者によって使用されている場合、このようなソリューションは、おそらく多くのビットを必要とします。上記の二つのソリューションの間で選択する際に、送信者の割り当てポリシーについての知識が有用である可能性があります。最後に、偶数IPv4のため、ヘッダ圧縮は圧縮ヘッダに含まれるIDフィールドの追加情報なしで設計することができます。そのようなスキームを使用するには、IDフィールドの割り当てポリシーは、送信者によって使用されているかを知らなければなりません。それは、このようなソリューションの適用は非常に不確実であることを意味する、知ることはできないかもしれません。携帯端末は、順次に近い割当ポリシーを使用すべきであるためしかし、IPv4のの設計者はスタック。
A.2.2. IP Traffic-Class / Type-Of-Service
A.2.2。 IPトラフィッククラス/サービス型
The Traffic-Class (IPv6) or Type-Of-Service (IPv4) field is expected to be constant during the lifetime of a packet stream or to change relatively seldom.
トラフィッククラス（IPv6）のまたはサービス型（IPv4）のフィールドは、パケットストリームの存続期間中に一定になるように、または比較的ほとんど変わらないと予想されます。
A.2.3. IP Hop-Limit / Time-To-Live
A.2.3。 IPホップリミット/生存時間
The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be constant during the lifetime of a packet stream or to alternate between a limited number of values due to route changes.
ホップリミット（IPv6）のまたはタイム・ツー・ライブ（IPv4）のフィールドは、パケットストリームの存続期間中に一定に又はルート変更に起因する値の制限された数との間で交互することが期待されます。
A.2.4. UDP Checksum
A.2.4。 UDPチェックサム
The UDP checksum is optional. If disabled, its value is constantly zero and could be compressed away. If enabled, its value depends on the payload, which for compression purposes is equivalent to it changing randomly with every packet.
UDPチェックサムはオプションです。無効にした場合、その値は常にゼロであると離れて圧縮することができます。有効にした場合、その値は、圧縮の目的のために、それはすべてのパケットをランダムに変更することに相当し、ペイロードに依存します。
A.2.5. RTP CSRC Counter
A.2.5。 RTP CSRCカウンター
This is a counter indicating the number of CSRC items present in the CSRC list. This number is expected to be almost constant on a packet- to-packet basis and change by small amounts. As long as no RTP mixer is used, the value of this field is zero.
これは、CSRCリストに存在CSRCアイテムの数を示すカウンタです。この番号は、パケット交換のパケットベースではほぼ一定であると、少量で変化することが予想されます。限りないRTPミキサを使用しないように、このフィールドの値はゼロです。
A.2.6. RTP Marker
A.2.6。 RTPマーカー
For audio the marker bit should be set only in the first packet of a talkspurt, while for video it should be set in the last packet of every picture. This means that in both cases the RTP marker is classified as SEMISTATIC with well-known values for both states.
ビデオのために、それはすべての映像の最後のパケットに設定する必要がありながら、オーディオ用マーカービットは、有音部の最初のパケットにのみ設定する必要があります。これは、両方のケースでRTPマーカーが両方の状態のためのよく知られた値を使用して半止水として分類されることを意味します。
A.2.7. RTP Payload Type
A.2.7。 RTPペイロードタイプ
Changes of the RTP payload type within a packet stream are expected to be rare. Applications could adapt to congestion by changing payload type and/or frame sizes, but that is not expected to happen frequently.
パケットストリーム内のRTPペイロードタイプの変更は稀であると予想されます。アプリケーションは、ペイロードタイプおよび/またはフレームサイズを変更することにより、輻輳に適応することができ、それが頻繁に発生すると予想されていません。
A.2.8. RTP Sequence Number
A.2.8。 RTPシーケンス番号
The RTP Sequence Number will be incremented by one for each packet sent.
RTPシーケンス番号が送信されたパケットごとに1ずつインクリメントされます。
A.2.9. RTP Timestamp
A.2.9。 RTPタイムスタンプ
In the audio case:
オーディオの場合：
As long as there are no pauses in the audio stream, the RTP Timestamp will be incremented by a constant delta, corresponding to the number of samples in the speech frame. It will thus mostly follow the RTP Sequence Number. When there has been a silent period and a new talkspurt begins, the timestamp will jump in proportion to the length of the silent period. However, the increment will probably be within a relatively limited range.
限りオーディオストリームには休止がないように、RTPタイムスタンプは、音声フレームのサンプル数に対応し、一定のデルタによってインクリメントされます。したがって、主にRTPシーケンス番号に従います。そこに沈黙期間となって、新たな有音が開始された場合、タイムスタンプは、サイレント期間の長さに比例してジャンプします。しかし、増分はおそらく、比較的限られた範囲内であろう。
In the video case:
ビデオの場合：
Between two consecutive packets, the timestamp will either be unchanged or increase by a multiple of a fixed value corresponding to the picture clock frequency. The timestamp can also decrease by a multiple of the fixed value if B-pictures are used. The delta interval, expressed as a multiple of the picture clock frequency, is in most cases very limited.
二つの連続するパケット間の、タイムスタンプが変更されませんいずれか又は画像クロック周波数に対応する固定値の倍数で増加します。 Bピクチャが使用される場合、タイムスタンプは、固定値の倍数だけ減少させることができます。デルタ間隔は、ほとんどの場合、非常に限られている、画像クロック周波数の倍数として表しました。
A.2.10. RTP Contributing Sources (CSRC)
A.2.10。 RTP貢献ソース（CSRC）
The participants in a session, which are identified by the CSRC fields, are expected to be almost the same on a packet-to-packet basis with relatively few additions and removals. As long as RTP mixers are not used, no CSRC fields are present at all.
CSRCフィールドで識別されるセッションの参加者は、比較的少数の追加と削除でパケット間ベースでほぼ同じであると予想されます。限りRTPミキサーが使用されていないとして、何のCSRCフィールドが全く存在しません。
A.3. Header compression strategies
A.3。ヘッダ圧縮戦略
This section elaborates on what has been done in previous sections. On the basis of the classifications, recommendations are given on how to handle the various fields in the header compression process. Seven different actions are possible; these are listed together with the fields to which each action applies.
このセクションでは、前のセクションで何が行われたかについて詳しく説明します。分類に基づいて、推奨は、ヘッダ圧縮プロセス中の様々なフィールドを処理する方法について説明しています。 7種類のアクションが可能です。これらは、各アクションが適用されるフィールドと一緒に記載されています。
A.3.1. Do not send at all
A.3.1。まったく送信しないでください
The fields that have well known values a priori do not have to be sent at all. These are:
よく知られている値のフィールドは、先験的にはまったく送信する必要はありません。これらは：
- IPv6 Payload Length - IPv4 Header Length - IPv4 Reserved Flag - IPv4 Last Fragment Flag - IPv4 Fragment Offset
- IPv6のペイロード長 - のIPv4ヘッダ長 - IPv4の予約旗 - IPv4の最後の断片旗 - IPv4のフラグメントオフセット
- UDP Checksum (if disabled) - RTP Version
- UDPチェックサム（無効の場合） - RTPのバージョン
A.3.2. Transmit only initially
A.3.2。のみ最初に送信
The fields that are constant throughout the lifetime of the packet stream have to be transmitted and correctly delivered to the decompressor only once. These are:
パケットストリームの存続期間を通じて一定であるフィールドが送信され、正常に一度だけ解凍器に配信する必要があります。これらは：
- IP Version - IP Source Address - IP Destination Address - IPv6 Flow Label - IPv4 May Fragment Flag - UDP Source Port - UDP Destination Port - RTP Padding Flag - RTP Extension Flag - RTP SSRC
- IPバージョン - IPソースアドレス - IP宛先アドレス - IPv6のフローラベル - IPv4の月断片旗 - UDP送信元ポート - UDP宛先ポート - RTPパディング旗 - RTP拡張旗 - RTP SSRC
A.3.3. Transmit initially, but be prepared to update
A.3.3。最初に送信しますが、更新する準備ができて
The fields that are changing only occasionally must be transmitted initially but there must also be a way to update these fields with new values if they change. These fields are:
たまにしか変更されているフィールドは、最初に送信しなければならないだけでなく、彼らは変更する場合、新しい値で、これらのフィールドを更新する方法がなければなりません。これらのフィールドは以下のとおりです。
- IPv6 Next Header - IPv6 Traffic Class - IPv6 Hop Limit - IPv4 Protocol - IPv4 Type Of Service (TOS) - IPv4 Time To Live (TTL) - RTP CSRC Counter - RTP Payload Type - RTP CSRC List
- IPv6の次のヘッダ - IPv6のトラフィッククラス - IPv6のホップ制限 - IPv4のプロトコル - サービスのIPv4のタイプ（TOS） - IPv4の時間（TTL）存続 - RTP CSRCカウンター - RTPペイロードタイプ - RTP CSRCリスト
Since the values of the IPv4 Protocol and the IPv6 Next Header fields are in effect linked to the type of the subsequent header, they deserve special treatment when subheaders are inserted or removed.
IPv4プロトコルとIPv6の次のヘッダフィールドの値が実際に後続のヘッダのタイプにリンクされているので、サブヘッダが挿入または削除されたとき、それらは、特別な治療に値します。
A.3.4. Be prepared to update or send as-is frequently
A.3.4。頻繁にあるとして、更新または送信するために調製することが
For fields that normally either are constant or have values deducible from some other field, but that frequently diverge from that behavior, there must be an efficient way to update the field value or send it as-is in some packets. These fields are:
通常どちらかが一定であるか、他のいくつかのフィールドから推定値を持っているが、それは頻繁にその振る舞いから発散するフィールドの場合、フィールドの値を更新したり、いくつかのパケットに-あるとして、それを送信するための効率的な方法がなければなりません。これらのフィールドは以下のとおりです。
- IPv4 Identification (if not sequentially assigned) - RTP Marker - RTP Timestamp
- （順次割り当てられていない場合）はIPv4身分 - RTPマーカ - RTPタイムスタンプ
A.3.5. Guarantee continuous robustness
A.3.5。連続堅牢性を保証
For fields that behave like a counter with a fixed delta for ALL packets, the only requirement on the transmission encoding is that packet losses between compressor and decompressor must be tolerable. If several such fields exist, all these can be communicated together. Such fields can also be used to interpret the values for fields listed in the previous section. Fields that have this counter behavior are:
すべてのパケットのための固定されたデルタを有するカウンタのように動作フィールドに、送信符号化の唯一の要件は、コンプレッサとデコンプレッサとの間のパケットロスが許容しなければならないことです。いくつかのようなフィールドが存在する場合、これらすべてが一緒に伝達することができます。そのようなフィールドは、前のセクションに記載されているフィールドの値を解釈するために使用することができます。このカウンタの動作を持っているフィールドは、次のとおりです。
- IPv4 Identification (if sequentially assigned) - RTP Sequence Number
- IPv4の識別（順次割り当てられている場合） - RTPシーケンス番号
A.3.6. Transmit as-is in all packets
A.3.6。すべてのパケットであるとして、送信
Fields that have completely random values for each packet must be included as-is in all compressed headers. Those fields are:
全ての圧縮ヘッダにそのまま各パケットの完全にランダムな値を持つフィールドが含まれていなければなりません。これらのフィールドは次のとおりです。
- IPv4 Identification (if randomly assigned) - UDP Checksum (if enabled)
- IPv4の識別（ランダムに割り当てられている場合） - UDPチェックサム（有効な場合）
A.3.7. Establish and be prepared to update delta
A.3.7。確立し、デルタを更新するように調製することが
Finally, there is a field that is usually increasing by a fixed delta and is correlated to another field. For this field it would make sense to make that delta part of the context state. The delta must then be initiated and updated in the same way as the fields listed in A.3.3. The field to which this applies is:
最後に、通常一定のデルタによって増加され、別のフィールドに相関している分野があります。このフィールドのためには、コンテキスト状態のデルタ部分を作るために意味をなさないと思います。デルタは、A.3.3に表示されるフィールドと同じ方法で開始され、更新されなければなりません。これが適用されるフィールドは次のとおりです。
- RTP Timestamp
- RTPタイムスタンプ
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。