[要約] RFC 3095は、ROHC（Robust Header Compression）のフレームワークと4つのプロファイル（RTP、UDP、ESP、非圧縮）に関する規格です。ROHCは、ネットワーク上でヘッダの圧縮を行うことで、帯域幅の効率化と通信の信頼性向上を目指しています。
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
堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮
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.
Copyright（c）The Internet Society（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つの通信技術が一般大衆によって一般的に使用されてきました：携帯電話とインターネット。Cellular Thelephonyは、ユーザーがどこにいても、合理的なサービス品質で常に到達できる革新的な可能性を提供しました。専用のターミナルが提供する主なサービスはスピーチでした。一方、インターネットは最初から複数のサービス用に設計されており、あらゆる種類の使用に対する柔軟性はその強みの1つです。インターネット端末は通常、汎用であり、固定接続に添付されています。一部のサービス（インターネットテレフォニーなど）の経験豊富な品質が低い場合があります。
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.
次に、私たちが想定しているシナリオの1つは、2つのモバイル端子が互いに通信している図1.1のシナリオである可能性があります。どちらもセルラーリンク上のベースステーションに接続されており、ベースステーションは有線（またはおそらくワイヤレス）ネットワークを介して互いに接続されています。2つのモバイル端子の代わりに、もちろん1つのモバイルと1つの有線端子がある可能性がありますが、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.
インタラクティブな音声会話に使用される場合のCellularリンクを介したIPの問題は、大きなヘッダーオーバーヘッドです。IPテレフォニーの音声データは、おそらくRTP [RTP]によって運ばれます。パケットは、リンクレイヤーフレーミングに加えて、IP [IPv4]ヘッダー（20オクテット）、UDP [UDP]ヘッダー（8オクテット）、および合計40オクテットのRTPヘッダー（12オクテット）を持ちます。IPv6 [IPv6]を使用すると、IPヘッダーは40オクテットで、合計60オクテットです。ペイロードのサイズは、音声コーディングとフレームサイズが使用されていることに依存し、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）が受け入れる必要があるセルラーリンクの喪失の動作です。重度の動作状況では、BERは1E-2になる可能性があります。もう1つの問題のある特性は、細胞リンクの長い往復時間（RTT）です。これは、100〜200ミリ秒ほどの高さです。追加の問題は、残留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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
ヘッダー圧縮スキームのパフォーマンスは、圧縮効率、堅牢性、圧縮透明度の3つのパラメーターで説明できます。圧縮効率は、圧縮スキームによってヘッダーサイズがどれだけ削減されるかによって決まります。
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.
ヘッダー圧縮スキームのパフォーマンスは、圧縮効率、堅牢性、圧縮透明度の3つのパラメーターで説明できます。圧縮透明性は、減圧ヘッダーが元のヘッダーと意味的に同一であることをスキームが保証する程度の尺度です。すべての減圧ヘッダーが対応する元のヘッダーと意味的に同一である場合、透明性は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-Modeおよび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-ModeのコンテキストのACKベースの更新、UおよびOモードの変更後の繰り返し、およびコンテキストの更新を保護するCRCSもあります。情報。
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計算の中間結果は、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.
以前のヘッダーまたはフィードバックのエラー（つまり、損失または損傷）またはフィードバックのために、誤った減圧ヘッダーの配信。
Loss propagation
損失伝播
Loss of headers, due to errors in (i.e., loss of or damage to) previous header(s)or feedback.
以前のヘッダーまたはフィードバックのエラー（すなわち、損失の損失または損傷）によるヘッダーの喪失。
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
以前のリンク
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.
PRE-HCリンクはすべて、ヘッダー圧縮ポイントの前にパケットが通過したリンクです。セルラーリンクを最初と最後のホップとするパスを考慮すると、最後のリンクのコンプレッサーのPRE-HCリンクは、最初のセルラーリンクとその間の有線リンクです。
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.
ヘッダー圧縮スキームのパフォーマンスは、圧縮効率、堅牢性、圧縮透明度の3つのパラメーターで説明できます。堅牢なスキームは、追加のパケットを失ったり、減圧ヘッダーに追加のエラーを導入せずに、ヘッダー圧縮が行われるリンクの損失と残留エラーを許容します。
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。RFC2508。CTCP圧縮TCP。VJヘッダー圧縮とも呼ばれます。RFC 1144.セキュリティペイロードをカプセル化するESP。FCフルコンテキスト状態（減圧装置）。FOファーストオーダー状態（コンプレッサー）。GREジェネリックルーティングカプセル化。RFC 2784、RFC2890。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リアルタイムプロトコル。RFC1889。RTTラウンドトリップ時間（セクション2を参照）。SC静的コンテキスト状態（減圧装置）。SN（圧縮）シーケンス番号。通常、RTPシーケンス番号。したがって、二次状態（コンプレッサー）。SPIセキュリティパラメーターインデックス。SSRC送信ソース。RTPヘッダーのフィールド。CSRC寄与源。RTPヘッダーのCSRCのオプションリスト。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]は、Van Jacobsonによって発明されました。CTCPは、40オクテットIP TCPヘッダーを4オクテットに圧縮します。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の修復メカニズムは、修理を高速化するリンクレベルのナックスキームで増強されます。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とJacobsonによるCRTP [CRTP、IPHC]は、UDPチェックサムが有効になっていない場合に、IPv4/UDP/RTPヘッダーの40オクテットを最低2オクテットに圧縮するヘッダー圧縮スキームです。UDPチェックサムが有効になっている場合、最小CRTPヘッダーは4オクテットです。UDP/RTPは再送信されないため、CRTPはCTCPと同じ修復メカニズムを使用できません。代わりに、CRTPは、Context_Stateメッセージと呼ばれるDecompressorからコンプレッサーへの明示的なシグナリングメッセージを使用して、コンテキストが同期していないことを示します。したがって、リンクの往復時間は、このコンテキスト修復メカニズムの速度を制限します。
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減圧装置は、2回と呼ばれるメカニズムを使用してコンテキストをローカルで修復しようとします。各CRTPパケットには、CRTPコンプレッサーによって送信された各パケットに対して1つずつインクリメントされるカウンターが含まれています。カウンターが複数増加すると、リンク上で少なくとも1つのパケットが失われました。減圧器は、失われたパケットがどのように更新されたかを推測することにより、コンテキストを修復しようとします。その後、パケットを減圧してUDPチェックサムをチェックすることにより、推測が検証されます。成功した場合、修理は成功し、パケットを転送または配信できます。圧縮されたパケットストリームが規則的である場合、正しい推測は現在のパケットにアップデートを2回適用することであるという観察結果から2回派生します。[CRTPC]は、2回でもCRTPが失われたパケットの数を2倍にすることを発見しました。CRTPのパフォーマンスを2回改善します。ただし、2回使用することにはいくつかの問題があります。
1) It becomes mandatory to use the UDP Checksum:
1) UDPチェックサムを使用することが必須になります。
- the minimal compressed header size increases by 100% to 4 octets.
- 最小限の圧縮ヘッダーサイズは、100％から4オクテット増加します。
- 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ヘッダーの更新が規則的ではありません。2回のシンプルなバージョンがひどくパフォーマンスを発揮します。より洗練されたバージョンでは、成功するためにより多くの修理の試みが必要になります。
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.
また、Speech Codecsは、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に詳細に分類されています。フィールドは最初に高レベルで分類され、そのうちのいくつかはより詳細に研究されています。最後に、付録は、ヘッダー圧縮アルゴリズムによってさまざまなフィールドをどのように処理するかについての推奨事項で終了します。描くことができる主な結論は、ほとんどのヘッダーフィールドが決して変化しないかめったに変わらないため、簡単に圧縮できるということです。合計サイズの約10オクテットの5つのフィールドのみが、より洗練されたメカニズムが必要です。これらのフィールドは次のとおりです。
- 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シーケンス番号から予測できることが明らかになりました。これは、RTPソースによって放出されるパケットごとに1つずつ増加します。M-BITも通常同じですが、時々明示的に通信する必要があります。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.
モバイルIP（IPv4またはIPv6用）に固有のヘッダーは、このドキュメントで特別な処理を受けません。ただし、それらは圧縮可能であり、拡張ヘッダーリストとトンネリングヘッダーの取り扱いにより、モバイルIPヘッダーの圧縮効率は十分であると予想されます。モバイルIPv6固有のヘッダーの特別な処理で新しいROHCプロファイルを導入することは、モバイルIPv6プロトコル（IETFで進行中の作業）で完了した作業が必要な場合に比較的痛みがありません。
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ヘッダーのエラー検出を展開することをお勧めします。
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つの方法のいずれかを選択することを示します。
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、IP-ID特性（ネットワークバイトの順序で16ビット値として増加する？ランダム？）、多くの古い参照ヘッダー、およびコンプレッサー/分解器状態マシン（次のセクションを参照）。
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.
このドキュメントでは、実際に4つのROHCプロファイルを定義します。1つの非圧縮プロファイル、メインROHC RTP圧縮プロファイル、およびそれぞれUDPとESPで終わるヘッダーチェーンを備えたパケットの圧縮のためのこのプロファイルの2つのバリアントですが、RTP圧縮は適用できません。このセクションの残りの部分の記述テキストは、メイン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つのコンプレッサーマシンと1つの分解機マシン間の相互作用として特徴付けられ、それぞれがコンテキストごとに1回インスタンス化されます。コンプレッサーと減圧装置にはそれぞれ3つの状態がありますが、州の意味が2つの当事者でわずかに異なる場合でも、多くの点で互いに関連しています。どちらのマシンも最低の圧縮状態で始まり、徐々により高い状態に通過します。
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）、1次（FO）、および2次（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)
- パケットヘッダーのバリエーション - 減圧装置からの肯定的なフィードバック（謝辞 - Acks） - 減圧装置からの負のフィードバック（ネガティブ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 Stateで送信された一部またはすべてのパケットには、コンテキストの更新情報があります。誤った更新やコンテキストの矛盾を避けるために、そのようなパケットの腐敗を検出することが非常に重要です。
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つの操作モードすべてを実装およびサポートする必要があります。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.
双方向の楽観的モードは、単方向モードに似ています。違いは、フィードバックチャネルを使用して、エラーリカバリリクエストを送信し、（オプションでは）decompressorからコンプレッサーへの重要なコンテキスト更新の謝辞を（ただし、純粋なシーケンス番号の更新についてはそうではありません）。周期的なリフレッシュは、双方向の楽観的モードでは使用されません。
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-Modeは、フィードバックチャネルの圧縮効率とスパースの使用を最大化することを目的としています。残留エラーまたはコンテキストの無効化により、上層に配信される損傷したヘッダーの数を減らします。コンテキストの無効化の頻度は、特に長い損失/エラーバーストが発生する場合、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-Modeは、損失の伝播と損傷の伝播に対する堅牢性を最大化することを目的としています。つまり、ヘッダーの損失/エラーバースト条件下でも、コンテキストの無効化の確率を最小限に抑えることです。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は正の整数です。K BITを受信した後、減圧器は以前に受信した値を参照（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]
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:
パラメーターPは、V_REFに関して解釈間隔をシフトできるように導入されます。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)].
c) 一定の値からわずかに逸脱すると予想されるフィールド値の場合、pは2^（k -1）に設定できます。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や誤った順序がある場合、Pを2^（k -2）に設定できるように、小さな負の変化や大きな肯定的な変化を受けると予想されるフィールド値の場合、間隔はなります。[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: 1) The compressor (decompressor) always uses v_ref_c (v_ref_d), the last value that has been compressed (decompressed), as v_ref;
以下は、LSB圧縮と減圧のための簡略化された手順です。次のサブセクションで堅牢性と損傷の伝播保護のために変更されます。1）コンプレッサー（減圧器）は常にV_REF_C（V_REF_D）を使用します。
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).
2) 値Vを圧縮するとき、コンプレッサーはkの最小値を見つけて、vが間隔f（v_ref_c、k）に分類されます。この関数を呼び出しますk = g（v_ref_c、v）。たとえば、パケット形式によって課される制限のためにkのいくつかの異なる値のみが可能な場合（セクション5.7を参照）、コンプレッサーは代わりにVを間隔f（v_ref_c、k）に置く最小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.
3) M LSBを受信すると、decompressorは、interval_dと呼ばれる解釈間隔f（v_ref_d、m）を使用します。LSBが受信したMビットと一致するInterval_dの減圧値として選択します。
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.
このスキームは、コンプレッサーと減圧装置間のパケット損失と、下層によって検出されない伝送エラーの2つの要因によって複雑になっています。前者の場合、コンプレッサーと分解器は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として常に使用します。b）減圧装置は、CRCの成功によって検証されたように、常に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.
u/oモードでは、1）b）が変更されるため、最後の検証されたSNリファレンスを使用してSNの減圧が失敗した場合、最後の1つの検証されたSN参照を使用して別の減圧試行が行われることに注意してください。この手順は、小さな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の正確な値を決定できない場合があります。ただし、フィードバックを使用するか、合理的な仮定を行うことにより、コンプレッサーは候補セットを制限できます。次に、コンプレッサーはkを計算して、候補セットのdecompressorが使用する候補セットに関係なく、Vは結果のinterval_dでカバーされます。
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について、コンプレッサーはk = max（g（v_min、v）、g（v_max、v））を選択します。ここで、v_minとv_maxはスライドウィンドウの最小値と最大値であり、gはfunction function function defined function前のセクションで。
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.
3) コンプレッサーが、特定の値Vとvより古いすべての値が減圧器による参照として使用されないことを十分に確信している場合、ウィンドウはそれらの値（Vを含む）を削除することで進歩します。自信はさまざまな手段によって得られる場合があります。Rモードでは、減圧器からのACKは、ACKEDより古い値をスライドウィンドウから削除できることを意味します。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).
減圧器は前のセクションで説明した手順に従っていることに注意してください。ただし、Rモードでは、後続のCRCで受け取った各ヘッダーをACKする必要があります（セクション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）の積分倍数です。たとえば、オーディオの場合、サンプルレートは通常8 kHzで、1つの音声フレームは20ミリ秒をカバーする場合があります。さらに、各音声フレームは、多くの場合、1つのRTPパケットで運ばれます。この場合、RTPの増分は常にn * 160（= 8000 * 0.02）であり、整数nです。ソースのサンプルクロックは通常、フレームレートまたはフレームの境界を変更せずに実行し続けるため、沈黙期間はこれに影響を与えません。
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 * 90000 /30）増加します。ビデオフレームは、多くの場合、パケット損失に対する堅牢性を高めるためにいくつかの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))
floor（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_STRIDE is explicitly, and TS_OFFSET implicitly, communicated to the decompressor. The following algorithm is used:
TS_STRIDEは明示的に、ts_offsetは暗黙的に、decompressorに通信します。次のアルゴリズムが使用されます。
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_offsetを（絶対値）modulo ts_strideに初期化するために減圧器によって使用されます。TS_OFFSETは、非スケーリングされたTS値が包まれていない限り、どの絶対値が使用されるかに関係なく同じであることに注意してください。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と仮定します。Ts_offsetは0x50 = 80です。次に、次のRTP TS = 0x00000130（つまり、増分が160 * 2 = 320）の場合、新しいTS_OFFSESTは0x00000130 modulo 0xa0 = 0x90 = 144である必要があります。ラップアラウンドのTS_OFFSET。代わりに、減圧装置は、無防備なTS（些細な）のラップアラウンドを検出し、ts_offsetを更新する必要があります
TS_OFFSET = (Wrapped around unscaled TS) modulo 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.
5. ラップアラウンドでの解釈間隔：最大スケーリングされたts、tss_max、（0xfffffffff / ts_stride）がフォーム2^m -m -1を持たないため、ラップアラウンドでのスケーリングされたtsの解釈間隔には特別なルールが必要です。160、スケーリングされたTSは、LSBS 10011001を備えた最大26843545です。したがって、TSS_MAX間のラップアラウンド境界は、LSB間の自然境界に対応できない場合があります。
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が解釈間隔の一部である場合、TSS_MAXの後に多くの未使用の値が挿入され、LSBが互いに自然に従うようになります。たとえば、TS_STRIDE = 160およびk = 4の場合、LSBS 1010から1111に対応する値が挿入されます。挿入された値の数は、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.
ラップアラウンドがない場合は、Aを必要なLSBの数とし、TSS_MAXとゼロの間で微分するために必要なLSBの数とします。TSS_MAXまたはゼロが通訳間隔の一部である間に送信するLSBビットの数は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_STRIDEとTS_OFFSESTの再目立化が完了するまで、非スケールのTSが圧縮されます。
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）サンプリングとともにロックステップで生成されると、タイムスタンプ値は、時刻。これは、インタラクティブなスピーチなどの会話メディアの場合です。線形比は、ソースサンプルレートによって決定されます。線形パターンは、パケット化（たとえば、ビデオフレームが通常いくつかのRTPパケットに対応するビデオの場合）またはフレームの再配置（たとえば、Bフレームが一部のビデオコーデックによって秩序外に送信される）によって複雑になる可能性があります。
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.
8 kHzの固定サンプルレートでは、時間ドメインで20ミリ秒で、Unscaled 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 LSBで改良することができます。正しい減圧を確保するために必要な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圧縮技術とは対照的です。これは、Talkspurtの開始時に、前の沈黙間隔の持続時間に応じて多数のビットを送信する必要があります。
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の両方を使用して作業することができますが、実際には、時計の解像度に要求が少ないため、たとえば1/8ミリ秒ではなく20ミリ秒の要件が少ないため、常にスケーリングされたTSエンコードと組み合わされていることに注意してください。したがって、以下に説明するアルゴリズムは、クロックベースのエンコードスキームがスケーリングされた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},
max {|（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.
時間型は、1つの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.
定数2は、コンプレッサーと分解器でクロックによって導入された量子化誤差を説明します。これは /-1です。
Note that the calculation of k follows the compression algorithm described in section 4.5.1, with p = 2^(k-1) - 1.
Kの計算は、P = 2^（k -1）-1でセクション4.5.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、A_REF）を維持します。ここで、T_REFは参照ヘッダーのスケーリングされたTSであり、A_REFは参照ヘッダーの到着時間です。
2) When receiving a compressed header n at time a_n, the approximation of the original scaled TS is calculated as:
2) 時間A_Nで圧縮ヘッダーnを受信すると、元のスケーリングされた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) 次に、セクション4.5.1の減圧アルゴリズムに従って、p = 2^（k -1）-1で、ヘッダーnで運ばれる最も有意なビットによって近似が改良されます。
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が積分数のクロックティックになるように時間を正規化する必要があります。たとえば、クロックティックが20 msで、time_strideが30 ms、（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.
注：減圧器はジッターを観察し、ジッターフィードバックオプションを使用してコンプレッサーにこれを報告する場合があります。コンプレッサーは、この情報を使用して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は少なくとも同じ量増加します。したがって、Offset、つまりIP-ID自体ではなく（IP-ID-RTP SN）を圧縮する方が効率的です。
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ビット量、つまりModulo 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は、ヘッダーiのIP-IDおよびRTP SNの値です。スライディングウィンドウには、ヘッダーフィールドの値ではなく、このようなオフセットが含まれていますが、ウィンドウからオフセットを追加および削除するためのルールは、それ以外の場合はセクション4.5.2に続きます。
Decompressor:
減圧器：
The reference header is the last correctly (as verified by CRC) decompressed header.
リファレンスヘッダーは、（CRCによって検証された）最後の正しい（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.
圧縮されたパケットMを受信すると、減圧装置はoffset_ref = id_ref -sn_refを計算します。ここで、ID_REFとSN_REFはそれぞれ参照ヘッダーのIP -IDおよびRTP SNの値です。
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デコードを使用して、Packet MおよびOffset_Refで受信したLSBを使用してOffset_mを減圧します。mには、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 = packet m offset_mの分解されたsn for m =
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は、音声で160、1 f/sビデオで90 000にすることができます。そのような値の転送を最適化するために、それらをエンコードするために可変数のオクテットを使用します。使用されるオクテットの数は、最初のオクテットの最初の数ビットによって決定されます。
First bit is 0: 1 octet. 7 bits transferred. Up to 127 decimal. Encoded octets in hexadecimal: 00 to 7F
最初のビットは0：1オクテットです。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
最初のビットは10：2オクテットです。14ビットが転送されました。最大16 383 10進数。ヘキサデシマルのエンコードオクテット：80 00〜BF ff
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
最初のビットは110：3オクテットです。21ビット転送。最大2 097 151 10進数。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
最初のビットは111：4オクテットです。29ビット転送。最大536 870 911 10進数。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.
たとえば、タイプ3の拡張を使用してUR-2ヘッダー（セクション5.7を参照）を使用して、未格付けのTS値を転送できます。拡張のTSCビットは控えめになり（ゼロ）、拡張の変数長tsフィールドはです。 4オクテット、TSで29ビットを使用できます（セクション4.5.6を参照）。 UOR-2 TSフィールドには、非スケーリングされたTSの3つの最も重要なビットが含まれ、拡張内の4-OCTET 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はSanity Checksを使用し、CRCSを重要なフィードバック情報に追加して、損傷したフィードバックの検出を可能にします。
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）は、コンテキストの無効化を検出するための「K-out-of」ルールを誤ってトリガーし、ヘッダーが破棄されるNACK/更新シーケンスになります。
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-modeでは、通常は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.
シナリオ（b）は、Rモードのようにコンテキストの更新ヘッダーが失われないことをコンプレッサーがACKを介して保証すると、ほぼ完全に排除されます。
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.
シナリオ（c）は、コンプレッサーがACKを介して、r-modeのようにdecompressorがSNラップアラウンドを常に検出することをACKを介して保証すると、ほぼ完全に排除されます。また、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.
シナリオ（d）は、コンプレッサーがW-LSBウィンドウに存在するいくつかのヘッダーの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.
シナリオ（e）残留エラーのバーストがCRCチェックがCRCを運ぶ最後のnヘッダーからkでCRCチェックを失敗させると発生します。大型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モード）が含まれていません。したがって、最小のヘッダーの場合、U/Oモードでは約7/8の確率で損傷が検出されます。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：boolean;falseの場合、短いCID表現（0〜15をカバーする0バイトまたは1つのプレフィックスバイト）が使用されます。Trueの場合、埋め込まれたCID表現（CID 0〜16383をカバーする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ヘッダーにはプロファイル識別子が含まれており、ヘッダーの残りの部分をどのように解釈するかを決定します。プロファイルパラメーターは、特定のコンテキストと組み合わせて使用されるパケットタイプの識別子とパケットタイプの構文とセマンティクスを決定することに注意してください。このドキュメントでは、プロファイル0x0000、0x0001、0x0002、および0x0003について説明しています。ROHCが将来拡張されると、さらにプロファイルが定義される場合があります。
Profile 0x0000 is for sending uncompressed IP packets. See section 5.10.
プロファイル0x0000は、非圧縮IPパケットを送信するためのものです。セクション5.10を参照してください。
Profile 0x0001 is for RTP/UDP/IP compression, see sections 5.3 through 5.9.
プロファイル0x0001はRTP/UDP/IP圧縮用です。セクション5.3〜5.9を参照してください。
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.
プロファイル0x0002は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 Over X」ドキュメントで定義されている場合、チャネルごとの交渉を使用して、コンテキストの状態情報を事前に確立することができます（たとえば、CID 15のプロファイル0x0000の交渉）。このような状態情報は、交渉で読み取り専用とマークすることもできます。これにより、減圧装置はそれを変更しようとする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上のCID 3およびチャネルB上のCID 3は、AとBのエンドポイントが同じノードであっても、同じコンテキストを参照しません。特に、フォワードチャネルとリバースチャネルのペアの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スペースは小さいと交渉することができます。つまり、CIDは0から15、または大きい値を取得できます。スモールは、チャネルが確立されたときよりもその後交渉されます。
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は、パケットタイプフィールド（ADD-CID）とさらに4ビットの代わりに4ビットフィールドで表されます。2つのオクテットに制限されたセクション4.5.6のエンコードスキームを使用して、大きなCIDが表されます。
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.
- オプションのパディング、フィードバックパケットタイプ、4ビットのCIDを提供するオプションの追加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）には、1つのADD-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
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | CID |
+---+---+---+---+---+---+---+---+
CID: 0x1 through 0xF indicates CIDs 1 through 15.
CID：0x1〜0xfは、CID 1〜15を示します。
Note: The Padding Octet looks like an Add-CID octet for CID 0.
注：パディングオクテットは、CID 0の追加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):
ヘッダーは、パケットタイプの表示で始まるか、追加のオクテットの直後にパケットタイプの表示があります。すべてのヘッダーパケットタイプには、次の一般的な形式があります（図では、スラッシュ "/"は変数の長さを示します）：
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.
静的ナック：減圧器の静的コンテキストが有効でないか、確立されていないことを示します。
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 Over 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 Over 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フィードバック情報形式は、Octet-Aligned、つまり、専用のフィードバックチャネル2）で形式を使用できるように、Octet境界で開始されます。
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チャネルで送信されたフィードバックは、1つ以上の連結されたフィードバック要素で構成されています。各フィードバック要素には次の形式があります。
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パラメーターは、フィードバックを運ぶチャネルのチャネルからではなく、受信コンプレッサーのチャネルのチャネル状態から取得されることに注意してください。
It is REQUIRED that the feedback field have either of the following two formats:
フィードバックフィールドには、次の2つの形式のいずれかが必要です。
FEEDBACK-1
フィードバック-1
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| profile specific information | 1 octet
+---+---+---+---+---+---+---+---+
FEEDBACK-2
フィードバック-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の場合、サイズが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.
3) 小さなCIDの場合、サイズが1オクテットよりも大きく、フィードバックが2ビット11で始まる場合、フィードバックはAdd-CIDオクテットから始まります。サイズが2の場合、フィードバック1が続きます。サイズが2より大きい場合、ADD-CIDの後にフィードバック2が続きます。
4) Otherwise, there is no Add-CID octet, and the feedback starts with a FEEDBACK-2.
4) それ以外の場合は、Add-CID Octetはありません。フィードバックはフィードバック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：セクション5.9.1の多項式を使用して計算された8ビットCRC。そのカバレッジはプロファイルに依存しますが、少なくともプロファイルフィールドで終わるパケットの最初の部分をカバーする必要があります。減圧器のコンテキストを初期化する情報は、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：セクション5.9.1の多項式を使用して計算された8ビットCRC。そのカバレッジはプロファイルに依存しますが、少なくともプロファイルフィールドで終わるパケットの最初の部分をカバーする必要があります。減圧器のコンテキストを初期化する情報は、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が故障した場合、またはチャネルパラメーターMRRUよりも大きい場合（5.1.1を参照）、再構成されたユニットは圧縮機によって破棄する必要があります。
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になったSteve Deering et al。のSEALに触発されたことに注意してください。セグメントにシーケンス番号を持たずに、再構築されたユニットで強力な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：パディングまたは追加のオクテット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）の場合は、すべての初期パディングオクテットを取り除き、次のステップをGOTOします。
2) If the first remaining octet starts with 1110, it is an Add-CID octet:
2) 最初の残りのオクテットが1110で始まる場合、それは追加のオクテットです：
remember the Add-CID octet; remove the octet.
Add-CIDオクテットを覚えておいてください。オクテットを取り外します。
3) If the first remaining octet starts with 11110, and an Add-CID octet was found in step 2),
3) 最初の残りのオクテットが11110で始まり、ステップ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:
4) 最初の残りのオクテットが11110で始まり、ステップ2で追加されたオクテットが見つからなかった場合、これはフィードバックです。
find the size of the feedback data, call it s; remove the feedback type octet;
フィードバックデータのサイズを見つけ、sと呼びます。フィードバックタイプのオクテットを削除します。
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).
コードが0の場合、サイズのオクテットを削除します。長さSのフィードバックデータを同じ側に関連するコンプレッサーに送信します。パケットが使い果たされた場合は、停止します。それ以外の場合は2）。
5) If the first remaining octet starts with 1111111, this is a segment:
5) 最初の残りのオクテットが1111111で始まる場合、これはセグメントです。
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.
セグメンテーションプロトコル（5.2.5）を使用して再構成を試みます。再構成されたパケットが生成されない場合、これにより元のパケットの処理が終了します。再構成されたパケットが生成された場合、上記のステップ1）に供給されます。パディング、セグメント、およびフィードバックは再構築されたパケットでは許可されていないため、それらを処理するときは、ステップ1）、4）、および5）は、条件が一致するときにパケットがさらなるアクションなしで破棄されるように変更されます。
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.
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.
8) フォワードトラフィックが大きなCIDを使用している場合、CIDは残りの2番目のオクテットから始まります。そのオクテットの最初のビットが0または10でない場合、パケットはさらなるアクションなしで破棄する必要があります。パケットタイプの直前（ステップ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.
10）パケットタイプがIRの場合、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.
11）パケットタイプがIR-Dynの場合、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.
a) CRCがパケットの検証に失敗した場合、破棄する必要があります。コンテキストでプロファイルが示されている場合、そのプロファイルのロジックは、フィードバックが送信されるものを決定します。コンテキストでプロファイルが認められない場合、それ以上のアクションは実行されません。
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.
b) コンテキストがIRパケットによって初期化されていない場合、パケットを破棄する必要があります。IR-Dynヘッダー（CRCによって検証された場合）に示されているプロファイルのロジックは、フィードバックが送信されるものを決定します。
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-functionのパラメーターがDecompressorによって知られている場合に最小限のパケットタイプが使用され、圧縮されたヘッダーがこれらの関数に準拠している場合に使用されます。したがって、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-Functionsのパラメーターを超える場合に使用されます。
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-mode and o-mode：rtp sn、rtp ts、ip-idの値のみを、将来の圧縮の参照として使用できます。拡張機能（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-functionsの値を伝えます。オプションでは、コンテキストの動的部分、つまり非粘性のSN-functionsのパラメーターも通信できます。
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-functionsのパラメーターを伝えます。
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.
タイプACK、NACK、および静的キャリーシーケンス番号、およびフィードバックパケットのフィードバックは、目的の圧縮モード：u、o、またはRを示すモードパラメーターを運ぶことができます。
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).
速記として、表記パケット（モード）を使用して、パケットがどのモード値が伝えるかを示します。たとえば、モードパラメーターrを備えたACKはACK（R）と記述され、モードパラメーターOを持つUOR-2は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状態にある場合、減圧器が静的コンテキスト情報を正しく受信したと仮定するまで、そこにとどまります。FOからSO状態への移行のために、コンプレッサーは、減圧器に固定パターンに従って減圧するために必要なすべてのパラメーターがあることを確信する必要があります。
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状態への移行よりも頻繁に実行される必要があります。したがって、これらの遷移には2つの異なるタイムアウトを使用する必要があります。定期的な更新を実装する方法の例については、[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リフレッシュを無効にする（または間隔を増やす）ことがあります。
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.
減圧が成功すると、減圧装置は常に完全なコンテキスト状態に移動します。繰り返し失敗した減圧により、減圧装置は下方に下方に移動します。減圧装置は、パケット自体に十分な情報が含まれていない限り、NOコンテキストおよび静的コンテキスト状態でヘッダーをまったく減圧しようとしません。
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.
完全なコンテキスト状態では、どの種類のパケットが受信されているかに関係なく、減圧を試みることができます。ただし、他の状態では、減圧が常に許可されているわけではありません。NOコンテキスト状態では、静的情報フィールドを運ぶ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.) 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.
ヘッダーを再構築するとき、減圧器はコンテキストに既に保存されているヘッダー情報を取得し、現在のヘッダーで受け取った情報で更新します。（再構築されたヘッダーがCRCチェックに失敗した場合、これらの更新は元に戻す必要があります。）シーケンス番号は、コンテキストのシーケンス番号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の不一致は、1つ以上の原因となる可能性があります。
1. residual bit errors in the current header
1. 現在のヘッダーの残留ビットエラー
2. a damaged context due to residual bit errors in previous headers
2. 以前のヘッダーの残留ビットエラーによる破損したコンテキスト
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）、減圧装置は追加の減圧の試みを試みる可能性があります。ケース3はRモードでは発生しないことに注意してください。
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.)
第二に、前のステップが修正を試みなかった場合、参照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:
上記の両方の手順が失敗した場合、追加の減圧試行は行われないでください。CRC障害には2つの理由があります。ケース1または回復不可能なコンテキストダメージです。これらのどれが実際の原因であるかを確実に知ることは不可能です。次のルールを使用する必要があります。
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チェックがたまにのみ失敗した場合、現在のヘッダーに残留エラーを想定し、単にパケットを破棄します。NACKSはこの時点で送信されないでください。
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チェックが失敗した場合、コンテキストの損傷を想定し、o-およびRモードでNACKを送信する必要があります。減圧器は静的コンテキスト状態に移動し、CRCチェックに合格する更新（IR、IR-Dyn、UOR-2）が受信されるまですべてのパケットを破棄します。
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チェックが失敗し、静的コンテキストの損傷を想定し、o-およびrで静的ナックを送信する必要があります。-モード。減圧器は、NOコンテキスト状態に移動します。
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. NOコンテキスト状態：Decompressorは、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の到着時間、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. 減圧が失敗すると、減圧装置は間隔= a（i）-a（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. ラップアラウンドが発生した場合、間隔は少なくとも2^k間のパケット時間に対応します。ここで、kは現在のヘッダーのSNビット数です。たとえば、到着平均、TS_STRIDE、またはTS_TIMEの移動平均を使用して取得されたパケット間攻撃時間の推定に基づいて、decompressorは、インターバルが2^k間パケット時間に対応できる場合はdecompressorの裁判官です。
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. 間隔が少なくとも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.
e. この減圧が成功した場合、減圧器はコンテキストを更新しますが、パケットを上層に配信してはなりません。また、次のパケットは減圧され、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。失敗すると、減圧装置はパケットを破棄し、規則a）からセクション5.3.2.2.3のc）から動作します。
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. 減圧器には、2つの減圧されたシーケンス番号が維持されます。最後の1つ（REF 0）とその前のシーケンス番号（REF -1）です。
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.
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で生成された場合。Ref -1を使用するときに生成されたCRCテストに合格しず、参照がSN Curr1とは異なるためにRef -1を使用するときに生成されたSN（SN Curr2）は、減圧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.
e. 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で生成された減圧ヘッダーの場合。CRCテストに合格すると、REF -1は変更されませんが、REF 0はSN Curr2に設定されています。
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.
g. dで生成された減圧ヘッダーの場合。CRCテストに合格しません。減圧装置は、ルールa）からセクション5.3.2.2.3のc）に従って機能します。
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つ目は上層に配信される必要があります。 3つのヘッダーのいずれかが失敗する場合、減圧器はそのヘッダーと以前に生成されたヘッダーを破棄し、セクション5.3.2.2.3のルールa）からc）に従って行動する必要があります。
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.
フィードバックチャネルを持つリンク上の単方向モードのパフォーマンスを改善するために、減圧が成功したときに減圧器が確認を送信する場合があります。ACKパケットのモードパラメーターをUに設定すると、コンプレッサーが単方向モードにとどまることを示します。ACK（U）を受信する場合、コンプレッサーは静的情報が正しく受信されているため、IRパケットの頻度を減らす必要がありますが、IRパケットの送信を停止する必要はありません。IRパケットが到着し続けると、減圧器はACK（U）を繰り返すことができますが、ACK（U）を継続的に繰り返すべきではありません。
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章で説明したのと同じ方法で機能します。ただし、楽観的なモードでは、タイムアウトはありません。代わりに、楽観的なモードでは、逆方向の遷移とオプションの改善された前方遷移のために、減圧器からコンプレッサーへのフィードバックを使用します。
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.
コンテキスト要求とも呼ばれる否定的な謝辞（NACKS）は、単方向モードで必要な定期的な更新を削除します。NACKを受信すると、コンプレッサーはFO状態に戻り、更新（IR-Dyn、UOR-2、またはIR）を減圧器に送信します。Nacksは、最新のパケットのSNを正常に減圧します。この情報は、コンプレッサーが更新する必要があるフィールドを決定するために使用できます。
Similarly, reception of a STATIC-NACK packet makes the compressor transit back to the IR state.
同様に、静的ナックパケットの受信により、コンプレッサーは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.
NACKSに加えて、双方向の楽観的モードのUOR-2パケットには、肯定的なフィードバック（ACK）も使用できます。アップデートパケット用の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ヘッダーのシーケンスが送信されて、パケットストリームの不規則性を通信する場合の更新イベントとします。最後のN_3アップデートイベントからK_3のACKを受信した場合、コンプレッサーは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タイムスタンプの値が壁1杯の時間に比例したときに圧縮効率を改善することができます。使用されるメカニズムは、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.
フィードバックロジックは、さまざまな州で動作するときに異なるイベントに起因するために送信するフィードバックを定義します。上記のように、フィードバックには3つの主要な種類があります。Ack、nack、static-nack。さらに、以下で説明するロジックは、減圧器が受信できるさまざまな種類のパケットを指します。初期化と更新（IR）パケット、静的情報（IR-DYN）およびタイプ2パケット（UOR-2）のないIRパケット、またはタイプ1（UO-1）とタイプ0パケット（UO-0）。タイプ0のパケットには、固定パターンに応じて圧縮されたパケットヘッダーが搭載されていますが、このパターンが壊れたときにタイプ1、2、およびIR-Dynパケットが使用されます。
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.
以下では、どのフィードバックを使用するかを示すルールが定義されています。 オプションのフィードバックが一度使用された場合、packetストリームの寿命のためにオプションのフィードバックを引き続き送信するには、減圧器が必要です。
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の開始時の考慮事項を条件として、静的ナック（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の不一致として扱い、セクション5.3.2.2.3のロジックを使用して、NACK（O）を送信するかどうかを判断します。
- 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.
- タイプ2パケット、IR-Dynパケット、またはIRパケットの減圧が失敗した場合、セクション5.3.2.2.3のロジックを使用して、静的ナック（O）を送信する必要があるかどうかを判断します。
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チェックに失敗したら、5.3.2.2.3のロジックを使用して、NACK（O）を送信するかどうかを判断します。
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 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.
上向きの遷移は、安全な参照原理によって決定されます。遷移手順は、セクション5.3.1.1.1で説明されているものと類似しており、1つの重要な違いがあります。コンプレッサーは、減圧器から受け取った謝辞のみに自信を持っています。これにより、圧縮コンテキストと減圧コンテキストの間の同期がパケットの損失により失われることはありません。
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で説明されているように、下向きの遷移は、更新の必要性または否定的な認識（NACKSおよびSTATIC_NACKS）によって引き起こされます。 Nacksは、使用される安全な参照のためにRモードではめったに発生しないことに注意してください（次のセクションの4番目の段落を参照）。
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パケットに対して有効なACKを受け取ると、FO状態に通過します（ACKは、以前に送信されたSNを参照しても有効です）。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.
コンプレッサーは、弦の存在を決定した後、SO状態に移動します（セクション2を参照）。自信はACKに基づいています。たとえば、文字列パターンに非SN-field = sn *勾配オフセットの形式がある典型的なケースでは、勾配が減圧器によって以前に確立された場合に1つのACKで十分です（つまり、新しいオフセットのみが必要です同期）。それ以外の場合は、減圧器には新しいスロープと新しいオフセットの両方を学習するために2つのヘッダーが必要なため、2つのAckが必要です。SO状態では、R-0*パケットが送信されます。
Note that a direct transition from the IR state to the SO state is possible.
IR状態からSO状態への直接的な移行が可能であることに注意してください。
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) スライド窓を縮小することが望ましいです。windowsは、ACKを受信した場合にのみ縮小されます。
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:
更新パケットを送信するための1つのアルゴリズムは次のとおりです。
* 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回の往復時間中に送信されるパケットの数とします。SO状態では、（64-PRTT）ヘッダーが最後のAcked Reference以降に送信されている場合、コンプレッサーはM1連続R-0-CRCヘッダーを送信し、（PRTT-M1）R-0ヘッダーを送信します。これらのヘッダーが送信された後、コンプレッサーが以前に送信されたR0-CRCの少なくとも1つにACKを受信していない場合、対応するACKを受信するまでR-0-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.
* FO状態では、パターンの変更があるときにM2 UOR-2ヘッダーが送信され、その後コンプレッサーが（PRTT-M2）R-1-*ヘッダーを送信します。M2は実装パラメーターであり、PRTTと同じ大きさです。その時点で、コンプレッサーが以前に送信されたUOR-2パケットに十分なAcksを受け取っていない場合、SO状態に移行するために、同じM2でサイクルを繰り返したり、より大きなM2でサイクルを繰り返したり、UORを送信したりできます。-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を持つ更新パケットのスライディングウィンドウを検索します。 見つかった場合、そのパケットはAckedになっているものです。 それ以外の場合、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_Uよりも長い場合、またはRTT_Lよりも短い場合、コンプレッサーは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モードのアキュキングスキームは、非圧縮性パケットがコンプレッサーによって送信されないことを保証しますが、残留エラーは、減圧を試みるべきではない予期しないパケットの配信を引き起こす可能性があります。
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）以前のヘッダーまたはフィードバックの残留ビットエラーによる破損したコンテキストのためにのみ発生します。どちらが実際の原因であるかを判断することは不可能ですが、ケース1の可能性が高くなります。損傷したパケットが7ビットまたは8ビットCRCに合格する可能性は低く、破損したパケットがフィードバックになる可能性は低いためそれはコンテキストに損害を与えます。減圧装置は、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.
- コンテキストダメージが検出されたら、完全なコンテキスト状態の場合はNACK（r）、静的コンテキスト状態の場合は静的ナック（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パケットを受信するときに静的ナック（R）を送信します。コンプレッサーはIR状態にとどまるため、有効なACKが受信されるまでIRパケットの送信を続けるため、CRCチェックに失敗するIRパケットを受信したときに、減圧器は静的ナック（R）を送信してはなりません（セクション5.5.1.2を参照）。
- 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パケットのシーケンスの場合、最初のパケットをAckedする必要があります。
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をAckedする必要があります。ここでは、nはコンプレッサーに新しい文字列パラメーターを取得したというコンプレッサーに信頼を与えるために必要なACKの数です（2番目を参照5.5.1.2の段落）。減圧器がnの値を決定できない場合、デフォルト値2を使用する必要があります。その後受信したパケットがヘッダーフィールドの同じ変更パターンを継続する場合、スパースACKを適用できます。それ以外の場合、新しいパターンを新しいシーケンスとして扱う必要があります。つまり、新しいパターンを示す最初のNパケットをAckedする必要があります。
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を送信した後、減圧器はRTTあたりの後続のパケットのみを選択できます（「スパースアック」）。ここで、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フィールドの長さと等しいフィードバックフォーマットを使用する必要があります。
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.
ある圧縮モードから別の圧縮モードに移動する決定は、減圧剤によって取得され、可能なモード遷移を下の図に示します。次の章では、遷移中の圧縮および減圧機能の例外を除いて、遷移がどのように実行されるかについて説明します。
+-------------------------+
| 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:
後続のサブセクションは、モード変数の値をいつ変更するかを正確に定義します。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パラメーターの可能な値は、（u）nidirectional、（o）ptimistic、および（r）leliableです。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 1) that the compressor only use packet formats common to all modes,
- C_TRANS：C_TRANSパラメーターの可能な値は（P）終了と（d）1つです。C_TRANSはDに初期化する必要があります。C_TRANSがPの場合、必須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パラメーターの可能な値は、（u）nidirectional、（o）ptimistic、および（r）eleableです。D_Modeは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）ニチエート、（p）終了、（d）1つです。D_TransはDに初期化する必要があります。D_TransがDの場合にのみモード遷移を開始できます。D_TransがIである場合、Decompressorは受信したパケットごとにCRCオプションを運ぶNACKまたはACKを送信します。
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を運ぶフィードバックパケットは、ModeパラメーターをOに設定して使用できます。Decompressorは、楽観的なモードで直接動作を開始できます。コンプレッサーは、モードパラメーターが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つのパケットが正しく減圧された後にのみ許可されます。つまり、少なくともコンテキストの静的部分が確立されます。CRCを運ぶACK（R）または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.
decompressorがRに設定されたモード遷移パラメーターを使用してUOR-2、IR-Dyn、またはIRパケットを受信していない限り、楽観的なモードにとどまる必要があります。コンプレッサーはパケットタイプ1または0を送信してはなりませんが、C_TRANSはP、つまり、Mode TransitionパラメーターがRに設定されたMode Transitionパラメーターで送信されたUOR-2、IR-Dyn、またはIRパケットのACKを受信するまでではありません。UOR-2、IR-Dyn、またはIRパケットをACKした後、パケットタイプ0または1を受信し、D_TransをDに設定します。
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.
decompressorがMode TransitionパラメーターをOに設定したUOR-2、IR-Dyn、またはIRパケットを受信していない限り、信頼できるモードにとどまる必要があります。コンプレッサーはパケットタイプ0または1を送信してはなりませんが、C_TRANSはP、つまり、Mode TransitionパラメーターがOに設定されたMode Transitionパラメーターで送信されたUOR-2、IR-Dyn、またはIRパケットのACKを受信するまでではありません。UOR-2、IR-Dyn、またはIRパケットをACKした後、パケットタイプ0または1を受信し、D_TransをDに設定します。
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:
減圧装置は、そうしたい場合、遷移を一方向モードに強制的に戻すことができます。この遷移が始まるモードに関係なく、コンプレッサー側での正しい遷移を確保するために、3方向の握手を実行する必要があります。遷移手順については、以下に説明します。
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.
最初のUOR-2（U）、IR-Dyn（U）、またはIR（U）をアシングした後、Decompressorはパケットタイプ0または1を受信するまで、モードパラメーターを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.
value（x）= field（x）圧縮ヘッダーにxが存在する場合。= context（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:
W-LSBで圧縮されています。セクション4.5.1を参照する解釈間隔は、次のように定義されています。
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フラグが1ではない最も内側のIPv4ヘッダーの圧縮IP-IDがあります。以下のルールは、IP-IDが最も内側のIPヘッダー用であると仮定します。外側のIPヘッダーの場合、RNDとNBOの代わりにRND2およびNBO2フラグが使用されます。
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）は、P = 0およびデフォルトスロープ（IP-IDオフセット）= 0を使用して、オフセットIP-IDエンコード（セクション4.5.5を参照）を使用して圧縮されます。
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）です。次に、拡張機能の後、圧縮ヘッダーの最後に追加のオクテットとして渡されます。
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）のオクテットは圧縮前および減圧後に交換されます。NBOの値は、値（RND）= 1の場合に無視されます。
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の場合、タイムスタンプ値はIS-ISのAS-default-slope（TS）= value（TS_STRIDE）に圧縮されます。
The interpretation intervals, see section 4.5.1, are defined as follows:
セクション4.5.1を参照する解釈間隔は、次のように定義されています。
p = 2^(bits(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チェックサムは無効になり、送信されません。Context（UDP Checksum）がゼロの場合、HDR（UDPチェックサム）がゼロでない場合、ヘッダーは圧縮できません。非圧縮されているか、IRパケットを使用してコンテキストを再活性化する必要があります。コンテキスト（UDPチェックサム）は、IRまたはIR-Dynヘッダーによってのみ更新されますが、タイプ2、1、または0のヘッダーに送信されるUDPチェックサムによっては更新されません。
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のRNDフラグを拡張ヘッダーのフォーマットを決定する前に検査する必要があることを意味します3を決定することができます。
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
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
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であることを示しています。
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.
注：コンテキストに値（RND）= 0の少なくとも1つのIPv4ヘッダーが含まれている場合、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ヘッダーがない場合、または値（RND）と値（RND2）が両方である場合、R-1-IDは使用できません。
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.
注：コンテキストにIPv4ヘッダーがない場合、または値（RND）と値（RND2）が両方である場合、R-1-TSは使用できません。
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
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.
注：コンテキストに値（RND）= 0の少なくとも1つのIPv4ヘッダーが含まれている場合、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）が両方である場合、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ヘッダーがない場合、または値（RND）と値（RND2）が両方とも1である場合、UO-1-TSは使用できません。
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であることを示しています。
UOR-2
UOR-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.
注：コンテキストに値（RND）= 0の少なくとも1つのIPv4ヘッダーが含まれている場合、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）が両方である場合、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.
注：ContextにIPv4ヘッダーがない場合、または値（RND）と値（RND2）が両方である場合、UOR-2-TSは使用できません。
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.)
（注：ROHCヘッダーに含まれる追加情報に使用される用語拡張部門は、IPで使用される用語拡張ヘッダーとの関係を負いません。）
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).
エクステンション内のフィールドは、1つがある場合、ベース圧縮ヘッダーの対応するフィールドと連結されています。拡張内のビットは、ベース圧縮ヘッダーのビットよりも有意ではありません（セクション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フィールドは、TSSフラグがTSフィールドがスケーリングされていないことを示す拡張3を使用する場合にオプションである場合を除き、ベースヘッダーにあるように、すべての拡張機能でスケーリングされます。値（TS_STRIDE）は、TSフィールドをスケーリングするときにスケール係数として使用されます。
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).
次の3つの拡張機能では、フィールドの解釈は、ベース圧縮ヘッダーに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 = 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ヘッダーと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_STRIDE）を使用してTSがセクション4.5.3に従ってスケーリングされていることを示します。コンテキスト（TSC）は常に1です。スケーリングが望ましくない場合、コンプレッサーはTS_STRIDE = 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：セクション4.5.6に従ってエンコードされたTSのさまざまな数のビット数。セクション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.
これらは、2つがある場合は内側のIPヘッダーと、それ以外の場合は単一のIPヘッダーに対応します。
0 1 2 3 4 5 6 7
..... ..... ..... ..... ..... ..... ..... .....
| TOS | TTL | DF | PR | IPX | NBO | RND | ip2 | if 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識別子）が圧縮されるのではなく、圧縮ヘッダーでISを送信するかどうかを示します。
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
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拡張ヘッダー：セクション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
..... ..... ..... ..... ..... ..... ..... .....
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
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：内側のヘッダーがIPv6ヘッダーでない限り、外側IPヘッダーのIP識別子フィールド、この場合は常にゼロです。
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
..... ..... ..... ..... ..... ..... ..... .....
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フラグの値は、拡張機能3またはIR-DynヘッダーでUOR-2ヘッダーを送信することにより変更されます。フラグには新しい値があります。フラグの確立手順は、現在のモードの通常の手順です。つまり、UモードとOモードでは、減圧器が少なくとも1つを受信するように値を数回繰り返します。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のRNDフラグを検査する必要があることを意味します。これは、拡張機能3を運ぶベースヘッダーの正確な形式を決定する前に、つまり、Tビットが存在するかどうかを決定できます。
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
NBO2 1 As NBO, but for outer header
RND2 0 As RND, but for outer header
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.
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) Oモードでは、減圧装置は、成功した減圧に関するフィードバックが送信されるレートを制限する必要があります（送信されている場合）。b）減圧が失敗した場合、フィードバックは、いくつかの連続したパケットの減圧が失敗した場合にのみ送信する必要があり、これが発生した場合、フィードバックレートは制限されるはずです。c）拒否されたパケットストリームに属するパケットを受信した場合、フィードバックレートは制限されるはずです。
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パケットのうち1つのみに対してフィードバックを送信することにより、フィードバックレートを制限する場合があります。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-Not-validオプションを搭載する必要があります。受容すると、コンプレッサーは有効なSN LSBと一致し、最新のヘッダーがLSBを一致させるSNで送信します。減圧装置は、この相関関係が曖昧にならないというフィードバックに十分なSN LSBを送信することを確認する必要があります。たとえば、8ビットのSN LSBフィールドが往復時間内に包むことができる場合、フィードバック1形式は使用できません。
FEEDBACK-1
フィードバック-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.
フィードバック1はACKです。NACKまたは静的ナックを送信するには、フィードバック2を使用する必要があります。フィードバック1には、モード情報が含まれていません。モード情報が必要な場合は、フィードバック-2を使用する必要があります。
FEEDBACK-2
フィードバック-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は予約されています（散算性に使用してはいけません）
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.
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がAdd-CIDオクテットで与えられている場合、Add-CIDオクテットはフィードバック1またはフィードバック-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.
拒否オプションは、圧縮機にフローを処理するのに十分なリソースがないことをコンプレッサーに通知します。
+---+---+---+---+---+---+---+---+
| 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.
拒否オプションを受信すると、コンプレッサーはパケットストリームの圧縮を停止し、しばらくの間圧縮されたパケットストリームの数を増やそうとすることを控える必要があります。拒否オプションを運ぶフィードバックパケットも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-Not-validオプションは、フィードバックのSNが無効であることを示します。コンプレッサーは、このオプションが存在するときに対応する送信ヘッダーを見つけるためにフィードバックのSNを使用してはなりません。
+---+---+---+---+---+---+---+---+
| Opt Type = 3 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
The SN option provides 8 additional bits of SN.
SNオプションは、8個の追加のSNを提供します。
+---+---+---+---+---+---+---+---+
| 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.
時計オプションは、減圧器のクロック解像度をコンプレッサーに通知します。 これは、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タイムスタンプのタイマーベースの圧縮を実行できないことを示します。クロックオプションを運ぶフィードバックパケットは、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オプションにより、減圧剤は最近観察した最大ジッターを報告できます。
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には、ヘッダーIを受信したときにコンプレッサーのスライドウィンドウの減圧器の最良の近似（セクション4.5.4を参照）を含むとします。
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 {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は減少する可能性があります。コンプレッサーが小さすぎるジッター推定値を使用すると、堅牢性が低下します。したがって、ジッターオプションを運ぶフィードバックパケットには、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.
損失オプションにより、減圧装置は、順番に失われた最大の観測されたパケット数を報告できます。この情報は、コンプレッサーによって使用されて、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.
減圧装置は、最も古い損失イベントを無視することを選択できます。したがって、報告された値は減少する場合があります。参照ウィンドウの設定が小さすぎると堅牢性が低下する可能性があるため、損失オプションを運ぶフィードバックパケットも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.
CID 8のフィードバックSN 17のACKと双方向信頼できるモードのACKを示すフィードバックは、次の形式を持つことができます。
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.
2番目、3番目、4番目のオクテットは、コンプレッサーに渡されます。
The FEEDBACK-1 format may also be used. Assuming large CIDs:
フィードバック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.
2番目と3番目のオクテットは、コンプレッサーに渡されます。
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.
2番目と3番目のオクテットは、コンプレッサーに渡されます。
Assuming small CIDs and CID 0 instead of CID 8:
CID 8の代わりに小さなCIDと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.3から5.7.7.7で定義されています。
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オクテットのUDPペイロードがIRまたはIR-Dynパケットで表現できないことを示すIP/UDP/RTPパケットを意味します。代わりに、このようなパケットは、非圧縮プロファイルを使用して表現できます（セクション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.
注：プロファイル0x0002（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も参照してください。
5.7.7.4. Initialization of IPv4 Header [IPv4, section 3.1].
5.7.7.4. IPv4ヘッダーの初期化[IPv4、セクション3.1]。
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）総長（減圧パケットで推測）存在する）
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も参照してください。
5.7.7.5. Initialization of UDP Header [RFC-768].
5.7.7.5. UDPヘッダーの初期化[RFC-768]。
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）。
5.7.7.6. Initialization of RTP Header [RTP].
5.7.7.6. RTPヘッダー[RTP]の初期化。
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：拡張の存在を制御します。
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ヘッダーからxビットのコピー（rx = 0の場合は0）
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リスト：セクション5.8.6.1に従ってエンコードされたCSRCリスト、すべてのCSRCアイテムが存在します。
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.
これは、null暗号化アルゴリズム[null]がESPで使用されていない場合であるため、ESPヘッダーの後のサブヘッダーが暗号化されます（5.12を参照）。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.
以前のサブセクションに明示的にリストされていないヘッダーは、IPv4またはIPv6ヘッダーに従って拡張ヘッダーチェーンの一部にすることによってのみ圧縮できます。セクション5.8を参照してください。
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).
リストには、RTPパケットのCSRCリストとIPパケットの拡張ヘッダーチェーン（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（index、item）ペア（必ずしも連続しているわけではない）を送信することにより、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.
Decompressorは、知っているすべて（インデックス、アイテム）のペアを含むテーブルを概念的に維持します。テーブルは、（インデックス、アイテム）ペアが受信されるたびに更新されます（そして、減圧は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:
Decompressor側の翻訳テーブルの各エントリには、次の構造があります。
+-------+------+
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.
既知のすべてのフィールドはゼロに初期化されます。 Decompressorが（インデックス、アイテム）ペアを受信すると、ポジションインデックスのテーブルにアイテムを挿入し、そのエントリに既知のフラグを1つに設定します。 既知のフラグがゼロである添付のアイテムのないインデックスが受信された場合、ヘッダーを破棄し、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の違いのエンコードです。圧縮リストを受信すると、Decompressorは元のリストを取得するために、その参照リストに違いを適用します。
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-Modeでは、参照リストの選択は謝辞に基づいています。つまり、コンプレッサーは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-modeでは、一連の同一のリストが同じ世代に属すると見なされ、すべて同じ生成識別子（gen_id）が割り当てられています。Gen_IDは、リストが変更されるたびに1増加し、参照リストとして使用される候補である圧縮および非圧縮リストで運ばれます。通常、gen_idは、リストをref_listとして使用する前に、少なくともlヘッダーで繰り返されている必要があります。ただし、一部の謝辞はOモード（およびUモード）で送信される場合があり、ヘッダーの確認が受信されるたびに、そのヘッダーのリストは既知と見なされ、さらに繰り返す必要はありません。GEN_IDの最も有意なビットは、u/o-modeの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-modeで、コンプレッサーはジェネリックリストとの生成識別子をまで送信します
1) a generation identifier has been repeated L times, or
1) 生成識別子は繰り返されています。
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-modeでは、コンプレッサーは、までに圧縮リストを生成識別子とともに送信し続けます。
1) a generation identifier has been repeated L times, or
1) 生成識別子は繰り返されています。
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-modeでは、コンプレッサーは保存する必要があります
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-modeでは、コンプレッサーは圧縮リストの生成識別子を送信しないことを選択できます。 生成識別子のないこのようなリストには、新世代の識別子が割り当てられておらず、将来の参照リストとして使用してはなりません。 彼らはコンテキストを更新しません。 この機能は、新しいリストが数回繰り返され、リストが古い価値に戻る場合に役立ちます。
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モードでは、減圧装置はIRパケットで送信されたリストを確認する場合があります。セクション5.3.2.3を参照してください。
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-modeでは、スライドウィンドウには、世代ごとに最大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-modeでは、圧縮リストに生成識別子があり、スライディングウィンドウにその生成識別子のリストが含まれていない場合、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.
圧縮リストの4つのエンコーディングスキームについて説明します。これらのエンコードスキームを使用した圧縮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,
3) curr_listがref_listとは異なるアイテムを持っている場合、
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.
4) 繰り返し3）curr_listが使い果たされるまで。
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.
このスキームは、ref_listでいくつかのアイテムを削除することでCurr_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,
3) curr_listがref_listとは異なるアイテムを持っている場合、
a set bit (1) is appended to the bit list; advance to the next item of ref_list;
セットビット（1）はビットリストに追加されます。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.
ゼロビット（0）がビットリストに追加されます。Curr_Listの次の項目に進出します。ref_listの次の項目に進みます。
4) Repeat 3) until curr_list has been exhausted.
4) 繰り返し3）curr_listが使い果たされるまで。
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のcurr_ext_hdr aとref_ext_hdr aをRef_listで比較すると、次のヘッダーフィールドの値は、拡張ヘッダーBの削除により、「タイプB」から「タイプC」に変更されます。A、つまり、「タイプ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]のシーケンス番号フィールドには、セキュリティ協会の単調に増加するカウンター値が含まれています。したがって、curr_listをref_listと比較する場合、AHのシーケンス番号が変更され、SPIフィールドが変更されない場合、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.
RTPシーケンス数が増加するとAHのシーケンス数が直線的に増加し、コンプレッサーが減圧器がパターンを取得したと確信している場合、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.
ストリーム内のヘッダーを検査することによってヌル暗号化が使用されるかどうかを判断することはできません。この情報は、暗号化エンドポイントにのみ存在します。ただし、コンプレッサーは、ヌル暗号化アルゴリズムが使用されているという仮定の下で圧縮を試み、仮定が誤っていることが判明した場合に後で圧縮を中止する場合があります。
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以外の暗号化アルゴリズムがおそらく使用されており、後続のヘッダーの圧縮を中止する必要があります。その後、ストリームの圧縮が中止されるか、ESPヘッダーまでのみ圧縮されるプロファイルを使用できます（5.12を参照）。ヘッダーを圧縮しようとしている間、コンプレッサーはESPヘッダーのSPIを宛先IPアドレスとともに使用して、どのパケットがストリームに属しているかを決定するための定義フィールドとして使用する必要があります。
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、セクション2]では、圧縮できるフィールドは、[ESP]で定義されている標準形式の場合、SPI、シーケンス番号、次のヘッダー、およびパディングバイトです。（いつものように、Decompressorはコンテキストの情報に基づいてこれらのフィールドを再挿入します。認証データを計算したのとまったく同じ情報で確認する必要があるため、すべての情報を正しく再挿入するように注意する必要があります。）
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.
パディング：パディングのオクテットは、[ESP]で定義されていると想定されています。つまり、値1、2、...、K、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-Incryption 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トンネルのカウンター値が含まれています。したがって、curr_listをref_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.
RTPシーケンス数が増加するとGREヘッダーのシーケンス番号が直線的に増加し、コンプレッサーが減圧器がパターンを受信したと確信している場合、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ビットプロトコルタイプフィールドエーテルタイプを使用したヘッダー（[割り当て]のエーテル型セクションを参照）が削除されます。2）ヘッダーの最初のオクテットとして1オクテットの次のヘッダーフィールドが挿入されます。次のヘッダーフィールドの値はGREに対応します（この値は、非圧縮アイテムがリストに挿入される場合、および後続のヘッダーのタイプに挿入される場合、[割り当てられたインターネットプロトコル番号セクション[割り当て]セクションに従って47です）に対応します。非圧縮アイテムは一般的なリストにあります。これは、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.
The fields Reserved0 and Reserved1 of the GRE header [GRE2] must be all zeroes; otherwise, the packet cannot be compressed by this profile.
GREヘッダー[GRE2]のフィールドは0および予約済み1である必要があります。それ以外の場合、このプロファイルによってパケットを圧縮することはできません。
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拡張ヘッダーと呼ばれるフィールドがあります。このセクションでは、そのフィールドの形式について説明します。
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 SEQ番号ESEQの存在を示します：圧縮されたESP SEQ番号GSEQの存在を示します。送信時にゼロに設定され、受け取ったときに無視されます
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フィールドのサイズを示します：PS = 0は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.
各アイテムは、xi 1、...、xi mのx = 1の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つです。
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.
削除の説明については、セクション5.8.3を参照してください。次にスキームを挿入します。
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静的です。
1) Entire AH header. 2) Entire ESP header. 3) Sequence number in GRE, Checksum in GRE
1) AHヘッダー全体。2）ESPヘッダー全体。3）GREのシーケンス番号、GREのチェックサム
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を計算する方法について説明します。（セクション5.2.5の再構築ユニットに対して別のタイプのCRCが定義されていることに注意してください。）
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は、Payloadを除外し、CIDまたはAdd-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
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静的または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静的オクテットは、元のヘッダーに表示されるのと同じ順序で配置され、続いて
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静的オクテットが変更されない限り、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状態で、15個はCRC-DYNAMICです。典型的なRTP/UDP/IPv6ヘッダーでは、49個のオクテットがCRC状態、11はCRC-DYNAMICです。したがって、この手法により、CRC計算の計算の複雑さがRTP/UDP/IPv4で約60％、RTP/UDP/IPv6で約80％を削減します。
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統計フィールドが変更されるたびに、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
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
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ヘッダーに対して圧縮が定義されていません。プロファイル0x0000は、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.
初期化後、プロファイル0x0000を使用してパケットを送信するための唯一のオーバーヘッドは、CIDのサイズです。非圧縮パケットが頻繁に発生する場合、プロファイル0x0000はサイズゼロまたは1オクテットのCIDに関連付けられている必要があります。プロファイル0x0000を複数のCIDと関連付ける必要はありません。
The initialization packet (IR packet) for Profile 0x0000 has the following format:
プロファイル0x0000の初期化パケット（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パケットに含まれる場合があります。減圧装置は、IRパケットの長さを考慮することにより、IPパケットが存在するかどうかを判断します。
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に関連付けられている場合、ADD-CIDオクテットがIPパケットに加えられます。チャネルが大きなCIDを使用すると、CIDが配置され、通常のパケットの2番目のオクテットから始まります。
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.
プロファイル0x0000には、単方向モードと双方向モードの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パケットを送信した後（リフレッシュ時に1つだけ）、コンプレッサーは通常の状態に切り替わります。
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.
d) IRパケットがNO_Context状態で受信されると、Decompressorは最初にCRCを使用してパケットを検証します。パケットが問題ない場合、減圧装置1）full_context状態に移動します。2）存在する場合は、IPパケットを上層に配信します、3）ACKを送信する場合があります。パケットが問題ない場合、さらなるアクションなしで破棄されます。
e) When any other packet is received in the NO_CONTEXT state, it is discarded without further action.
e) NO_Context状態で他のパケットが受信されると、さらなるアクションなしで破棄されます。
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を送信する場合があります。 パケットが問題ない場合、アクションは実行されません。
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.
g) 通常のパケットがfull_context状態で受信されると、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).
プロファイル0x0000のフィードバックの唯一のフィードバックはAcksです。プロファイル0x0000を拒否してはなりません。プロファイル0x0000は、せいぜい1つのCIDに関連付ける必要があります。ACKSセクション5.2のフィードバック1形式を使用します。フィードバック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プロファイルでは、コンプレッサーは16ビットシーケンス番号SNを生成し、パケットストリームで受信したパケットごとに1つ増加します。したがって、このシーケンス番号は比較的行方不明であり、ROHC RTPについて説明されているほとんどのメカニズムの基礎として機能します。以下のsnまたはudp snと呼ばれます。特に明記しない限り、ROHC RTPのメカニズムはROHC UDPにも使用され、UDP SNはRTPシーケンス番号の役割を担っています。
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プロファイルは、SNを解釈するときに常にp = -1を使用します。これは、コンプレッサーで生成された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) セクション5.7.7.1のようにIRパケットを使用します。ここで、プロファイルは2（2）で、静的チェーンは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）を使用します。これは、IR-Dynパケット（セクション5.7.7.2）を使用して行われます。プロファイル0x0002を識別します。動的チェーンは、UDPヘッダーで終了する既存の静的チェーンのプレフィックスに対応します。UDP SNは、以前のプロファイルがプロファイル0x0001である場合、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とは異なります。Checkumフィールドの後に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.
注：2）は、最初はRTPストリームであると想定されていたパケットストリームに使用できます。そのため、圧縮はプロファイル0x0001で始まりましたが、後で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ヘッダー（RTP SNを除く）のフィールドを扱うメカニズムは使用されません。減圧された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の開始を参照）。パディングとCIDは、フィードバックパケットタイプ（5.7.6.1）とフィードバックと同様に同じです。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.
圧縮パケットの一般的な形式も同じですが、以下に詳述する特定の形式と拡張機能に違いがあります。違いは、RTP SNを除くすべてのRTP固有の情報の削除によって引き起こされます。RTPSNはUDP SNに置き換えられます。
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
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
UOR-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.
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）クロックオプション（5.7.6.6）は使用されません。3）ジッターオプション（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) セクション5.7.7.1のようにIRパケットを使用することにより、プロファイルは3（3）で、静的チェーンは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ヘッダーの静的部分が含まれる既存のコンテキストを再利用することにより。これは、IR-Dynパケット（セクション5.7.7.2）を使用して行われます。プロファイル0x0003を識別します。動的チェーンは、ESPヘッダーで終了する既存の静的チェーンのプレフィックスに対応します。
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以外の暗号化アルゴリズムが使用されていることが明らかになった場合、コンプレッサーは2）に従ってIR-Dynを送信して、IRパケットを送信せずにプロファイル0x0003に切り替えることができます。
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.
ROHC ESPのパケットタイプは、ROHC UDPの場合と同じです。ただし、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.
このセクションでは、無効なコンテキストのために破棄されるパケットの数を減らすためのオプションの減圧剤操作について説明します。
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、...、i kとします。ここで、私は最初のパケットであり、I Kはコンテキストが更新される前の最後のパケットです。減圧器は、保存されたパケットを逆順序で回復しようとします。つまり、i kから始めて、iに戻ります。保存されたパケットが再構築されると、その正確性は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. Decompressorは、無効なコンテキストのために正しく減圧できない圧縮パケットを保存します。
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. Decompressorがコンテキストの更新パケットを受信し、コンテキストが検証された場合、保存された最後のパケットを回復するようになります。減圧後、減圧器は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.
3. 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セッションでは、2種類のパケットストリームがあります。1つはRTPヘッダーとアプリケーションデータを使用し、もう1つはRTCP制御情報を備えています。輸送レベルのストリーム間の違いはUDPポート番号にあります。RTPポート番号は常に均等です。RTCPポート番号はその数字と1つであり、したがって常に奇妙です[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.
1. CIDを使用してそれらを区別するためにCIDを使用して、同じチャネルで両方のタイプのストリームを運ぶ1つのコンプレッサー/減圧エンティティ。1つのチャネルにRTCPパケットと一緒に単一のRTPストリームを送信するには、lage_cidsをfalseに設定し、rtpパケットを暗黙のcid 0で送信し、add-cidメカニズムを使用してRTCPパケットを送信することが最も効率的です。
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用の2つのコンプレッサー/分解器エンティティ、もう1つはRTCP用のエンティティで、2つのタイプのストリームを別々のチャネルに携帯しています。これは、同じCID番号スペースを共有しないことを意味します。
RTCP headers may simply be sent uncompressed using profile 0x0000. More efficiently, ROHC UDP compression (profile 0x0002) can be used.
RTCPヘッダーは、プロファイル0x0000を使用して非圧縮されているだけで送信される場合があります。より効率的に、ROHC UDP圧縮（プロファイル0x0002）を使用できます。
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の実装には、2種類のパラメーターがあります。必須であり、コンプレッサーと減圧装置のピアとの間で交渉する必要がある構成パラメーターと、オプションで、使用するとROHC実装がどのように動作するかを規定する実装パラメーターです。
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 -Signalこのパラメーターは、静的部分と動的部分の両方でコンプレッサー全体のコンテキスト全体の再発現をトリガーします。コンプレッサーは、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 -value：正の整数のリスト（バイト）このパラメーターは、設定されている場合、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_aallowedまたはpacket_sizes_allowedが使用するために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.
モード - 値：[u-mode、o-mode、r-mode]このパラメーターは、パラメーターが値を変更したとき、つまりu-mode（unidirectionalモード）に変化するときに記述されたメカニズムを使用してモード遷移をトリガーします。モード（双方向の楽観的モード）またはRモード（双方向信頼できるモード）。モード遷移は、実装パラメーターによって信号されるように、現在のモードから新しいモードへと行われます。たとえば、現在のモードが双方向の楽観的モードである場合、モードには値が値が必要です。モードがRモードに変更されている場合、モード遷移は、双方向の楽観的モードから双方向信頼できるモードに行う必要があります。モードは、モード遷移のトリガーとして機能するだけでなく、どのモード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 -value：非陰性整数このパラメーターは、セクション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は、最悪の場合、交渉された数のコンテキストを収容できるよりも大きくすることができます。次に、コンテキストリソースが消費されると、フィードバックペイロードの拒否オプションを使用して、新しいコンテキストを設定しようとする試みが減圧器によって拒否される場合があります。
Upon reception of a REJECT option, the compressor SHOULD wait for a while before attempting to compress additional streams destined for the rejecting node.
拒否オプションを受信すると、コンプレッサーはしばらく待ってから、拒否ノードに向けて追加のストリームを圧縮しようとする必要があります。
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 These elements may be common to all modes or mode specific. The following table summarizes all these elements.
a) スライドウィンドウ（SW）B）翻訳テーブル（TT）C）フラグD）フィールドこれらの要素は、すべてのモードまたはモード固有に共通する場合があります。次の表は、これらすべての要素をまとめたものです。
+--------+---------------------------+-------------+----------------+
| | 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で定義）とaで指定されたフィールドで構成されていますが、bで指定されたフィールドを除外します。
a) Packet Arrival Time (if TIS = 1) Scaled RTP Time Stamp (if TSS = 1) (optional) Offset_i (if RND = 0) (optional)
a) パケットの到着時間（TIS = 1の場合）スケーリングされたRTPタイムスタンプ（TSS = 1の場合）（オプション）offset_i（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 UO_CSW: CSRC Sliding Window in U/O-mode
R_IESW：R-ModeのIPv6エクステンションヘッダースライドウィンドウUO_CSW：CSRCスライディングウィンドウ
UO_IESW: IPv6 Extension Header Sliding Window in U/O-mode
uo_iesw：ipv6拡張ヘッダースライディングウィンドウu/o-modeのウィンドウ
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：ipv6拡張ヘッダー翻訳テーブルU/o-modeのテーブル
UO_CTT: CSRC Translation Table in U/O-mode
uo_ctt：u/o-modeのcsrc翻訳テーブル
UO_IETT: IPv6 Extension Header Translation Table in U/O-mode
uo_iett：ipv6拡張ヘッダー翻訳テーブルU/o-modeのテーブル
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) Acked：減圧装置がこれまでに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で定義されている静的チェーンと同じです。動的部分は複数の要素で構成されており、その1つはすべての非停止フィールドを含む非スタット参照ヘッダーです。これらの非スタットフィールドは、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) Acked：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：最近受信したパケットのCSRCGEN_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-modeリスト圧縮では、コンプレッサー側と減圧器側の両方のスライドウィンドウの各エントリには、次の構造があります。
+--------+--------+------------+
| 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.
侵入者が（たとえば）偽の静的、動的、またはフィードバックパケットをリンクに導入し、それにより圧縮効率を低下させる場合、サービス拒否攻撃が可能です。ただし、この方法でリンクレイヤーに任意のパケットを注入する機能を持つ侵入者は、ヘッダー圧縮の使用に関連する追加のセキュリティ問題を提起します。
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つの最も有意なビットには特に重要なものがあります。 - 数え切れない。この関係を強調するには、プロファイル識別子を16進数（0x1234のように、たとえば0x0A34に取って代わる）を与える必要があります。
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.
[Iana-Consididerations]で概説されているポリシーに従って、プロファイル識別子に新しい値を割り当てるためのIANAポリシーは、必要な仕様です。値とその意味は、RFCまたは他の永続的で容易に利用可能な参照で、十分な詳細で文書化する必要があります。独立した実装間の相互運用性が可能です。8つのLSBでは、範囲0〜127はIETF標準トラック仕様用に予約されています。範囲128〜254は、この要件を満たす他の仕様（情報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
0x0000 RFCSIS ROHC非圧縮0x0001 rfcis rohc rtp 0x0002 rfcis rohc udp 0x0003 rfctis rohc esp
Earlier header compression schemes described in [CJHC], [IPHC], and [CRTP] have been important sources of ideas and knowledge.
[CJHC]、[IPHC]、および[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.
編集者は、実際に多くの編集作業を行ったMikael DeGermarkと、コピー編集をドキュメントに通過させたPeter Erikssonのおかげで、編集の一貫性を大幅に向上させました。もちろん、残りのすべての編集上の問題は、編集者によって挿入されました。
Thanks to Andreas Jonsson (Lulea University), who supported this work by his study of header field change patterns.
Andreas Jonsson（Lulea University）のおかげで、ヘッダーフィールド変更パターンの研究によってこの作品を支援しました。
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輸送エリアのディレクターであるAllison MankinとScott Bradnerから、編集と技術の両方のコメントで飾られた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] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPv4] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and 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.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 1889、1996年1月。
[HDLC] Simpson, W., "PPP in HDLC-like framing", STD 51, RFC 1662, July 1994.
[HDLC]シンプソン、W。、「HDLCのようなフレーミングのPPP」、STD 51、RFC 1662、1994年7月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998.
[ESP] Kent、S。およびR. Atkinson、「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] Glenn、R。およびS. Kent、「Null暗号化アルゴリズムとIPSECでのその使用」、RFC 2410、1998年11月。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH] Kent、S。およびR. Atkinson、「IP認証ヘッダー」、RFC 2402、1998年11月。
[MINE] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[鉱山] Perkins、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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、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。、「KeyおよびSequence Number GREへの拡張」、RFC 2890、2000年8月。
[ASSIGNED] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[割り当て] Reynolds、J。およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。
[VJHC] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[VJHC] Jacobson、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. Pink、「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. Jacobson、「低速シリアルリンクのIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[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.、Hannu、H.、Jonsson、L.E.、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-Considerations] Alvestrand、H。およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
Carsten Bormann, Editor Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
Carsten Bormann、編集者Universitaet Bremen Tzi Postfach 330440 D-28334ブレーメン、ドイツ
Phone: +49 421 218 7024
Fax: +49 421 218 7000
EMail: cabo@tzi.org
Carsten Burmeister Panasonic European Laboratories GmbH Monzastr. 4c 63225 Langen, Germany
Carsten Burmeister Panasonic European Laboratories Gmbh Monzastr。4C 63225 Langen、ドイツ
Phone: +49-6103-766-263
Fax: +49-6103-766-166
EMail: burmeister@panasonic.de
Mikael Degermark The University of Arizona Dept of Computer Science P.O. Box 210077 Tucson, AZ 85721-0077, USA
ミカエル・デジャーマークアリゾナ大学コンピューターサイエンス大学P.O.Box 210077 Tucson、AZ 85721-0077、米国
Phone: +1 520 621-3498
Fax: +1 520 621-4642
EMail: micke@cs.arizona.edu
Hideaki Fukushima Matsushita Electric Industrial Co., Ltd006, Kadoma, Kadoma City, Osaka, Japan
Hideaki Fukushima Matsushita Electric Industrial Co.、LTD006、Kadoma、Kadoma City、大阪、日本
Phone: +81-6-6900-9192 Fax: +81-6-6900-9193 EMail: fukusima@isl.mei.co.jp Hans Hannu Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden
電話：81-6-6900-9192 FAX：81-6-6900-9193メール：fukusima@isl.mei.co.jp Hans Hannu Box 920 Ericsson Erisoft AB SE-971 28 Lulea、Swedenen
Phone: +46 920 20 21 84
Fax: +46 920 20 20 99
EMail: hans.hannu@ericsson.com
Lars-Erik Jonsson Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden
Lars-erik Jonsson Box 920 Ericsson Erisoft AB SE-971 28 Lulea、Sweden
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
EMail: lars-erik.jonsson@ericsson.com
Rolf Hakenberg Panasonic European Laboratories GmbH Monzastr. 4c 63225 Langen, Germany
Rolf Hakenberg Panasonic European Laboratories Gmbh Monzastr。4C 63225 Langen、ドイツ
Phone: +49-6103-766-162
Fax: +49-6103-766-166
EMail: hakenberg@panasonic.de
Tmima Koren Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134, USA
Tmima Koren Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134、米国
Phone: +1 408-527-6169 EMail: tmima@cisco.com Khiem Le 2-700 Mobile Networks Laboratory Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA
電話：1 408-527-6169メール：tmima@cisco.com Khiem le 2-700モバイルネットワーク研究所ノキアリサーチセンター6000接続ドライブIrving、TX 75039、米国
Phone: +1-972-894-4882
Fax: +1 972 894-4589
EMail: khiem.le@nokia.com
Zhigang Liu 2-700 Mobile Networks Laboratory Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA
Zhigang Liu 2-700モバイルネットワーク研究所Nokia Research Center 6000 Connection Drive Irving、TX 75039、米国
Phone: +1 972 894-5935
Fax: +1 972 894-4589
EMail: zhigang.liu@nokia.com
Anton Martensson Ericsson Radio Systems AB Torshamnsgatan 23 SE-164 80 Stockholm, Sweden
アントン・マーテンソン・エリクソン・ラジオシステムab torshamnsgatan 23 Se-164 80ストックホルム、スウェーデン
Phone: +46 8 404 3881
Fax: +46 8 757 5550
EMail: anton.martensson@era.ericsson.se
Akihiro Miyazaki Matsushita Electric Industrial Co., Ltd 1006, Kadoma, Kadoma City, Osaka, Japan
明氏宮崎matsushita Electric Industrial Co.、Ltd 1006、Kadoma、Kadoma City、大阪、日本
Phone: +81-6-6900-9192 Fax: +81-6-6900-9193 EMail: akihiro@isl.mei.co.jp Krister Svanbro Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden
電話：81-6-6900-9192ファックス：81-6-6900-9193メール：akihiro@isl.mei.co.jp
Phone: +46 920 20 20 77
Fax: +46 920 20 20 99
EMail: krister.svanbro@ericsson.com
Thomas Wiebke Panasonic European Laboratories GmbH Monzastr. 4c 63225 Langen, Germany
Thomas Wiebke Panasonic European Laboratories Gmbh Monzastr。4C 63225 Langen、ドイツ
Phone: +49-6103-766-161
Fax: +49-6103-766-166
EMail: wiebke@panasonic.de
Takeshi Yoshimura NTT DoCoMo, Inc. 3-5, Hikarinooka Yokosuka, Kanagawa, 239-8536, Japan
Takeshi Yoshimura Ntt Docomo、Inc。3-5、Hikarinooka Yokosuka、Kanagawa、239-8536、日本
Phone: +81-468-40-3515
Fax: +81-468-40-3788
EMail: yoshi@spg.yrp.nttdocomo.co.jp
Haihong Zheng 2-700 Mobile Networks Laboratory Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA
Haihong Zheng 2-700モバイルネットワーク研究所Nokia Research Center 6000 Connection Drive Irving、TX 75039、米国
Phone: +1 972 894-4232
Fax: +1 972 894-4589
EMail: haihong.zheng@nokia.com
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は、圧縮と機能を最適化するために、さまざまなヘッダーフィールドをヘッダー圧縮スキームによってどのように処理するかについての結論とともに、この付録をまとめたものです。
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.
これらのフィールドには、パケットを運ぶフレームのサイズなど、他の値から推測できる値が含まれているため、圧縮スキームではまったく処理する必要はありません。
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-DEF STATIC fields whose values define a packet stream. They are in general handled as STATIC.
値がパケットストリームを定義する静的DEF静的フィールド。それらは一般に静的として処理されます。
STATIC-KNOWN These STATIC fields are expected to have well-known values and therefore do not need to be communicated at all.
静的に知られているこれらの静的フィールドは、よく知られている値を持つと予想されるため、まったく通信する必要はありません。
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ヘッダーフィールドのそれぞれがこれらのクラスのいずれかに割り当てられています。変更として分類された分野を除くすべてのフィールドについて、分類の動機も述べられています。セクションA.2では、予想される変化挙動に基づいて、変化するフィールドをさらに調べて分類します。
+---------------------+-------------+----------------+
| 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バージョンでなければなりません。したがって、フィールドは静的に分類されます。
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.
このフィールドは、特定のパケットストリームに属するパケットを識別するために使用できます。使用しない場合は、値をゼロに設定する必要があります。それ以外の場合、同じストリームに属するすべてのパケットは、このフィールドで同じ値を持っている必要があります。これは、ストリームを定義するフィールドの1つです。したがって、フィールドは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.
パケットの長さに関する情報（およびその結果、ペイロード長）は、リンクレイヤーによって提供されると予想されます。したがって、フィールドは推測されているように分類されます。
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.
このフィールドは通常、パケットストリームのすべてのパケットで同じ値を持ちます。後続のヘッダーのタイプをエンコードします。拡張ヘッダーが存在し、時には存在しない場合にのみ、フィールドはストリームの存続期間中にその値を変更します。したがって、フィールドは静的に分類されます。
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 |
+--------------+--------------+
+---------------------+-------------+----------------+
| 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バージョンでなければなりません。したがって、フィールドは静的に分類されます。
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ヘッダーには長いオプションが存在しないため、ヘッダーの長さは一定でよく知られています。オプションがある場合、フィールドは静的になりますが、ここではオプションがないと想定されています。したがって、このフィールドは静的な既知として分類されます。
Packet Length
パケット長
Information about packet length is expected to be provided by the link layer. The field is therefore classified as 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.
予約されたフラグはゼロに設定する必要があるため、静的な既知として分類されます。DONTフラグメント（DF）フラグは、ストリーム内のすべてのパケットに対して一定であるため、静的に分類されます。
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）フラグがゼロになると予想されます。したがって、より多くのフラグメントフラグは、静的な既知として分類されます。
Fragment Offset
フラグメントオフセット
Under the assumption that no fragmentation occurs, the fragment offset is always zero. The field is therefore classified as STATIC-KNOWN.
フラグメンテーションが発生しないという仮定の下では、フラグメントオフセットは常にゼロです。したがって、このフィールドは静的な既知として分類されます。
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.
このフィールドは通常、パケットストリームのすべてのパケットで同じ値を持ちます。後続のヘッダーのタイプをエンコードします。拡張ヘッダーが存在し、時には存在しない場合にのみ、フィールドはストリームの存続期間中にその価値を変更します。したがって、フィールドは静的に分類されます。
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ヘッダー情報が圧縮されている場合、この追加チェックサムを持つことには意味がありません。代わりに、減圧器側で再生できます。したがって、フィールドは推測されているように分類されます。
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 |
+--------------+----------------+
+------------------+-------------+-------------+
| 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 |
+------------+---------------+
+-----------------+-------------+----------------+
| 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.
したがって、バージョン2、つまりバージョン2の作業RTPバージョンのみが存在します。したがって、フィールドは静的な既知として分類されます。
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.
このフィールドの使用はアプリケーションに依存しますが、ペイロードパディングを使用すると、すべてのパケットに存在する可能性があります。したがって、フィールドは静的に分類されます。
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拡張機能がアプリケーションで使用されている場合、これらの拡張機能はすべてのパケットに存在する可能性があります（ただし、拡張機能の使用は非常にまれです）。ただし、安全のために、このフィールドは静的であり、静的ではないものとして分類されます。
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) |
+--------------+---------------+
Summarizing this for IP/UDP/RTP one obtains
IP/UDP/RTPのためにこれを要約する
+----------------+----------------+----------------+
| 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) |
+----------------+----------------+----------------+
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.
静的これらは、一般的に変更されていると分類されたフィールドですが、特定の追加の仮定により、ここでは静的として分類されます。
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.
これらのフィールドはほとんどの場合静的です。ただし、値が変更されますが、既知の数のパケットの後に元の値に戻ります。
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.
これらは不規則で、最後に、有用な変更パターンを特定できないフィールドです。
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.
分類が行われると、分類に従って、フィールド値および/またはフィールドデルタに関する追加の知識の可能性に関して、その他の詳細も記載されています。静的または半骨として分類されたフィールドの場合、フィールドの値は静的であるだけでなく、先験的によく知られている（半骨磁場の2つの状態）である可能性があります。非不規則な変更動作を持つフィールドの場合、変化は通常、フィールドの最大変化と比較して限られた範囲内にあることが知られている可能性があります。他のフィールドの場合、値は完全に不明です。
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：ヘッダーフィールドの変更の分類
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および以下の議論は、圧縮ポイントの前の損失または並べ替えによって引き起こされる変更を考慮しないことに注意してください。
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ヘッダーの識別フィールド（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が、各パケットストリームの個別の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フィールドがすべてのパケットでISに送信される非効率的で信頼性の高いソリューションがあり、圧縮ヘッダーが2オクターで増加します。これは、送信者がIDフィールドのランダム割り当てを使用する場合、IDフィールドを処理する最良の方法です。第二に、シーケンシャルジャンプの割り当てが使用されている限り、ID処理に必要なビットをより少なくする必要があるより柔軟なメカニズムを備えたソリューションがあります。このようなソリューションは、送信者がランダム割り当てを使用する場合、おそらくさらに多くのビットを必要とします。したがって、送信者の割り当てポリシーに関する知識は、上記の2つのソリューションを選択する場合に役立ちます。最後に、IPv4の場合でも、ヘッダー圧縮は、圧縮ヘッダーに含まれるIDフィールドの追加情報なしで設計できます。このようなスキームを使用するには、送信者が使用しているIDフィールドの割り当てポリシーを知っている必要があります。それは知ることができないかもしれませんが、これはそのようなソリューションの適用性が非常に不確実であることを意味します。ただし、セルラー端子のIPv4スタックの設計者は、シーケンシャルに近い割り当てポリシーを使用する必要があります。
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）フィールドは、パケットストリームの寿命中に一定になるか、比較的めったに変化することが予想されます。
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）フィールドは、パケットストリームの寿命の間に一定であるか、ルートの変更による限られた数の値を交互にすると予想されます。
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チェックサムはオプションです。無効になった場合、その値は常にゼロであり、圧縮される可能性があります。有効にすると、その値はペイロードに依存します。これは、圧縮目的では、すべてのパケットでランダムに変化することと同等です。
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ミキサーが使用されない限り、このフィールドの値はゼロです。
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.
オーディオの場合、マーカービットはTalkspurtの最初のパケットでのみ設定する必要がありますが、ビデオではすべての画像の最後のパケットに設定する必要があります。これは、どちらの場合も、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ペイロードタイプの変更はまれであると予想されます。アプリケーションは、ペイロードの種類やフレームサイズを変更することにより、うっ血に適応する可能性がありますが、それは頻繁に発生するとは予想されていません。
The RTP Sequence Number will be incremented by one for each packet sent.
RTPシーケンス番号は、送信されるパケットごとに1つずつ増加します。
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シーケンス番号に従います。静かな期間があり、新しいTalkspurtが始まると、タイムスタンプは静かな期間の長さに比例してジャンプします。ただし、増分はおそらく比較的限られた範囲内にあります。
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.
2つの連続したパケットの間に、タイムスタンプは変更されず、画像クロック周波数に対応する固定値の倍数によって増加します。Bピクチャーを使用すると、タイムスタンプは固定値の倍数によって減少する可能性があります。画像クロック周波数の倍数として表されるデルタ間隔は、ほとんどの場合非常に限られています。
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フィールドはまったく存在しません。
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つの異なるアクションが可能です。これらは、各アクションが適用されるフィールドと一緒にリストされています。
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 Checksum（無効の場合）-RTPバージョン
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:
パケットストリームの生涯を通じて一定のフィールドは、1回だけ分解器に正しく配信される必要があります。これらは：
- 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拡張フラグ-RTPSSRC
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の次のヘッダーフィールドの値は、その後のヘッダーのタイプに有効になっているため、サブヘッダーが挿入または削除された場合、特別な治療に値します。
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タイムスタンプ
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シーケンス番号
Fields that have completely random values for each packet must be included as-is in all compressed headers. Those fields are:
各パケットに完全にランダムな値を持つフィールドは、すべての圧縮ヘッダーにISを含める必要があります。それらのフィールドは次のとおりです。
- IPv4 Identification (if randomly assigned) - UDP Checksum (if enabled)
- IPv4識別（ランダムに割り当てられた場合）-UDPチェックサム（有効になっている場合）
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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。