Network Working Group S. Casner
Request for Comments: 2508 Cisco Systems
Category: Standards Track V. Jacobson
Cisco Systems
February 1999
Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In many cases, all three headers can be compressed to 2-4 bytes.
この文書では、低速シリアルリンク上のオーバーヘッドを減らすために、IP / UDP / RTPデータグラムのヘッダを圧縮するための方法を説明します。多くの場合、すべての3つのヘッダは2-4バイトに圧縮することができます。
Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s).
コメントが募集され、ワーキンググループメーリングリストrem-conf@es.netおよび/または著者（複数可）に対処する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
Since the Real-time Transport Protocol was published as an RFC [1], there has been growing interest in using RTP as one step to achieve interoperability among different implementations of network audio/video applications. However, there is also concern that the 12-byte RTP header is too large an overhead for 20-byte payloads when operating over low speed lines such as dial-up modems at 14.4 or 28.8 kb/s. (Some existing applications operating in this environment use an application-specific protocol with a header of a few bytes that has reduced functionality relative to RTP.)
リアルタイムトランスポートプロトコルはRFCとして公開されて以来[1]、ネットワークオーディオ/ビデオアプリケーションの異なる実装間の相互運用性を達成するための一歩として、RTPを使用することに関心が高まっています。しかしながら、12バイトのRTPヘッダーが14.4又は28.8キロバイト/ sで、ダイヤルアップモデムなどの低速回線で動作する20バイトのペイロードのためのオーバーヘッドが大きすぎるという懸念もあります。 （この環境で動作するいくつかの既存のアプリケーションは、RTPに機能を相対的に低減された数バイトのヘッダと、アプリケーション固有のプロトコルを使用します。）
Header size may be reduced through compression techniques as has been done with great success for TCP [2]. In this case, compression might be applied to the RTP header alone, on an end-to-end basis, or to the combination of IP, UDP and RTP headers on a link-by-link basis. Compressing the 40 bytes of combined headers together provides substantially more gain than compressing 12 bytes of RTP header alone because the resulting size is approximately the same (2-4 bytes) in either case. Compressing on a link-by-link basis also provides better performance because the delay and loss rate are lower. Therefore, the method defined here is for combined compression of IP, UDP and RTP headers on a link-by-link basis.
TCPのために大きな成功を収めて行われてきたように、ヘッダサイズは、[2]の圧縮技術によって減少させることができます。この場合、圧縮は、単独で、RTPヘッダに、エンドツーエンドベースで、またはリンクごとにIP、UDP及びRTPヘッダの組み合わせに適用されるかもしれません。一緒に合わせたヘッダの40のバイトを圧縮すると、得られたサイズが約いずれの場合も（2~4バイト）と同じであるため、単独でRTPヘッダの12のバイトを圧縮するよりも実質的に多くの利得を提供します。遅延と損失率が低いので、リンクごとに圧縮するとも優れたパフォーマンスを提供します。したがって、ここで定義された方法は、リンクごとにIP、UDP及びRTPヘッダの組み合わせ圧縮するためのものです。
This document defines a compression scheme that may be used with IPv4, IPv6 or packets encapsulated with more than one IP header, though the initial focus is on IPv4. The IP/UDP/RTP compression defined here is intended to fit within the more general compression framework specified in [3] for use with both IPv6 and IPv4. That framework defines TCP and non-TCP as two classes of transport above IP. This specification creates IP/UDP/RTP as a third class extracted from the non-TCP class.
この文書では、初期フォーカスがIPv4であるが、のIPv4、IPv6のまたは複数のIPヘッダでカプセル化されたパケットで使用されてもよい圧縮方式を定義します。ここで定義されたIP / UDP / RTP圧縮は、IPv6とIPv4の両方で使用するために、[3]で指定されたより一般的な圧縮フレームワーク内に適合するように意図されています。そのフレームワークは、IP上での輸送の二つのクラスとしてTCPおよび非TCPを定義します。この仕様は、非TCPクラスから抽出された第三のクラスとしてIP / UDP / RTPを作成します。
The goal of this compression scheme is to reduce the IP/UDP/RTP headers to two bytes for most packets in the case where no UDP checksums are being sent, or four bytes with checksums. It is motivated primarily by the specific problem of sending audio and video over 14.4 and 28.8 dialup modems. These links tend to provide full-duplex communication, so the protocol takes advantage of that fact, though the protocol may also be used with reduced performance on simplex links. This compression scheme performs best on local links with low round-trip-time.
この圧縮方式の目標は、ほとんど何のUDPチェックサムが送信されないされている場合は、パケット、またはチェックサムと4バイトのための2つのバイトにIP / UDP / RTPヘッダを削減することです。これは、14.4と28.8ダイヤルアップモデムを介してオーディオおよびビデオを送信する特定の問題により、主に動機付けられています。これらのリンクは、全二重通信を提供する傾向があるので、プロトコルはまた、シンプレックスリンク上のパフォーマンスの低下で使用してもよいプロトコルは、その事実を利用しています。この圧縮方式は、低往復時間とローカルリンク上で最高の性能を発揮します。
This specification does not address segmentation and preemption of large packets to reduce the delay across the slow link experienced by small real-time packets, except to identify in Section 4 some interactions between segmentation and compression that may occur. Segmentation schemes may be defined separately and used in conjunction with the compression defined here.
この仕様は、セクション4で発生し得るセグメンテーションと圧縮の間に何らかの相互作用を同定するために除いて、小さなリアルタイムパケットによって経験された低速リンクを介して遅延を低減するために大規模なパケットの分割とプリエンプションを扱っていません。セグメンテーションスキームは別々に定義され、ここで定義された圧縮と組み合わせて使用することができます。
It should be noted that implementation simplicity is an important factor to consider in evaluating a compression scheme. Communications servers may need to support compression over perhaps as many as 100 dial-up modem lines using a single processor. Therefore, it may be appropriate to make some simplifications in the design at the expense of generality, or to produce a flexible design that is general but can be subsetted for simplicity. Higher compression gain might be achieved by communicating more complex models for the changing header fields from the compressor to the decompressor, but that complexity is deemed unnecessary. The next sections discuss some of the tradeoffs listed here.
実装のシンプルさは圧縮方式を評価する際に考慮すべき重要な要因であることに留意すべきです。通信サーバは、単一のプロセッサを使用して、おそらくのような多くの100などのダイヤルアップモデム回線を介して圧縮をサポートする必要があるかもしれません。したがって、一般性を犠牲にして設計の一部の単純化を行うために、または一般的であるが、簡略化のためにサブセットすることができる柔軟な設計を生成するために適切であり得ます。高い圧縮利得は、解凍装置へ圧縮機からの変更ヘッダフィールドのためのより複雑なモデルを通信することによって達成されるかもしれないが、その複雑さは不要であると考えられます。次のセクションでは、ここに記載されているトレードオフのいくつかを議論します。
In the absence of other constraints, a compression scheme that worked over simplex links would be preferred over one that did not. However, operation over a simplex link requires periodic refreshes with an uncompressed packet header to restore compression state in case of error. If an explicit error signal can be returned instead, the delay to recovery may be shortened substantially. The overhead in the no-error case is also reduced. To gain these performance improvements, this specification includes an explicit error indication sent on the reverse path.
他の制約がない場合には、シンプレックスリンク上で働いていた圧縮方式はしませんでした1よりも優先されるだろう。しかしながら、シンプレックスリンクを介して動作がエラーの場合に圧縮状態を復元するために、非圧縮パケットのヘッダを持つ周期的リフレッシュを必要とします。明示的なエラー信号が代わりに返すことができる場合には、回復への遅延が大幅に短縮されてもよいです。ノーエラー場合のオーバーヘッドも低減されます。これらの性能向上を得るために、この仕様は逆の経路で送信され、明示的なエラーの表示を含みます。
On a simplex link, it would be possible to use a periodic refresh instead. Whenever the decompressor detected an error in a particular packet stream, it would simply discard all packets in that stream until an uncompressed header was received for that stream, and then resume decompression. The penalty would be the potentially large number of packets discarded. The periodic refresh method described in Section 3.3 of [3] applies to IP/UDP/RTP compression on simplex links or links with high delay as well as to other non-TCP packet streams.
シンプレックスリンクでは、その代わりに、定期的にリフレッシュを使用することも可能です。減圧装置が特定のパケットストリームにエラーを検出するたびに、それは単に非圧縮ヘッダがそのストリームのために受信されるまで、そのストリーム内のすべてのパケットを廃棄し、その後減圧を再開することになります。ペナルティは、廃棄されたパケットの潜在的に多数であろう。セクション3.3で説明定期的なリフレッシュ方法[3]高遅延で、ならびに他の非TCPパケットストリームに単純リンクまたはリンクのIP / UDP / RTP圧縮に適用されます。
Delay induced by the time required to send a large packet over the slow link is not a problem for one-way audio, for example, because the receiver can adapt to the variance in delay. However, for interactive conversations, minimizing the end-to-end delay is critical. Segmentation of large, non-real-time packets to allow small real-time packets to be transmitted between segments can reduce the delay.
受信機は、遅延のばらつきに適応することができますので、低速リンクで大きなパケットを送信するために必要な時間によって誘発される遅延は、例えば、一方向のオーディオのための問題ではありません。しかし、インタラクティブな会話のために、エンドツーエンド遅延を最小限に抑えることが重要です。小さなリアルタイムパケットがセグメントの間で送信されることを可能にする大規模な、非リアルタイムパケットのセグメント化は、遅延を低減することができます。
This specification deals only with compression and assumes segmentation, if included, will be handled as a separate layer. It would be inappropriate to integrate segmentation and compression in such a way that the compression could not be used by itself in situations where segmentation was deemed unnecessary or impractical. Similarly, one would like to avoid any requirements for a reservation protocol. The compression scheme can be applied locally on the two ends of a link independent of any other mechanisms except for the requirements that the link layer provide some packet type codes, a packet length indication, and good error detection.
圧縮のみとし、含まれている場合、セグメント化を想定している本明細書の取引は、別個の層として扱われます。圧縮は分割が不要または非現実的と考えられた状況で単独で使用することができなかったような方法で分割と圧縮を統合することが不適切です。同様に、1は予約プロトコルのためのいずれかの要件を避けるためにしたいと思います。圧縮方式は、リンク層は、いくつかのパケットタイプコード、パケット長指示、及び良好なエラー検出を提供する要件以外の任意の他の機構のリンク独立の両端に局所的に適用することができます。
Conversely, separately compressing the IP/UDP and RTP layers loses too much of the compression gain that is possible by treating them together. Crossing these protocol layer boundaries is appropriate because the same function is being applied across all layers.
逆に、別途IP / UDPとRTP層を圧縮することは、それらを一緒に処理することにより可能である圧縮ゲインのあまりを失います。同様の機能は、全ての層にわたって適用されているので、これらのプロトコル層の境界を横断することは適切です。
The compression algorithm defined in this document draws heavily upon the design of TCP/IP header compression as described in RFC 1144 [2]. Readers are referred to that RFC for more information on the underlying motivations and general principles of header compression.
この文書で定義された圧縮アルゴリズムは、RFC 1144に記載されているようにTCP / IPヘッダー圧縮の設計に大きく描画[2]。読者は、根底にある動機とヘッダ圧縮の一般的な原理の詳細については、そのRFCと呼ばれます。
In TCP header compression, the first factor-of-two reduction in data rate comes from the observation that half of the bytes in the IP and TCP headers remain constant over the life of the connection. After sending the uncompressed header once, these fields may be elided from the compressed headers that follow. The remaining compression comes from differential coding on the changing fields to reduce their size, and from eliminating the changing fields entirely for common cases by calculating the changes from the length of the packet. This length is indicated by the link-level protocol.
TCPヘッダ圧縮は、データレートの最初の因子の二減少がIPおよびTCPヘッダ内のバイトの半分は、接続の寿命にわたって一定のまま観察から来ています。一度圧縮されていないヘッダを送信した後、これらのフィールドは、以下の圧縮されたヘッダから省略されてもよいです。残りの圧縮、および完全に一般的なケースのために変化するフィールドを排除からパケットの長さからの変化を計算することにより、それらのサイズを減少させるために変化するフィールドに差動符号化から来ます。この長さは、リンクレベルプロトコルで示されています。
For RTP header compression, some of the same techniques may be applied. However, the big gain comes from the observation that although several fields change in every packet, the difference from packet to packet is often constant and therefore the second-order difference is zero. By maintaining both the uncompressed header and the first-order differences in the session state shared between the compressor and decompressor, all that must be communicated is an indication that the second-order difference was zero. In that case, the decompressor can reconstruct the original header without any loss of information simply by adding the first-order differences to the saved uncompressed header as each compressed packet is received.
RTPヘッダ圧縮のために、同じ技術の一部を適用することができます。しかし、大きなゲインは、いくつかのフィールドは、パケットごとに変化するものの、パケットにパケットとの違いは、多くの場合、一定であり、したがって、二次差がゼロであるという観察から来ています。非圧縮ヘッダコンプレッサとデコンプレッサとの間で共有セッション状態の一次差の両方を維持することによって、通信されなければならないすべては、2次差分がゼロであったことを示しています。その場合、デコンプレッサは、単に各圧縮パケットを受信するように保存された非圧縮ヘッダに一次差分を追加することにより、情報を失うことなく、元のヘッダを再構成することができます。
Just as TCP/IP header compression maintains shared state for multiple simultaneous TCP connections, this IP/UDP/RTP compression SHOULD maintain state for multiple session contexts. A session context is defined by the combination of the IP source and destination addresses, the UDP source and destination ports, and the RTP SSRC field. A compressor implementation might use a hash function on these fields to index a table of stored session contexts. The compressed packet carries a small integer, called the session context identifier or CID, to indicate in which session context that packet should be interpreted. The decompressor can use the CID to index its table of stored session contexts directly.
TCP / IPヘッダー圧縮は、複数の同時TCP接続の共有状態を維持して同じように、このIP / UDP / RTP圧縮は、複数のセッションのコンテキストの状態を維持する必要があります。セッション・コンテキストは、IP送信元アドレスと宛先アドレス、UDP送信元ポートと宛先ポート、およびRTP SSRCフィールドの組み合わせによって定義されます。コンプレッサーの実装では、保存されたセッションのコンテキストのインデックステーブルにこれらのフィールドのハッシュ関数を使用する場合があります。圧縮されたパケットは、小さな整数を運ぶ、パケットが解釈されるべきであることでセッション・コンテキストを示すために、セッションコンテキスト識別子またはCIDと呼ばれます。デコンプレッサは、直接インデックスに保存されたセッションコンテキストのそのテーブルをCIDを使用することができます。
Because the RTP compression is lossless, it may be applied to any UDP traffic that benefits from it. Most likely, the only packets that will benefit are RTP packets, but it is acceptable to use heuristics to determine whether or not the packet is an RTP packet because no harm is done if the heuristic gives the wrong answer. This does require executing the compression algorithm for all UDP packets, or at least those with even port numbers (see section 3.4).
RTP圧縮はロスレスであるので、それはそれから利益を得る任意のUDPトラフィックに適用することができます。ほとんどの場合、恩恵を受けるだけパケットがRTPパケットであるが、ヒューリスティックが間違った答えを与える場合も害が行われないため、パケットは、RTPパケットであるか否かを判断するヒューリスティックを使用することが可能です。これは、すべてのUDPパケットのための圧縮アルゴリズムを実行する必要、あるいはポート番号（セクション3.4を参照）と少なくともそれらありません。
Most compressor implementations will need to maintain a "negative cache" of packet streams that have failed to compress as RTP packets for some number of attempts in order to avoid further attempts. Failing to compress means that some fields in the potential RTP header that are expected to remain constant most of the time, such as the payload type field, keep changing. Even if the other such fields remain constant, a packet stream with a constantly changing SSRC field SHOULD be entered in the negative cache to avoid consuming all of the available session contexts. The negative cache is indexed by the source and destination IP address and UDP port pairs but not the RTP SSRC field since the latter may be changing. When RTP compression fails, the IP and UDP headers MAY still be compressed.
ほとんどのコンプレッサーの実装はさらに試みを避けるために、試みのいくつかの数のRTPパケットとして圧縮することができなかったパケットストリームの「ネガティブキャッシュ」を維持する必要があります。圧縮するのに失敗すると、ほとんどの時間を一定に維持することが期待される潜在的なRTPヘッダ内のいくつかのフィールドは、そのようなペイロードタイプフィールドとして、変化し続けることを意味します。他のこのようなフィールドが一定た場合でも、常に変化しSSRCフィールドを持つパケットストリームは、利用可能なセッションのコンテキストのすべてを消費を避けるために、負のキャッシュに入力する必要があります。後者は変更することができるので、ネガティブキャッシュは、送信元と宛先IPアドレスとUDPポートのペアではなく、RTP SSRCフィールドによってインデックス付けされます。 RTP圧縮が失敗した場合、IPおよびUDPヘッダはまだ圧縮することができます。
Fragmented IP Packets that are not initial fragments and packets that are not long enough to contain a complete UDP header MUST NOT be sent as FULL_HEADER packets. Furthermore, packets that do not additionally contain at least 12 bytes of UDP data MUST NOT be used to establish RTP context. If such a packet is sent as a FULL_HEADER packet, it MAY be followed by COMPRESSED_UDP packets but MUST NOT be followed by COMPRESSED_RTP packets.
完全なUDPヘッダを含むのに十分な長さではありません最初のフラグメントパケットでない断片化されたIPパケットは、FULL_HEADERパケットとして送ってはいけません。さらに、さらにUDPデータの少なくとも12のバイトが含まれていないパケットはRTPのコンテキストを確立するために使用してはいけません。このようなパケットがFULL_HEADERパケットとして送信された場合、それはCOMPRESSED_UDPパケットが続くかもしれないが、COMPRESSED_RTPパケットに続いてはなりません。
In the IPv4 header, only the total length, packet ID, and header check-sum fields will normally change. The total length is redundant with the length provided by the link layer, and since this compression scheme must depend upon the link layer to provide good error detection (e.g., PPP's CRC [4]), the header checksum may also be elided. This leaves only the packet ID, which, assuming no IP fragmentation, would not need to be communicated. However, in order to maintain lossless compression, changes in the packet ID will be transmitted. The packet ID usually increments by one or a small number for each packet. (Some systems increment the ID with the bytes swapped, which results in slightly less compression.) In the IPv6 base header, there is no packet ID nor header checksum and only the payload length field changes.
IPv4ヘッダーでは、唯一の合計長、パケットID、及びヘッダチェックサムフィールドは、正常に変更されます。全長は、リンク層により提供される長さと冗長であり、この圧縮方式は、良好なエラー検出を提供するために、リンクレイヤに依存しなければならないので（例えば、PPPのCRC [4]）、ヘッダチェックサムも省略されてもよいです。これは、何のIPフラグメンテーションがないと仮定すると、通信する必要はありませんだけパケットIDを、残します。しかし、可逆圧縮を維持するために、パケットIDに変更が送信されます。パケットIDは、通常、1つまたは各パケットのために小さな数でインクリメントします。 （一部のシステムでは、わずかに小さい圧縮をもたらすスワップバイトとIDをインクリメント）のIPv6基本ヘッダでは、何らのパケットIDやヘッダチェックサムのみペイロード長さフィールドの変更はありません。
In the UDP header, the length field is redundant with the IP total length field and the length indicated by the link layer. The UDP check-sum field will be a constant zero if the source elects not to generate UDP checksums. Otherwise, the checksum must be communicated intact in order to preserve the lossless compression. Maintaining end-to-end error detection for applications that require it is an important principle.
UDPヘッダにおいて、長さフィールドは、IP全長フィールドとリンク層によって示される長さと冗長です。ソースは、UDPチェックサムを生成しないことを選択した場合、UDPチェックサムフィールドは定数ゼロになります。それ以外の場合は、チェックサムは、可逆圧縮を維持するためにそのまま伝達されなければなりません。それが重要な原則である必要とするアプリケーションのためのエンドツーエンドのエラー検出を維持します。
In the RTP header, the SSRC identifier is constant in a given context since that is part of what identifies the particular context. For most packets, only the sequence number and the timestamp will change from packet to packet. If packets are not lost or misordered upstream from the compressor, the sequence number will increment by one for each packet. For audio packets of constant duration, the timestamp will increment by the number of sample periods conveyed in each packet. For video, the timestamp will change on the first packet of each frame, but then stay constant for any additional packets in the frame. If each video frame occupies only one packet, but the video frames are generated at a constant rate, then again the change in the timestamp from frame to frame is constant. Note that in each of these cases the second-order difference of the sequence number and timestamp fields is zero, so the next packet header can be constructed from the previous packet header by adding the first-order differences for these fields that are stored in the session context along with the previous uncompressed header. When the second-order difference is not zero, the magnitude of the change is usually much smaller than the full number of bits in the field, so the size can be reduced by encoding the new first-order difference and transmitting it rather than the absolute value.
それは特定のコンテキストを識別するものの一部であるので、RTPヘッダに、SSRC識別子は、与えられた文脈において一定です。ほとんどのパケットの場合、シーケンス番号とタイムスタンプのみがパケットごとに変更されます。パケットが紛失したり、圧縮機の上流misorderedされていない場合、シーケンス番号は各パケットに対して1つずつ増加します。一定の持続時間のオーディオパケットの場合、タイムスタンプは、各パケットに搬送サンプル周期の数でインクリメントします。ビデオでは、タイムスタンプは、各フレームの最初のパケットに変更されますが、その後、フレーム内の任意の追加のパケットに対して一定のまま。各ビデオフレームは、一つだけのパケットを占有するが、ビデオフレームは一定の割合で発生している場合は、再度フレームからフレームへのタイムスタンプの変化が一定です。これらの場合のそれぞれにおいて、シーケンス番号とタイムスタンプフィールドの二次差分がゼロであるので、次のパケットのヘッダがに格納されているこれらのフィールドの一次差分を加算することにより、以前のパケットヘッダから構築することができることに注意してください前の非圧縮ヘッダと共にセッションコンテキスト。二階差分がゼロでない場合には、変化の大きさは、フィールド内のビットの完全な数よりも通常はるかに小さいので、サイズは新しい一次差分を符号化し、絶対的ではなく、それを送信することにより低減することができます値。
The M bit will be set on the first packet of an audio talkspurt and the last packet of a video frame. If it were treated as a constant field such that each change required sending the full RTP header, this would reduce the compression significantly. Therefore, one bit in the compressed header will carry the M bit explicitly.
Mビットは、オーディオ、有音部の最初のパケット及びビデオフレームの最後のパケットに設定されます。それは、各変化がフルRTPヘッダを送信する必要ように、一定のフィールドとして処理した場合、これは大幅な圧縮を減少させるであろう。したがって、圧縮ヘッダ内の1ビットは、明示的にMビットを伝送します。
If the packets are flowing through an RTP mixer, most commonly for audio, then the CSRC list and CC count will also change. However, the CSRC list will typically remain constant during a talkspurt or longer, so it need be sent only when it changes.
パケットは、オーディオ用の最も一般的に、RTPミキサーを通して流れている場合は、CSRCリストとCC数も変更されます。しかし、CSRCリストは、一般的に、有音部の間に一定のままである以上、それが変化した場合にのみ、それが送信される必要があるだろう。
The compression protocol must maintain a collection of shared information in a consistent state between the compressor and decompressor. There is a separate session context for each IP/UDP/RTP packet stream, as defined by a particular combination of the IP source and destination addresses, UDP source and destination ports, and the RTP SSRC field. The number of session contexts to be maintained MAY be negotiated between the compressor and decompressor. Each context is identified by an 8- or 16-bit identifier, depending upon the number of contexts negotiated, so the maximum number is 65536. Both uncompressed and compressed packets MUST carry the context ID and a 4-bit sequence number used to detect packet loss between the compressor and decompressor. Each context has its own separate sequence number space so that a single packet loss need only invalidate one context.
圧縮プロトコルは、コンプレッサとデコンプレッサとの間の一貫性のある状態で、共有情報の収集を維持しなければなりません。 IP送信元および宛先アドレス、UDP送信元ポートと宛先ポート、およびRTP SSRCフィールドの特定の組み合わせによって定義される各IP / UDP / RTPパケットストリームのための別個のセッション・コンテキストがあります。維持するセッション・コンテキストの数は、コンプレッサとデコンプレッサとの間で交渉されるかもしれません。各コンテキストは、ネゴシエートされたコンテキストの数に応じて、8ビットまたは16ビットの識別子によって識別されるので、最大数は、コンテキストIDとパケットを検出するために使用される4ビットのシーケンス番号を運ばなければなりません65536の非圧縮および圧縮の両方のパケットでありますコンプレッサとデコンプレッサとの間の損失。単一のパケット損失が唯一のコンテキストを無効にする必要がなるように各コンテキストは、独自の独立したシーケンス番号空間があります。
The shared information in each context consists of the following items:
各コンテキストで共有される情報は、以下の項目で構成されています。
o The full IP, UDP and RTP headers, possibly including a CSRC list, for the last packet sent by the compressor or reconstructed by the decompressor.
フルIP、UDP及びRTPヘッダO、おそらくはデコンプレッサによって圧縮機によって送信されるか、または再構成された最後のパケットのためのCSRCリストを含みます。
o The first-order difference for the IPv4 ID field, initialized to 1 whenever an uncompressed IP header for this context is received and updated each time a delta IPv4 ID field is received in a compressed packet.
このコンテキストの非圧縮IPヘッダが受信され、デルタのIPv4 IDフィールドが圧縮されたパケットで受信されるたびに更新されるたびに1に初期化したIPv4 IDフィールドに対する一次差分、O。
o The first-order difference for the RTP timestamp field, initialized to 0 whenever an uncompressed packet for this context is received and updated each time a delta RTP timestamp field is received in a compressed packet.
このコンテキストの非圧縮パケットを受信し、デルタRTPタイムスタンプフィールドは、圧縮されたパケットで受信されるたびに更新されるたびにRTPタイムスタンプフィールドの一次差分O、0に初期化します。
o The last value of the 4-bit sequence number, which is used to detect packet loss between the compressor and decompressor.
コンプレッサとデコンプレッサとの間のパケット損失を検出するために使用される4ビットのシーケンス番号の最後の値O。
o The current generation number for non-differential coding of UDP packets with IPv6 (see [3]). For IPv4, the generation number may be set to zero if the COMPRESSED_NON_TCP packet type, defined below, is never used.
IPv6でUDPパケットの非差動符号化のための現在の世代番号（[3]参照）O。以下に定義COMPRESSED_NON_TCPパケットタイプが、使用されない場合にIPv4のため、世代番号がゼロに設定されてもよいです。
o A context-specific delta encoding table (see section 3.3.4) may optionally be negotiated for each context.
コンテキスト固有のデルタ符号化テーブルO（セクション3.3.4を参照）必要に応じて各コンテキストのために交渉することができます。
In order to communicate packets in the various uncompressed and compressed forms, this protocol depends upon the link layer being able to provide an indication of four new packet formats in addition to the normal IPv4 and IPv6 packet formats:
種々の非圧縮および圧縮形式でパケットを通信するために、このプロトコルは、通常のIPv4およびIPv6パケットフォーマットの他の4つの新たなパケットフォーマットの指示を提供することができるリンクレイヤに依存します。
FULL_HEADER - communicates the uncompressed IP header plus any following headers and data to establish the uncompressed header state in the decompressor for a particular context. The FULL-HEADER packet also carries the 8- or 16-bit session context identifier and the 4-bit sequence number to establish synchronization between the compressor and decompressor. The format is shown in section 3.3.1.
FULL_HEADER - は、非圧縮IPヘッダを通信プラス任意の以下のヘッダおよびデータは、特定のコンテキストのデコンプレッサで圧縮されていないヘッダ状態を確立します。フルヘッダーパケットは、8ビットまたは16ビットのセッションコンテキスト識別子とコンプレッサとデコンプレッサとの間の同期を確立するための4ビットのシーケンス番号を運びます。フォーマットは、セクション3.3.1に示されています。
COMPRESSED_UDP - communicates the IP and UDP headers compressed to 6 or fewer bytes (often 2 if UDP checksums are disabled), followed by any subsequent headers (possibly RTP) in uncompressed form, plus data. This packet type is used when there are differences in the usually constant fields of the (potential) RTP header. The RTP header includes a potentially changed value of the SSRC field, so this packet may redefine the session context. The format is shown in section 3.3.3.
COMPRESSED_UDPは - （UDPチェックサムが無効になっている場合、多くの場合、2）非圧縮形式、プラスデータに後続ヘッダ（おそらくRTP）、続いて、6つの以下のバイトに圧縮IP及びUDPヘッダを通信します。 （電位）RTPヘッダの通常一定の分野に違いがある場合、このパケットタイプが使用されます。 RTPヘッダはSSRCフィールドの潜在的に変更された値を含むので、このパケットは、セッションコンテキストを再定義することができます。フォーマットは、セクション3.3.3に示されています。
COMPRESSED_RTP - indicates that the RTP header is compressed along with the IP and UDP headers. The size of this header may still be just two bytes, or more if differences must be communicated. This packet type is used when the second-order difference (at least in the usually constant fields) is zero. It includes delta encodings for those fields that have changed by other than the expected amount to establish the first-order differences after an uncompressed RTP header is sent and whenever they change. The format is shown in section 3.3.2.
COMPRESSED_RTPは - RTPヘッダがIP及びUDPヘッダとともに圧縮されることを示しています。差が伝達されなければならない場合は、このヘッダのサイズは、依然としてわずか2バイト以上であってもよいです。 （通常一定の分野における少なくとも）二階差分がゼロである場合、このパケットタイプが使用されます。これは、圧縮されていないRTPヘッダの後の最初の階差分を確立するために予想される量以外で変更されたフィールドのデルタエンコーディングが送信さ含み、それらが変更するたび。フォーマットは、セクション3.3.2に示されています。
CONTEXT_STATE - indicates a special packet sent from the decompressor to the compressor to communicate a list of context IDs for which synchronization has or may have been lost. This packet is only sent across the point-to-point link so it requires no IP header. The format is shown in section 3.3.5.
CONTEXT_STATEは - 同期が失われた可能性がありましたか、そのためのコンテキストIDのリストを通信するために圧縮機に減圧装置から送信された特殊なパケットを示しています。それはIPヘッダを必要としないので、このパケットは、ポイントツーポイントリンクを介して送信されます。フォーマットは、セクション3.3.5に示されています。
When this compression scheme is used with IPv6 as part of the general header compression framework specified in [3], another packet type MAY be used:
この圧縮方式は、[3]、別のパケットタイプを使用することができるで指定された一般的なヘッダ圧縮フレームワークの一部として、IPv6で使用する場合：
COMPRESSED_NON_TCP - communicates the compressed IP and UDP headers as defined in [3] without differential encoding. If it were used for IPv4, it would require one or two bytes more than the COMPRESSED_UDP form listed above in order to carry the IPv4 ID field. For IPv6, there is no ID field and this non-differential compression is more resilient to packet loss.
COMPRESSED_NON_TCPは、 - 差動符号化することなく、[3]で定義されるように圧縮されたIP及びUDPヘッダを通信します。それはIPv4のために使用した場合、それは、IPv4 IDフィールドを搬送するために上記COMPRESSED_UDP形よりも1または2バイト以上を必要とするであろう。 IPv6の場合、そこにはIDフィールドではありませんし、この非差分圧縮は、パケット損失をより弾力的です。
Assignments of numeric codes for these packet formats in the Point-to-Point Protocol [4] are to be made by the Internet Assigned Numbers Authority.
ポイントツーポイントプロトコルでこれらのパケットフォーマットのための数値コードの割り当ては、[4]、インターネット割り当て番号機関によってなされるべきです。
The definition of the FULL_HEADER packet given here is intended to be the consistent with the definition given in [3]. Full details on design choices are given there.
ここで与えられたFULL_HEADERパケットの定義は、[3]で与えられた定義と一致するように意図されています。デザインの選択の完全な詳細はそこに与えられています。
The format of the FULL_HEADER packet is the same as that of the original packet. In the IPv4 case, this is usually an IP header, followed by a UDP header and UDP payload that may be an RTP header and its payload. However, the FULL_HEADER packet may also carry IP encapsulated packets, in which case there would be two IP headers followed by UDP and possibly RTP. Or in the case of IPv6, the packet may be built of some combination of IPv6 and IPv4 headers. Each successive header is indicated by the type field of the previous header, as usual.
FULL_HEADERパケットのフォーマットは、元のパケットと同じです。 IPv4のケースでは、これは通常、UDPヘッダ及びRTPヘッダ及びペイロードであってもよいUDPペイロードが続くIPヘッダです。しかし、FULL_HEADERパケットはUDPおよびおそらくRTP続く2つのIPヘッダが存在するであろうその場合、IPカプセル化されたパケットを、さらに有していてもよいです。またはIPv6の場合、パケットは、IPv6とIPv4ヘッダのいくつかの組み合わせで構築することができます。連続する各ヘッダは、通常のように、以前のヘッダのタイプフィールドによって示されます。
The FULL_HEADER packet differs from the corresponding normal IPv4 or IPv6 packet in that it must also carry the compression context ID and the 4-bit sequence number. In order to avoid expanding the size of the header, these values are inserted into length fields in the IP and UDP headers since the actual length may be inferred from the length provided by the link layer. Two 16-bit length fields are needed; these are taken from the first two available headers in the packet. That is, for an IPv4/UDP packet, the first length field is the total length field of the IPv4 header, and the second is the length field of the UDP header. For an IPv4 encapsulated packet, the first length field would come from the total length field of the first IP header, and the second length field would come from the total length field of the second IP header.
また、圧縮コンテキストIDと、4ビットのシーケンス番号を運ばなければならないという点でFULL_HEADERパケットは、対応する正常なIPv4またはIPv6パケットは異なります。実際の長さは、リンク層により提供される長さから推測することができるので、ヘッダのサイズを拡大しないようにするために、これらの値はIP及びUDPヘッダの長さフィールドに挿入されます。 2つの16ビット長のフィールドが必要とされています。これらは、パケットの最初の2つの可能なヘッダから取得されます。それは、IPv4 / UDPパケットのために、第1の長さフィールドは、IPv4ヘッダの合計長フィールドは、であり、そして第二は、UDPヘッダの長さフィールドです。 IPv4のカプセル化されたパケットのために、第一の長さフィールドは、最初のIPヘッダーの全長フィールドから来る、及び第2の長さフィールドは、第2のIPヘッダーの全長フィールドから来ます。
As specified in Sections 5.3.2 of [3], the position of the context ID (CID) and 4-bit sequence number varies depending upon whether 8- or 16-bit context IDs have been selected, as shown in the following diagram (16 bits wide, with the most-significant bit is to the left):
[3]のセクション5.3.2で指定されるように、コンテキストID（CID）の位置と、4ビットのシーケンス番号は、（以下の図に示すように、8ビットまたは16ビットのコンテキストIDは、選択されたかどうかに依存して変化します16ビット幅は、最上位ビットを用いて）左側にあります。
For 8-bit context ID:
8ビットのコンテキストIDのために：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Generation| CID | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | seq | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For 16-bit context ID:
16ビットのコンテキストIDのための：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Generation| 0 | seq | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first bit in the first length field indicates the length of the CID. The length of the CID MUST either be constant for all contexts or two additional distinct packet types MUST be provided to separately indicate COMPRESSED_UDP and COMPRESSED_RTP packet formats with 8- and 16-bit CIDs. The second bit in the first length field is 1 to indicate that the 4-bit sequence number is present, as is always the case for this IP/UDP/RTP compression scheme.
第1の長さフィールドの最初のビットはCIDの長さを示します。 CIDの長さすべてのコンテキストまたは二つの追加の異なるパケットタイプのために一定でなければならないのいずれかでは、8ビットおよび16ビットのCIDとCOMPRESSED_UDPとCOMPRESSED_RTPパケットフォーマットを別々に示すために提供されなければなりません。第1の長さフィールドに2番目のビットは、常にこのIP / UDP / RTP圧縮方式の場合のように4ビットのシーケンス番号が、存在していることを示すために1です。
The generation field is used with IPv6 for COMPRESSED_NON_TCP packets as described in [3]. For IPv4-only implementations that do not use COMPRESSED_NON_TCP packets, the compressor SHOULD set the generation value to zero. For consistent operation between IPv4 and IPv6, the generation value is stored in the context when it is received by the decompressor, and the most recent value is returned in the CONTEXT_STATE packet.
[3]に記載のように生成フィールドはCOMPRESSED_NON_TCPパケットのIPv6で使用されます。 COMPRESSED_NON_TCPパケットを使用しないIPv4のみの実装では、圧縮機がゼロに世代値を設定する必要があります。それは解凍器によって受信された場合に、IPv4とIPv6との間の一貫性の動作のために、発生値をコンテキストに格納されており、最新の値がCONTEXT_STATEパケットに戻されます。
When a FULL_HEADER packet is received, the complete set of headers is stored into the context selected by the context ID. The 4-bit sequence number is also stored in the context, thereby resynchronizing the decompressor to the compressor.
FULL_HEADERパケットを受信すると、ヘッダの完全なセットは、コンテキストIDによって選択されたコンテキストに格納されます。 4ビットのシーケンス番号はまた、圧縮機への減圧装置を再同期、コンテキストに格納されます。
When COMPRESSED_NON_TCP packets are used, the 4-bit sequence number is inserted into the "Data Field" of that packet and the D bit is set as described in Section 6 of [3]. When a COMPRESSED_NON_TCP packet is received, the generation number is compared to the value stored in the context. If they are not the same, the context is not up to date and MUST be refreshed by a FULL_HEADER packet. If the generation does match, then the compressed IP and UDP header information, the 4-bit sequence number, and the (potential) RTP header are all stored into the saved context.
COMPRESSED_NON_TCPパケットが使用される場合、4ビットのシーケンス番号は、パケットの「データフィールド」に挿入され、[3]のセクション6で説明したようにDビットが設定されています。 COMPRESSED_NON_TCPパケットを受信した場合、世代番号がコンテキストに格納されている値と比較されます。それらが同じでない場合は、コンテキストが最新ではないとFULL_HEADERパケットによってリフレッシュされなければなりません。世代が一致しない場合、圧縮されたIP及びUDPヘッダ情報、4ビットのシーケンス番号、及び（電位）RTPヘッダは、すべて保存されてコンテキストに格納されます。
The amount of memory required to store the context will vary depending upon how many encapsulating headers are included in the FULL_HEADER packet. The compressor and decompressor MAY negotiate a maximum header size.
コンテキストを格納するのに必要なメモリの量は、ヘッダがFULL_HEADERパケットに含まれるどのように多くのカプセル化に依存して変化します。コンプレッサとデコンプレッサは、最大ヘッダーサイズを交渉することができます。
When the second-order difference of the RTP header from packet to packet is zero, the decompressor can reconstruct a packet simply by adding the stored first-order differences to the stored uncompressed header representing the previous packet. All that need be communicated is the session context identifier and a small sequence number (not related to the RTP sequence number) to maintain synchronization and detect packet loss between the compressor and decompressor.
パケットのパケットからRTPヘッダの二次差分がゼロである場合、デコンプレッサは、単に以前のパケットを表す格納された非圧縮ヘッダに格納された第一階差分を加算することによってパケットを再構成することができます。通信される必要があるすべてのセッションコンテキスト識別子と小さなシーケンス番号（RTPシーケンス番号に関連していない）同期を維持し、コンプレッサとデコンプレッサとの間のパケット損失を検出することです。
If the second-order difference of the RTP header is not zero for some fields, the new first-order difference for just those fields is communicated using a compact encoding. The new first-order difference values are added to the corresponding fields in the uncompressed header in the decompressor's session context, and are also stored explicitly in the context to be added to the corresponding fields again on each subsequent packet in which the second-order difference is zero. Each time the first-order difference changes, it is transmitted and stored in the context.
RTPヘッダの二次差分は、いくつかのフィールドのゼロではない場合は、単にそれらのフィールドのための新しい一次差分をコンパクトエンコーディングを使用して通信されます。新しい一次差分値は、デコンプレッサのセッションコンテキストにおける非圧縮ヘッダの対応するフィールドに追加され、また、第二階差分各後続パケットに再び対応するフィールドに追加される文脈に明示的に格納されていますゼロです。一次差が変化するたびに、それが送信され、コンテキストに格納されます。
In practice, the only fields for which it is useful to store the first-order difference are the IPv4 ID field and the RTP timestamp. For the RTP sequence number field, the usual increment is 1. If the sequence number changes by other than 1, the difference must be communicated but does not set the expected difference for the next packet. Instead, the expected first-order difference remains fixed at 1 so that the difference need not be explicitly communicated on the next packet assuming it is in order.
実際に、第一階差分を保存するために有用であるのみフィールドは、IPv4 IDフィールドとRTPタイムスタンプです。シーケンス番号が1以外によって変更される場合RTPシーケンス番号フィールドの場合は、通常の増分は1で、違いが伝達されなければならないが、次のパケットのための期待の違いを設定しません。代わりに、予想される一次差分は、差分が明示的にそれがオーダーであると仮定すると次のパケットで通信する必要がないように1に固定されたままです。
For the RTP timestamp, when a FULL_HEADER, COMPRESSED_NON_TCP or COMPRESSED_UDP packet is sent to refresh the RTP state, the stored first-order difference is initialized to zero. If the timestamp is the same on the next packet (e.g., same video frame), then the second-order difference is zero. Otherwise, the difference between the timestamps of the two packets is transmitted as the new first-order difference to be added to the timestamp in the uncompressed header stored in the decompressor's context and also stored as the first-order difference in that context. Each time the first-order difference changes on subsequent packets, that difference is again transmitted and used to update the context.
FULL_HEADER、COMPRESSED_NON_TCP又はCOMPRESSED_UDPパケットがRTPの状態を更新するために送信されるRTPタイムスタンプ、のために、格納された第一階差分をゼロに初期化されます。タイムスタンプが次のパケット（例えば、同じビデオフレーム）上で同じである場合、二次差分はゼロです。そうでない場合、二つのパケットのタイムスタンプとの差がデコンプレッサのコンテキストに格納された非圧縮ヘッダ内のタイムスタンプに追加される新たな一次差分として送信し、また、そのコンテキストにおける一次差分として記憶されます。一次差分が後続のパケットに変更するたびに、その差が再び送信され、コンテキストを更新するために使用されます。
Similarly, since the IPv4 ID field frequently increments by one, the first-order difference for that field is initialized to one when the state is refreshed by a FULL_HEADER packet, or when a COMPRESSED_NON_TCP packet is sent since it carries the ID field in uncompressed form. Thereafter, whenever the first-order difference changes, it is transmitted and stored in the context.
COMPRESSED_NON_TCPパケットが以降送信されたときのIPv4 IDフィールドは、しばしば1つ増分するので状態がFULL_HEADERパケットによって更新されたとき、同様に、そのフィールドの一次差分が1に初期化され、またはそれは、非圧縮形式のIDフィールドを運びます。その後、一次差が変化するたびに、それが送信され、コンテキストに格納されます。
A bit mask will be used to indicate which fields have changed by other than the expected difference. In addition to the small link sequence number, the list of items to be conditionally communicated in the compressed IP/UDP/RTP header is as follows:
ビットマスクは、予想される違い以外で変更されたフィールドを示すために使用されるであろう。次のように小さなリンクシーケンス番号に加えて、条件付き圧縮IP / UDP / RTPヘッダに通信されるアイテムのリストです。
I = IPv4 packet ID (always 0 if no IPv4 header) U = UDP checksum M = RTP marker bit S = RTP sequence number T = RTP timestamp L = RTP CSRC count and list
I = IPv4パケットID（常に0ないIPv4ヘッダ場合）Uは= UDPチェックサムM = RTPマーカビットS = RTPシーケンス番号T = RTPタイムスタンプL = RTP CSRCカウントとリスト
If 4 bits are needed for the link sequence number to get a reasonable probability of loss detection, there are too few bits remaining to assign one bit to each of these items and still fit them all into a single byte to go along with the context ID.
4ビットが損失検出の合理的な確率を取得するには、リンクのシーケンス番号のために必要とされる場合は、これらの項目のそれぞれに1ビットを割り当て、まだコンテキストIDと一緒に行くために、単一のバイトにそれらすべてに適合するために、残りの数が少なすぎるビットが存在します。
It is not necessary to explicitly carry the U bit to indicate the presence of the UDP checksum because a source will typically include check-sums on all packets of a session or none of them. When the session state is initialized with an uncompressed header, if there is a nonzero checksum present, an unencoded 16-bit checksum will be inserted into the compressed header in all subsequent packets until this setting is changed by sending another uncompressed packet.
明示的にソースは、通常のセッションのすべてのパケットのチェックサムまたはそれらのいずれもが含まれますので、UDPチェックサムの存在を示すために、Uビットを運ぶ必要はありません。セッション状態は、非圧縮ヘッダで初期化されるときにゼロでないチェックサムが存在する場合、この設定は、別の非圧縮パケットを送信することによって変更されるまで、エンコードされていない16ビットのチェックサムは、後続のすべてのパケット内の圧縮ヘッダに挿入されます。
Of the remaining items, the L bit for the CSRC count and list may be the one least frequently used. Rather than dedicating a bit in the mask to indicate CSRC change, an unusual combination of the other bits may be used instead. This bit combination is denoted MSTI. If all four of the bits for the IP packet ID, RTP marker bit, RTP sequence number and RTP timestamp are set, this is a special case indicating an extended form of the compressed RTP header will follow. That header will include an additional byte containing the real values of the four bits plus the CC count. The CSRC list, of length indicated by the CC count, will be included just as it appears in the uncompressed RTP header.
残りのアイテムの、CSRCカウント及びリスト用のLビットは、少なくとも頻繁に使用されるものであってもよいです。むしろ、CSRCの変化を示すために、マスクのビットを専用よりも、他のビットの珍しい組み合わせを用いてもよいです。このビットの組み合わせはMSTI表記します。 IPパケットIDのビットすべての4つは、RTPマーカビットは、RTPシーケンス番号及びRTPのタイムスタンプが設定されている場合、これは続く圧縮RTPヘッダの拡張された形態を示す特別なケースです。そのヘッダーは4ビットプラスCCカウントの実際の値を含む付加的なバイトを含むであろう。 CSRCリストは、CCの数で示される長さの、それが圧縮されていないRTPヘッダに表示されて同じように含まれます。
The other fields of the RTP header (version, P bit, X bit, payload type and SSRC identifier) are assumed to remain relatively constant. In particular, the SSRC identifier is defined to be constant for a given context because it is one of the factors selecting the context. If any of the other fields change, the uncompressed RTP header MUST sent as described in Section 3.3.3.
RTPヘッダー（バージョン、Pビット、Xビット、ペイロードタイプとSSRC識別子）の他のフィールドは、比較的一定のままであると仮定されます。それは、コンテキストを選択する要因の一つであるため、特に、SSRC識別子は、所与のコンテキストのための定数であると定義されます。他のフィールドのいずれかが変更された場合、セクション3.3.3に記載したように、非圧縮RTPヘッダを送信しなければなりません。
The following diagram shows the compressed IP/UDP/RTP header with dotted lines indicating fields that are conditionally present. The most significant bit is numbered 0. Multi-byte fields are sent in network byte order (most significant byte first). The delta fields are often a single byte as shown but may be two or three bytes depending upon the delta value as explained in Section 3.3.4.
次の図は、条件付きで存在するフィールドを示す点線で圧縮されたIP / UDP / RTPヘッダを示します。最上位ビットが0マルチバイトフィールドは、ネットワークバイト順（最上位バイトが最初）で送信される番号付けされています。デルタフィールドが示すように、多くの場合、シングルバイトであるが、セクション3.3.4で説明したように、デルタ値に応じて、2つのまたは3バイトであってもよいです。
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+---+---+---+---+---+---+---+---+
| M | S | T | I | link sequence |
+---+---+---+---+---+---+---+---+
: :
+ UDP checksum + (if nonzero in context)
: :
+...............................+
: :
+ "RANDOM" fields + (if encapsulated)
: :
+...............................+
: M'| S'| T'| I'| CC : (if MSTI = 1111)
+...............................+
: delta IPv4 ID : (if I or I' = 1)
+...............................+
: delta RTP sequence : (if S or S' = 1)
+...............................+
: delta RTP timestamp : (if T or T' = 1)
+...............................+
: :
: CSRC list : (if MSTI = 1111
: : and CC nonzero)
: :
+...............................+
: :
: RTP header extension : (if X set in context)
: :
: :
+-------------------------------+
| |
| RTP data |
/ /
/ /
| |
+-------------------------------+
: padding : (if P set in context)
+...............................+
When more than one IPv4 header is present in the context as initialized by the FULL_HEADER packet, then the IP ID fields of encapsulating headers MUST be sent as absolute values as described in
FULL_HEADERパケットによって初期化されるように複数のIPv4ヘッダがコンテキスト中に存在する場合で説明したように、次にヘッダーをカプセル化するIP IDフィールドは、絶対値として送信されなければなりません
[3]. These fields are identified as "RANDOM" fields. They are inserted into the COMPRESSED_RTP packet in the same order as they appear in the original headers, immediately following the UDP checksum if present or the MSTI byte if not, as shown in the diagram. Only if an IPv4 packet immediately precedes the UDP header will the IP ID of that header be sent differentially, i.e., potentially with no bits if the second difference is zero, or as a delta IPv4 ID field if not. If there is not an IPv4 header immediately preceding the UDP header, then the I bit MUST be 0 and no delta IPv4 ID field will be present.
[3]。これらのフィールドは、「RANDOM」フィールドとして識別されます。それらは直ちに現在またはMSTIのバイトでない場合であればUDPチェックサムを、以下、オリジナルのヘッダーに表示される図に示されるように、それらは、同じ順序でCOMPRESSED_RTPパケットに挿入されます。 IPv4パケットは、直ちに第二の差がゼロであるか、またはデルタのIPv4 IDフィールドとならない場合にUDPヘッダは、そのヘッダのIP IDがないビットで、潜在的に、すなわち、差動的に送信される先行する場合のみ。直ちにUDPヘッダの前にIPv4ヘッダが存在しない場合、Iビットが0でなければなりませんと全くデルタIPv4のIDフィールドが存在しないであろう。
If there is a change in any of the fields of the RTP header that are normally constant (such as the payload type field), then an uncompressed RTP header MUST be sent. If the IP and UDP headers do not also require updating, this RTP header MAY be carried in a COMPRESSED_UDP packet rather than a FULL_HEADER packet. The COMPRESSED_UDP packet has the same format as the COMPRESSED_RTP packet except that the M, S and T bits are always 0 and the corresponding delta fields are never included:
（例えば、ペイロードタイプフィールドなど）は通常一定であるRTPヘッダのフィールドのいずれかに変更があった場合には、圧縮されていないRTPヘッダが送信されなければなりません。 IPおよびUDPヘッダも更新を必要としない場合は、このRTPヘッダはCOMPRESSED_UDPパケットではなくFULL_HEADERパケットに行うことができます。 COMPRESSED_UDPパケットはM、SおよびTビットは常に0であり、対応するデルタフィールドが含まれることはないことを除いてCOMPRESSED_RTPパケットと同じフォーマットを有します。
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | I | link sequence |
+---+---+---+---+---+---+---+---+
: :
+ UDP checksum + (if nonzero in context)
: :
+...............................+
: :
+ "RANDOM" fields + (if encapsulated)
: :
+...............................+
: delta IPv4 ID : (if I = 1)
+-------------------------------+
| UDP data |
: (uncompressed RTP header) :
Note that this constitutes a form of IP/UDP header compression different from COMPRESSED_NON_TCP packet type defined in [3]. The motivation is to allow reaching the target of two bytes when UDP checksums are disabled, as IPv4 allows. The protocol in [3] does not use differential coding for UDP packets, so in the IPv4 case, two bytes of IP ID, and two bytes of UDP checksum if nonzero, would always be transmitted in addition to two bytes of compression prefix. For IPv6, the COMPRESSED_NON_TCP packet type MAY be used instead.
この[3]で定義COMPRESSED_NON_TCPパケットタイプとは異なるIP / UDPヘッダー圧縮の形態を構成することに留意されたいです。 UDPチェックサムが無効になっているときはIPv4が許す限り動機は、2バイトの目標を達成できるようにすることです。プロトコル[3]のIPv4場合に、IP IDの2バイト、およびUDPチェックサムの2つのバイトがゼロでない場合には、常に圧縮プレフィックスの2つのバイトに加えて送信される、UDPパケットのための差分符号化を使用しません。 IPv6の場合、COMPRESSED_NON_TCPパケットタイプを用いてもよいです。
The delta fields in the COMPRESSED_RTP and COMPRESSED_UDP packets are encoded with a variable-length mapping for compactness of the more commonly-used values. A default encoding is specified below, but it is RECOMMENDED that implementations use a table-driven delta encoder and decoder to allow negotiation of a table specific for each session if appropriate, possibly even an optimal Huffman encoding. Encodings based on sequential interpretation of the bit stream, of which this default table and Huffman encoding are examples, allow a reasonable table size and may result in an execution speed faster than a non-table-driven implementation with explicit tests for ranges of values.
COMPRESSED_RTPとCOMPRESSED_UDPパケットにおけるデルタ・フィールドは、より一般的に使用される値のコンパクト化のための可変長マッピングで符号化されます。デフォルトのエンコーディングは、以下に指定され、あっても、最適なハフマン符号化可能性、実装が適切な場合、各セッションのための特定のテーブルのネゴシエーションを可能にするために、テーブル駆動デルタエンコーダおよびデコーダを使用することをお勧めします。このデフォルトのテーブルとハフマン符号化は一例でありれたビットストリームのシーケンシャルな解釈に基づいて符号化は、合理的なテーブルサイズを可能にし、より高速な値の範囲の明示的な試験と非テーブル駆動型の実装より実行速度をもたらすことができます。
The default delta encoding is specified in the following table. This encoding was designed to efficiently encode the small changes that may occur in the IP ID and in RTP sequence number when packets are lost upstream from the compressor, yet still handling most audio and video deltas in two bytes. The column on the left is the decimal value to be encoded, and the column on the right is the resulting sequence of bytes shown in hexadecimal and in the order in which they are transmitted (network byte order). The first and last values in each contiguous range are shown, with ellipses in between:
デフォルトのデルタエンコーディングは、次の表に指定されています。この符号化は、パケットは、圧縮機の上流に失われた場合に効率的にIP IDおよびRTPシーケンス番号で起こり得る小さな変化をコードするように設計され、依然として2バイトでほとんどのオーディオおよびビデオデルタを処理しました。左の列は十進値を符号化することであり、右側の列は16進数で、それらが送信される順序（ネットワークバイト順）に示されるバイトの得られた配列です。各連続した範囲の最初と最後の値は、間に楕円で示されています。
Decimal Hex
10進数16進数
-16384 C0 00 00 : : -129 C0 3F 7F -128 80 00 : : -1 80 7F 0 00 : : 127 7F 128 80 80 : : 16383 BF FF 16384 C0 40 00 : : 4194303 FF FF FF
-16384 C0 00 00：-129 C0 3F 7F -128 80：00：80 -1 7F 0：00：127 7F 128 80 80：16383 BF FF 16384 C0 40 00：4194303 FF FF FF
For positive values, a change of zero through 127 is represented directly in one byte. If the most significant two bits of the byte are 10 or 11, this signals an extension to a two- or three-byte value, respectively. The least significant six bits of the first byte are combined, in decreasing order of significance, with the next one or two bytes to form a 14- or 22-bit value.
正の値の場合、127を介して、ゼロの変化は、1バイトで直接表されています。バイトの最上位の2ビットが10または11である場合、これは、それぞれ、2または3バイト値の拡張を通知します。最初のバイトの最下位の6ビットは、14-または22ビット値を形成するために、次の1つのまたは2バイトを用いて、有意性の低い順に、組み合わされます。
Negative deltas may occur when packets are misordered or in the intentionally out-of-order RTP timestamps on MPEG video [5]. These events are less likely, so a smaller range of negative values is encoded using otherwise redundant portions of the positive part of the table.
パケットが[5] misorderedまたはMPEGビデオに意図的にアウトオブオーダRTPタイムスタンプにある場合、負のデルタが発生する可能性があります。これらのイベントは、可能性が低いので、負の値の小さい方の範囲は、テーブルの正の部分のそれ以外の場合は、冗長部分を使用して符号化されます。
A change in the RTP timestamp value less than -16384 or greater than 4194303 forces the RTP header to be sent uncompressed using a FULL_HEADER, COMPRESSED_NON_TCP or COMPRESSED_UDP packet type. The IP ID and RTP sequence number fields are only 16 bits, so negative deltas for those fields SHOULD be masked to 16 bits and then encoded (as large positive 16-bit numbers).
-16384より小さいかより大きい4194303の力RTPヘッダのRTPタイムスタンプ値の変化がFULL_HEADER、COMPRESSED_NON_TCP又はCOMPRESSED_UDPパケットタイプを使用して圧縮されていない送信します。 IP IDとRTPシーケンス番号フィールドは、16ビットなので、これらのフィールドのための負のデルタが16ビットにマスキングされ、その後、（大きな正の16ビット数として）符号化されるべきです。
Whenever the 4-bit sequence number for a particular context increments by other than 1, except when set by a FULL_HEADER or COMPRESSED_NON_TCP packet, the decompressor MUST invalidate that context and send a CONTEXT_STATE packet back to the compressor indicating that the context has been invalidated. All packets for the invalid context MUST be discarded until a FULL_HEADER or COMPRESSED_NON_TCP packet is received for that context to re-establish consistent state (unless the "twice" algorithm is used as described later in this section). Since multiple compressed packets may arrive in the interim, the decompressor SHOULD NOT retransmit the CONTEXT_STATE packet for every compressed packet received, but instead SHOULD limit the rate of retransmission to avoid flooding the reverse channel.
たびFULL_HEADER又はCOMPRESSED_NON_TCPパケットによって設定された場合を除いて1以外によって特定のコンテキスト増分用の4ビットのシーケンス番号は、解凍器はそのコンテキストを無効にしなければならない状況が無効にされたことを示す圧縮機に戻すCONTEXT_STATEパケットを送信します。 FULL_HEADER又はCOMPRESSED_NON_TCPパケットは、（このセクションで後述するように「倍」アルゴリズムが使用されていない限り）一貫性のある状態を再確立するために、そのコンテキストに受信されるまで無効コンテキストのすべてのパケットが廃棄されなければなりません。複数の圧縮されたパケットがその間に到着する可能性があるので、逆圧縮器は、受信されたすべての圧縮パケットのためCONTEXT_STATEパケットを再送するべきではなく、代わりに逆方向チャネルのフラッディングを回避するために、再送の速度を制限する必要があります。
When an error occurs on the link, the link layer will usually discard the packet that was damaged (if any), but may provide an indication of the error. Some time may elapse before another packet is delivered for the same context, and then that packet would have to be discarded by the decompressor when it is observed to be out of sequence, resulting in at least two packets lost. To allow faster recovery if the link does provide an explicit error indication, the decompressor MAY optionally send an advisory CONTEXT_STATE packet listing the last valid sequence number and generation number for one or more recently active contexts (not necessarily all). For a given context, if the compressor has sent no compressed packet with a higher sequence number, and if the generation number matches the current generation, no corrective action is required. Otherwise, the compressor MAY choose to mark the context invalid so that the next packet is sent in FULL_HEADER or COMPRESSED_NON_TCP mode (FULL_HEADER is required if the generation doesn't match). However, note that if the link round-trip-time is large compared to the inter-packet spacing, there may be several packets from multiple contexts in flight across the link, increasing the probability that the sequence numbers will already have advanced when the CONTEXT_STATE packet is received by the compressor. The result could be that some contexts are invalidated unnecessarily, causing extra bandwidth to be consumed.
エラーがリンク上で発生した場合、リンク層は、通常、（もしあれば）が破損したパケットを破棄しますが、エラーの表示を提供することができます。別のパケットが同じコンテキストに配信される前にいくつかの時間が経過して、その後、そのパケットは、失われ、少なくとも二つのパケットで、その結果、シーケンス外であることが観察されたときにデコンプレッサによって破棄しなければならないであろう。リンクは、明示的なエラー表示が提供されていた場合に迅速な復旧を可能にするには、デコンプレッサは、必要に応じて1つまたは複数の最近の活動的な文脈（必ずしもすべてではない）のために、最後の有効なシーケンス番号と世代番号をリスト顧問CONTEXT_STATEパケットを送信することができます。所与のコンテキストのために、圧縮機はより高いシーケンス番号を持つ圧縮されたパケットを送信していない、及び世代番号が現在の世代と一致した場合、何の是正措置が必要とされない場合。そうでなければ、コンプレッサーは次のパケットが（世代が一致しない場合FULL_HEADERが必要です）FULL_HEADERまたはCOMPRESSED_NON_TCPモードで送信されるように、無効なコンテキストをマークするために選ぶかもしれません。ただし、リンクのラウンドトリップ時間がパケット間の間隔に比べて大きい場合、CONTEXT_STATEシーケンス番号がすでに進んでいるだろうという確率が高く、リンクを介して飛行中の複数のコンテキストからのいくつかのパケットがあるかもしれないことに注意してくださいパケットは、圧縮機によって受信されます。その結果は、いくつかの文脈は、余分な帯域幅が消費させる、不必要に無効にされていることが考えられます。
The format of the CONTEXT_STATE packet is shown in the following diagrams. The first byte is a type code to allow the CONTEXT_STATE packet type to be shared by multiple compression schemes within the general compression framework specified in [3]. The contents of the remainder of the packet depends upon the compression scheme. For the IP/UDP/RTP compression scheme specified here, the remainder of the CONTEXT_STATE packet is structured as a list of blocks to allow the state for multiple contexts to be indicated, preceded by a one-byte count of the number of blocks.
CONTEXT_STATEパケットのフォーマットは、次の図に示されています。最初のバイトはCONTEXT_STATEパケットタイプ[3]で指定された一般的な圧縮フレームワーク内の複数の圧縮方式で共有できるようにするタイプのコードです。パケットの残りの内容は圧縮方式に依存します。ここで指定されたIP / UDP / RTP圧縮方式のため、CONTEXT_STATEパケットの残りの部分はブロックの数の1バイト・カウントが先行示されるべき複数のコンテキストのための状態を可能にするためにブロックのリストとして構成されています。
Two type code values are used for the IP/UDP/RTP compression scheme. The value 1 indicates that 8-bit session context IDs are being used:
二つのタイプのコード値は、IP / UDP / RTP圧縮方式のために使用されています。値1は、8ビットのセッションコンテキストIDが使用されていることを示しています。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 = IP/UDP/RTP with 8-bit CID |
+---+---+---+---+---+---+---+---+
| context count |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| session context ID |
+---+---+---+---+---+---+---+---+
| I | 0 | 0 | 0 | sequence |
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
...
+---+---+---+---+---+---+---+---+
| session context ID |
+---+---+---+---+---+---+---+---+
| I | 0 | 0 | 0 | sequence |
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
The value 2 indicates that 16-bit session context IDs are being used. The session context ID is sent in network byte order (most significant byte first):
値2は、16ビットのセッションコンテキストIDが使用されていることを示しています。セッションコンテキストIDは、ネットワークバイト順（最上位バイトが最初）に送信されます。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 2 = IP/UDP/RTP with 16-bit CID|
+---+---+---+---+---+---+---+---+
| context count |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| |
+ session context ID +
| |
+---+---+---+---+---+---+---+---+
| I | 0 | 0 | 0 | sequence |
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
...
+---+---+---+---+---+---+---+---+
| |
+ session context ID +
| |
+---+---+---+---+---+---+---+---+
| I | 0 | 0 | 0 | sequence |
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
The bit labeled "I" is set to one for contexts that have been marked invalid and require a FULL_HEADER of COMPRESSED_NON_TCP packet to be transmitted. If the I bit is zero, the context state is advisory. The I bit is set to zero to indicate advisory context state that MAY be sent following a link error indication.
ビットラベルは、「I」は無効とマークして送信するCOMPRESSED_NON_TCPパケットのFULL_HEADERを必要とされているコンテキストのいずれかに設定されています。 Iビットがゼロの場合は、コンテキスト状態は顧問です。 Iビットがリンクエラー表示次送るかもしれアドバイザリーコンテキスト状態を示すためにゼロに設定されています。
Since the CONTEXT_STATE packet itself may be lost, retransmission of one or more blocks is allowed. It is expected that retransmission will be triggered only by receipt of another packet, but if the line is near idle, retransmission MAY be triggered by a relatively long timer (on the order of 1 second).
CONTEXT_STATEパケット自体が失われる可能性があるため、一つ以上のブロックの再送信が許可されています。再送信のみを別のパケットの受信によってトリガされることが予想されますが、ラインがアイドル状態に近い場合、再送信は、（1秒程度）の比較的長いタイマーによってトリガすることができます。
If a CONTEXT_STATE block for a given context is retransmitted, it may cross paths with the FULL_HEADER or COMPRESSED_NON_TCP packet intended to refresh that context. In that case, the compressor MAY choose to ignore the error indication.
所与のコンテキストのCONTEXT_STATEブロックが再送される場合は、そのコンテキストを更新することを意図FULL_HEADER又はCOMPRESSED_NON_TCPパケットに経路を横断することができます。その場合、コンプレッサーは、エラー表示を無視することを選択するかもしれません。
In the case where UDP checksums are being transmitted, the decompressor MAY attempt to use the "twice" algorithm described in section 10.1 of [3]. In this algorithm, the delta is applied more than once on the assumption that the delta may have been the same on the missing packet(s) and the one subsequently received. Success is indicated by a checksum match. For the scheme defined here, the difference in the 4- bit sequence number tells number of times the delta must be applied. Note, however, that there is a nontrivial risk of an incorrect positive indication. It may be advisable to request a FULL_HEADER or COMPRESSED_NON_TCP packet even if the "twice" algorithm succeeds.
UDPチェックサムが送信されている場合には、減圧装置は、[3]のセクション10.1に記載された「二回」アルゴリズムを使用することを試みることができます。このアルゴリズムでは、デルタはデルタが欠落パケット（S）と、続いて受信された1つで同じであったかもしれないことを前提に複数回印加されます。成功は、チェックサムの一致によって示されています。ここで定義されたスキームのために、4ビットのシーケンス番号の差は、デルタが適用されなければならない回数を伝えます。間違った陽性表示の自明でない危険性があること、しかし、注意してください。 「二回」アルゴリズムが成功してもFULL_HEADERまたはCOMPRESSED_NON_TCPパケットを要求することをお勧めします。
Some errors may not be detected, for example if 16 packets are lost in a row and the link level does not provide an error indication. In that case, the decompressor will generate packets that are not valid. If UDP checksums are being transmitted, the receiver will probably detect the invalid packets and discard them, but the receiver does not have any means to signal the decompressor. Therefore, it is RECOMMENDED that the decompressor verify the UDP checksum periodically, perhaps one out of 16 packets. If an error is detected, the decompressor would invalidate the context and signal the compressor with a CONTEXT_STATE packet.
16個のパケットが一列に失われ、リンクレベルはエラー表示を提供しない場合、いくつかのエラーは、例えば、検出されない可能性があります。その場合、デコンプレッサは、有効ではありませんパケットを生成します。 UDPチェックサムが送信されている場合は、受信機は、おそらく無効なパケットを検出し、それらを廃棄しますが、受信機は、圧縮解除を通知するための任意の手段を持っていないでしょう。したがって、おそらく1つの16個のパケットのうち、解凍装置は周期的にUDPチェックサムを検証することが推奨されます。エラーが検出された場合、デコンプレッサは、コンテキストを無効とCONTEXT_STATEパケットで圧縮機に信号を送ることになります。
By relying on the RTP convention that data is carried on an even port number and the corresponding RTCP packets are carried on the next higher (odd) port number, one could tailor separate compression schemes to be applied to RTP and RTCP packets. For RTCP, the compression could apply not only to the header but also the "data", that is, the contents of the different packet types. The numbers in Sender Report (SR) and Receiver Report (RR) RTCP packets would not compress well, but the text information in the Source Description (SDES) packets could be compressed down to a bit mask indicating each item that was present but compressed out (for timing purposes on the SDES NOTE item and to allow the end system to measure the average RTCP packet size for the interval calculation).
データは偶数ポート番号上に担持され、対応するRTCPパケットは次の上位（奇数）ポート番号に担持されていることをRTP規則に依存することによって、一つはRTPとRTCPパケットに適用される別の圧縮スキームを調整することができました。 RTCPのために、圧縮されたが、異なるパケットタイプのコンテンツであり、ヘッダも「データ」に限らず適用することができます。送信者レポート（SR）内の数字とレシーバレポート（RR）RTCPパケットはうまく圧縮しないであろうが、ソース記述（SDES）パケットが存在していた各項目を示すビットマスクに圧縮なくて圧縮することができるテキスト情報（SDESメモ項目に目的のタイミングおよび間隔計算の平均RTCPパケットサイズを測定するために、エンドシステムを可能にするため）。
However, in the compression scheme defined here, no compression will be done on the RTCP headers and "data" for several reasons (though compression SHOULD still be applied to the IP and UDP headers). Since the RTP protocol specification suggests that the RTCP packet interval be scaled so that the aggregate RTCP bandwidth used by all participants in a session will be no more than 5% of the session bandwidth, there is not much to be gained from RTCP compression. Compressing out the SDES items would require a significant increase in the shared state that must be stored for each context ID. And, in order to allow compression when SDES information for several sources was sent through an RTP "mixer", it would be necessary to maintain a separate RTCP session context for each SSRC identifier. In a session with more than 255 participants, this would cause perfect thrashing of the context cache even when only one participant was sending data.
（圧縮はまだIPおよびUDPヘッダーに適用されるべきであるが）しかし、ここで定義された圧縮方式では、圧縮はいくつかの理由から、RTCPヘッダおよび「データ」には行われません。 RTPプロトコル仕様は、セッションのすべての参加者によって使用される骨材RTCP帯域幅がセッション帯域幅の5％以下となるようにRTCPパケット間隔がスケーリングされることを示唆しているので、RTCP圧縮から得られることが多くはありません。 SDESアイテムを圧縮して各コンテキストIDに格納しなければならない共有状態の有意な増加を必要とするであろう。そして、いくつかのソースのSDES情報がRTP「ミキサー」を介して送信された圧縮を可能にするためには、各SSRC識別子のための別個のRTCPセッションコンテキストを維持することが必要であろう。 255人のを超える参加者とのセッションでは、これは1人の参加者だけがデータを送信してもコンテキストキャッシュの完璧なスラッシングを引き起こします。
Even though RTCP is not compressed, the fraction of the total bandwidth occupied by RTCP packets on the compressed link remains no more than 5% in most cases, assuming that the RTCP packets are sent as COMPRESSED_UDP packets. Given that the uncompressed RTCP traffic consumes no more than 5% of the total session bandwidth, then for a typical RTCP packet length of 90 bytes, the portion of the compressed bandwidth used by RTCP will be no more than 5% if the size of the payload in RTP data packets is at least 108 bytes. If the size of the RTP data payload is smaller, the fraction will increase, but is still less than 7% for a payload size of 37 bytes. For large data payloads, the compressed RTCP fraction is less than the uncompressed RTCP fraction (for example, 4% at 1000 bytes).
RTCPが圧縮されていないにもかかわらず、圧縮されたリンク上のRTCPパケットによって占有される総帯域幅の割合は、RTCPパケットがCOMPRESSED_UDPパケットとして送信されていると仮定し、ほとんどの場合、5％以下のまま。の大きさならば、非圧縮RTCPトラフィックは総セッション帯域幅の5％以下を消費することを考慮すると、その後、90バイトの典型的なRTCPパケット長に対して、RTCPによって使用される圧縮された帯域幅の一部は5％以下であろうRTPデータパケット内のペイロードは、少なくとも108バイトです。 RTPデータペイロードのサイズが小さい場合、画分は増加するが、37バイトのペイロードサイズに依然として7％未満であろう。大きなデータペイロードのために、圧縮されたRTCP画分は、非圧縮RTCP分率未満である（例えば、1000バイトに4％）。
As described earlier, the COMPRESSED_UDP packet MAY be used to compress UDP packets that don't carry RTP. Whatever data follows the UDP header is unlikely to have some constant values in the bits that correspond to usually constant fields in the RTP header. In particular, the SSRC field would likely change. Therefore, it is necessary to keep track of the non-RTP UDP packet streams to avoid using up all the context slots as the "SSRC field" changes (since that field is part of what identifies a particular RTP context). Those streams may each be given a context, but the encoder would set a flag in the context to indicate that the changing SSRC field should be ignored and COMPRESSED_UDP packets should always be sent instead of COMPRESSED_RTP packets.
前述したように、COMPRESSED_UDPパケットは、RTPを運ばないUDPパケットを圧縮するために使用されるかもしれません。どのようなデータは、UDPヘッダはRTPヘッダ内の通常一定のフィールドに対応するビット数である定数値を有するにくい以下。具体的には、SSRCフィールドはおそらく変化するであろう。したがって、（そのフィールドは、特定のRTPコンテキストを識別するものの一部であるため）「SSRCフィールド」変化としてすべてのコンテキストスロットを使用しないように、非RTP UDPパケットストリームを追跡する必要があります。これらのストリームは、各コンテキストが与えられてもよいが、エンコーダは、変化SSRCフィールドは無視されるべきであり、COMPRESSED_UDPパケットは常にCOMPRESSED_RTPパケットの代わりに送信されるべきであることを示すために、コンテキストにフラグを設定することになります。
A segmentation scheme may be used in conjunction with RTP header compression to allow small, real-time packets to interrupt large, presumably non-real-time packets in order to reduce delay. It is assumed that the large packets bypass the compressor and decompressor since the interleaving would modify the sequencing of packets at the decompressor and cause the appearance of errors. Header compression should be less important for large packets since the overhead ratio is smaller.
セグメンテーションスキームは小さな、リアルタイムパケット遅延を低減するために大規模な、おそらく非リアルタイムパケットを中断することを可能にするためにRTPヘッダ圧縮と組み合わせて使用することができます。インターリービングが減圧装置でパケットの順序を変更し、エラーの出現を引き起こすので、大きなパケットは、圧縮装置と解凍をバイパスすることが想定されます。ヘッダ圧縮は、オーバーヘッド比率が小さいため、大きなパケットにはあまり重要であるべきです。
If some packets from an RTP session context are selected for segmentation (perhaps based on size) and some are not, there is a possibility of re-ordering. This would reduce the compression efficiency because the large packets would appear as lost packets in the sequence space. However, this should not cause more serious problems because the RTP sequence numbers should be reconstructed correctly and will allow the application to correct the ordering.
RTPセッションコンテキストからいくつかのパケットをセグメント化するために選択された（おそらくサイズに基づいて）、一部ではないれている場合、再順序付けの可能性があります。大きなパケットがシーケンス空間で失われたパケットとして現れるので、これは圧縮効率を低減するであろう。 RTPシーケンス番号を正しく再構築する必要があり、アプリケーションが順序を修正することができますので、しかし、これはより深刻な問題が発生することはありません。
Link errors detected by the segmentation scheme using its own sequencing information MAY be indicated to the compressor with an advisory CONTEXT_STATE message just as for link errors detected by the link layer itself.
独自のシーケンシング情報を使用してセグメント化方式によって検出されたリンクエラーは単にリンク層自体によって検出されたリンクエラーのようなアドバイザリーCONTEXT_STATEメッセージで圧縮機に示すことができます。
The context ID byte is placed first in the COMPRESSED_RTP header so that this byte MAY be shared with the segmentation layer if such sharing is feasible and has been negotiated. Since the compressor may assign context ID values arbitrarily, the value can be set to match the context identifier from the segmentation layer.
このような共有が可能であるとネゴシエートされた場合、このバイトはセグメント化層と共有することができるように、コンテキストIDバイトはCOMPRESSED_RTPヘッダに最初に配置されています。圧縮機は、任意のコンテキストID値を割り当てることができるので、値は、セグメント化層からのコンテキスト識別子に一致するように設定することができます。
The use of IP/UDP/RTP compression over a particular link is a function of the link-layer protocol. It is expected that such negotiation will be defined separately for PPP [4], for example. The following items MAY be negotiated:
特定のリンク上のIP / UDP / RTP圧縮を使用することは、リンク層プロトコルの関数です。このような交渉は、例えば、PPP [4]のために個別に定義されることが期待されます。以下の項目は、交渉されることがあります。
o The size of the context ID. o The maximum size of the stack of headers in the context. o A context-specific table for decoding of delta values.
コンテキストIDのサイズO。コンテキストにおけるヘッダのスタックの最大サイズO。デルタ値の復号化のためのOコンテキスト固有のテーブル。
Several people have contributed to the design of this compression scheme and related problems. Scott Petrack initiated discussion of RTP header compression in the AVT working group at Los Angeles in March, 1996. Carsten Bormann has developed an overall architecture for compression in combination with traffic control across a low-speed link, and made several specific contributions to the scheme described here. David Oran independently developed a note based on similar ideas, and suggested the use of PPP Multilink protocol for segmentation. Mikael Degermark has contributed advice on integration of this compression scheme with the IPv6 compression framework.
いくつかの人々は、この圧縮方式と関連する問題の設計に貢献しました。スコット2000 Petrackと3月にロサンゼルスでAVTワーキンググループでRTPヘッダー圧縮の議論を開始し、1996年カルステンボルマンは、低速リンクを介してトラフィック制御と組み合わせて圧縮のための全体的なアーキテクチャを開発し、スキームには、いくつかの具体的な貢献をしてきましたここで説明します。デビッド・オランは独立して同様の考え方に基づいてノートを開発し、セグメンテーションのためのPPPマルチリンクプロトコルの使用を示唆しました。ミカエルDegermarkは、IPv6圧縮フレームワークと、この圧縮方式の統合に関するアドバイスを貢献してきました。
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for real-time applications", RFC 1889, January 1996.
[1] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[2] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links", RFC 1144, February 1990.
[2]ジェーコブソン、V.、 "TCP / IP圧縮低速シリアルリンクの"、RFC 1144、1990年2月。
[3] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for IPv6", RFC 2507, February 1999.
[3] Degermark、M.、Nordgren、B.及びS.ピンク、 "IPv6のヘッダ圧縮"、RFC 2507、1999年2月。
[4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[4]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[5] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[5]ホフマン、D.、フェルナンド、G.、Goyal氏、V.とM. Civanlar、 "MPEG1 / MPEG2ビデオのためのRTPペイロードフォーマット"、RFC 2250、1998年1月。
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. That would allow compression to still be applied.
暗号化は、この圧縮方式を活用しようとすると、冗長性を排除しているため、低帯域幅リンク上での動作を実現するために暗号化を見送るためにいくつかの誘因があります。しかし、データはなく、ヘッダの暗号化が十分であるような場合のために、RTPは、RTPペイロードが暗号化され、ヘッダは平文で放置された別の暗号化方式を指定しません。これは圧縮がまだ適用することが可能となります。
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 [3].
誤動作や悪意のあるコンプレッサーは、デコンプレッサは、元のパケットに一致するが、まだ有効なIP、UDPおよびRTPヘッダーや可能性も有効なUDPのチェックサムを持っていないパケットを再構成する可能性があります。そのような破損は、圧縮によって影響されないエンドツーエンド認証および完全性機構を用いて検出することができます。 [3]に記載されているように、認証ヘッダの一定部分が圧縮されます。
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制御パケットに対して実行されません。デコンプレッサと、コンプレッサとの間のリンクにアクセスできる攻撃者は、偽のCONTEXT_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.
不均一受信エンド計算負荷を有する圧縮技術を使用するときに潜在的なサービス拒否の脅威が存在します。攻撃者は、他のストリームのオーバーロードされる受信機と分解処理を解凍し、原因が複雑であるストリームに病理学的データグラムを注入することができます。しかし、この圧縮は、有意な不均一性を示しません。
A security review of this protocol found no additional security considerations.
このプロトコルのセキュリティレビューには、追加のセキュリティ上の考慮事項は認められませんでした。
Stephen L. Casner Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 United States
スティーブンL. Casnerシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706米国
EMail: casner@cisco.com
メールアドレス：casner@cisco.com
Van Jacobson Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 United States
ヴァンヤコブソンシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706米国
EMail: van@cisco.com
メールアドレス：van@cisco.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。