RFC2508 日本語訳
2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. S.Casner, V. Jacobson. February 1999. (Format: TXT=60474 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Casner
Request for Comments: 2508 Cisco Systems
Category: Standards Track V. Jacobson
Cisco Systems
February 1999
Casnerがコメントのために要求するワーキンググループS.をネットワークでつないでください: 2508年のシスコシステムズカテゴリ: 標準化過程V.ジェーコブソンシスコシステムズ1999年2月
Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮します。
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
1. Introduction
1. 序論
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.)
レアル-時間TransportプロトコルがRFC[1]として発表されたので、ネットワークオーディオ/ビデオアプリケーションの異なった実現の中で相互運用性を達成するのにワンステップとしてRTPを使用することへの増加している関心がありました。 しかしながら、14.4か28.8kb/sのダイヤルアップモデムなどの低速線で作動するとき、12バイトのRTPヘッダーが20バイトのペイロードのための大き過ぎるオーバーヘッドであるという関心もあります。 (この環境で作動するいくつかの既存のアプリケーションがRTPに比例して機能性を減らした数バイトのヘッダーとのアプリケーション特有のプロトコルを使用します。)
Casner & Jacobson Standards Track [Page 1] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[1ページ]RFC2508
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バイトを圧縮するより実質的に多くの利得(2-4バイト)がどちらのケースにも供給されます。 また、遅れと損失率が低いので、リンクごとのベースでの圧縮は、より良い性能を提供します。 したがって、ここで定義された方法は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.
このドキュメントは1個以上のIPヘッダーと共にカプセルに入れられたIPv4、IPv6またはパケットと共に使用されるかもしれない圧縮技術を定義します、初期の焦点がIPv4にありますが。 ここで定義されたIP/UDP/RTP圧縮が使用のための[3]でIPv6とIPv4の両方で指定されたより一般的な圧縮枠組みの中で合うことを意図します。 その枠組みはIPの上でTCPと非TCPを2つのクラスの輸送と定義します。 この仕様は非TCPのクラスから抽出された3番目のクラスとしてIP/UDP/RTPを作成します。
2. Assumptions and Tradeoffs
2. 仮定と見返り
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チェックサムを全く送らないか、またはオーディオとビデオに14.4以上を送るという主として特定の問題でチェックサムそれがある4バイトを動機づける場合におけるほとんどのパケットと28.8個のダイアルアップモデムのためにIP/UDP/RTPヘッダーを2バイトまで減少させることです。これらのリンクが、全二重通信を提供する傾向があるので、プロトコルはその事実を利用します、また、プロトコルがシンプレクスリンクに関する減少している性能と共に使用されるかもしれませんが。 この圧縮技術は低往復の時間との地方のリンクの上によく振る舞います。
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のダイヤルアップモデム回線の上の圧縮を支持する必要があるかもしれません。 したがって、一般性を犠牲にしてデザインにおけるいくつかの簡素化をするか、または一般的ですが、簡単さのためにsubsettedされることができるフレキシブルなデザインを生産するのが適切であるかもしれません。 より高い圧縮利得は、交信することによって、より複雑な状態で獲得されるかもしれません。
Casner & Jacobson Standards Track [Page 2] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[2ページ]RFC2508
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.
変化ヘッダーフィールドのために、複雑さが不要であることは考えられていなかったなら、コンプレッサーから減圧装置までモデル化します。 次のセクションはここに記載された見返りのいくつかについて論じます。
2.1. Simplex vs. Full Duplex
2.1. シンプレクス対全二重
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.
シンプレクスリンクでは、周期的にaを使用するのが代わりにリフレッシュするのは、可能でしょう。 減圧装置が特定のパケットの流れで誤りを検出したときはいつも、それは、その流れで単にすべてのパケットをその流れのために解凍されたヘッダーを受け取るまで捨てて、次に、減圧を再開するでしょう。 刑罰は捨てられた多くのパケットでしょう。 周期的は[3]のセクション3.3で説明された方法をリフレッシュします。また、高い遅れとのシンプレクスリンクかリンクで他の非TCPパケットの流れに関してIP/UDP/RTP圧縮に適用します。
2.2. Segmentation and Layering
2.2. 分割とレイヤリング
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つは予約プロトコルのためのどんな要件も避けたがっています。 リンクレイヤがいくつかのパケットタイプコード、パケット長指示、および良い誤りに検出を提供するという要件以外のいかなる他のメカニズムの如何にかかわらず局所的にリンクの2つの端に圧縮技術を付けることができます。
Casner & Jacobson Standards Track [Page 3] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[3ページ]RFC2508
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層を圧縮すると、それらを一緒に扱うことによって可能な圧縮利得のあまりに多くが損をします。 同じ機能がすべての層の向こう側に適用されているので、これらのプロトコル層境界に交差するのは適切です。
3. The Compression Algorithm
3. 圧縮アルゴリズム
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.
本書では定義された圧縮アルゴリズムはRFC1144[2]で説明されるように大いにTCP/IPヘッダー圧縮のデザインを利用します。 読者はヘッダー圧縮の基本的な動機と綱領に関する詳しい情報についてそのRFCを参照されます。
3.1. The basic idea
3.1. 基本的な考え方
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番目のオーダー差がゼロであるという観測から来ます。 セッション状態の解凍されたヘッダーと一次違いの両方がコンプレッサーと減圧装置を平等に割り当てたと主張することによって、伝えなければならないすべてが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圧縮SHOULDは複数のセッション文脈のために状態を維持します。 セッション文脈はIPソースと送付先アドレス、UDPソース、および仕向港の組み合わせ、およびRTP SSRC分野によって定義されます。 コンプレッサー実現は、格納されたセッション文脈のテーブルに索引をつけるのにこれらのフィールドのハッシュ関数を使用するかもしれません。 圧縮されたパケットは、そのパケットがどのセッション文脈で解釈されるべきであるかを示すためにセッション文脈の識別子かCIDと呼ばれるわずかな整数を運びます。 減圧装置は、直接格納されたセッション文脈のテーブルに索引をつけるのにCIDを使用できます。
Casner & Jacobson Standards Track [Page 4] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[4ページ]RFC2508
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圧縮がlosslessであるので、それはそれの利益を得るどんな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分野SHOULDが絶えず変化していた状態で、パケットの流れです。 後者が変化しているかもしれないので、否定的キャッシュはRTP SSRC分野ではなく、ソース、送付先IPアドレス、およびUDPポート組によって索引をつけられます。 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.
FULL_HEADERパケットとして初期の断片でない断片化しているIP Packetsと完全なUDPヘッダーを含むことができるくらいには長くないパケットを送ってはいけません。 その上、RTP文脈を証明するのにさらに、少なくとも12バイトのUDPデータを含まないパケットを使用してはいけません。 FULL_HEADERパケットとしてそのようなパケットを送るなら、それのCOMPRESSED_UDPパケットがあとに続くかもしれませんが、COMPRESSED_RTPパケットはあとに続いてはいけません。
3.2. Header Compression for RTP Data Packets
3.2. 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、およびヘッダーチェックサム分野だけが変化するでしょう。 全長はリンクレイヤのそばで長さを提供していて余分です、そして、CRC[4])、この圧縮技術が良い誤り検出(を例えば、PPP提供するためにリンクレイヤによらなければならないので、また、ヘッダーチェックサムは削除されるかもしれません。 これはパケットIDだけを残します。(IP断片化を全く仮定しない場合、それはコミュニケートする必要はないでしょう)。 しかしながら、可逆圧縮を維持するために、パケットIDにおける変化は伝えられるでしょう。 通常、IDが1つ増加するパケットかそれぞれのパケットの少ない数。 (いくつかのシステムがバイトが交換されているIDを増加します。)(IDは、より少ない圧縮をわずかにもたらします)。 IPv6ベースヘッダーには、パケットIDが全くありません、そして、ヘッダーには、チェックサムとペイロード長分野変化しかありません。
Casner & Jacobson Standards Track [Page 5] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[5ページ]RFC2508
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つ増加するでしょう。 一定の持続時間のオーディオパケットに関しては、標本数に従って、タイムスタンプは各パケットを運ばれた状態で期間を増加するでしょう。 ビデオに関しては、タイムスタンプはそれぞれのフレームの最初のパケットで変化するでしょうが、フレームのどんな追加パケットにも一定のままでいてください。 それぞれのビデオフレームが1つのパケットだけを占領しますが、ビデオフレームが一定の割合で発生するなら、一方、フレームからフレームまでのタイムスタンプにおける変化は一定です。 前のパケットのヘッダーから前の解凍されたヘッダーに伴うセッション文脈に格納されるこれらの野原のための一次違いを加えることによって次のパケットのヘッダーを組み立てることができるようにそれぞれのこれらの場合では、一連番号とタイムスタンプ分野の2番目のオーダー差がゼロであることに注意してください。 2番目のオーダー差がゼロでないときに、変化の程度がその分野のビットの定員よりはるかに通常わずかであるので、サイズは新しい一次違いをコード化して、絶対値よりむしろそれを伝えることによって、減少できます。
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.
オーディオの最初のパケットのセットがtalkspurtであるつもりであったなら噛み付かれた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リストがtalkspurtの間、一定であるか、または、より長いままで通常残るので、変化するときだけ、それを送らなければなりません。
3.3. The protocol
3.3. プロトコル
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/RTPパケットの流れのための別々のセッション関係があります、IPソースと送付先アドレス、UDPソース、および目的地の特定の組み合わせで定義されるように
Casner & Jacobson Standards Track [Page 6] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[6ページ]RFC2508
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であり。 両方が解凍しました、そして、圧縮されたパケットは文脈IDを運ばなければなりません、そして、4ビットの一連番号は以前はよくコンプレッサーと減圧装置の間のパケット損失を検出していました。 各文脈にはそれ自身の別々の一連番号スペースがあるので、単一のパケット損失は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 ことによるとコンプレッサーで送ったか、または減圧装置で再建した最後のパケットのためのCSRCリストを含む完全な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 IPv4ID分野のための一次違い、その都度この文脈のための解凍されたIPヘッダーを受け取って、アップデートするときはいつも、1に初期化されて、圧縮されたパケットにデルタIPv4ID野原を受け取ります。
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タイムスタンプ分野のための一次違い、その都度この文脈のための解凍されたパケットを受け取って、アップデートするときはいつも、0に初期化されて、圧縮されたパケットにデルタRTPタイムスタンプ野原を受け取ります。
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 現代はUDPの非差分符号化のためにIPv6と共にパケットに付番します。([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ヘッダー、どんな次のヘッダー、およびデータも伝えます。 また、FULL- HEADERパケットは8か16ビットのセッション文脈識別子と確立する4ビットの一連番号を運びます。
Casner & Jacobson Standards Track [Page 7] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[7ページ]RFC2508
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--ヘッダーが6か解凍されたフォームでどんなその後のヘッダー(ことによるとRTP)によっても従われたより少ないバイト(しばしば2はUDPチェックサムであるなら障害がある)とデータに圧縮した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バイト以上であるかもしれません。 2番目のオーダー差(少なくとも通常一定の分野の)がゼロであるときに、このパケットタイプは使用されています。 解凍されたRTPヘッダーを送って、後変化するときはいつも、予想された量を除いて、一次違いを証明するために変えて、それはそれらの分野へのそうしたデルタencodingsを含んでいます。 書式はセクション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_州--特別なパケットが同期がそうした文脈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に使用されるなら、1バイトかCOMPRESSED_UDP書式がIPv4ID野原を運ぶために上に記載したより多くの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.
ポイントへのPointプロトコル[4]のこれらのパケット・フォーマットのための数字コードの課題はインターネットAssigned民数記Authorityによって作られていることです。
3.3.1. FULL_HEADER (uncompressed) packet format
3.3.1. FULL_HEADER(解凍される)パケット・フォーマット
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]で与える定義との一致であることを意図します。 デザイン選択での一部始終をそこに与えます。
Casner & Jacobson Standards Track [Page 8] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[8ページ]RFC2508
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場合では、通常、これはRTPヘッダーとそのペイロードであるかもしれないUDPヘッダーとUDPペイロードがいうことになったIPヘッダーです。 しかしながら、また、FULL_HEADERパケットはIPの要約のパケット、どの場合にUDPによって続かれた2個のIPヘッダーがあるだろうか、そして、およびことによると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パケットは圧縮文脈IDと4ビットの一連番号を運ばなければならないという点においても対応する正常なIPv4かIPv6パケットと異なっています。 ヘッダーのサイズを広げるのを避けるために、実際の長さがリンクレイヤで提供された長さから推論されるかもしれないので、これらの値は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):
セクション5.3.2で指定されるように、8か16ビットの文脈IDが選択されたかどうかによって、文脈ID(CID)と4ビットの一連番号の位置は[3]において異なります、以下のダイヤグラムで示されるように(左には最も多くの重要であるのによる幅16ビットのビットがあります):
For 8-bit context ID:
8ビットの文脈IDのために:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Generation| CID | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1| 世代| Cid| 最初に、長さの分野+++++++++++++++++
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | seq | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | seq| 2番目の長さの分野+++++++++++++++++
For 16-bit context ID:
16ビットの文脈IDのために:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Generation| 0 | seq | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| 世代| 0 | seq| 最初に、長さの分野+++++++++++++++++
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cid| 2番目の長さの分野+++++++++++++++++
Casner & Jacobson Standards Track [Page 9] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[9ページ]RFC2508
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 MUSTの長さをすべての文脈に一定であるか、または別々に8と16ビットのCIDsと共にCOMPRESSED_UDPとCOMPRESSED_RTPパケット・フォーマットを示すために提供しなければなりません2の追加異なったパケットが、タイプする。 最初の長さの分野における2番目のビットは4ビットの一連番号が存在しているのを示す1です、いつものことだがこのIP/UDP/RTP圧縮技術のために。
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.
世代分野はCOMPRESSED_NON_TCPパケットにIPv6と共に[3]で説明されるように使用されます。 COMPRESSED_NON_TCPパケットを使用しないIPv4だけ実現のために、コンプレッサーSHOULDは世代値をゼロに設定します。 IPv4とIPv6の間の一貫した操作において、減圧装置でそれを受け取るとき、文脈に世代値を格納して、CONTEXT_州パケットで最新の値を返します。
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パケットに含まれているかによりながら、文脈を格納するのに必要であるメモリー容量は異なるでしょう。 コンプレッサーと減圧装置は最大のヘッダーサイズを交渉するかもしれません。
3.3.2. COMPRESSED_RTP packet format
3.3.2. COMPRESSED_RTPパケット・フォーマット
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番目のオーダー差がゼロであるときに、減圧装置は、単に前のパケットを表す格納された解凍されたヘッダーに格納された一次違いを加えることによって、パケットを再建できます。 伝えられなければならないすべてが、コンプレッサーと減圧装置の間に同期を維持して、パケット損失を検出するセッション文脈識別子とわずかな一連番号(RTP一連番号に関連しない)です。
Casner & Jacobson Standards Track [Page 10] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[10ページ]RFC2508
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番目のオーダー差がいくつかの分野へのゼロでないなら、まさしくそれらの分野のための新しい一次違いは、コンパクトなコード化を使用することで伝えられます。 新しい一次違いの値は、減圧装置のセッション文脈の解凍されたヘッダーで対応する分野に加えられて、また、再び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.
実際には、一次違いを格納するのが役に立つ唯一の分野が、IPv4ID分野とRTPタイムスタンプです。 RTP一連番号分野に、普通の増分は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タイムスタンプに関しては、格納された一次違いをゼロに初期化します。 タイムスタンプが次のパケット(例えば、同じビデオフレーム)で同じであるなら、2番目のオーダー差はゼロです。 さもなければ、2つのパケットに関するタイムスタンプの違いは減圧装置の文脈に格納されて、また一次違いとしてその文脈に格納された解凍されたヘッダーでタイムスタンプに追加されるべき新しい最初のオーダー差として伝えられます。 その違いは、文脈をアップデートするのに再び伝えられて、一次違いがその後のパケットで変化するたびに使用されます。
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.
FULL_HEADERパケットで状態をリフレッシュするか、またはそれが解凍されたフォームでID野原を運ぶのでCOMPRESSED_NON_TCPパケットを送るとき、同様に、ID分野が頻繁に1つ増加するIPv4以来、その分野のための一次違いを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ヘッダーで条件付きにコミュニケートするべき項目のリストは以下の通りです:
Casner & Jacobson Standards Track [Page 11] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[11ページ]RFC2508
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
私がIPv4パケットIDと等しい、(いつも0はUDP IPv4ヘッダーがありません) U=チェックサムMであるなら=RTP CSRCが数えて、リストアップするRTP RTP RTPマーカービットS=一連番号T=タイムスタンプLと等しいです。
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ビットが必要であるなら、文脈IDと協力するために、それぞれのこれらの項目に1ビットを割り当てて、まだ1バイトにそれらにすべて収まっているように残っているビットがわずかしかあり過ぎるというわけではありません。
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ビットは頻繁に使用される1つの最少であるかもしれません。 CSRCが変化するのを示すためにマスクで少し捧げるよりむしろ、他のビットの珍しい組み合わせは代わりに使用されるかもしれません。 このビット・コンビネーションは指示されたMSTIです。 IPパケットIDのためのすべての4ビット、RTPマーカービットであるなら、RTP一連番号とRTPタイムスタンプは設定されて、これは圧縮されたRTPヘッダーの拡張型が続くのを示す特別なそうです。 そのヘッダーは4ビットとCCカウントの実価を含む追加バイトを入れるでしょう。 CSRCリストはちょうど解凍されたRTPヘッダーに現れるようにCCカウントで示された長さについて含まれるでしょう。
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つであるので与えられた文脈に一定になるように定義されます。 他の分野のどれかが変化するなら、セクション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です。 ネットワークバイトオーダーでマルチバイト野原を送る、(最も重要なバイト、1番目) デルタ分野は、セクション3.3.4で説明されるようにしばしば示されるように1バイトですが、2バイトかデルタ値に依存する3バイトであるかもしれません。
Casner & Jacobson Standards Track [Page 12] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[12ページ]RFC2508
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)
+...............................+
0 1 2 3 4 5 6 7 +...............................+ : セッション文脈IDのmsb: (16ビットのCidであるなら) +-------------------------------+ | セッション文脈IDのlsb| +---+---+---+---+---+---+---+---+ | M| S| T| I| リンク系列| +---+---+---+---+---+---+---+---+ : : + UDPチェックサム+(文脈の非零であるなら): : +...............................+ : : + 「無作為」の分野+(要約されるなら): : +...............................+ : 'M'| S| 'T'| '私'| CC: (MSTI=1111であるなら) +...............................+ : デルタIPv4ID: '、(私かI'=1であるなら) +...............................+ : デルタRTP系列: (SかSの=1であるなら) +...............................+ : デルタRTPタイムスタンプ: '、(TかT'=1であるなら) +...............................+ : : : CSRCは記載します: (MSTI=1111: : CC非零であるなら) : : +...............................+ : : : RTPヘッダー拡張子: (Xが状況内においてセットしたなら) : : : : +-------------------------------+ | | | RTPデータ| / / / / | | +-------------------------------+ : 詰め物: (Pが状況内においてセットしたなら) +...............................+
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
1個以上のIPv4ヘッダーがFULL_HEADERパケットによって初期化されるように文脈に出席している、そして、いつ説明されるとしての絶対値として要約のヘッダーのIP ID野原を送らなければなりませんか。
Casner & Jacobson Standards Track [Page 13] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[13ページ]RFC2508
[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チェックサムの後をつけるオリジナルのヘッダーかMSTIバイトに現れるのに従って、それらは同次でCOMPRESSED_RTPパケットに挿入されます、ダイヤグラムで示されるように。 IPv4パケットがすぐにヘッダーがIP IDを望んでいるUDPに先行する場合にだけ、まして、すなわち、2番目の違いであるならビットなしでヘッダーを特異的に潜在的に送るのは、ゼロであるかデルタIPv4ID分野としてそうです。 すぐにUDPヘッダーに先行するIPv4ヘッダーがなければ、Iビットは0であるに違いありません、そして、どんなデルタIPv4ID分野も存在しないでしょう。
3.3.3. COMPRESSED_UDP packet format
3.3.3. COMPRESSED_UDPパケット・フォーマット
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) :
0 1 2 3 4 5 6 7 +...............................+ : セッション文脈IDのmsb: (16ビットのCidであるなら) +-------------------------------+ | セッション文脈IDのlsb| +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | I| リンク系列| +---+---+---+---+---+---+---+---+ : : + UDPチェックサム+(文脈の非零であるなら): : +...............................+ : : + 「無作為」の分野+(要約されるなら): : +...............................+ : デルタIPv4ID: (私=1であるなら) +-------------------------------+ | UDPデータ| : (解凍されたRTPヘッダー) :
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に差分符号化を使用しません。
Casner & Jacobson Standards Track [Page 14] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[14ページ]RFC2508
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パケットタイプは代わりに使用されるかもしれません。
3.3.4. Encoding of differences
3.3.4. 違いのコード化
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パケットのデルタ分野は一般的により使用された値のコンパクト性のための可変長のマッピングでコード化されます。 デフォルトコード化は以下で指定されますが、実現が各セッションのために特定ですが、適切な状態でテーブルの交渉を許すのにテーブル駆動のデルタエンコーダとデコーダを使用するのは、RECOMMENDEDです、ことによると最適のハフマン符号化さえ。 このデフォルトテーブルとハフマン符号化が例であるビットストリームの連続した解釈に基づくEncodingsは妥当なテーブル・サイズを許容して、値の範囲のための明白なテストでテーブル駆動の非実現より速く実行速度をもたらすかもしれません。
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進と注文に示されたバイト(ネットワークバイトオーダー)の結果として起こる系列です。 それぞれの隣接の範囲の1番目と最終値は中間で楕円で示されます:
Decimal Hex
10進十六進法
-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
-16384C0 00 00: : -129 C0 3F7F-128 80 00: : -1 80 7F0 00: : 127 7F128 80 80: : 16383 BF ff16384C0 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バイトまで合図します。
Casner & Jacobson Standards Track [Page 15] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[15ページ]RFC2508
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.
パケットがmisorderedされるか、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ビットの数として)SHOULDです。
3.3.5. Error Recovery
3.3.5. エラー回復
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.
1を除いて、特定の文脈がFULL_HEADERかCOMPRESSED_NON_TCPパケットによって設定されるときに時以外の減圧装置を増加するので、4ビットの一連番号がその文脈を無効にして、CONTEXT_州パケットをそれを示すコンプレッサーに送り返さなければならないときはいつも、文脈は無効にされました。 その文脈が一貫した状態を再証明するようにFULL_HEADERかCOMPRESSED_NON_TCPパケットを受け取るまで(「二度」というアルゴリズムがこのセクションで後述のように使用されない場合)無効の文脈のためのすべてのパケットを捨てなければなりません。 複数の圧縮されたパケットがその間到着するかもしれないので、減圧装置SHOULD NOTはあらゆる圧縮されたパケットのための州パケットが受けたCONTEXT_を再送しますが、代わりに、SHOULDは逆のチャンネルをあふれさせるのを避けるために「再-トランスミッション」のレートを制限します。
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つのパケットをもたらすのは損をしました。 リンクが明白な誤り表示を提供するなら、減圧装置は、より速い回復を許すために、任意に、顧問CONTEXT_州パケットに最後の有効な一連番号を記載するのを送って、個人的にはか、より最近アクティブな文脈(必ずすべてであるというわけではない)を世代番号に送るかもしれません。 与えられた文脈に関しては、コンプレッサーが、より高い一連番号と共に圧縮されたパケットを全く送らないで、世代番号が現代に合っているなら、修正措置は全く必要ではありません。 さもなければ、コンプレッサーが、FULL_HEADERかCOMPRESSED_NON_TCPモードで次のパケットを送るように文脈が無効であるとマークするのを選ぶかもしれない、(FULL_HEADER
Casner & Jacobson Standards Track [Page 16] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[16ページ]RFC2508
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.
世代が合わないなら必要である、) しかしながら、往復の時間がリンクであるなら大きいというメモは相互パケットスペースと比較されて、複数の文脈からのいくつかのパケットがリンクのむこうに飛行であるかもしれません、コンプレッサーでCONTEXT_州パケットを受け取るとき、一連番号が既に進んでしまうだろうという確率を増加させて。 結果は余分な帯域幅が消費されることを引き起こして、いくつかの文脈が不必要に無効にされるということであるかもしれません。
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_州パケットの書式は以下のダイヤグラムで示されます。最初のバイトはCONTEXT_州パケットタイプが[3]で指定された一般的な圧縮枠組みの中の複数の圧縮技術によって共有されるのを許容するタイプコードです。 パケットの残りのコンテンツは圧縮技術によります。 ここで指定されたIP/UDP/RTP圧縮技術においてCONTEXT_州パケットの残りは複数の文脈が示されるために状態を許容するためにブロックのリストとして構造化されます、ブロックの数の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:
2つのタイプコード値が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 |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 8ビットのCidがある=IP/UDP/RTP| +---+---+---+---+---+---+---+---+ | 文脈カウント| +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | セッション文脈ID| +---+---+---+---+---+---+---+---+ | I| 0 | 0 | 0 | 系列| +---+---+---+---+---+---+---+---+ | 0 | 0 | 世代| +---+---+---+---+---+---+---+---+ ... +---+---+---+---+---+---+---+---+ | セッション文脈ID| +---+---+---+---+---+---+---+---+ | I| 0 | 0 | 0 | 系列| +---+---+---+---+---+---+---+---+ | 0 | 0 | 世代| +---+---+---+---+---+---+---+---+
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を送る、(最も重要なバイト、1番目)、:
Casner & Jacobson Standards Track [Page 17] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[17ページ]RFC2508
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 |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 2 16ビットのCidがある=IP/UDP/RTP| +---+---+---+---+---+---+---+---+ | 文脈カウント| +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | | + セッション文脈ID+| | +---+---+---+---+---+---+---+---+ | I| 0 | 0 | 0 | 系列| +---+---+---+---+---+---+---+---+ | 0 | 0 | 世代| +---+---+---+---+---+---+---+---+ ... +---+---+---+---+---+---+---+---+ | | + セッション文脈ID+| | +---+---+---+---+---+---+---+---+ | I| 0 | 0 | 0 | 系列| +---+---+---+---+---+---+---+---+ | 0 | 0 | 世代| +---+---+---+---+---+---+---+---+
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.
「私」とラベルされたビットは無効であるとマークされて、伝えられるために圧縮された_非_のTCPパケットを完全な_ヘッダーに要求する文脈のための1つへのセットです。 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_州パケット自体が失われるかもしれないので、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_州ブロックが再送されるなら、それはその文脈をリフレッシュすることを意図する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で説明されたアルゴリズムを使用するのを試みるかもしれません。 このアルゴリズムで、デルタは(s)とものが次にデルタがなくなったパケットで同じであったかもしれないという前提での一度受信されたより適用されます。 成功はそうです。
Casner & Jacobson Standards Track [Page 18] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[18ページ]RFC2508
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の噛み付いている一連番号の違いは、デルタを適用しなければならないと回数に言います。 しかしながら、不正確な積極的な指示の重要なリスクがあることに注意してください。 「二度」というアルゴリズムが成功しても、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チェックサムについて確かめるのが、RECOMMENDEDであり、16からの恐らく1つはパケットです。 誤りが検出されるなら、減圧装置は、CONTEXT_州パケットで文脈を無効にして、コンプレッサーを示すでしょう。
3.4. Compression of RTCP Control Packets
3.4. RTCPコントロールパケットの圧縮
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パケットは次の、より高い(変な)ポートナンバーで運ばれます、そして、1つはRTPとRTCPパケットに適用されるために別々の圧縮技術を合わせるかもしれません。 RTCPに関しては、ヘッダーに適用するだけではなく、「データ」(すなわち、異なったパケットタイプのコンテンツ)にも圧縮は適用できました。 中のSender Report(SR)とReceiver Report(RR)RTCPパケットが圧縮しない数が噴出しますが、Source記述(SDES)パケットのテキスト情報を存在している各個条を示すしばらくマスクまで圧縮されましたが、外(SDES NOTEの品目のタイミング目的、エンドシステムが間隔計算のために平均した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ヘッダーと「データ」で全く圧縮しないでしょう(圧縮SHOULDですが、それでも、IPとUDPヘッダーに適用されてください)。 RTPプロトコル仕様が、RTCPパケット間隔がセッションのときにすべての関係者によって使用された集合RTCP帯域幅がセッション帯域幅の5%未満になるようにスケーリングされるのを示すので、RTCP圧縮から獲得するために、多くがありません。 SDESの品目を外に圧縮するのはそれぞれの文脈IDのために格納しなければならない共有された状態のかなりの増加を必要とするでしょう。 そして、RTP「ミキサー」を通していくつかのソースへのSDES情報を送ったとき、圧縮を許すために、それぞれのSSRC識別子のための別々のRTCPセッション関係を維持するのが必要でしょう。 1人の関係者だけが255人以上の関係者とのセッションのときにデータを送ったときさえ、これは文脈キャッシュについて完全な打つことを引き起こすでしょう。
Casner & Jacobson Standards Track [Page 19] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[19ページ]RFC2508
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パケットによって占領された総帯域幅の部分は5%未満残っています、RTCPパケットがCOMPRESSED_UDPパケットとして送られると仮定して。 解凍されたRTCP交通がそして、90バイトの典型的なRTCPパケット長のために総セッション帯域幅の5%未満を消費すると、RTCPによって使用された圧縮された帯域幅の部分はRTPデータ・パケットのペイロードのサイズが少なくとも108バイトであるなら5%未満になるでしょう。 RTPデータペイロードのサイズが、より小さいなら、断片は、増加しますが、それでも、37バイトのペイロードサイズのための7%未満です。 大きいデータペイロードに関しては、圧縮されたRTCP断片は解凍されたRTCP断片(例えば、1000バイトにおける4%)より少ないです。
3.5. Compression of non-RTP UDP Packets
3.5. 非RTP UDPパケットの圧縮
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文脈を特定することに関する部分であるので)すべての文脈スロットを使いきるのを避けるために非RTP UDPパケットの流れの動向をおさえるのが必要です。 それぞれそれらの流れに文脈を与えるかもしれませんが、エンコーダは、文脈の旗にSSRCがさばく変化が無視されるべきであり、COMPRESSED_UDPパケットがCOMPRESSED_RTPパケットの代わりにいつも送られるべきであるのを示すように設定するでしょう。
4. Interaction With Segmentation
4. 分割との相互作用
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一連番号が、正しく再建されるべきであり、アプリケーションが注文を修正するのを許容するので、これは、より重大な問題を引き起こすべきではありません。
Casner & Jacobson Standards Track [Page 20] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[20ページ]RFC2508
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_州メッセージでコンプレッサーに示されるかもしれません。
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値を割り当てるかもしれないので、値が分割層からの文脈識別子に合うように設定できます。
5. Negotiating Compression
5. 圧縮を交渉します。
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 A文脈詳細がデルタ値を解読するために見送る文脈のヘッダーのスタックの最大サイズ。
6. Acknowledgments
6. 承認
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.
数人は、この圧縮技術のデザインに貢献して、問題を関係づけました。スコットPetrackは1996年3月にロサンゼルスのAVTワーキンググループにおける、RTPヘッダー圧縮の議論を開始しました。 カルステン・ボルマンは、トラフィックコントロールと組み合わせて圧縮のために低い速度リンクの向こう側に総合的な構造を開発して、ここでいくつかの特定の貢献が計画に説明されるのを作りました。 デヴィッド・オランは、独自に同様の考えに基づく注意を開発して、PPP Multilinkプロトコルの分割の使用を示しました。 マイケル・デーゲルマルクはIPv6圧縮枠組みがあるこの圧縮技術の統合に関するアドバイスを寄付しました。
Casner & Jacobson Standards Track [Page 21] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[21ページ]RFC2508
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.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのTransportプロトコル」、RFC1889、1996年1月。
[2] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links",
RFC 1144, February 1990.
[2] ジェーコブソン、V.、「低速連続のリンクのためのTCP/IP圧縮」、RFC1144、1990年2月。
[3] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for
IPv6", RFC 2507, February 1999.
[3] デーゲルマルクとM.とNordgrenとB.とS.ピンク、「IPv6"、RFC2507、1999年2月のためのヘッダー圧縮。」
[4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[4] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、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有効搭載量形式」、RFC2250、1998年1月。
8. Security Considerations
8. セキュリティ問題
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_州コントロールパケットに実行されません。 減圧装置とコンプレッサーとのリンクへのアクセスの攻撃者は減少するために偽のCONTEXT_州パケットと原因圧縮効率を注入できました、たぶんリンクで混雑をもたらして。 しかしながら、また、リンクへのアクセスの攻撃者は他の多くの方法で交通を中断できました。
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
不均等な受信端末コンピュータの負荷を持っている圧縮のテクニックを使用するとき、潜在的サービスの否定の脅威は存在しています。 しかしながら、攻撃者が、流れの中への減圧するために複雑な病理学的なデータグラムを注入して、受信機が積みすぎられて、他の流れの処理を下がらせていることを引き起こす場合がある、この圧縮
Casner & Jacobson Standards Track [Page 22] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[22ページ]RFC2508
does not exhibit any significant non-uniformity.
少しの重要な非の一様性も示しません。
A security review of this protocol found no additional security considerations.
このプロトコルの安全レビューは追加担保問題を全く見つけませんでした。
9. Authors' Addresses
9. 作者のアドレス
Stephen L. Casner Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 United States
西タスマン・DriveスティーブンL.CasnerシスコシステムズInc.170カリフォルニア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
西タスマン・DriveヴァンジェーコブソンシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(合衆国)
EMail: van@cisco.com
メール: van@cisco.com
Casner & Jacobson Standards Track [Page 23] RFC 2508 Compressing IP/UDP/RTP Headers February 1999
ヘッダー1999年2月にIP/UDP/RTPを圧縮するCasnerとジェーコブソン標準化過程[23ページ]RFC2508
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Casner & Jacobson Standards Track [Page 24]
Casnerとジェーコブソン標準化過程[24ページ]
一覧
スポンサーリンク
