[要約] RFC 2736は、RTPペイロード形式仕様の作成者向けのガイドラインです。このRFCの目的は、一貫性と相互運用性を確保するために、RTPペイロード形式の仕様書の作成方法に関する指針を提供することです。
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
RTPペイロード形式の仕様の作家のためのガイドライン
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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が開発中に進化したため、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が開発中に進化したため、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は、アプリケーションレベルフレーミング（ALF）の概念を中心に設計され、最初にClarkとTennenhouse [2]によって記述されました。ALFの根底にある重要な議論は、アプリケーションが誤ったパケットまたは紛失したパケットに対処できる可能性のあるさまざまな方法があるということです。これらは、損失を無視することから、欠落データの再配置（バッファーまたは再生による）、および欠落データに取って代わる新しいデータの送信にまで及びます。アプリケーションには、トランスポートプロトコルが「アプリケーションデータユニット」（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.
Adusの輸送プロトコルの重要な特性は、各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
o 基礎となるネットワークのMTUを超えると、パケットが断片化されます
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の断片化に依存することは、ネットワークの有効損失率を大幅に増加させ、Goodputを減らすため、悪い設計戦略です。これは、1つのフラグメントが失われた場合、残りのフラグメント（ボトルネックの帯域幅を使い果たした）がレシーバーによって破棄される必要があるためです。また、フラグメンテーションを実行するルーターと、フラグメントを再組み立てる最終システムに追加の負荷をかけます。
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人のホスト間の輸送時間は一定ではないことに注意してください。これは、トラフィックを横断する背後で列に並んでいることによって引き起こされるジッターとルーティングの変更による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.
これらの要件の最初は、インターネットの性質に基づいています。慎重なプロビジョニングまたは非ベストエフォルトサービスの使用により、インターネットの一部を設計して低損失率を生成することは可能かもしれませんが、原則として、これらの特別な目的環境向けにペイロード形式を設計すべきではありません。ペイロードフォーマットは、Best Effect Serviceを使用してPublic Internetで使用するように設計する必要があります。したがって、適度な損失率が表示されることを期待する必要があります。たとえば、5％の損失率は珍しくありません。TCPの定常状態モデル[3] [4] [6]は、1kbyteパケットサイズと200msの往復時間の5％の損失率が、TCPが約180kbit/sのスループットを達成することを示していることに注意してください。データレートを削減するためにTCPを制約するには、より高い損失率、パケットサイズ、またはより大きなRTTが必要です。ほとんどの場合、多くの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:
これらの要件の2番目は、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.
+ Codecの最小ユニットのデータは、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の断片化に依存してはなりません。代わりに、独自の断片化メカニズムを定義する必要があります。このようなメカニズムには、フラグメントの解読を可能にするコーデック固有の情報が含まれる場合があります。あるいは、Codecに依存しないパケットレベルのフォワードエラー補正[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ビデオフレームの12分の1です。
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.
PCMの場合、ADUサイズは1バイトであるため、オーディオがどのようにパケット化されるかは関係ありません。GSMオーディオの場合、任意のパケットは2つのパケットに20ミリ秒のフレームを分割します。つまり、1つのパケットが失われた場合、損失の前後のパケットの部分的なフレームは無意味です。これは、欠落しているパケットのビットが失われただけでなく、ボトルネック帯域幅を使用した隣接するパケットの追加ビットも、レシーバーがそれらを捨てる必要があるためにも効果的に失われたことを意味します。代わりに、いくつかの完全な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 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.
H.261仕様により、ゴブは最大3kバイトの長さになりますが、ほとんどの場合、これよりも小さくなります。ブロックのグループをフィットしたときにパケットに挿入し、ゴブが大きい場合は2つ以上のパケットにGOBを任意に分割する必要があると考えられるかもしれません。H.261ペイロード形式の最初のバージョンでは、これが行われたことです。ただし、これは、H.261パケットが受信機に到着し、他のパケットが失われたため廃棄する必要がある状況があることを意味します。これは、避けたい損失乗数効果です。実際、マクロブロックと呼ばれるH.261ビットストリームにはゴブよりも小さなユニットがありますが、GOBの開始から解析せずに識別できません。ただし、各パケットの開始時に少し追加の情報を提供すると、GOBの開始から解析することで通常見つかる情報を回復でき、マクロブロックの境界上のデータストリームを分割することでH.261をパケット化できます。これは、H.261のGOBパケット化よりも明白なパケット化ではありませんが、レシーバーのわずかにスマートな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などの多くのオーディオコーデックはこの形式です。通常、それらは損失耐性であり、損失後、予測係数が減衰しているため、一定の時間の後、損失によって誘導される予測誤差が消えます。テレフォニーサービス向けに設計されたほとんどのコーデックは、デコーダー予測子状態が永続的に正しくないままでないビットエラーに対処するように設計されているため、この形式です。パケットの複数のコーデックフレームで構成されるように、これらの形式をパケット化するだけで、パケットの損失をデコードできた直後に受信したパケットは最適ではない可能性があります。なぜなら、デコーダー予測子はエンコーダーでステップが外れているためです。原則として、すべてのパケットの開始時にヘッダーを使用してデコーダーのすべての内部状態を追加できますが、ビットレートエンコーディングが低い場合、この状態は非常に重要であるため、ビットレートが低くなります。ただし、通常、妥協点が見つかります。デコーダー状態の大幅に縮小された形態は、すべてのパケットで送信されます。これにより、エンコーダー予測子は正確に再現されませんが、前のパケットが失われたときに生成される歪みの大きさと持続時間を短縮します。このような圧縮状態は、定義上、問題のコーデックに大きく依存しています。したがって、お勧めします：
+ 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:
同様の問題は、Codecパラメーターと、ペイロード形式に含めるべきかどうかに関係しています。例としては、圧縮用のハフマンテーブルを選択できるコーデックがあります。コーデックは、エンコードにハフマン表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プロファイルまたはプロファイル拡張機能の定義が必要です。また、たとえば[7]などのFECスキームを使用することを困難にします。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.
ペイロード形式の設計者は、RTPヘッダー圧縮のニーズにも注意する必要があります[1]。特に、圧縮アルゴリズムは、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で使用する新しいコーデックの設計者は、コーデックの出力を「自然にパケット化可能」にすることを検討する必要があります。これは、コーデックが少しストリームではなくパケットストリームを生成するように設計する必要があることを意味します。そして、そのパケットストリームには、デコーダー予測子追跡を最小限に抑えて、各パケットが独立してデコードできるようにするために必要な最小限の冗長性が含まれています。パケット損失に対する堅牢性を高めるために、少量の帯域幅を犠牲にすることは、しばしば価値のあるトレードオフであることが認識されています。
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ペイロードフォーマットは、実際のネットワーク条件の存在下で堅牢な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
マークハンドリーAT＆TセンターICSIのインターネット研究センター、国際コンピューターサイエンス研究所、1947年センターストリート、スイート600、バークレー、カリフォルニア州94704、米国
EMail: mjh@aciri.org
Colin Perkins Dept of Computer Science, University College London, Gower Street, London WC1E 6BT, UK.
Colin Perkins Dept of Computer Science、University College London、Gower Street、ロンドンWC1E 6BT、英国。
EMail: 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.
この文書は、ヴァン・ジェイコブソン、スティーブ・マッキャンヌ、スティーブ・カスナー、ヘニング・シュルツリン、ティエリー・ターレット、ジョナサン・ローゼンバーグ、クリスチャン・フイテマなど、多くの人々が数年にわたって得た経験に基づいています。
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. Jacobson、「低速シリアルリンク用のIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[2] D. Clark and D. Tennenhouse, "Architectural Considerations for a New Generation of Network Protocols" Proc ACM Sigcomm 90.
[2] D.クラークとD.テネンハウス、「新世代のネットワークプロトコルに対する建築上の考慮事項」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.マフダビとS.フロイド。「TCPに優しいユニキャストレートベースのフロー制御」。1997年1月、End2end-Interestメーリングリストに送信されたメモ。
[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. Mathis、J。Semske、J。Mahdavi、およびT. Ott。「TCP混雑回避アルゴリズムのマクロスコピック挙動」。コンピューター通信レビュー、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、Don Towsley、「信頼性の高いマルチキャストトランスミッションのパリティベースの損失回復」、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。Kurose、「モデリング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] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.C.、Vega-Garcia、A。and S. Fosse-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] Ramakrishnan、K。およびS. Floyd、「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.、Frederick、R。and V. Jacobson、「リアルタイム輸送プロトコル」、RFC 1889、1996年1月。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。