Network Working Group M. Handley
Request for Comments: 2736 ACIRI
BCP: 36 C. Perkins
Category: Best Current Practice UCL
December 1999
Guidelines for Writers of RTP Payload Format Specifications
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development.
この文書では、良い形式を決定するにはRTPペイロードフォーマットの仕様の作成者を支援することを目的の一般的なガイドラインを提供します。これらのガイドラインは、その開発中に進化してRTPで得られた経験の一部を捕獲しようとします。
This document provides general guidelines aimed at assisting the authors of RTP [9] Payload Format specifications in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development.
この文書では、良い形式を決定するにはRTP [9]ペイロードフォーマットの仕様の作成者を支援することを目的の一般的なガイドラインを提供します。これらのガイドラインは、その開発中に進化してRTPで得られた経験の一部を捕獲しようとします。
The principles outlined in this document are applicable to almost all data types, but are framed in examples of audio and video codecs for clarity.
この文書で概説した原理は、ほとんどすべてのデータ型に適用されるが、明確にするためのオーディオおよびビデオコーデックの例で囲まれています。
RTP was designed around the concept of Application Level Framing (ALF), first described by Clark and Tennenhouse [2]. The key argument underlying ALF is that there are many different ways an application might be able to cope with misordered or lost packets. These range from ignoring the loss, to re-sending the missing data (either from a buffer or by regenerating it), and to sending new data which supersedes the missing data. The application only has this choice if the transport protocol is dealing with data in "Application Data Units" (ADUs). An ADU contains data that can be processed out-of- order with respect to other ADUs. Thus the ADU is the minimum unit of error recovery.
RTPは、[2]第クラークとTennenhouseによって記述、アプリケーションレベルフレーミング（ALF）の概念に基づいて設計しました。 ALFの基礎となる重要な引数は、アプリケーションがmisorderedまたは失われたパケットに対処することができるかもしれない多くの異なる方法があるということです。損失を無視してから、これらの範囲は、再送信する（バッファから、またはそれを再生することによってのいずれか）、及び欠落データに取って代わる新たなデータを送信する欠落データを。トランスポートプロトコルは、「アプリケーション・データ・ユニット」（のADU）内のデータを扱っている場合、アプリケーションは、この選択肢を持っています。 ADUは、他のADUに対してアウトオブオーダーを処理することができるデータを含みます。したがって、ADUは、エラーリカバリの最小単位です。
The key property of a transport protocol for ADUs is that each ADU contains sufficient information to be processed by the receiver immediately. An example is a video stream, wherein the compressed video data in an ADU must be capable of being decompressed regardless of whether previous ADUs have been received. Additionally the ADU must contain "header" information detailing its position in the video image and the frame from which it came.
ADUのためのトランスポートプロトコルの重要な特性は、各ADUが直ちに受信機によって処理されるのに十分な情報を含んでいることです。例では、ADUで圧縮されたビデオデータに関係なく、以前のADUが受信されたかどうかに解凍されることが可能でなければならない、ビデオストリームです。さらにADUは、ビデオ画像と、それが来たフレーム内の位置を詳述する「ヘッダ」情報を含んでいなければなりません。
Although an ADU need not be a packet, there are many applications for which a packet is a natural ADU. Such ALF applications have the great advantage that all packets that are received can be processed by the application immediately.
ADUは、パケットである必要はありませんが、パケットが自然ADUであるため、多くのアプリケーションがあります。このようなALFアプリケーションが受信されたすべてのパケットがすぐにアプリケーションで処理することができるという大きな利点を持っています。
RTP was designed around an ALF philosophy. In the context of a stream of RTP data, an RTP packet header provides sufficient information to be able to identify and decode the packet irrespective of whether it was received in order, or whether preceding packets have been lost. However, these arguments only hold good if the RTP payload formats are also designed using an ALF philosophy.
RTPは、ALFの哲学を中心に設計されました。 RTPデータストリームの文脈では、RTPパケットのヘッダに関係なく、それが順に受信されたかどうか、または前のパケットが失われたかどうかパケットを識別し、復号することができるように十分な情報を提供します。 RTPペイロードフォーマットはまた、ALFの哲学を使用して設計されている場合は、これらの引数は、唯一の良い保持します。
Note that this also implies smart, network aware, end-points. An application using RTP should be aware of the limitations of the underlying network, and should adapt its transmission to match those limitations. Our experience is that a smart end-point implementation can achieve significantly better performance on real IP-based networks than a naive implementation.
これはまた、スマート、ネットワークを意識、エンドポイントを意味することに注意してください。 RTPを使用するアプリケーションは、基盤となるネットワークの限界を認識しておく必要があり、そしてこれらの制限に合わせて、その送信を適応させる必要があります。私たちの経験では、スマートエンドポイントの実装は素朴な実装よりも実際のIPベースのネットワーク上の有意に優れた性能を実現することができるということです。
We identify the following channel characteristics that influence the best-effort transport of RTP over UDP/IP in the Internet:
私たちは、インターネットでUDP / IP上でRTPのベストエフォート型の輸送に影響を与える以下のチャネル特性を識別します。
o Packets may be lost
Oパケットが失われることがあります
o Packets may be duplicated
Oパケットは重複する可能性があり
o Packets may be reordered in transit
Oパケットは、輸送中に並べ替えすることができます
o Packets will be fragmented if they exceed the MTU of the underlying network
彼らは基礎となるネットワークのMTUを超えた場合、Oパケットは断片化されます
The loss characteristics of a link may vary widely over short time intervals.
リンクの損失特性は、短い時間間隔にわたって広範囲に変化し得ます。
Although fragmentation is not a disastrous phenomenon if it is a rare occurrence, relying on IP fragmentation is a bad design strategy as it significantly increases the effective loss rate of a network and decreases goodput. This is because if one fragment is lost, the remaining fragments (which have used up bottleneck bandwidth) will then need to be discarded by the receiver. It also puts additional load on the routers performing fragmentation and on the end-systems re-assembling the fragments.
フラグメンテーションが悲惨な現象ではないが、それはまれである場合、それは著しくネットワークの実効損失率を増加させ、グッドプットが減少すると、IP断片化に依存することは悪い設計戦略です。一つの断片が失われた場合、（ボトルネック帯域幅を使用していた）残りのフラグメントは、受信機によって破棄される必要があるためです。それはまた、断片化を実行するルータ上および断片を再組み立てエンドシステムに追加の負荷をかけます。
In addition, it is noted that the transit time between two hosts on the Internet will not be constant. This is due to two effects - jitter caused by being queued behind cross-traffic, and routing changes. The former is possible to characterise and compensate for by using a playout buffer, but the latter is impossible to predict and difficult to accommodate gracefully.
また、インターネット上の2つのホスト間の通過時間が一定ではないことに留意されたいです。クロストラフィックの後ろにキューイングされることによって引き起こされるジッター、およびルーティングの変更 - これは二つの効果によるものです。前者は、再生バッファを使用することによって特徴づけ及び補償することが可能であるが、後者は、正常に対応するために予測することは不可能とは困難です。
We identify the following requirements of RTP payload format specifications:
私たちは、RTPペイロードフォーマットの仕様は、次の要件を識別します。
+ A payload format should be devised so that the stream being transported is still useful even in the presence of a moderate amount of packet loss.
搬送されるストリームもパケット損失の適度な量の存在下で依然として有用であるよう+ペイロードフォーマットが考案されなければなりません。
+ Ideally all the contents of every packet should be possible to be decoded and played out irrespective of whether preceding packets have been lost or arrive late.
+理想的にはすべてのパケットのすべての内容は、復号化と関係なく、前のパケットが失われたり、遅れて到着されているかどうかのうちに再生することが可能であるべきです。
The first of these requirements is based on the nature of the Internet. Although it may be possible to engineer parts of the Internet to produce low loss rates through careful provisioning or the use of non-best-effort services, as a rule payload formats should not be designed for these special purpose environments. Payload formats should be designed to be used in the public Internet with best effort service, and thus should expect to see moderate loss rates. For example, a 5% loss rate is not uncommon. We note that TCP steady state models [3][4][6] indicate that a 5% loss rate with a 1KByte packet size and 200ms round-trip time will result in TCP achieving a throughput of around 180Kbit/s. Higher loss rates, smaller packet sizes, or a larger RTT are required to constrain TCP to lower data rates. For the most part, it is such TCP traffic that is producing the background loss that many RTP flows must co-exist with. Without explicit congestion notification (ECN) [8], loss must be considered an intrinsic property of best-effort parts of the Internet.
これらの要件の最初は、インターネットの性質に基づいています。ルールペイロード形式はこれらの特別な目的の環境向けに設計されてはならないよう、慎重なプロビジョニングまたは非ベストエフォート型のサービスを使用して低損失率を生成するために、インターネットの部分を操作することが可能かもしれないが。ペイロード形式は、ベストエフォート型のサービスで、パブリックインターネットで使用するように設計されなければならないので、適度の損失率を見ることを期待すべきです。例えば、5％の損失率は、珍しいことではありません。我々は、TCP定常状態モデル[3] [4] [6] 1Kバイトのパケットサイズと200msの往復時間で5％の損失率が180Kbit /秒程度のスループットを達成するTCPをもたらすであろうことを示していることに注意してください。高い損失率、小さいパケットサイズ、または大きなRTTが低いデータレートにTCPを拘束するために必要とされています。ほとんどの部分については、それは多くのRTPフローがと共存しなければならないことを背景損失を生産しているようにTCPトラフィックです。明示的輻輳通知（ECN）がなければ、[8]、損失は、インターネットのベストエフォート型部品の固有の特性を考慮しなければなりません。
When payload formats do not assume packet loss will occur, they should state this explicitly up front, and they will be considered special purpose payload formats, unsuitable for use on the public Internet without special support from the network infrastructure.
ペイロードフォーマットは、パケットロスが発生すると想定していないときは、明示的にフロントまでこのことを明記してください、そして、彼らはネットワークインフラストラクチャからの特別なサポートなしで公共のインターネット上での使用には適さない、特別な目的のペイロードフォーマットとみなされます。
The second of these requirements is more explicit about how RTP should cope with loss. If an RTP payload format is properly designed, every packet that is actually received should be useful. Typically this implies the following guidelines are adhered to:
これらの要件の第二は、RTPが損失に対処すべきかについて、より明確です。 RTPペイロード形式が適切に設計されている場合は、実際に受信されたすべてのパケットが有用であろう。通常、これは、以下のガイドラインを順守している意味します：
+ Packet boundaries should coincide with codec frame boundaries. Thus a packet should normally consist of one or more complete codec frames.
+パケットの境界は、コーデック、フレームの境界と一致する必要があります。したがって、パケットは、通常、1つまたは複数の完全なコーデックフレームで構成する必要があります。
+ A codec's minimum unit of data should never be packetised so that it crosses a packet boundary unless it is larger than the MTU.
それはMTUよりも大きくない限り、それはパケット境界を横切るように+データのコーデックの最小単位をパケット化してはいけません。
+ If a codec's frame size is larger than the MTU, the payload format must not rely on IP fragmentation. Instead it must define its own fragmentation mechanism. Such mechanisms may involve codec-specific information that allows decoding of fragments. Alternatively they might allow codec-independent packet-level forward error correction [5] to be applied that cannot be used with IP-level fragmentation.
+コーデックのフレームサイズがMTUより大きい場合、ペイロードフォーマットは、IPフラグメンテーションに依存してはいけません。代わりに、それは自身の断片化のメカニズムを定義する必要があります。そのようなメカニズムは、フラグメントの復号を可能にするコーデック固有の情報を含むことができます。あるいは、それらは、[5] IPレベルの断片化と一緒に使用することができない適用されるコーデックに依存しないパケットレベルの順方向誤り訂正を可能にするかもしれません。
In the abstract, a codec frame (i.e., the ADU or the minimum size unit that has semantic meaning when handed to the codec) can be of arbitrary size. For PCM audio, it is one byte. For GSM audio, a frame corresponds to 20ms of audio. For H.261 video, it is a Group of Blocks (GOB), or one twelfth of a CIF video frame.
抽象的には、コーデックのフレーム（すなわち、ADUまたはコーデックに渡さセマンティックな意味を持つ最小寸法部）は任意のサイズであってもよいです。 PCMオーディオの場合は、1バイトです。 GSM音声ため、フレームは、オーディオの20ミリ秒に相当します。 H.261ビデオの場合は、ブロックのグループ（GOB）、またはCIFビデオフレームの1/12です。
For PCM, it does not matter how audio is packetised, as the ADU size is one byte. For GSM audio, arbitrary packetisation would split a 20ms frame over two packets, which would mean that if one packet were lost, partial frames in packets before and after the loss are meaningless. This means that not only were the bits in the missing packet lost, but also that additional bits in neighboring packets that used bottleneck bandwidth were effectively also lost because the receiver must throw them away. Instead, we would packetise GSM by including several complete GSM frames in a packet; typically four GSM frames are included in current implementations. Thus every packet received can be decoded because even in the presence of loss, no incomplete frames are received.
ADUのサイズは1バイトであるとして、オーディオは、パケット化されどのようにPCMの場合、それは問題ではありません。 GSMオーディオのため、任意のパケット化は、一つのパケットが失われた場合、前損失後のパケット内の部分的なフレームが無意味であることを意味する二つのパケット、上20msのフレームを分割することになります。これは、失われた欠落パケット内のビットだったが、また、受信機はそれらを離れて投げなければならないため、ボトルネック帯域を使用し、隣接パケットでその追加のビットが有効にも失われただけでなく、ことを意味します。代わりに、私たちは、パケット内のいくつかの完全なGSMフレームを含むことにより、GSMをパケット化でしょう。典型的には4つのGSMフレームは、現在の実装に含まれています。損失の存在下で、不完全なフレームが受信されないため、受信した全てのパケットを復号することができます。
The H.261 specification allows GOBs to be up to 3KBytes long, although most of the time they are smaller than this. It might be thought that we should insert a group of blocks into a packet when it fits, and arbitrarily split the GOB over two or more packets when a
時間のほとんどは、彼らがこれより小さいものの、H.261仕様は、GOBのは長い3KBytesまでにすることができます。我々はそれが収まるとき、パケットにブロックのグループを挿入し、任意に2つの以上のパケット上でGOBを分割する必要があることを考えることが可能性がある場合
GOB is large. In the first version of the H.261 payload format, this is what was done. However, this still means that there are circumstances where H.261 packets arrive at the receiver and must be discarded because other packets were lost - a loss multiplier effect that we wish to avoid. In fact there are smaller units than GOBs in the H.261 bit-stream called macroblocks, but they are not identifiable without parsing from the start of the GOB. However, if we provide a little additional information at the start of each packet, we can reinstate information that would normally be found by parsing from the start of the GOB, and we can packetise H.261 by splitting the data stream on macroblock boundaries. This is a less obvious packetisation for H.261 than the GOB packetisation, but it does mean that a slightly smarter depacketiser at the receiver can reconstruct a valid H.261 bitstream from a stream of RTP packets that has experienced loss, and not have to discard any of the data that arrived.
GOBが大きいです。 H.261ペイロード形式の最初のバージョンでは、これが行われたものです。損失乗数効果我々は避けたい - しかし、これはまだH.261パケットが受信機に到達し、他のパケットが失われたために廃棄されなければならない事情があることを意味しています。実際にはそこにマクロブロックと呼ばれるH.261ビットストリーム中のGOBよりも小さい単位がありますが、それらはGOBの開始から解析せずに識別可能ではありません。私たちは、各パケットの開始時にわずかな追加情報を提供する場合は、我々は通常、GOBの開始から解析することによって見られる情報を元に戻すことができ、そして我々は、マクロブロックの境界上のデータストリームを分割することにより、H.261をパケット化することができます。これは、GOBのパケット化よりもH.261にはあまり明らかパケット化であるが、それは、受信機で少し賢くdepacketiserがする必要がある損失を経験したRTPパケットのストリームから有効なH.261ビットストリームを再構築し、できないことを意味してい到着したデータのいずれかを捨てます。
An additional guideline concerns codecs that require the decoder state machine to keep step with the encoder state machine. Many audio codecs such as LPC or GSM are of this form. Typically they are loss tolerant, in that after a loss, the predictor coefficients decay, so that after a certain amount of time, the predictor error induced by the loss will disappear. Most codecs designed for telephony services are of this form because they were designed to cope with bit errors without the decoder predictor state permanently remaining incorrect. Just packetising these formats so that packets consist of integer multiples of codec frames may not be optimal, as although the packet received immediately after a packet loss can be decoded, the start of the audio stream produced will be incorrect (and hence distort the signal) because the decoder predictor is now out of step with the encoder. In principle, all of the decoder's internal state could be added using a header attached to the start of every packet, but for lower bit-rate encodings, this state is so substantial that the bit rate is no longer low. However, a compromise can usually be found, where a greatly reduced form of decoder state is sent in every packet, which does not recreate the encoders predictor precisely, but does reduce the magnitude and duration of the distortion produced when the previous packet is lost. Such compressed state is, by definition, very dependent on the codec in question. Thus we recommend:
付加的なガイドラインは、符号器状態機械とのステップを保つために、デコーダ状態機械を必要とするコーデックに関する。このようLPCやGSMなどの多くのオーディオコーデックはこの形式です。一定時間後、損失によって誘導される予測誤差が消滅するように、それは損失の後、予測は、減衰係数で典型的には、寛容の損失です。それらはデコーダ予測状態が永続的に間違って残りせずにビットエラーに対処するように設計されたので、電話サービスのために設計されたほとんどのコーデックはこの形式です。パケットは、パケットがパケット損失の直後に受信が復号することができるように、最適ではないかもしれないコーデックフレームの整数倍で構成されるようにだけ、これらのフォーマットをpacketising、正しくないであろう産オーディオストリームの開始（従って、信号を歪ませます）デコーダ予測はエンコーダ付きステップのうち、今からです。原理的には、デコーダの内部状態の全ては、各パケットの先頭に添付ヘッダを使用して追加することができ、より低いビットレートの符号化のために、この状態は、ビットレートがもはや低いほど大きいです。デコーダ状態の大幅に低減形態を正確エンコーダ予測を再現するが、前のパケットが失われた際に生じる歪みの大きさおよび持続時間を低減しないすべてのパケットで送信される場合しかし、妥協は通常、求めることができます。このような圧縮された状態では、定義により、問題のコーデックに非常に依存します。したがって、私たちはお勧めします：
+ Payload formats for encodings where the decoder contains internal data-driven state that attempts to track encoder state should normally consider including a small additional header that conveys the most critical elements of this state to reduce distortion after packet loss.
+デコーダは通常、パケット損失の後歪みを低減するために、この状態の最も重要な要素を伝える小さな追加ヘッダを含めることを検討すべきであるエンコーダの状態を追跡しようとする内部データ駆動状態が含まエンコーディングのためのペイロード・フォーマット。
A similar issue arises with codec parameters, and whether or not they should be included in the payload format. An example is with a codec that has a choice of huffman tables for compression. The codec may use either huffman table 1 or table 2 for encoding and the receiver needs to know this information for correct decoding. There are a number of ways in which this kind of information can be conveyed:
同様の問題は、コーデックのパラメータで生じ、そしてかどうか、彼らは、ペイロードフォーマットに含まれるべきです。例では、圧縮のためのハフマンテーブルの選択肢を持っているコーデックです。コーデックは、符号化のためのハフマン表1または表2のいずれかを使用することができ、受信機は、正しい復号化のために、この情報を知る必要があります。この種の情報を搬送することができるいくつかの方法があります：
o Out of band signalling, prior to media transmission.
Oバンド信号のうち、前のメディア送信します。
o Out of band signalling, but the parameter can be changed mid-session. This requires synchronization of the change in the media stream.
Oバンドのうちのシグナリングが、パラメータは半ばセッションを変更することができます。これは、メディアストリームの変更の同期を必要とします。
o The change is signaled through a change in the RTP payload type field. This requires mapping the parameter space into particular payload type values and signalling this mapping out-of-band prior to media transmission.
O変化はRTPペイロードタイプフィールドの変化を介してシグナリングされます。これは、特定のペイロード・タイプの値にパラメータ空間をマッピングし、前のメディア送信に帯域外このマッピングをシグナリングが必要です。
o Including the parameter in the payload format. This allows for adapting the parameter in a robust manner, but makes the payload format less efficient.
ペイロード形式のパラメータを含むO。これは、堅牢な方法でパラメータを適応することができますが、ペイロード形式はあまり効率的になります。
Which mechanism to use depends on the utility of changing the parameter in mid-session to support application layer adaptation. However, using out-of-band signalling to change a parameter in mid-session is generally to be discouraged due to the problem of synchronizing the parameter change with the media stream.
使用するメカニズムは、アプリケーション層の適応をサポートするために、半ばセッションでパラメータを変更するの有用性に依存します。しかし、半ばセッションでパラメータを変更するには、シグナリング帯域外使用することは、メディア・ストリームとパラメータの変更を同期化する問題に落胆することが一般的です。
Many RTP payload formats require some additional header information to be carried in addition to that included in the fixed RTP packet header. The recommended way of conveying this information is in the payload section of the packet. The RTP header extension should not be used to convey payload specific information ([9], section 5.3) since this is inefficient in its use of bandwidth; requires the definition of a new RTP profile or profile extension; and makes it difficult to employ FEC schemes such as, for example, [7]. Use of an RTP header extension is only appropriate for cases where the extension in question applies across a wide range of payload types.
多くのRTPペイロードフォーマットは、固定されたRTPパケットのヘッダに含まれるものに加えて実施されるいくつかの追加のヘッダ情報を必要とします。この情報を伝えるの推奨方法は、パケットのペイロード部にあります。これは、帯域幅の使用において非効率的であるので、RTPヘッダ拡張は、ペイロード特有の情報（[9]、セクション5.3）を伝達するために使用すべきではありません。新しいRTPプロファイルまたはプロファイル拡張の定義が必要です。それは難しい例えばようなFEC方式を採用することができる[7]。 RTPヘッダ拡張を使用することは、問題の拡張は、ペイロードタイプの幅広い適用の場合にのみ適しています。
Designers of payload formats should also be aware of the needs of RTP header compression [1]. In particular, the compression algorithm functions best when the RTP timestamp increments by a constant value between consecutive packets. Payload formats which rely on sending packets out of order, such that the timestamp increment is not constant, are likely to compress less well than those which send packets in order. This has most often been an issue when designing payload formats for FEC information, although some video codecs also rely on out-of-order transmission of packets at the expense of reduced compression. Although in some cases such out-of-order transmission may be the best solution, payload format designers are encourage to look for alternative solutions where possible.
ペイロードフォーマットの設計者は、[1] RTPヘッダ圧縮の必要性を認識しなければなりません。特に、圧縮アルゴリズム機能最良とき連続するパケット間の一定値によってRTPタイムスタンプインクリメントします。順序が狂ったパケットを送信するに依存しているペイロードフォーマットは、タイムスタンプインクリメントが一定でないように、あまりよく順番にパケットを送信するものよりも圧縮する可能性があります。 FEC情報のペイロードフォーマットを設計する際に、いくつかのビデオコーデックも小さく圧縮を犠牲にしてパケットのアウト・オブ・オーダーの送信に依存しているが、これはほとんどの場合、問題となっています。いくつかのケースでは、このようなアウトオブオーダー送信が最善の解決策かもしれませんが、ペイロードフォーマットの設計者は、可能な場合は代替ソリューションを探すために奨励されています。
Designing packet formats for RTP is not a trivial task. Typically a detailed knowledge of the codec involved is required to be able to design a format that is resilient to loss, does not introduce loss magnification effects due to inappropriate packetisation, and does not introduce unnecessary distortion after a packet loss. We believe that considerable effort should be put into designing packet formats that are well tailored to the codec in question. Typically this requires a very small amount of processing at the sender and receiver, but the result can be greatly improved quality when operating in typical Internet environments.
RTPのパケットフォーマットを設計することは簡単な作業ではありません。典型的に関与するコーデックの詳細な知識が損失弾性のあるフォーマットを設計することができることが要求される、不適切なパケット化による損失の拡大効果を導入しないと、パケットロスの後、不要な歪みを導入しません。私たちは、かなりの努力がよく問題になっているコーデックに合わせて調整されたパケットのフォーマットを設計に入れるべきであると考えています。典型的には、これは、送信側と受信側での処理の非常に少量を必要とするが、一般的なインターネット環境で動作するとき、結果が大幅に品質を向上させることができます。
Designers of new codecs for use with RTP should consider making the output of the codec "naturally packetizable". This implies that the codec should be designed to produce a packet stream, rather than a bit-stream; and that that packet stream contains the minimal amount of redundancy necessary to ensure that each packet is independently decodable with minimal loss of decoder predictor tracking. It is recognised that sacrificing some small amount of bandwidth to ensure greater robustness to packet loss is often a worthwhile tradeoff.
RTPで使用する新しいコーデックの設計者は、「自然にpacketizable」コーデックの出力を行うことを検討すべきです。このコーデックではなくビットストリームより、パケットストリームを生成するように設計されなければならないことを意味します。そして、それはそのパケットストリームは、各パケットがデコーダ予測追跡の最小の損失で、独立して復号可能であることを保証するために必要な冗長性の最小量を含有します。パケットロスに大きな堅牢性を確保するために、帯域幅のいくつかの小さな量を犠牲にすることは、多くの場合、価値のあるトレードオフであることが認識されています。
It is hoped that, in the long run, new codecs should be produced which can be directly packetised, without the trouble of designing a codec-specific payload format.
長期的には、新しいコーデックはコーデック固有のペイロードフォーマットを設計する手間なしに、直接パケット化することができますが製造されなければならない、ということが期待されます。
It is possible to design generic packetisation formats that do not pay attention to the issues described in this document, but such formats are only suitable for special purpose networks where packet loss can be avoided by careful engineering at the network layer, and are not suited to current best-effort networks.
この文書に記載されている問題に注意を払っていない一般的なパケット化フォーマットを設計することが可能であるが、そのようなフォーマットは、パケット損失がネットワーク層で慎重に操作することによって回避することができ、特別な目的のネットワークにのみ適している、とに適していません現在のベストエフォート型のネットワーク。
The guidelines in this document result in RTP payload formats that are robust in the presence of real world network conditions. Designing payload formats for special purpose networks that assume negligable loss rates will normally result in slightly better compression, but produce formats that are more fragile, thus rendering them easier targets for denial-of-service attacks.
この文書のガイドラインは、現実世界のネットワーク条件の存在下で頑健であるRTPペイロードフォーマットになります。したがって、サービス拒否攻撃のためにそれらを簡単にターゲットをレンダリングし、無視できる損失率は、通常、わずかに良い圧縮につながると仮定しますが、より壊れやすいフォーマットを作る特別な目的のネットワークのためのペイロードフォーマットを設計します。
Designers of payload formats should pay close attention to possible security issues that might arise from poor implementations of their formats, and should be careful to specify the correct behaviour when anomalous conditions arise. Examples include how to process illegal field values, and conditions when there are mismatches between length fields and actual data. Whilst the correct action will normally be to discard the packet, possible such conditions should be brought to the attention of the implementor to ensure that they are trapped properly.
ペイロードフォーマットの設計者は、その形式の貧弱な実装に起因する可能性のあるセキュリティ問題に細心の注意を払う必要があり、かつ異常な状況が発生したときに正しい動作を指定するように注意する必要があります。例としては、長さフィールドと、実際のデータの間に不一致がある場合違法フィールド値、および条件を処理する方法が挙げられます。正しい動作が正常にパケットを破棄するようになりながら、可能な条件は、それらが適切に閉じ込められていることを確認するために、実装者の注意を喚起しなければなりません。
The RTP specification covers encryption of the payload. This issue should not normally be dealt with by payload formats themselves. However, certain payload formats spread information about a particular application data unit over a number of packets, or rely on packets which relate to a number of application data units. Care must be taken when changing the encryption of such streams, since such payload formats may constrain the places in a stream where it is possible to change the encryption key without exposing sensitive data.
RTP仕様は、ペイロードの暗号化をカバーしています。この問題は通常、ペイロードフォーマット自身によって対処すべきではありません。しかし、特定のペイロード・フォーマットは、パケットの数を超える特定のアプリケーションデータユニットについての情報を広め、またはアプリケーションデータ単位の数に関連するパケットに依存しています。そのようなストリームの暗号化を変更する場合、そのようなペイロードフォーマットは、機密データを露出することなく、暗号鍵を変更することができるストリーム内の場所を制約する可能性があるので注意が払わなければなりません。
Designers of payload formats which include FEC should be aware that the automatic addition of FEC in response to packet loss may increase network congestion, leading to a worsening of the problem which the use of FEC was intended to solve. Since this may, at its worst, constitute a denial of service attack, designers of such payload formats should take care that appropriate safeguards are in place to prevent abuse.
FECを含むペイロードフォーマットの設計者は、パケット損失に応じてFECの自動添加がFECの使用を解決することを意図した問題の悪化につながる、ネットワークの輻輳を増大させることができることに注意すべきです。これは、その最悪で、サービス拒否攻撃を構成することができるので、そのようなペイロードフォーマットの設計者は適切な保護措置が虐待を防止するための場所であることに注意する必要があります。
Authors' Addresses
著者のアドレス
Mark Handley AT&T Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA
ICSI、国際コンピュータサイエンス研究所、1947センターストリート、スイート600、バークレー、CA 94704、USAでのインターネットリサーチのためのマーク・ハンドリーAT＆Tセンター
EMail: mjh@aciri.org
メールアドレス：mjh@aciri.org
Colin Perkins Dept of Computer Science, University College London, Gower Street, London WC1E 6BT, UK.
コンピュータサイエンス、ユニバーシティ・カレッジ・ロンドン、ガウアー・ストリート、ロンドンWC1E 6BT、英国のコリンパーキンス部。
EMail: C.Perkins@cs.ucl.ac.uk
メールアドレス：C.Perkins@cs.ucl.ac.uk
Acknowledgments
謝辞
This document is based on experience gained over several years by many people, including Van Jacobson, Steve McCanne, Steve Casner, Henning Schulzrinne, Thierry Turletti, Jonathan Rosenberg and Christian Huitema amongst others.
この文書は、バン・ジェイコブソン、スティーブMcCanne、スティーブCasner、ヘニングSchulzrinneと、ティエリーTurletti、ジョナサン・ローゼンバーグと他の中でクリスチャン・ハイテマを含む多くの人々、によって、数年にわたって得られた経験に基づいています。
References
リファレンス
[1] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[1] Casner、S.とV.ヤコブソンを、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。
[2] D. Clark and D. Tennenhouse, "Architectural Considerations for a New Generation of Network Protocols" Proc ACM Sigcomm 90.
[2] D.クラークとD. Tennenhouse、 "ネットワークプロトコルの新世代のための建築に関する注意事項" PROC ACM SIGCOMM 90。
[3] J. Mahdavi and S. Floyd. "TCP-friendly unicast rate-based flow control". Note sent to end2end-interest mailing list, Jan 1997.
[3] J. MahdaviとS.フロイド。 「TCPフレンドリーなユニキャストレートベースのフロー制御」。注意end2end金利メーリングリストに送信され、1997年1月。
[4] M. Mathis, J. Semske, J. Mahdavi, and T. Ott. "The macro-scopic behavior of the TCP congestion avoidance algorithm". Computer Communication Review, 27(3), July 1997.
[4] M.マシス、J. Semske、J. Mahdavi、及びT.オット。 「TCPの輻輳回避アルゴリズムのマクロSCOPIC行動」。コンピュータコミュニケーションレビュー、27（3）、1997年7月。
[5] J. Nonnenmacher, E. Biersack, Don Towsley, "Parity-Based Loss Recovery for Reliable Multicast Transmission", Proc ACM Sigcomm
[5] J. Nonnenmacher、E. Biersack、ドン・トウズリー、 "高信頼マルチキャスト伝送のためのパリティベースの損失回復"、PROC ACM SIGCOMM
[6] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", Proc. ACM Sigcomm 1998.
[6] J. Padhye、V. Firoiu、D. Towsley、J.黒瀬、 "モデルTCPスループット：簡単なモデルとその実証的検証"、PROC。 ACM SIGCOMM 1998。
[7] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
冗長[7]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、JC、ベガ・ガルシア、A.及びS.フォッシー-Parisis、「RTPペイロードオーディオデータ」、RFC 2198、1997年9月。
[8] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[8]ラマクリシュナン、K.およびS.フロイド、 "IPに明示的輻輳通知（ECN）を追加する提案"、RFC 2481、1999年1月を。
[9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "Real-Time Transport Protocol", RFC 1889, January 1996.
[9] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "リアルタイムトランスポートプロトコル"、RFC 1889、1996年1月。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。