[要約] 要約：RFC 3545は、高遅延、パケットロス、およびパケット順序の問題を解決するための改良された圧縮RTP（CRTP）プロトコルについての規格です。 目的：このRFCの目的は、ネットワークの問題によって引き起こされる通信の品質低下を軽減し、効率的なデータ転送を実現するためのCRTPの実装を提供することです。
Network Working Group T. Koren
Request for Comments: 3545 Cisco Systems
Category: Standards Track S. Casner
Packet Design
J. Geevarghese
Motorola India Electronics Ltd.
B. Thompson
P. Ruddy
Cisco Systems
July 2003
Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering
高い遅延、パケットの損失、並べ替えを伴うリンクのための拡張圧縮RTP（CRTP）
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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays.
このドキュメントでは、パケットの損失と長い遅延を備えたポイントツーポイントリンクのヘッダー圧縮スキームについて説明します。これは、RFC 2508で説明されているIP/UDP/RTPヘッダー圧縮である圧縮リアルタイムトランスポートプロトコル（CRTP）に基づいています。CRTPはそのようなリンクではうまく機能しません。コンテキストが修復される前に、より多くのパケットが破棄されます。このようなリンクに対するCRTPの動作を修正するために、プロトコルへのいくつかの拡張機能をここで指定します。拡張機能は、コンプレッサーがdecompressorのコンテキストを更新する方法を変更することにより、コンテキストの破損を減らすことを目的としています。これらの拡張機能により、CRTPはパケットの損失、パケットの再注文、長い遅延を伴うリンクをよく実行します。
Table of Contents
目次
1. Introduction ................................................. 2
1.1. CRTP Operation ......................................... 4
1.2. How do contexts get corrupted? ......................... 4
1.3. Preventing context corruption .......................... 5
1.4. Specification of Requirements .......................... 5
2. Enhanced CRTP ................................................ 5
2.1. Extended COMPRESSED_UDP packet ......................... 6
2.2. CRTP Headers Checksum .................................. 11
2.3. Achieving robust operation ............................. 13
2.3.1. Examples ....................................... 15
3. Negotiating usage of enhanced-CRTP ........................... 18
4. Security Considerations ...................................... 18
5. Acknowledgements ............................................. 19
6. References ................................................... 19
6.1. Normative References ................................... 19
6.2. Informative References ................................. 20
7. Intellectual Property Rights Notice .......................... 20
8. Authors' Addresses ........................................... 21
9. Full Copyright Statement ..................................... 22
RTP header compression (CRTP) as described in RFC 2508 was designed to reduce the header overhead of IP/UDP/RTP datagrams by compressing the three headers. The IP/UDP/RTP headers are compressed to 2-4 bytes most of the time.
RFC 2508で説明されているRTPヘッダー圧縮（CRTP）は、3つのヘッダーを圧縮することにより、IP/UDP/RTPデータグラムのヘッダーオーバーヘッドを減らすように設計されました。IP/UDP/RTPヘッダーは、ほとんどの場合2〜4バイトに圧縮されます。
CRTP was designed for reliable point to point links with short delays. It does not perform well over links with high rate of packet loss, packet reordering and long delays.
CRTPは、短い遅延を伴う信頼できるポイントツーポイントリンク向けに設計されています。パケット損失の割合、パケットの並べ替え、長い遅延のあるリンクよりもうまく機能しません。
An example of such a link is a PPP session that is tunneled using an IP level tunneling protocol such as L2TP. Packets within the tunnel are carried by an IP network and hence may get lost and reordered. The longer the tunnel, the longer the round trip time.
このようなリンクの例は、L2TPなどのIPレベルのトンネルプロトコルを使用してトンネル化されたPPPセッションです。トンネル内のパケットはIPネットワークによって運ばれるため、紛失して並べ替える可能性があります。トンネルが長いほど、往復時間が長くなります。
Another example is an IP network that uses layer 2 technologies such as ATM and Frame Relay for the access portion of the network. Layer 2 transport networks such as ATM and Frame Relay behave like point to point serial links in that they do not reorder packets. In addition, Frame Relay and ATM virtual circuits used as IP access technologies often have a low bit rate associated with them. These virtual circuits differ from low speed serial links in that they may span a larger physical distance than a point to point serial link. Speed of light delays within the layer 2 transport network will result in higher round trip delays between the endpoints of the circuit. In addition, congestion within the layer 2 transport network may result in an effective drop rate for the virtual circuit which is significantly higher than error rates typically experienced on point to point serial links.
別の例は、ネットワークのアクセス部分にATMやフレームリレーなどのレイヤー2テクノロジーを使用するIPネットワークです。ATMやフレームリレーなどのレイヤー2トランスポートネットワークは、パケットを並べ替えないという点で、ポイントトゥポイントシリアルリンクのように動作します。さらに、IPアクセステクノロジーとして使用されるフレームリレーとATM仮想回路は、それらに関連するビットレートが低いことがよくあります。これらの仮想回路は、ポイントツーポイントシリアルリンクよりも大きな物理的距離に及ぶ可能性があるという点で、低速シリアルリンクとは異なります。レイヤー2トランスポートネットワーク内の光の遅延速度は、回路のエンドポイント間の往復遅延が高くなります。さらに、レイヤー2トランスポートネットワーク内の輻輳により、仮想回路の有効なドロップレートが発生する可能性があります。仮想回路は、ポイントツーポイントシリアルリンクで通常経験されるエラーレートよりも大幅に高くなります。
It may be desirable to extend existing CRTP implementations for use also over IP tunnels and other virtual circuits, where packet losses, reordering, and long delays are common characteristics. To address these scenarios, this document defines modifications and extensions to CRTP to increase robustness to both packet loss and misordering between the compressor and the decompressor. This is achieved by repeating updates and allowing the sending of absolute (uncompressed) values in addition to delta values for selected context parameters. Although these new mechanisms impose some additional overhead, the overall compression is still substantial. The enhanced CRTP, as defined in this document, is thus suitable for many applications in the scenarios discussed above, e.g., tunneling and other virtual circuits.
IPトンネルやその他の仮想サーキットでも使用するために既存のCRTP実装を拡張することが望ましい場合があります。パケット損失、再注文、および長い遅延は一般的な特性です。これらのシナリオに対処するために、このドキュメントでは、CRTPへの変更と拡張を定義して、コンプレッサーと減圧器間のパケット損失と誤った順序の両方の堅牢性を高めます。これは、更新を繰り返し、選択したコンテキストパラメーターのデルタ値に加えて、絶対的な（非圧縮）値の送信を許可することで達成されます。これらの新しいメカニズムは追加のオーバーヘッドを課しますが、全体的な圧縮は依然としてかなりのものです。したがって、このドキュメントで定義されているように、拡張されたCRTPは、上記のシナリオ、例えばトンネルやその他の仮想回路の多くのアプリケーションに適しています。
RFC 3095 defines another RTP header compression scheme called Robust Header Compression [ROHC]. ROHC was developed with wireless links as the main target, and introduced new compression mechanisms with the primary objective to achieve the combination of robustness against packet loss and maximal compression efficiency. ROHC is expected to be the preferred compression mechanism over links where compression efficiency is important. However, ROHC was designed with the same link assumptions as CRTP, e.g., that the compression scheme should not have to tolerate misordering of compressed packets between the compressor and decompressor, which may occur when packets are carried in an IP tunnel across multiple hops.
RFC 3095は、堅牢なヘッダー圧縮[ROHC]と呼ばれる別のRTPヘッダー圧縮スキームを定義します。ROHCは、ワイヤレスリンクを主要なターゲットとして開発し、パケット損失と最大圧縮効率に対する堅牢性の組み合わせを実現するための主要な目的で新しい圧縮メカニズムを導入しました。ROHCは、圧縮効率が重要なリンクよりも好ましい圧縮メカニズムになると予想されます。ただし、ROHCは、CRTPと同じリンクの仮定で設計されています。たとえば、圧縮スキームは、コンプレッサーと減圧装置間の圧縮パケットの誤った順序に耐える必要はないということです。
At some time in the future, enhancements may be defined for ROHC to allow it to perform well in the presence of misordering of compressed packets. The result might be more efficient than the compression protocol specified in this document. However, there are many environments for which the enhanced CRTP defined here may be the preferred choice. In particular, for those environments where CRTP is already implemented, the additional effort required to implement the extensions defined here is expected to be small. There are also cases where the implementation simplicity of this enhanced CRTP relative to ROHC is more important than the performance advantages of ROHC.
将来のある時期には、ROHCの強化が定義され、圧縮パケットの誤用装置の存在下でうまく機能できるようにすることができます。結果は、このドキュメントで指定された圧縮プロトコルよりも効率的かもしれません。ただし、ここで定義されている強化されたCRTPが好ましい選択である可能性のある多くの環境があります。特に、CRTPが既に実装されている環境では、ここで定義されている拡張機能を実装するために必要な追加の取り組みが小さいと予想されます。また、ROHCに対するこの強化されたCRTPの実装の単純さが、ROHCのパフォーマンスの利点よりも重要な場合もあります。
During compression of an RTP stream, a session context is defined. For each context, the session state is established and shared between the compressor and the decompressor. Once the context state is established, compressed packets may be sent.
RTPストリームの圧縮中に、セッションコンテキストが定義されます。各コンテキストについて、セッション状態が確立され、コンプレッサーと減圧器の間で共有されます。コンテキスト状態が確立されると、圧縮パケットが送信される場合があります。
The context state consists of the full IP/UDP/RTP headers, a few first order differential values, a link sequence number, a generation number and a delta encoding table.
コンテキスト状態は、完全なIP/UDP/RTPヘッダー、いくつかの一次差、リンクシーケンス番号、生成番号、デルタエンコードテーブルで構成されています。
The headers part of the context is set by the FULL_HEADER packet that always starts a compression session. The first order differential values (delta values) are set by sending COMPRESSED_RTP packets that include updates to the delta values.
コンテキストのヘッダー部分は、常に圧縮セッションを開始するFull_headerパケットによって設定されます。一次差（デルタ値）は、Delta値の更新を含むCompressed_RTPパケットを送信することにより設定されます。
The context state must be synchronized between compressor and decompressor for successful decompression to take place. If the context gets out of sync, the decompressor is not able to restore the compressed headers accurately. The decompressor invalidates the context and sends a CONTEXT_STATE packet to the compressor indicating that the context has been corrupted. To resume compression, the compressor must re-establish the context.
コンテキスト状態は、コンプレッサーと減圧器間で同期して、減圧を成功させるために行う必要があります。コンテキストが同期しなくなった場合、減圧器は圧縮ヘッダーを正確に復元できません。Decompressorはコンテキストを無効にし、Context_Stateパケットをコンプレッサーに送信して、コンテキストが破損していることを示します。圧縮を再開するには、コンプレッサーがコンテキストを再確立する必要があります。
During the time the context is corrupted, the decompressor discards all the packets received for that context. Since the context repair mechanism in CRTP involves feedback from the decompressor, context repair takes at least as much time as the round trip time of the link. If the round trip time of the link is long, and especially if the link bandwidth is high, many packets will be discarded before the context is repaired. On such links it is desirable to minimize context invalidation.
コンテキストが破損する間、減圧器はそのコンテキストで受け取ったすべてのパケットを破棄します。CRTPのコンテキスト修復メカニズムには減圧装置からのフィードバックが含まれるため、コンテキストの修理には、リンクの往復時間と少なくとも同じくらいの時間がかかります。リンクの往復時間が長く、特にリンク帯域幅が高い場合、コンテキストが修復される前に多くのパケットが破棄されます。このようなリンクでは、コンテキストの無効化を最小限に抑えることが望ましいです。
As long as the fields in the combined IP/UDP/RTP headers change as expected for the sequence of packets in a session, those headers can be compressed, and the decompressor can fully restore the compressed headers using the context state. When the headers don't change as expected it's necessary to update some of the full or the delta values of the context. For example, the RTP timestamp is expected to increment by delta RTP timestamp (dT). If silence suppression is used, packets are not sent during silence periods. Then when voice activity resumes, packets are sent again, but the RTP timestamp is incremented by a large value and not by dT. In this case an update must be sent.
セッション内のパケットのシーケンスに期待どおりに変更されたIP/UDP/RTPヘッダーのフィールドが変更されている限り、それらのヘッダーを圧縮し、コンプレッサーはコンテキスト状態を使用して圧縮ヘッダーを完全に復元できます。ヘッダーが予想どおりに変更されない場合、コンテキストの完全またはデルタ値の一部を更新する必要があります。たとえば、RTPタイムスタンプは、Delta RTPタイムスタンプ（DT）によって増加すると予想されます。沈黙の抑制が使用されている場合、沈黙期間中にパケットは送信されません。その後、音声アクティビティが再開すると、パケットが再び送信されますが、RTPタイムスタンプはDTではなく大きな値によって増加します。この場合、更新を送信する必要があります。
If a packet that includes an update to some context state values is lost, the state at the decompressor is not updated. The shared state is now different at the compressor and decompressor. When the next packet arrives at the decompressor, the decompressor will fail to restore the compressed headers accurately since the context state at the decompressor is different than the state at the compressor.
コンテキスト状態値の更新を含むパケットが失われた場合、減圧器の状態は更新されません。共有状態は現在、コンプレッサーと減圧器で異なります。次のパケットが減圧器に到着すると、減圧剤のコンプレッサー状態はコンプレッサーの状態とは異なるため、減圧器は圧縮ヘッダーを正確に復元できません。
Note that the decompressor fails not when a packet is lost, but when the next compressed packet arrives. If the next packet happens to include the same context update as in the lost packet, the context at the decompressor may be updated successfully and decompression may continue uninterrupted. If the lost packet included an update to a delta field such as the delta RTP timestamp (dT), the next packet can't compensate for the loss since the update of a delta value is relative to the previous packet which was lost. But if the update is for an absolute value such as the full RTP timestamp or the RTP payload type, this update can be repeated in the next packet independently of the lost packet. Hence it is useful to be able to update the absolute values of the context.
減圧器は、パケットが紛失したときではなく、次の圧縮パケットが到着したときに失敗することに注意してください。次のパケットに、失われたパケットと同じコンテキスト更新が含まれる場合、減圧器のコンテキストが正常に更新され、減圧が中断されない場合があります。Lost Packetに、Delta RTP Timestamp（DT）などのDeltaフィールドの更新が含まれている場合、Delta値の更新が失われた前のパケットに関連しているため、次のパケットは損失を補償できません。ただし、アップデートが完全なRTPタイムスタンプやRTPペイロードタイプなどの絶対値の場合、この更新は失われたパケットとは無関係に次のパケットで繰り返すことができます。したがって、コンテキストの絶対値を更新できると便利です。
The next chapter describes several extensions to CRTP that add the capability to selectively update absolute values of the context, rather than sending a FULL_HEADER packet, in addition to the existing updates of the delta values. This enhanced version of CRTP is intended to minimize context invalidation and thus improve the performance over lossy links with a long round trip time.
次の章では、Delta値の既存の更新に加えて、Full_headerパケットを送信するのではなく、コンテキストの絶対値を選択的に更新する機能を追加するCRTPへのいくつかの拡張について説明します。CRTPのこの拡張バージョンは、コンテキストの無効化を最小限に抑え、長い往復時間で損失のあるリンクよりもパフォーマンスを向上させることを目的としています。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This chapter specifies the changes in this enhanced version of CRTP. They are:
この章では、CRTPのこの拡張バージョンの変更を指定します。彼らです：
- Extensions to the COMPRESSED_UDP packet to allow updating the differential RTP values in the decompressor context and to selectively update the absolute IPv4 ID and the following RTP values: sequence number, timestamp, payload type, CSRC count and CSRC list. This allows context sync to be maintained even with some packet loss.
- Compressed_udpパケットへの拡張機能は、Decompressorコンテキストで差動RTP値を更新し、絶対IPv4 IDと次のRTP値を選択的に更新します：シーケンス番号、タイムスタンプ、ペイロードタイプ、CSRCカウント、CSRCリスト。これにより、パケットの損失がある場合でも、コンテキスト同期を維持できます。
- A "headers checksum" to be inserted by the compressor and removed by the decompressor when the UDP checksum is not present so that validation of the decompressed headers is still possible. This allows the decompressor to verify that context sync has not been lost after a packet loss.
- コンプレッサーによって挿入され、分解器によって削除された「ヘッダーチェックサム」は、UDPチェックサムが存在しない場合、減圧されたヘッダーの検証がまだ可能です。これにより、減圧装置は、パケットの損失後にコンテキスト同期が失われていないことを確認できます。
An algorithm is then described to use these changes with repeated updates to achieve robust operation over links with packet loss and long delay.
次に、アルゴリズムを説明して、これらの変更を繰り返し更新して使用して、パケットの損失と長い遅延を伴うリンク上の堅牢な操作を実現します。
It is possible to accommodate some packet loss between the compressor and decompressor using the "twice" algorithm in RFC 2508 so long as the context remains in sync. In that algorithm, the delta values are added to the previous context twice (or more) to effect the change that would have occurred if the missing packets had arrived. The result is verified with the UDP checksum. Keeping the context in sync requires reliably communicating both the absolute value and the delta value whenever the delta value changes. For many environments, sufficient reliability can be achieved by repeating the update with each of several successive packets.
コンテキストが同期している限り、RFC 2508の「2回」アルゴリズムを使用して、コンプレッサーと減圧装置間のパケット損失に対応することができます。そのアルゴリズムでは、Delta値が前のコンテキストに2回（またはそれ以上）追加され、欠落したパケットが到着した場合に発生した変更を実施します。結果は、UDPチェックサムで検証されています。コンテキストを同期させるには、デルタ値が変更されるたびに絶対値とデルタ値の両方を確実に通信する必要があります。多くの環境では、いくつかの連続したパケットのそれぞれで更新を繰り返すことで、十分な信頼性を実現できます。
The COMPRESSED_UDP packet satisfies the need to communicate the absolute values of the differential RTP fields, but it is specified in RFC 2508 to reset the delta RTP timestamp. That limitation can be removed with the following simple change: RFC 2508 describes the format of COMPRESSED_UDP as being the same as COMPRESSED_RTP except that the M, S and T bits are always 0 and the corresponding delta fields are never included. This enhanced version of CRTP changes that specification to say that the T bit MAY be nonzero to indicate that the delta RTP timestamp is included explicitly rather than being reset to zero.
Compressed_udpパケットは、差動RTPフィールドの絶対値を通信する必要性を満たしますが、Delta RTPタイムスタンプをリセットするためにRFC 2508で指定されています。この制限は、次の単純な変更で削除できます。RFC2508は、m、s、およびtビットが常に0であり、対応するデルタフィールドが含まれないことを除いて、Compressed_udpの形式をCompressed_rtpと同じであると説明します。CRTPのこの拡張バージョンは、Tビットがゼロにリセットされるのではなく、Delta RTPタイムスタンプが明示的に含まれていることを示すために、tビットがゼロではないと言うようにその仕様を変更します。
A second change adds another byte of flag bits to the COMPRESSED_UDP packet to allow only selected individual uncompressed fields of the RTP header to be included in the packet rather than carrying the full RTP header as part of the UDP data. The additional flags do increase computational complexity somewhat, but the corresponding increase in bit efficiency is important when the differential field updates are communicated multiple times in successive COMPRESSED_UDP packets. With this change, there are flag bits to indicate inclusion of both delta values and absolute values, so the flag nomenclature is changed. The original S, T, I bits which indicate the inclusion of deltas are renamed dS, dT, dI, and the inclusion of absolute values is indicated by S, T, I. The M bit is absolute as before. A new flag P indicates inclusion of the absolute RTP payload type value and another flag C indicates the inclusion of the CSRC count. When C=1, an additional byte is added following the two flag bytes to include the absolute value of the four-bit CC field in the RTP header.
2番目の変更により、Compressed_udpパケットにフラグビットの別のバイトが追加され、RTPヘッダーの選択された個々の非圧縮フィールドのみが、UDPデータの一部として完全なRTPヘッダーを運ぶのではなく、パケットに含めることができます。追加のフラグは計算の複雑さをいくらか増やしますが、微分フィールドの更新が連続してCompredessed_udpパケットで複数回通信されると、ビット効率の対応する増加が重要です。この変更により、デルタ値と絶対値の両方を含めることを示すフラグビットがあるため、旗の命名法が変更されます。デルタの包含を示す元のs、t、iビットは、DS、DT、DIと改名され、絶対値を含めることはS、T、Iによって示されます。Mビットは以前と同様に絶対的です。新しいフラグPは、絶対RTPペイロードタイプ値を含めることを示し、別のフラグCはCSRCカウントの包含を示します。C = 1の場合、2つのフラグバイトに続いて追加のバイトが追加され、RTPヘッダーの4ビットCCフィールドの絶対値が含まれます。
The last of the three changes to the COMPRESSED_UDP packet deals with updating the IPv4 ID field. For this field, the COMPRESSED_UDP packet as specified in RFC 2508 can already convey a new value for the delta IPv4 ID, but not the absolute value which is only conveyed by the FULL_HEADER packet. Therefore, a new flag I is added to the COMPRESSED_UDP packet to indicate inclusion of the absolute IPv4 ID value. The I flag replaces the dS flag which is not needed in the COMPRESSED_UDP packet since the delta RTP sequence number always remains 1 in the decompressor context and hence does not need to be updated. Note that IPv6 does not have an IP ID field, so when compressing IPv6 packets both the I and the dI flags are always set to 0.
Compressed_udpパケットの3つの変更の最後は、IPv4 IDフィールドの更新を扱います。このフィールドでは、RFC 2508で指定されているCompressed_udpパケットは、full_headerパケットによってのみ伝達される絶対値ではなく、delta ipv4 idの新しい値を既に伝えることができます。したがって、絶対IPv4ID値の包含を示すために、Compressed_udpパケットに新しいフラグが追加されます。Iフラグは、Delta RTPシーケンス番号が常に減圧器のコンテキストでは1のままであるため、更新する必要はないため、Compressed_UDPパケットでは必要ないDSフラグに置き換えられます。IPv6にはIP IDフィールドがないため、IPv6パケットを圧縮する場合、iフラグとDIフラグの両方が常に0に設定されています。
The format of the flags/sequence byte for the original COMPRESSED_UDP packet is shown here for reference:
元のCompressed_udpパケットのフラグ/シーケンスバイトの形式は、参照のためにここに示されています。
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 |dI | link sequence |
+---+---+---+---+---+---+---+---+
The new definition of the flags/sequence byte plus an extension flags byte for the COMPRESSED_UDP packet is as follows, where the new F flag indicates the inclusion of the extension flags byte:
Flags/Sequence Byteの新しい定義と、Compressed_udpパケットの拡張フラグバイトは次のとおりです。新しいFフラグは、拡張フラグバイトの包含を示します。
+---+---+---+---+---+---+---+---+
| F | I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
: M : S : T : P : C : 0 : 0 : 0 : (if F = 1)
+...+...+...+...+...+...+...+...+
dI = delta IPv4 ID dT = delta RTP timestamp I = absolute IPv4 ID F = additional flags byte M = marker bit S = absolute RTP sequence number T = absolute RTP timestamp P = RTP payload type C = CSRC count CID = Context ID When F=0, there is only one flags byte, and the only available flags are: dI, dT and I. In this case the packet includes the full RTP header. As in RFC 2508, if dI=0, the decompressor does not change deltaI. If dT=0, the decompressor sets deltaT to 0.
di = delta ipv4 id dt = delta rtpタイムスタンプi =絶対IPv4 id f =追加フラグbyte m =マーカービットs =絶対rtpシーケンス番号t =絶対rtpタイムスタンプp = rtpペイロードタイプc = csrcカウントcid =コンテキストid= 0には、フラグが1つだけあり、利用可能なフラグは唯一のフラグです：DI、DT、およびIの場合、この場合、パケットには完全なRTPヘッダーが含まれています。RFC 2508のように、Di = 0の場合、減圧器はDeltaiを変更しません。dt = 0の場合、分解器はdeltatを0に設定します。
When C=1, an additional byte is added following the two flag bytes. This byte includes the CC, the count of CSRC identifiers, in its lower 4 bits:
C = 1の場合、2つのフラグバイトに続いて追加のバイトが追加されます。このバイトには、4ビットの下部にあるCSRC識別子のカウントCCが含まれます。
+---+---+---+---+---+---+---+---+
| F | I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
: M : S : T : P : C : 0 : 0 : 0 : (if F = 1)
+...+...+...+...+...+...+...+...+
: 0 : 0 : 0 : 0 : CC : (if C = 1)
+...+...+...+...+...............+
The bits marked "0" in the second flag byte and the CC byte SHOULD be set to zero by the sender and SHOULD be ignored by the receiver.
2番目のフラグバイトとCCバイトの「0」とマークされたビットは、送信者によってゼロに設定され、受信機は無視する必要があります。
Some example packet formats will illustrate the use of the new flags. First, when F=0, the "traditional" COMPRESSED_UDP packet which carries the full RTP header as part of the UDP data:
パケット形式の例のいくつかは、新しいフラグの使用を示しています。まず、f = 0の場合、UDPデータの一部として完全なRTPヘッダーを搭載した「従来の」Compressed_udpパケット：
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+---+---+---+---+---+---+---+---+
|F=0| I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
: :
+ UDP checksum + (if nonzero in context)
: :
+...............................+
: :
+ "RANDOM" fields + (if encapsulated)
: :
+...............................+
: delta IPv4 ID : (if dI = 1)
+...............................+
: delta RTP timestamp : (if dT = 1)
+...............................+
: :
+ IPv4 ID + (if I = 1)
: :
+...............................+
| UDP data |
: (uncompressed RTP header) :
When F=1, there is an additional flags byte and the available flags are: dI, dT, I, M, S, T, P, C. If C=1, there is an additional byte that includes the number of CSRC identifiers. When F=1, the packet does not include the full RTP header, but includes selected fields from the RTP header as specified by the flags. As in RFC 2508, if dI=0 the decompressor does not change deltaI. However, in contrast to RFC 2508, if dT=0 the decompressor KEEPS THE CURRENT deltaT in the context (DOES NOT set deltaT to 0).
f = 1の場合、追加のフラグバイトがあり、利用可能なフラグは次のとおりです。Di、dt、i、m、s、t、p、C。。F = 1の場合、パケットには完全なRTPヘッダーは含まれていませんが、フラグで指定されているRTPヘッダーから選択したフィールドが含まれます。RFC 2508のように、Di = 0の場合、減圧器はDeltaiを変更しません。ただし、RFC 2508とは対照的に、dt = 0の場合、減圧器はコンテキストに現在のdeltatを保持します（deltatを0に設定しません）。
An enhanced COMPRESSED_UDP packet is similar in contents and behavior to a COMPRESSED_RTP packet, but it has more flag bits, some of which correspond to absolute values for RTP header fields.
拡張されたCompressed_udpパケットは、Compressed_RTPパケットとコンテンツと動作が類似していますが、フラグビットが多くあり、その一部はRTPヘッダーフィールドの絶対値に対応しています。
COMPRESSED_UDP with individual RTP fields, when F=1:
f = 1の場合、個々のRTPフィールドを使用したCompressed_udp：
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+---+---+---+---+---+---+---+---+
|F=1| I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
| M | S | T | P | C | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+
: 0 : 0 : 0 : 0 : CC : (if C = 1)
+...+...+...+...+...............+
: :
+ UDP checksum + (if nonzero in context)
: :
+...............................+
: :
: "RANDOM" fields : (if encapsulated)
: :
+...............................+
: delta IPv4 ID : (if dI = 1)
+...............................+
: delta RTP timestamp : (if dT = 1)
+...............................+
: :
+ IPv4 ID + (if I = 1)
: :
+...............................+
: :
+ RTP sequence number + (if S = 1)
: :
+...............................+
: :
+ +
: :
+ RTP timestamp + (if T = 1)
: :
+ +
: :
+...............................+
: RTP payload type : (if P = 1)
+...............................+
: :
: CSRC list : (if CC > 0)
: :
+...............................+
: :
: RTP header extension : (if X set in context)
: :
+-------------------------------+
| |
/ RTP data /
/ /
| |
+-------------------------------+
: padding : (if P set in context)
+...............................+
Usage for the enhanced COMPRESSED_UDP packet:
Enhanced Compressed_udpパケットの使用：
It is useful for the compressor to periodically refresh the state of the decompressor to avoid having the decompressor send CONTEXT_STATE messages in the case of unrecoverable packet loss. Using the flags F=0 and I=1, dI=1, dT=1, the COMPRESSED_UDP packet refreshes all the context parameters.
コンプレッサーが解凍器の状態を定期的に更新して、回転不可能なパケット損失の場合にdecompressorがContext_Stateメッセージを送信させないようにするのに役立ちます。フラグf = 0およびi = 1、di = 1、dt = 1を使用して、Compressed_udpパケットはすべてのコンテキストパラメーターを再リッシュします。
When compression is done over a lossy link with a long round trip delay, we want to minimize context invalidation. If the delta values are changing frequently, the context might get invalidated often. In such cases the compressor MAY choose to always send absolute values and never delta values, using COMPRESSED_UDP packets with the flags F=1, and any of S, T, I as necessary.
長い往復遅延を伴う喪失したリンクで圧縮が行われると、コンテキストの無効化を最小限に抑えたいと思います。デルタ値が頻繁に変化している場合、コンテキストが頻繁に無効になる可能性があります。そのような場合、コンプレッサーは、フラグf = 1を使用してCompressed_udpパケットを使用して、必要に応じてs、t、iのいずれかを使用して、常に絶対値を送信し、デルタ値を絶対に送信することを選択できます。
RFC 2508, in Section 3.3.5, describes how the UDP checksum may be used to validate header reconstruction periodically or when the "twice" algorithm is used. When a UDP checksum is not present (has value zero) in a stream, such validation would not be possible. To cover that case, this enhanced CRTP provides an option whereby the compressor MAY replace the null UDP checksum with a 16-bit headers checksum (HDRCKSUM) which is subsequently removed by the decompressor after validation. Note that this option is never used with IPv6 since a null UDP checksum is not allowed.
セクション3.3.5のRFC 2508は、UDPチェックサムを使用してヘッダー再構成を定期的に検証する方法、または「2回」アルゴリズムが使用される時期について説明します。UDPチェックサムがストリームに存在しない（値ゼロ）、そのような検証は不可能です。そのケースをカバーするために、この強化されたCRTPは、コンプレッサーがNULL UDPチェックサムを16ビットヘッダーチェックサム（HDRCKSUM）に置き換えることができるオプションを提供します。NULL UDPチェックサムは許可されていないため、このオプションはIPv6で使用されないことに注意してください。
A new flag C in the FULL_HEADER packet, as specified below, indicates when set that all COMPRESSED_UDP and COMPRESSED_RTP packets sent in that context will have HDRCKSUM inserted. The compressor MAY set the C flag when UDP packet carried in the FULL_HEADER packet originally contained a checksum value of zero. If the C flag is set, the FULL_HEADER packet itself MUST also have the HDRCKSUM inserted. If a packet in the same stream subsequently arrives at the compressor with a UDP checksum present, then a new FULL_HEADER packet MUST be sent with the flag cleared to re-establish the context.
以下に指定されているように、Full_headerパケットの新しいフラグCは、そのコンテキストで送信されたすべてのCompressed_udpとCompressed_rtpパケットがHDRCKSUMを挿入することを設定したことを示します。コンプレッサーは、UDPパケットがFull_headerパケットに携帯されていたときにCフラグを設定することができます。もともとはゼロのチェックサム値が含まれています。Cフラグが設定されている場合、Full_headerパケット自体にもHDRCKSUMを挿入する必要があります。同じストリーム内のパケットがその後、UDPチェックサムが存在するコンプレッサーに到着した場合、コンテキストを再確立するために、フラグをクリアした新しいFull_headerパケットを送信する必要があります。
The HDRCKSUM is calculated in the same way as a UDP checksum except that it does not cover all of the UDP data. That is, the HDRCKSUM is the 16-bit one's complement of the one's complement sum of the pseudo-IP header (as defined for UDP), the UDP header, the first 12 bytes of the UDP data which are assumed to hold the fixed part of an RTP header, and the CSRC list. The extended part of the RTP header beyond the CSRC list and the RTP data will not be included in the HDRCKSUM. The HDRCKSUM is placed in the COMPRESSED_UDP or COMPRESSED_RTP packet where a UDP checksum would have been. The decompressor MUST zero out the UDP checksum field in the reconstructed packets.
HDRCKSUMは、すべてのUDPデータをカバーしていないことを除いて、UDPチェックサムと同じ方法で計算されます。つまり、HDRCKSUMは、固定部分を保持すると想定されるUDPデータの最初の12バイトであるUDPヘッダーである擬似IPヘッダーの補完合計（UDP用）の16ビットの補完です。RTPヘッダーとCSRCリストの。RTPヘッダーの拡張部分はCSRCリストを超えて、RTPデータはHDRCKSUMに含まれません。HDRCKSUMは、UDPチェックサムがあったであろうCompressed_udpまたはCompressed_rtpパケットに配置されます。減圧器は、再構築されたパケットのUDPチェックサムフィールドをゼロにする必要があります。
For a non-RTP context, there may be fewer than 12 UDP data bytes present. The IP and UDP headers can still be compressed into a COMPRESSED_UDP packet. For this case, the HDRCKSUM is calculated over the pseudo-IP header, the UDP header, and the UDP data bytes that are present. If the number of data bytes is odd, then a zero padding byte is appended for the purpose of calculating the checksum, but not transmitted.
非RTPコンテキストの場合、12未満のUDPデータバイトが存在する場合があります。IPおよびUDPヘッダーは、Compressed_UDPパケットに圧縮できます。この場合、HDRCKSUMは、PSEUDO-IPヘッダー、UDPヘッダー、および存在するUDPデータバイトを介して計算されます。データバイトの数が奇妙な場合、チェックサムを計算する目的でゼロのパディングバイトが追加されますが、送信されません。
The HDRCKSUM does not validate the RTP data. If the link layer is configured to deliver packets without checking for errors, then errors in the RTP data will not be detected. Over such links, the compressor SHOULD add the HDRCKSUM if a UDP checksum is not present, and the decompressor SHOULD validate each reconstructed packet to make sure that at least the headers are correct. This ensures that the packet will be delivered to the right destination. If only HDRCKSUM is available, the RTP data will be delivered even if it includes errors. This might be a desirable feature for applications that can tolerate errors in the RTP data. The same holds for the extended part of the RTP header beyond the CSRC list.
HDRCKSUMはRTPデータを検証しません。リンクレイヤーがエラーをチェックせずにパケットを配信するように構成されている場合、RTPデータのエラーは検出されません。このようなリンクで、コンプレッサーはUDPチェックサムが存在しない場合はHDRCKSUMを追加する必要があり、減圧器は各再構成されたパケットを検証して、少なくともヘッダーが正しいことを確認する必要があります。これにより、パケットが適切な目的地に配信されることが保証されます。HDRCKSUMのみが利用可能な場合、エラーが含まれていてもRTPデータが配信されます。これは、RTPデータのエラーに耐えることができるアプリケーションにとって望ましい機能かもしれません。同じことが、CSRCリストを超えたRTPヘッダーの拡張部分についても保持されます。
Here is the format of the FULL_HEADER length fields with the new flag C to indicate that a header checksum will be added in COMPRESSED_UDP and COMPRESSED_RTP packets:
以下は、新しいフラグCを備えたFull_header Lengthフィールドの形式です。これは、Header ChecksumがCompressed_udpおよびCompressed_rtpパケットに追加されることを示しています。
For 8-bit context ID:
8ビットコンテキストIDの場合：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Generation| CID | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |C| seq | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added
For 16-bit context ID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Generation| 0 |C| seq | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Enhanced CRTP achieves robust operation by sending changes multiple times to keep the compressor and decompressor in sync. This method is characterized by a number "N" that represents the quality of the link between the hosts. What it means is that the probability of more than N adjacent packets getting lost on this link is small. For every change in a full value or a delta value, if the compressor includes the change in N+1 consecutive packets, then the decompressor can keep its context state in sync with the compressor using the "twice" algorithm so long as no more than N adjacent packets are lost.
強化されたCRTPは、コンプレッサーと分解器を同期させ続けるために変更を複数回送信することにより、堅牢な動作を実現します。この方法は、ホスト間のリンクの品質を表す数字「n」によって特徴付けられます。それが意味するのは、このリンクでn隣接するパケットを超える確率が小さいことです。完全な値またはデルタ値の変更ごとに、コンプレッサーにN 1連続パケットの変更が含まれている場合、減圧器はn以下の「2回」アルゴリズムを使用してコンプレッサーとコンプレッサーと同期することができます。隣接するパケットが失われます。
Since updates are repeated in N+1 packets, if at least one of these N+1 update packets is received by the decompressor, both the full and delta values in the context at the decompressor will get updated and its context will stay synchronized with the context at the compressor. We can conclude that as long as less than N+1 adjacent packets are lost, the context at the decompressor is guaranteed to be synchronized with the context at the compressor, and use of the "twice" algorithm to recover from packet loss will successfully update the context and restore the compressed packets.
n 1パケットで更新が繰り返されるため、これらのn 1アップデートパケットの少なくとも1つが減圧器によって受信された場合、decompressorのコンテキストの完全とデルタ値の両方が更新され、そのコンテキストはのコンテキストと同期し続けますコンプレッサー。n 1隣接するパケット未満が失われる限り、decompressorのコンテキストはコンプレッサーのコンテキストと同期することが保証されていると結論付けることができ、パケット損失から回復するための「2回」アルゴリズムの使用は正常に更新されるコンテキストと圧縮パケットを復元します。
The link sequence number cycles in 16 packets, so it's not always clear how many packets were lost. For example, if the previous link sequence number was 5 and the current number is 4, one possibility is that 15 packets were lost, but another possibility is that due to misordering packet 5 arrived before packet 4 and they are really adjacent. If there is an interpretation of the link sequence numbers that could be a gap of less than N+1, the "twice" algorithm may be applied that many times and verified with the UDP checksum (or the HDRCKSUM).
リンクシーケンス番号は16個のパケットでサイクルするため、失われたパケットの数は必ずしも明確ではありません。たとえば、前のリンクシーケンス番号が5で、現在の数値が4の場合、1つのパケットが失われた可能性が1つありますが、別の可能性は、パケット5の前にパケット5が到着し、実際に隣接することです。n 1未満のギャップになる可能性のあるリンクシーケンス番号の解釈がある場合、「2回」アルゴリズムを何度も適用し、UDPチェックサム（またはHDRCKSUM）で検証することができます。
When more than N packets are lost, all of the repetitions of an update might have been lost. The context state may then be different at the compressor and decompressor. The decompressor can still try to recover by making one or more guesses for how many packets were lost and then applying the "twice" algorithm that many times.
Nパケット以上が失われると、更新の繰り返しのすべてが失われた可能性があります。コンテキスト状態は、コンプレッサーと減圧器で異なる場合があります。減圧装置は、失われたパケットの数について1つ以上の推測を行い、その後何度も「2回」アルゴリズムを適用することにより、回復を試みることができます。
However, since the IPv4 ID field is not included in the checksum, this does not validate the IPv4 ID.
ただし、IPv4 IDフィールドはチェックサムに含まれていないため、IPv4 IDは検証されません。
The conclusion is that for IPv4 if more than N packets were lost, the decompressor SHOULD NOT try to recover using the "twice" algorithm and instead SHOULD invalidate the context and send a CONTEXT_STATE packet. In IPv6 the decompressor MAY always try to recover from packet loss by using the "twice" algorithm and verifying the result with the UDP checksum.
結論は、IPv4の場合、nパケットを超えた場合、減圧装置は「2回」アルゴリズムを使用して回復しようとしないでください。代わりにコンテキストを無効にしてContext_stateパケットを送信する必要があります。IPv6では、「2回」アルゴリズムを使用し、UDPチェックサムで結果を検証することにより、減圧剤は常にパケット損失から回復しようとします。
It is up to the implementation to derive an appropriate N for a link. The value is maintained independently for each context and is not required to be the same for all contexts. When compressing a new stream, the compressor sets a value of N for that context and sends N+1 FULL_HEADER packets. The compressor MUST also repeat each subsequent COMPRESSED_UDP update N+1 times. The value of N may be changed for an existing context by sending a new sequence of FULL_HEADER packets.
リンクに適したnを導出するのは実装次第です。値は、各コンテキストに対して独立して維持され、すべてのコンテキストで同じである必要はありません。新しいストリームを圧縮するとき、コンプレッサーはそのコンテキストに対してnの値を設定し、n 1 full_headerパケットを送信します。コンプレッサーは、後続の各Compressed_udp更新nを1回繰り返す必要があります。nの値は、full_headerパケットの新しいシーケンスを送信することにより、既存のコンテキストに対して変更される場合があります。
The decompressor learns the value of N by counting the number of times the FULL_HEADER packet is repeated and storing the resulting value in the corresponding context. If some of the FULL_HEADER packets are lost, the decompressor may still be able to determine the correct value of N by observing the change in the 4-bit sequence number carried in the FULL_HEADER packets. Any inaccuracy in the counting will lead the decompressor to assume a smaller value of N than the compressor is sending. This is safe in that the only negative consequence is that the decompressor might send a CONTEXT_STATE packet when it was not really necessary to do so. In response, the compressor will send FULL_HEADER packets again, providing another opportunity for the decompressor to count the correct N.
減圧器は、Full_headerパケットが繰り返され、対応するコンテキストに結果の値を保存する回数をカウントすることにより、nの値を学習します。Full_headerパケットの一部が紛失した場合、減圧装置は、Full_headerパケットで運ばれる4ビットシーケンス数の変更を観察することにより、Nの正しい値を決定できる場合があります。カウントの不正確さは、圧縮機がコンプレッサーが送信しているよりもNの値が少ないと仮定するようになります。これは、唯一の否定的な結果は、それが実際に必要でなかったときにdedypompressorがContext_Stateパケットを送信する可能性があるということです。これに応じて、コンプレッサーはfull_headerパケットを再び送信し、decompressorが正しいNをカウントする別の機会を提供します。
The sending of FULL_HEADER packets is also triggered by a change in one of the fields held constant in the context, such as the IP TOS. If such a change should occur while the compressor is in the middle of sending the N+1 FULL_HEADER packets, then the compressor MUST send N+1 FULL_HEADER packets after making the change. This could cause the decompressor to receive more than N+1 FULL_HEADER packets in a row with the result that it assumes a larger value for N than is correct. That could lead to an undetected loss of context synchronization. Therefore, the compressor MUST change the "generation" number in the context and in the FULL_HEADER packet when it begins sending the sequence of N+1 FULL_HEADER packets so the decompressor can detect the new sequence. For IPv4, this is a change in behavior relative to RFC 2508.
Full_headerパケットの送信は、IP TOSなどのコンテキストで一定に保持されているフィールドの1つの変更によってトリガーされます。コンプレッサーがN 1 Full_headerパケットの送信中にそのような変更が発生する場合、コンプレッサーは変更を行った後にN 1 Full_headerパケットを送信する必要があります。これにより、減圧装置はn 1以上のfull_headerパケットを連続して受け取る可能性があり、結果としてnの値が正しいよりも大きな値を想定する可能性があります。それは、文脈の同期の検出されない喪失につながる可能性があります。したがって、コンプレッサーは、n 1 full_headerパケットのシーケンスの送信を開始すると、コンテキストとfull_headerパケットの「生成」数を変更する必要があります。IPv4の場合、これはRFC 2508に比べて動作の変化です。
CONTEXT_STATE packets SHOULD also be repeated N+1 times (using the same sequence number for each context) to provide a similar measure of robustness against packet loss. Here N can be the largest N of all contexts included in the CONTEXT_STATE packet, or any number the decompressor finds necessary in order to ensure robustness.
Context_Stateパケットは、パケット損失に対する堅牢性の同様の尺度を提供するために、n 1回（各コンテキストに同じシーケンス番号を使用）繰り返す必要があります。ここで、nは、Context_Stateパケットに含まれるすべてのコンテキストの中で最大のnになります。または、堅牢性を確保するために必要だと思われる任意の数字です。
Here are some examples to demonstrate the robust operation of enhanced CRTP using N+1 repetitions of updates. In this stream the audio codec sends a sample every 10 milliseconds. The first talkspurt is 1 second long. Then there are 2 seconds of silence, then another talkspurt. We also assume in this first example that the IPv4 ID field does not increment at a constant rate because the host is generating other uncorrelated traffic streams at the same time and therefore the delta IPv4 ID changes for each packet.
n 1の更新の繰り返しを使用して、強化されたCRTPの堅牢な操作を実証するためのいくつかの例を以下に示します。このストリームでは、オーディオコーデックは10ミリ秒ごとにサンプルを送信します。最初のTalkspurtは1秒の長さです。その後、2秒の沈黙があり、別のTalkspurtがあります。また、この最初の例では、ホストが他の無相関のトラフィックストリームを同時に生成しているため、各パケットのDELTA IPv4 IDが変更されているため、IPv4 IDフィールドは一定の速度で増加しないと想定しています。
In these examples, we will use some short notations:
これらの例では、いくつかの短い表記を使用します。
FH FULL_HEADER CR COMPRESSED_RTP CU COMPRESSED_UDP
FH FULL_HEADER CR Compressed_rtp Cu Compressed_udp
When operating on a link with low loss, we can just use COMPRESSED_RTP packets in the basic CRTP method specified in RFC 2508. We might have the following packet sequence:
低損失のリンクで操作する場合、RFC 2508で指定された基本的なCRTPメソッドでCompressed_RTPパケットを使用できます。次のパケットシーケンスがある場合があります。
seq Time pkt updates and comments # type 1 10 FH 2 20 CR dI dT=10 3 30 CR dI 4 40 CR dI ... 100 1000 CR dI
seq time pktの更新とコメント＃タイプ1
101 3010 CR dI dT=2010 102 3020 CR dI dT=10 103 3030 CR dI 104 3040 CR dI ...
101 3010 cr di dt = 2010 102 3020 cr di dt = 10 103 3030 cr di 104 3040 cr di ...
In the above sequence, if a packet is lost we cannot recover ("twice" will not work due to the unpredictable IPv4 ID) and the context must be invalidated.
上記のシーケンスでは、パケットが失われた場合、回復できません（予測不可能なIPv4 IDのために「2回」は機能しません）、コンテキストを無効にする必要があります。
Here is the same example using the enhanced CRTP method specified in this document, when N=2. Note that the compressor only sends the absolute IPv4 ID (I) and not the delta IPv4 ID (dI).
n = 2の場合、このドキュメントで指定された拡張されたCRTPメソッドを使用して、同じ例です。コンプレッサーは、絶対的なIPv4 ID（I）のみを送信し、Delta IPv4 ID（DI）を送信することに注意してください。
seq Time pkt CU flags updates and comments
# type F I dT dI M S T P
1 10 FH
2 20 FH repeat constant fields
3 30 FH repeat constant fields
4 40 CU 1 1 1 0 M 0 1 0 I T=40 dT=10
5 50 CU 1 1 1 0 M 0 1 0 I T=50 dT=10 repeat update T & dT
6 60 CU 1 1 1 0 M 0 1 0 I T=60 dT=10 repeat update T & dT
7 70 CU 1 1 0 0 M 0 0 0 I
8 80 CU 1 1 0 0 M 0 0 0 I
...
100 1000 CU 1 1 0 0 M 0 0 0 I
101 3010 CU 1 1 0 0 M 0 1 0 I T=3010 T changed, keep deltas 102 3020 CU 1 1 0 0 M 0 1 0 I T=3020 repeat updated T 103 3030 CU 1 1 0 0 M 0 1 0 I T=3030 repeat updated T 104 3040 CU 1 1 0 0 M 0 0 0 I 105 3050 CU 1 1 0 0 M 0 0 0 I ...
101 3010 cu 1 1 0 0 M 0 1 0繰り返し更新されたt 104 3040 cu 1 1 0 0 m 0 0 0 i 105 3050 cu 1 1 0 0 m 0 0 0 i ...
This second example is the same sequence, but assuming the delta IP ID is constant. First the basic CRTP for a lossless link:
この2番目の例は同じシーケンスですが、Delta IP IDが一定であると仮定します。最初に、ロスレスリンクの基本CRTP：
seq Time pkt updates and comments # type 1 10 FH 2 20 CR dI dT=10 3 30 CR 4 40 CR ... 100 1000 CR
seq time pktの更新とコメント＃タイプ1
101 3010 CR dT=2010 102 3020 CR dT=10 103 3030 CR 104 3040 CR ...
101 3010 cr dt = 2010 102 3020 cr dt = 10 103 3030 cr 104 3040 cr ...
For the equivalent sequence in enhanced CRTP, the more efficient COMPRESSED_RTP packet can still be used once the deltas are all established:
拡張CRTPの同等のシーケンスの場合、デルタがすべて確立されると、より効率的なCompressed_RTPパケットを使用できます。
seq Time pkt CU flags updates and comments
# type F I dT dI M S T P
1 10 FH
2 20 FH repeat constant fields
3 30 FH repeat constant fields
4 40 CU 1 1 1 1 M 0 1 0 I dI T=40 dT=10
5 50 CU 1 1 1 1 M 0 1 0 I dI T=50 dT=10 repeat updates
6 60 CU 1 1 1 1 M 0 1 0 I dI T=60 dT=10 repeat updates
7 70 CR
8 80 CR
...
100 1000 CR
101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas 102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T 103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T 104 3040 CR 105 3050 CR ...
101 3010 CU 1 0 0 0 M 0 1 0 T = 3010 T変更、キープデルタ102 3020更新されたt 104 3040 cr 105 3050 crを繰り返します...
Here is the second example when using IPv6. First the basic CRTP for a lossless link:
IPv6を使用するときの2番目の例は次のとおりです。最初に、ロスレスリンクの基本CRTP：
seq Time pkt updates and comments # type 1 10 FH 2 20 CR dT=10 3 30 CR 4 40 CR ... 100 1000 CR
seq time pktの更新とコメント＃タイプ1 10 fh 2 20 cr dt = 10 3 30 cr 4 40 cr ... 100 1000 cr
101 3010 CR dT=2010 102 3020 CR dT=10 103 3030 CR 104 3040 CR ...
101 3010 cr dt = 2010 102 3020 cr dt = 10 103 3030 cr 104 3040 cr ...
For the equivalent sequence in enhanced CRTP, the more efficient COMPRESSED_RTP packet can still be used once the deltas are all established:
拡張CRTPの同等のシーケンスの場合、デルタがすべて確立されると、より効率的なCompressed_RTPパケットを使用できます。
seq Time pkt CU flags updates and comments
# type F I dT dI M S T P
1 10 FH
2 20 FH repeat constant fields
3 30 FH repeat constant fields
4 40 CU 1 0 1 0 M 0 1 0 T=40 dT=10
5 50 CU 1 0 1 0 M 0 1 0 T=50 dT=10 repeat updates
6 60 CU 1 0 1 0 M 0 1 0 T=60 dT=10 repeat updates
7 70 CR
8 80 CR
...
100 1000 CR
101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas 102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T 103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T 104 3040 CR 105 3050 CR ...
101 3010 CU 1 0 0 0 M 0 1 0 T = 3010 T変更、キープデルタ102 3020更新されたt 104 3040 cr 105 3050 crを繰り返します...
The use of IP/UDP/RTP compression (CRTP) over a particular link is a function of the link-layer protocol. It is expected that negotiation of the use of CRTP will be defined separately for each link layer.
特定のリンクでのIP/UDP/RTP圧縮（CRTP）の使用は、リンク層プロトコルの関数です。CRTPの使用の交渉は、各リンクレイヤーに対して個別に定義されることが予想されます。
For link layers that already have defined a negotiation for the use of CRTP as specified in RFC 2508, an extension to that negotiation will be required to indicate use of the enhanced CRTP defined in this document since the syntax of the existing packet formats has been extended.
RFC 2508で指定されているCRTPの使用に関するネゴシエーションを既に定義しているリンクレイヤーの場合、既存のパケット形式の構文が拡張されているため、このドキュメントで定義された強化されたCRTPの使用を示すために、そのネゴシエーションの拡張が必要になります。。
Because encryption eliminates the redundancy that this compression scheme tries to exploit, there is some inducement to forego encryption in order to achieve operation over a low-bandwidth link. However, for those cases where encryption of data and not headers is satisfactory, RTP does specify an alternative encryption method in which only the RTP payload is encrypted and the headers are left in the clear [SRTP]. That would allow compression to still be applied.
暗号化は、この圧縮スキームが悪用しようとする冗長性を排除するため、低帯域幅リンク上で動作を達成するために、暗号化を忘れていく誘惑があります。ただし、ヘッダーではなくデータの暗号化が満足できる場合、RTPはRTPペイロードのみが暗号化され、ヘッダーがクリア[SRTP]に残される代替暗号化方法を指定します。これにより、圧縮がまだ適用されます。
A malfunctioning or malicious compressor could cause the decompressor to reconstitute packets that do not match the original packets but still have valid IP, UDP and RTP headers and possibly even valid UDP check-sums. Such corruption may be detected with end-to-end authentication and integrity mechanisms which will not be affected by the compression. Constant portions of authentication headers will be compressed as described in [IPHCOMP].
誤動作または悪意のあるコンプレッサーにより、減圧装置は元のパケットと一致しないが、有効なIP、UDP、RTPヘッダー、場合によっては有効なUDPチェックサムを持っているパケットを再構成する可能性があります。このような腐敗は、圧縮の影響を受けないエンドツーエンドの認証と整合性メカニズムで検出される場合があります。[IPHComp]で説明されているように、認証ヘッダーの定数が圧縮されます。
No authentication is performed on the CONTEXT_STATE control packet sent by this protocol. An attacker with access to the link between the decompressor and compressor could inject false CONTEXT_STATE packets and cause compression efficiency to be reduced, probably resulting in congestion on the link. However, an attacker with access to the link could also disrupt the traffic in many other ways.
このプロトコルによって送信されたContext_Stateコントロールパケットでは、認証は実行されません。減圧器とコンプレッサーの間のリンクにアクセスできる攻撃者は、誤ったコンテキスト_Stateパケットを注入し、圧縮効率を低下させる可能性があり、おそらくリンクに輻輳が発生します。ただし、リンクにアクセスできる攻撃者は、他の多くの方法でトラフィックを破壊する可能性もあります。
A potential denial-of-service threat exists when using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decompress and cause the receiver to be overloaded and degrading processing of other streams. However, this compression does not exhibit any significant non-uniformity.
不均一なレシーバー末端計算負荷を備えた圧縮技術を使用する場合、潜在的なサービス拒否脅威が存在します。攻撃者は、病理学的データグラムをストリームに挿入し、それを複雑にして減圧し、受信機を過負荷にし、他のストリームの処理を分解します。ただし、この圧縮は有意な不均一性を示しません。
The authors would like to thank Van Jacobson, co-author of RFC 2508, and the authors of RFC 2507, Mikael Degermark, Bjorn Nordgren, and Stephen Pink. The authors would also like to thank Dana Blair, Francois Le Faucheur, Tim Gleeson, Matt Madison, Hussein Salama, Mallik Tatipamula, Mike Thomas, Alex Tweedly, Herb Wildfeuer, Andrew Johnson, and Dan Wing.
著者は、RFC 2508の共著者であるVan Jacobson、およびRFC 2507、Mikael Degermark、Bjorn Nordgren、Stephen Pinkの著者に感謝します。著者はまた、ダナ・ブレア、フランソワ・ル・フォーチュール、ティム・グリーソン、マット・マディソン、フセイン・サラマ、マリク・タティパムラ、マイク・トーマス、アレックス・トゥーダリー、ハーブ・ワイルドフェイアー、アンドリュー・ジョンソン、ダン・ウィングにも感謝したいと思います。
[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月。
[IPHCOMP] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[iphcomp] Degermark、M.、Nordgren、B。およびS. Pink、「IPヘッダー圧縮」、RFC 2507、1999年2月。
[IPCPHC] Koren, T., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 3544, July 2003.
[IPCPHC] Koren、T.、Casner、S。、およびC. Bormann、「PPP上のIPヘッダー圧縮」、RFC 3544、2003年7月。
[KEYW] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[keyw] Bradner、S。「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RTP] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[RTP] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 3550、2003年7月。
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[Rohc] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L.、Hakenberg、R.、Koren、T.、Le、K.、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T。、およびH. Zheng、 "堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[SRTP] Baugher, M., McGrew, D., Carrara, E., Naslund, M. and K. Norrman, "The Secure Real-time Transport Protocol", Work in Progress.
[SRTP] Baugher、M.、McGrew、D.、Carrara、E.、Naslund、M。and K. Norrman、「安全なリアルタイム輸送プロトコル」、進行中の作業。
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エグゼクティブディレクターに宛ててください。
Tmima Koren Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Tmima Koren Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134-1706 USA
EMail: tmima@cisco.com
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 USA
Stephen L. Casner Packet Design 3400 Hillview Avenue、Building 3 Palo Alto、CA 94304 USA
EMail: casner@acm.org
John Geevarghese Motorola India Electronics Ltd. No. 33 A Ulsoor Road Bangalore, India
John Geevarghese Motorola India Electronics Ltd. 33 A Ulsoor Road Bangalore、India
EMail: geevjohn@hotmail.com
Bruce Thompson Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
ブルーストンプソンシスコシステムズ、170ウェストタスマンドライブサンノゼ、カリフォルニア95134-1706 USA
EMail: brucet@cisco.com
Patrick Ruddy Cisco Systems, Inc. 3rd Floor 96 Commercial Street Leith, Edinburgh EH6 6LX Scotland
Patrick Ruddy Cisco Systems、Inc。3rd Floor 96 Commercial Street Leith、Edinburgh EH6 6LX Scotland
EMail: pruddy@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。