[要約] 要約： RFC 2508は、低速シリアルリンクでのIP/UDP/RTPヘッダーの圧縮に関する標準化された手法を提供しています。このRFCの目的は、ネットワークトラフィックの効率を向上させ、低速シリアルリンク上での通信の品質を向上させることです。
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
低速シリアルリンク用のIP/UDP/RTPヘッダーの圧縮
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.
Copyright（c）The Internet Society（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).
コメントが求められており、ワーキンググループメーリングリストremconf@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.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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]として公開されて以来、ネットワークオーディオ/ビデオアプリケーションのさまざまな実装間で相互運用性を実現するための1つのステップとしてRTPを使用することに関心が高まっています。ただし、12バイトのRTPヘッダーは、14.4または28.8 kb/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バイトの組み合わせヘッダーを圧縮することで、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、またはパケットで使用できる圧縮スキームを定義しますが、最初の焦点はIPv4に焦点を当てています。ここで定義されているIP/UDP/RTP圧縮は、IPv6とIPv4の両方で使用するために[3]で指定されたより一般的な圧縮フレームワーク内に適合することを目的としています。このフレームワークでは、TCPと非TCPをIPを超える2つのクラスのトランスポートとして定義しています。この仕様は、非TCPクラスから抽出された3番目のクラスとして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バイトの場合、ほとんどのパケットのIP/UDP/RTPヘッダーを2バイトに減らすことです。これは、主に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
実装の単純さは、圧縮スキームの評価において考慮すべき重要な要素であることに注意する必要があります。通信サーバーは、単一のプロセッサを使用して、おそらく最大100個のダイヤルアップモデムラインで圧縮をサポートする必要がある場合があります。したがって、一般性を犠牲にしてデザインを単純化するか、一般的な柔軟なデザインを作成することが適切であるかもしれませんが、簡単にするためにサブセットされます。より複雑な通信をすることで、より高い圧縮ゲインが達成される可能性があります
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.
変化するヘッダーフィールドのモデルは、コンプレッサーから減圧装置までですが、その複雑さは不要であると見なされます。次のセクションでは、ここにリストされているトレードオフのいくつかについて説明します。
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.
他の制約がない場合、シンプレックスリンクで動作する圧縮スキームは、そうでないリンクよりも好まれます。ただし、シンプレックスリンク上の動作には、エラーの場合に圧縮状態を復元するために、圧縮されていないパケットヘッダーを備えた定期的な更新が必要です。代わりに明示的なエラー信号を返すことができる場合、回復の遅延が大幅に短縮される場合があります。ノーエラーケースのオーバーヘッドも削減されます。これらのパフォーマンスの改善を得るために、この仕様には、逆パスで送信された明示的なエラー表示が含まれます。
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で説明されている定期的な更新方法は、シンプレックスリンクまたは高い遅延を備えたリンク上のIP/UDP/RTP圧縮、および他の非TCPパケットストリームに適用されます。
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.
この仕様は圧縮のみを扱い、セグメンテーションが含まれている場合、別のレイヤーとして処理されると想定します。セグメンテーションが不必要または非実用的であると見なされた状況では、セグメンテーションと圧縮を統合することは不適切です。同様に、予約プロトコルの要件を回避したいと思います。圧縮スキームは、リンクレイヤーがパケットタイプのコード、パケットの長さの表示、および良好なエラー検出を提供する要件を除き、他のメカニズムとは無関係にリンクの両端にローカルに適用できます。
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 [2]で説明されているように、TCP/IPヘッダー圧縮の設計に大きく描かれています。根本的な動機とヘッダー圧縮の一般原則の詳細については、読者はその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ヘッダー圧縮では、データレートの2つの因子の減少は、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次の差はゼロであるという観察からもたらされます。圧縮されていないヘッダーとコンプレッサーと減圧装置の間で共有されるセッション状態の1次の違いの両方を維持することにより、通信する必要があるのは、2次の差がゼロであったことを示しています。その場合、減圧装置は、各圧縮パケットを受信するときに保存された非圧縮ヘッダーに1次の違いを追加するだけで、情報を損なうことなく元のヘッダーを再構築できます。
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パケットとして送信してはなりません。さらに、RTPコンテキストを確立するために、少なくとも12バイトのUDPデータを追加しないパケットを使用してはなりません。このようなパケットが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]）、ヘッダーチェックサムも排除できます。これにより、パケットIDのみが残ります。これは、IPの断片化がないと仮定すると、通信する必要がないと仮定します。ただし、ロスレス圧縮を維持するために、パケット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識別子は特定のコンテキストで一定です。ほとんどのパケットでは、シーケンス番号とタイムスタンプのみがパケットからパケットに変更されます。パケットがコンプレッサーから上流に紛失したり、上流に誤って並んでいない場合、シーケンス番号はパケットごとに1つずつ増加します。一定期間のオーディオパケットの場合、タイムスタンプは各パケットで伝えられるサンプル期間の数だけ増加します。ビデオの場合、タイムスタンプは各フレームの最初のパケットで変更されますが、フレーム内の追加のパケットに対して一定のままにします。各ビデオフレームが1つのパケットのみを占有しているが、ビデオフレームが一定の速度で生成される場合、フレームからフレームへのタイムスタンプの変更は一定です。これらの各ケースでは、シーケンス番号とタイムスタンプフィールドの2次の差がゼロであるため、次のパケットヘッダーは、これらのフィールドに保存されているこれらのフィールドの1次差を追加することにより、以前のパケットヘッダーから構築できることに注意してください。セッションコンテキストと以前の非圧縮ヘッダー。 2次の差がゼロでない場合、変化の大きさは通常、フィールド内のビット数よりもはるかに少ないため、新しい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ビットは、オーディオTalkspurtの最初のパケットとビデオフレームの最後のパケットに設定されます。各変更が完全な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リストは通常、Talkspurt以上の間は一定のままであるため、変更された場合にのみ送信する必要があります。
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
圧縮プロトコルは、コンプレッサーと減圧器の間の一貫した状態で共有情報のコレクションを維持する必要があります。IPソースと宛先アドレス、UDPソース、および宛先の特定の組み合わせによって定義される、各IP/UDP/RTPパケットストリームには別のセッションコンテキストがあります。
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.
ポート、およびRTP SSRCフィールド。維持されるセッションコンテキストの数は、コンプレッサーと減圧器の間で交渉することができます。各コンテキストは、交渉されたコンテキストの数に応じて8ビットまたは16ビットの識別子によって識別されるため、最大数は65536です。コンプレッサーと減圧器間の損失。各コンテキストには独自のシーケンス番号スペースがあり、単一のパケット損失が1つのコンテキストを無効にする必要があります。
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.
o コンプレッサーによって送信される最後のパケットまたは減圧器によって再構築されたフルIP、UDP、およびRTPヘッダー。
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.
o IPv4 IDフィールドの1次の違いは、このコンテキストの非圧縮IPヘッダーが受信および更新されるたびに1に初期化され、DELTA IPv4 IDフィールドを圧縮パケットで受信するたびに更新されます。
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.
o RTPタイムスタンプフィールドの1次の違いは、このコンテキストの非圧縮パケットが受信され、デルタRTPタイムスタンプフィールドが圧縮パケットで受信されるたびに0に初期化されます。
o The last value of the 4-bit sequence number, which is used to detect packet loss between the compressor and decompressor.
o コンプレッサーと分解器間のパケット損失を検出するために使用される4ビットシーケンス番号の最後の値。
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.
o IPv6を使用したUDPパケットの非差的コーディングの現在の生成数（[3]を参照）。IPv4の場合、以下に定義されているCompressed_Non_TCPパケットタイプが使用されない場合、生成数をゼロに設定できます。
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
FULL_HEADER-非圧縮IPヘッダーと次のヘッダーとデータを伝えて、特定のコンテキストの減圧器内の非圧縮ヘッダー状態を確立します。フルヘッドパケットには、8ビットまたは16ビットのセッションコンテキスト識別子と4ビットシーケンス番号も搭載して、確立します
synchronization between the compressor and decompressor. The format is shown in section 3.3.1.
コンプレッサーと減圧器間の同期。形式はセクション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-圧縮されたIPおよびUDPヘッダーは、6バイト以下に圧縮されています（UDPチェックサムが無効になっている場合は2）、その後のヘッダー（おそらくRTP）と非圧縮形式のヘッダーとデータが続きます。このパケットタイプは、（電位）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バイトである場合があります。このパケットタイプは、2次の違い（少なくとも通常一定のフィールドで）がゼロの場合に使用されます。これには、非圧縮RTPヘッダーが送信された後、変更されるたびに1次の違いを確立するために、予想される金額以外に変更されたフィールドのデルタエンコーディングが含まれています。形式はセクション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に使用された場合、IPv4IDフィールドを運ぶために、上記の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の場合、これは通常IPヘッダーであり、続いてRTPヘッダーとそのペイロードであるUDPヘッダーとUDPペイロードが続きます。ただし、Full_headerパケットには、IPカプセル化されたパケットも搭載される場合があります。その場合、2つのIPヘッダーに続いてUDPと場合によってはRTPが続きます。または、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.
FULL_HEADERパケットは、対応する通常のIPv4またはIPv6パケットとは異なります。これは、圧縮コンテキストIDと4ビットシーケンス番号も搭載する必要があるからです。ヘッダーのサイズが拡大しないようにするために、実際の長さはリンクレイヤーによって提供される長さから推測される可能性があるため、これらの値はIPおよびUDPヘッダーの長さフィールドに挿入されます。2つの16ビットの長さフィールドが必要です。これらは、パケット内の最初の2つの利用可能なヘッダーから取得されます。つまり、IPv4/UDPパケットの場合、最初の長さフィールドはIPv4ヘッダーの総長さフィールドで、2番目は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.
最初の長さフィールドの最初のビットは、CIDの長さを示します。CIDの長さは、すべてのコンテキストに対して一定でなければなりません。または、8ビットおよび16ビットCIDを備えたCompressed_UDPおよびCompressed_RTPパケット形式を個別に示すために、2つの追加の異なるパケットタイプを提供する必要があります。最初の長さフィールドの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の間の一貫した動作の場合、生成値はDecompressorによって受信されるとコンテキストに保存され、最新の値は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ビットシーケンス番号がそのパケットの「データフィールド」に挿入され、Dビットが[3]のセクション6で説明されているように設定されます。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ヘッダーのパケットからパケットへの2次の違いがゼロの場合、減圧装置は、以前のパケットを表す保存された非圧縮ヘッダーに保存された1次差を追加するだけでパケットを再構築できます。通信する必要があるのは、セッションコンテキスト識別子と小さなシーケンス番号（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ヘッダーの2次差がゼロでない場合、これらのフィールドのみの新しい1次の差は、コンパクトエンコードを使用して通信されます。新しい1次差値は、Decompressorのセッションコンテキストの非圧縮ヘッダーの対応するフィールドに追加され、2次の違いが次の各パケットで再び対応するフィールドに再び追加されるコンテキストに明示的に保存されます。ゼロです。一次差が変わるたびに、コンテキストに送信され、保存されます。
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.
実際には、1次の違いを保存することが役立つ唯一のフィールドは、IPv4 IDフィールドとRTPタイムスタンプです。RTPシーケンス番号フィールドの場合、通常の増分は1です。シーケンス番号が1以外に変更された場合、差は通信する必要がありますが、次のパケットの予想される差は設定されません。代わりに、予想される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.
RTPタイムスタンプの場合、full_header、Compressed_non_tcp、またはCompressed_udpパケットがRTP状態を更新するために送信されると、保存された1次差はゼロに初期化されます。タイムスタンプが次のパケット（例：同じビデオフレーム）で同じ場合、2次の違いはゼロです。それ以外の場合、2つのパケットのタイムスタンプ間の違いは、減圧器のコンテキストに保存されている非圧縮ヘッダーのタイムスタンプに追加される新しい1次の違いとして送信され、そのコンテキストの1次の違いとして保存されます。後続のパケットで1次の違いが変化するたびに、その差は再び送信され、コンテキストの更新に使用されます。
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.
同様に、IPv4 IDフィールドは頻繁に1つずつ増加するため、そのフィールドの1次の差は、状態がFull_headerパケットによって更新されたとき、またはCompressed_non_tcpパケットが[圧縮]フォームでIDフィールドを運ぶため送信されるときに1つに初期化されます。。その後、一次差が変化するたびに、コンテキストに送信され、保存されます。
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ヘッダーの場合は0）
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、RTPマーカービット、RTPシーケンス番号、RTPタイムスタンプの4つのビットすべてが設定されている場合、これは圧縮されたRTPヘッダーの拡張形式を示す特別なケースです。そのヘッダーには、4ビットの実際の値とCCカウントを含む追加のバイトが含まれます。CCカウントで示される長さのCSRCリストは、非圧縮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識別子は、コンテキストを選択する要因の1つであるため、特定のコンテキストで一定であると定義されます。他のフィールドのいずれかが変更された場合、非圧縮RTPヘッダーはセクション3.3.3で説明されているように送信する必要があります。
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ヘッダーを示しており、条件付きで存在するフィールドを示す点線の線を示しています。最も重要なビットには番号が付けられています。マルチバイトフィールドはネットワークバイトの順序で送信されます（最初に最も重要なバイト）。Deltaフィールドは、多くの場合、図のように単一のバイトですが、セクション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]。これらのフィールドは、「ランダム」フィールドとして識別されます。図に示すように、UDPチェックサムの直後に元のヘッダーに表示されるのと同じ順序で、元のヘッダーに表示されるのと同じ順序で挿入されます。UDPヘッダーの直前のIPv4パケットがそのヘッダーのIP IDが差別的に送信される場合、つまり、2番目の差がゼロの場合はビットなし、またはそうでない場合はDelta IPv4 IDフィールドとして潜在的にビットなしで送信されます。UDPヘッダーの直前のIPv4ヘッダーがない場合、iビットは0でなければならず、Delta 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ヘッダーは、Full_headerパケットではなくCompressed_udpパケットで運ばれる場合があります。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
これは、[3]で定義されているCompressed_non_tcpパケットタイプとは異なるIP/UDPヘッダー圧縮の形式を構成することに注意してください。IPv4で許可されているように、UDPチェックサムが無効になっているときに、2バイトのターゲットに到達することを可能にすることです。[3]のプロトコルは、UDPパケットの微分コーディングを使用していないため、IPv4ケースでは2つ
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.
IP IDのバイト、およびゼロ以外の場合の2バイトのUDPチェックサムは、2バイトの圧縮プレフィックスに加えて常に送信されます。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パケットのDeltaフィールドは、より一般的に使用される値をコンパクトにするための可変長マッピングでエンコードされています。デフォルトのエンコードは以下に指定されていますが、実装はテーブル駆動型のデルタエンコーダーとデコーダーを使用して、必要に応じて各セッションに固有のテーブルの交渉を許可することをお勧めします。ビットストリームのシーケンシャル解釈に基づいたエンコーディング。このデフォルトのテーブルとハフマンエンコードは、合理的なテーブルサイズを可能にし、値の範囲を明示的なテストを備えた非テーブル駆動型の実装よりも速く実行速度をもたらす可能性があります。
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:
デフォルトのデルタエンコードは、次の表に指定されています。このエンコードは、コンプレッサーからパケットが上流で失われたが、ほとんどのオーディオとビデオのデルタを2バイトで処理するときに、IP IDおよびRTPシーケンス番号で発生する可能性のある小さな変更を効率的にエンコードするように設計されています。左側の列はエンコードされる小数値であり、右側の列は、六分位で示されているバイトのシーケンスであり、それらが送信される順に表示されます（ネットワークバイトの順序）。各隣接範囲の最初と最後の値が表示され、その間に楕円があります。
Decimal Hex
小数十数頭
-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
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
正の値の場合、ゼロから127の変化は1つのバイトで直接表されます。バイトの最も重要な2ビットが10または11の場合、これは2バイトまたは3バイトの拡張を示します
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.
それぞれ価値。最初のバイトの最も重要な6ビットが組み合わされており、有意順位が減少し、次の1つまたは2バイトが14ビットまたは22ビットの値を形成します。
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.
ネガティブデルタは、パケットが誤用されている場合、またはMPEGビデオ[5]の意図的に外れた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).
RTPタイムスタンプ値の変更は、-16384未満または4194303を超える強制で、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.
特定のコンテキストの4ビットシーケンス番号が1以外の場合に1つ以外の増分を増やした場合、full_headerまたはCompressed_non_tcpパケットによって設定された場合を除き、減圧器はそのコンテキストを無効にし、コンテキストのパケットをコンプレッサーに送り返す必要があります。無効なコンテキストのすべてのパケットは、そのコンテキストのFull_headerまたはCompressed_non_tcpパケットが一貫した状態を再確立するまで受信するまで破棄する必要があります（「2回」アルゴリズムがこのセクションで説明されているように使用されない限り）。複数の圧縮パケットが暫定的に到着する可能性があるため、減圧装置は受信したすべての圧縮パケットの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
リンクでエラーが発生すると、リンクレイヤーは通常、損傷したパケット（ある場合）を破棄しますが、エラーの兆候を提供する場合があります。同じコンテキストで別のパケットが配信されるまでには時間がかかる場合があります。その後、そのパケットは、シーケンスが外れていることが観察されると、減圧器によって破棄され、少なくとも2つのパケットが失われます。リンクが明示的なエラー表示を提供する場合、より速い回復を可能にするために、減圧装置はオプションで、1つ以上のアクティブコンテキスト（必ずしもすべてではない）の最後の有効なシーケンス番号と生成番号をリストするアドバイザリーContext_Stateパケットを送信することができます。特定のコンテキストでは、コンプレッサーがより高いシーケンス番号を持つ圧縮パケットを送信していない場合、および生成数が現在の世代と一致する場合、修正アクションは必要ありません。それ以外の場合、コンプレッサーは、次のパケットがfull_headerまたはCompressed_non_tcpモード（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.
世代が一致しない場合は必要です）。ただし、リンクの往復時間がパケット間間隔に比べて大きい場合、リンクを横切るフライト中の複数のコンテキストからいくつかのパケットがある可能性があることに注意してください。パケットはコンプレッサーによって受信されます。その結果、一部のコンテキストが不必要に無効になり、余分な帯域幅が消費される可能性があります。
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パケットの形式は、次の図に示されています。最初のバイトは、[3]で指定された一般的な圧縮フレームワーク内の重圧縮スキームによってContext_Stateパケットタイプを共有できるようにするタイプコードです。パケットの残りの部分の内容は、圧縮スキームによって異なります。ここで指定されている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圧縮スキームには、2つのタイプコード値が使用されます。値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つ以上のブロックの再送信が許可されています。再送信は別のパケットを受け取ることによってのみトリガーされることが予想されますが、ラインが近くアイドル状態にある場合、再送信は比較的長いタイマーによってトリガーされる可能性があります（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
UDPチェックサムが送信されている場合、減圧装置は[3]のセクション10.1で説明されている「2回」アルゴリズムを使用しようとする場合があります。このアルゴリズムでは、デルタは、Deltaが欠落しているパケットとその後受信したパケットで同じである可能性があると仮定して、複数回適用されます。成功はです
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.
チェックサムの一致で示されています。ここで定義されているスキームの場合、4ビットシーケンス番号の違いは、デルタを適用する必要がある回数を示します。ただし、誤った肯定的な兆候のわずかなリスクがあることに注意してください。「2回」アルゴリズムが成功した場合でも、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チェックサムが送信されている場合、受信者はおそらく無効なパケットを検出して破棄しますが、受信機には減圧装置に信号を送信する手段がありません。したがって、減圧装置はUDPチェックサムを定期的に検証することをお勧めします。おそらく16個のパケットのうち1つです。エラーが検出された場合、減圧器はコンテキストを無効にし、コンプレッサーを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).
RTP規則に依存することにより、データは均等なポート番号に搭載されており、対応するRTCPパケットが次の（奇数）ポート番号に搭載されているため、RTPおよびRTCPパケットに適用される個別の圧縮スキームを調整できます。RTCPの場合、圧縮はヘッダーだけでなく、「データ」、つまり異なるパケットタイプの内容にも適用できます。Sender Report（SR）およびReceiver Report（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.
ただし、ここで定義されている圧縮スキームでは、いくつかの理由でRTCPヘッダーと「データ」で圧縮は行われません（ただし、圧縮はIPおよびUDPヘッダーにまだ適用する必要があります）。RTPプロトコルの仕様は、RTCPパケット間隔をスケーリングして、セッションですべての参加者が使用する集計RTCP帯域幅がセッション帯域幅の5％以下になることを示唆しているため、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％以下を消費することを考えると、典型的なRTCPパケット長は90バイトの場合、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フィールドは変化する可能性があります。したがって、「SSRCフィールド」が変更されるにつれてすべてのコンテキストスロットを使用しないように、非RTP UDPパケットストリームを追跡する必要があります（そのフィールドは特定のRTPコンテキストを識別するものの一部であるため）。これらのストリームにはそれぞれコンテキストが与えられる場合がありますが、エンコーダーはコンテキストにフラグを設定して、変化するSSRCフィールドを無視し、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.
独自のシーケンス情報を使用してセグメンテーションスキームによって検出されたリンクエラーは、リンクレイヤー自体によって検出されたリンクエラーと同様に、アドバイザリーコンテキスト_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.
o コンテキストIDのサイズ。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.
この圧縮スキームと関連する問題の設計に何人かの人々が貢献しています。Scott Petrackは、1996年3月にロサンゼルスのAVTワーキンググループでのRTPヘッダー圧縮の議論を開始しました。CarstenBormannは、低速リンク全体で交通制御と組み合わせて圧縮するための全体的なアーキテクチャを開発し、スキームにいくつかの具体的な貢献をしました。ここで説明します。David Oranは、同様のアイデアに基づいて独立してメモを開発し、セグメンテーションにPPPマルチリンクプロトコルの使用を提案しました。Mikael Degermarkは、この圧縮スキームのIPv6圧縮フレームワークの統合に関するアドバイスを提供しました。
7. References:
7. 参考文献：
[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.、Frederick、R。and V. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 1889、1996年1月。
[2] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links", RFC 1144, February 1990.
[2] Jacobson、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. Pink、「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] Hoffman、D.、Fernando、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コントロールパケットでは、認証は実行されません。減圧器とコンプレッサーの間のリンクにアクセスできる攻撃者は、誤ったコンテキスト_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
Stephen L. Casner Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134-1706米国
EMail: casner@cisco.com
Van Jacobson Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 United States
Van Jacobson Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134-1706米国
EMail: van@cisco.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。