RFC2736 日本語訳

Network Working Group                                            M. Handley
Request for Comments: 2736                                            ACIRI
BCP: 36                                                          C. Perkins
Category: Best Current Practice                                         UCL
                                                              December 1999

コメントを求めるワーキンググループM.ハンドレー要求をネットワークでつないでください: 2736ACIRI BCP: 36C.パーキンスカテゴリ: 最も良い現在の練習UCL1999年12月

      Guidelines for Writers of RTP Payload Format Specifications

RTP有効搭載量書式仕様の作家へのガイドライン

Status of this Memo

この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.

Copyright(C)インターネット協会(1999)。 All rights reserved。

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有効搭載量Format仕様の作者を補助するのを目的とされた一般的ガイドラインを提供します。 これらのガイドラインは、開発の間、発展したのでRTPと共に行われた経験のいくつかを捕らえるのを試みます。

1.  Introduction

1. 序論

   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]有効搭載量Format仕様の作者を補助するのを目的とされた一般的ガイドラインを提供します。 これらのガイドラインは、開発の間、発展したので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.

本書では概説された原則は、ほとんどすべてのデータ型に適切ですが、明快ためにオーディオとビデオコーデックに関する例で縁どられます。

2.  Background

2. バックグラウンド

   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-

RTPはApplication Level Framing(ALF)、クラークによって説明された1番目、およびTennenhouse[2]の概念の周りで設計されました。 主要な議論の基本的なALFはアプリケーションがmisorderedされたか無くなっているパケットに対処できるかもしれない多くの異なった方法があるということです。 損失を無視するのから欠測値(バッファかそれを作り直すのによる)を再送することまで欠測値に取って代わる新しいデータを送ることへのこれらの範囲。 アプリケーションには、トランスポート・プロトコルが「アプリケーションデータユニット」(ADUs)のデータに対処している場合にだけ、この選択があります。 ADUが外に処理できるデータを含んでいる、-、-

Handley & Perkins        Best Current Practice                  [Page 1]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999

RTP有効搭載量形式1999年12月の作家へのハンドレーとパーキンス最も良い現在の習慣[1ページ]RFC2736のガイドライン

   order with respect to other ADUs.  Thus the ADU is the minimum unit
   of error recovery.

他のADUsに関して、注文してください。 したがって、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がすぐに受信機で処理できるくらいの情報を含んでいるということです。 例はビデオストリームです。(そこでは、前のADUsを受け取ったかどうかにかかわらず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接続を基本にしたネットワークに関するかなり良い性能を実現できるということです。

3.  Channel Characteristics

3. チャネル特性

   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.

リンクの損失の特性は短い時間間隔にわたってばらつきが大きいかもしれません。

Handley & Perkins        Best Current Practice                  [Page 2]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999

RTP有効搭載量形式1999年12月の作家へのハンドレーとパーキンス最も良い現在の習慣[2ページ]RFC2736のガイドライン

   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.

断片化はそれがまれな出来事であるなら悲惨な現象ではありませんが、ネットワークの有効な損失率をかなり増加させて、goodputを減少させるのに従って、IP断片化に依存するのは、悪いデザイン戦略です。 これは次に、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のためにこれは効果です--交差交通、およびルーティング変化の後ろに列に並ばせられることによって引き起こされたジター。 前者は再生バッファを使用することによって特徴付けて、補うのにおいて可能ですが、後者は、予測するのが不可能であって優雅に収容するのは難しいです。

4.  Guidelines

4. ガイドライン

   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.

これらの要件の1番目はインターネットの性質に基づいています。 非ベストエフォート型のサービスの慎重な食糧を供給するか使用で低損失率を生産するためにインターネットの地域を設計するのが可能であるかもしれませんが、原則として、これらの専用環境のためにペイロード形式を設計するべきではありません。 有効搭載量形式は、公共のインターネットでベストエフォート型サービスで使用されるように設計されるべきであり、その結果、適度の損失率を見ると予想するべきです。 例えば、5%の損失率は並はずれていません。 私たちは、TCP定常状態モデル[3][4][6]が1KByteパケットサイズと200msが往復であることでの時間が180Kbit/sの周りでスループットを達成するTCPに結果になる5%の損失率にそれを示すことに注意します。 より高い損失率、より小さいパケットサイズ、または、より大きいRTTが、TCPがデータ信号速度を下ろすのを抑制するのに必要です。 それはだいたい、多くのRTP流れが共存しなければならないバックグラウンドの損失を起こしているTCP交通です。 明白な混雑通知(電子証券取引ネットワーク)[8]がなければ、インターネットのベストエフォート型地域の本質的な特性であると損失を考えなければなりません。

Handley & Perkins        Best Current Practice                  [Page 3]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999

RTP有効搭載量形式1999年12月の作家へのハンドレーとパーキンス最も良い現在の習慣[3ページ]RFC2736のガイドライン

   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がどう損失を切り抜けるはずであるかに関してこれらの要件の2番目は、より明白です。 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.

+ コーデックのデータの最小ユニットが決してpacketisedされるべきでないので、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オーディオのために、フレームはオーディオの20msに対応しています。 H.261ビデオに関しては、それは、Blocks(GOB)のGroup、または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.

PCMに関しては、オーディオがADUサイズが1バイトであるのでどのようにpacketisedされるかは重要ではありません。 GSMオーディオのために、任意のpacketisationは2つのパケットの上で20msフレームを分けるでしょう。パケットは1つのパケットが失われたなら、損失の前後にパケットの部分的なフレームが無意味であることを意味するでしょう。 受信機がそれらを捨てなければならないので、これは、また、なくなったパケットのビットがなくされただけではなく、事実上、ボトルネック帯域幅を使用した隣接しているパケットの追加ビットがなくされもしたことを意味します。 代わりに、私たちはパケットのいくつかの完全なGSMフレームを含んでいるのによるpacketise 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

長い間、GOBsはH.261仕様が3KBytes次第にさせます、彼らがこれよりたいてい小さいのですが。 aであるときに、私たちが合うとブロックのグループをパケットに挿入して、任意により多くのGOBより多くのtwoパケットを分けるべきであると思われるかもしれません。

Handley & Perkins        Best Current Practice                  [Page 4]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999

RTP有効搭載量形式1999年12月の作家へのハンドレーとパーキンス最も良い現在の習慣[4ページ]RFC2736のガイドライン

   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パケットは受信機に到着して、捨てなければならないところにあることをまだ意味しています--避けたいと思う損失乗数効果。 事実上、macroblocksと呼ばれるH.261ビットストリームにはGOBsより小さい単位がありますが、GOBの始まりから分析しないで、彼らは身元保証可能ではありません。 しかしながら、それぞれのパケットの始めで少しの追加情報を提供するなら、私たちは通常、GOBの始まりから分析することによって見つけられる情報を復職させることができます、そして、macroblock境界におけるデータ・ストリームを分けるのによるpacketise H.261を復職させることができます。 これはGOB packetisationよりH.261ためのそれほど明白でないpacketisationですが、それは、受信機のわずかに賢いdepacketiserが損失になったRTPパケットの流れから有効なH.261 bitstreamを再建して、到着したデータのどれかを捨てる必要はないことができることを意味します。

   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して、したがって、パケットがコーデックフレームの整数倍数から成るのは、最適でないかもしれません、パケット損失直後受け取られたパケットを解読できますが、デコーダ予言者が現在エンコーダと調子外れであるので起こされたオーディオストリームの始まりが不正確であるので(したがって、信号を歪めてください)。 原則として、あらゆるパケットの始まりに取り付けられたヘッダーを使用することでデコーダの内部の状態のすべてを加えることができるでしょうが、下側のビット伝送速度encodingsに関して、この状態が非常に実質的であるので、ビット伝送速度はもう低くはありません。 しかしながら、通常、妥協を見つけることができます、大いに減少しているフォームのデコーダ州が正確にエンコーダ予言者を休養させるというわけではないあらゆるパケットで送りますが、前のパケットが無くなるとき発生したひずみの大きさと持続時間を減少させるところで。 そのような圧縮された状態は定義上問題のコーデックに非常に依存しています。 したがって、私たちは以下を推薦します。

   +  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.

デコーダが内部のデータ駆動型を含んでいるところに+ encodingsのための有効搭載量形式は、通常、エンコーダ状態を追跡する試みが、ひずみを減少させるこの状態のパケット損失の後の最も重要な要素を伝える小さい追加ヘッダーを含んでいると考えるはずであると述べます。

Handley & Perkins        Best Current Practice                  [Page 5]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999

RTP有効搭載量形式1999年12月の作家へのハンドレーとパーキンス最も良い現在の習慣[5ページ]RFC2736のガイドライン

   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:

コーデックパラメタとそれらがペイロード形式で含まれるべきであるかどうかで同様の問題は起こります。 例が圧縮のためのhuffmanテーブルの選択を持っているコーデックをもってあります。 コーデックはコード化にhuffmanテーブル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.

どのメカニズムを使用したらよいかは支持するためには中間のセッション応用層適合におけるパラメタを変えるユーティリティによります。 しかしながら、一般に、バンドの外で中間のセッションのときにパラメタを変える合図を使用するのはメディアの流れにパラメータ変動を連動させるという問題のためにお勧めできないことになっています。

4.1.  RTP Header Extensions

4.1. RTPヘッダー拡張子

   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ヘッダー拡張子の使用は適切です。

4.2.  Header Compression

4.2. ヘッダー圧縮

   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

また、ペイロード形式のデザイナーもRTPヘッダー圧縮[1]の必要性を意識しているべきです。 連続したパケットの間の恒常価値によるRTPタイムスタンプ増分であるときに、特に、圧縮アルゴリズムは最もよく機能します。 タイムスタンプ増分がそのようなものですが、故障していた状態で送付パケットを当てにする有効搭載量形式

Handley & Perkins        Best Current Practice                  [Page 6]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999

RTP有効搭載量形式1999年12月の作家へのハンドレーとパーキンス最も良い現在の習慣[6ページ]RFC2736のガイドライン

   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.

定数はオーダーをそれほどパケットを送るものよりよくない圧縮しそうにはありません。 FEC情報のためにペイロード形式を設計するとき、これはたいてい、問題です、また、いくつかのビデオコーデックが減少している圧縮を犠牲にしてパケットの不適切なトランスミッションに依存しますが。 そのような不適切なトランスミッションはいくつかの場合最も良い解決策であるかもしれませんが、ペイロード形式デザイナーは可能であるところで代替の解決策を探す督励です。

5.  Summary

5. 概要

   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のためにパケット・フォーマットを設計するのは、些細なタスクではありません。 かかわったコーデックに関する詳細な知識は、通常、損失に弾力がある形式を設計できるのが必要であり、不適当なpacketisationのため損失倍率効果を導入しないで、またパケット損失の後に不要なひずみを導入しません。 私たちは、かなりの努力が問題のコーデックによく合わせるパケット・フォーマットを設計するのにそそがれるべきであると信じています。 通常、これは送付者と受信機でわずか少量の処理を必要としますが、典型的なインターネット環境で作動するとき、結果は大いに改良された品質であるかもしれません。

   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.

結局直接packetisedされることができる新しいコーデックは生産されるべきです、コーデック特有のペイロード形式を設計するという問題なしで望まれています。

   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.

本書では説明された問題に注意を向けない一般的なpacketisation形式を設計するのが可能ですが、そのような形式は、単にネットワーク層における慎重な工学でパケット損失を避けることができる専用ネットワークに適して、現在のベストエフォート型ネットワークに合っていません。

6.  Security Considerations

6. セキュリティ問題

   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ペイロード形式をもたらします。 negligable損失率を仮定する専用ネットワークのためのペイロード形式を設計すると、わずかに良い圧縮は通常もたらされるでしょうが、よりこわれやすい形式を発生させてください、その結果、サービス不能攻撃のための、より簡単な目標をそれらに表します。

Handley & Perkins        Best Current Practice                  [Page 7]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999

RTP有効搭載量形式1999年12月の作家へのハンドレーとパーキンス最も良い現在の習慣[7ページ]RFC2736のガイドライン

   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でのインターネット調査のためのマークハンドレーAT&Tセンター、国際電子計算機科学協会、1947は通り、スイート600、バークレー、カリフォルニア 94704、米国を中心に置きます。

   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

Handley & Perkins        Best Current Practice                  [Page 8]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999

RTP有効搭載量形式1999年12月の作家へのハンドレーとパーキンス最も良い現在の習慣[8ページ]RFC2736のガイドライン

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、ジョナサン・ローゼンバーグ、およびクリスチャンのHuitemaを含んでいて。

References

参照

   [1]  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
        Low-Speed Serial Links", RFC 2508, February 1999.

[1]Casner、S.、およびRFC2508、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 Sigcomm90。

   [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輻輳回避アルゴリズムの巨視的な振舞い。」 コンピュータコミュニケーションレビュー、27(3)、1997年7月。

   [5]  J. Nonnenmacher, E. Biersack, Don Towsley, "Parity-Based Loss
        Recovery for Reliable Multicast Transmission", Proc ACM Sigcomm

[5] Proc ACM Sigcomm、Towsley、「信頼できるマルチキャスト送信のためのパリティベースの損失回復」をJ.Nonnenmacher(E.Biersack)は身につけます。

   [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対Firoiu、D.Towsley、J.黒瀬、「モデルTCPスループット:」 「Simple ModelとそのEmpirical Validation」、Proc。 ACM Sigcomm1998。

   [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とJ.C.、ベガ-ガルシアとA.とS.堀-Parisis、「余分なオーディオデータのためのRTP有効搭載量」RFC2198(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.フロイド、「Explicit Congestion Notification(電子証券取引ネットワーク)をIPに追加するProposal」RFC2481、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.、および「リアルタイムのトランスポート・プロトコル」、RFC1889、1996年1月対ジェーコブソン

Handley & Perkins        Best Current Practice                  [Page 9]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999

RTP有効搭載量形式1999年12月の作家へのハンドレーとパーキンス最も良い現在の習慣[9ページ]RFC2736のガイドライン

Full Copyright Statement

完全な著作権宣言文

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Handley & Perkins        Best Current Practice                 [Page 10]

ハンドレーとパーキンスBest現在の習慣[10ページ]