[要約] RFC 4587は、H.261ビデオストリームのRTPペイロード形式に関する仕様です。このRFCの目的は、H.261ビデオストリームをRTPパケットにエンコードするための標準的な方法を提供することです。
Network Working Group R. Even
Request for Comments: 4587 Polycom
Obsoletes: 2032 August 2006
Category: Standards Track
RTP Payload Format for H.261 Video Streams
H.261ビデオストリームのRTPペイロード形式
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
Abstract
概要
This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP.
このメモは、リアルタイムトランスポートプロトコル、RTPを使用してトランスポートするためにH.261ビデオストリームをパケット化するスキームについて説明します。
The memo also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.261 video codec. A media type registration is included for this payload format.
このメモは、H.261ビデオコーデックをサポートするために必要なセッション記述プロトコル（SDP）パラメータの構文とセマンティクスについても説明しています。このペイロード形式には、メディアタイプの登録が含まれています。
This specification obsoletes RFC 2032.
この仕様はRFC 2032を廃止します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Structure of the Packet Stream ..................................3
3.1. Overview of the ITU-T Recommendation H.261 .................3
3.2. Considerations for Packetization ...........................4
4. Specification of the Packetization Scheme .......................5
4.1. Usage of RTP ...............................................5
4.2. Recommendations for Operation with Hardware Codecs .........8
5. Packet Loss Issues ..............................................9
6. IANA Considerations ............................................10
6.1. Media Type Registrations ..................................10
6.1.1. Registration of MIME Media Type video/H261 .........10
6.2. SDP Parameters ............................................12
6.2.1. Usage with the SDP Offer Answer Model ..............12
7. Backward Compatibility to RFC 2032 .............................13
7.1. Optional H.261-Specific Control Packets ...................13
7.2. New SDP Optional Parameters ...............................13
8. Security Considerations ........................................14
9. Acknowledgements ...............................................14
10. Changes from RFC 2032 .........................................14
11. References ....................................................15
11.1. Normative References .....................................15
11.2. Informative References ...................................15
ITU-T Recommendation H.261 [H261] specifies the encoding used by ITU-T-compliant video-conference codecs. Although this encoding was originally specified for fixed-data rate Integrated Services Digital Network (ISDN) circuits, experiments [INRIA], [MICE] have shown that they can also be used over packet-switched networks, such as the Internet.
ITU-T勧告H.261 [H261]は、ITU-T準拠のビデオ会議コーデックで使用されるエンコーディングを指定しています。このエンコーディングは元々、固定データレートの統合デジタルサービス通信網（ISDN）回線用に指定されていましたが、実験[INRIA]、[MICE]は、インターネットなどのパケット交換ネットワークでも使用できることを示しています。
The purpose of this memo is to specify the RTP payload format for encapsulating H.261 video streams in RTP [RFC3550].
このメモの目的は、RTPでH.261ビデオストリームをカプセル化するためのRTPペイロード形式を指定することです[RFC3550]。
This document obsoletes RFC 2032 and updates the "video/h261" media type that was registered in RFC 3555.
このドキュメントはRFC 2032を廃止し、RFC 3555に登録された「video / h261」メディアタイプを更新します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant RTP implementations.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]の説明に従って解釈され、準拠RTP実装の要件レベルを示します。
The H.261 coding is organized as a hierarchy of groupings. The video stream is composed of a sequence of images, or frames, which are themselves organized as a set of Groups of Blocks (GOB). Note that H.261 "pictures" are referred to as "frames" in this document. Each GOB holds a set of 3 lines of 11 macro blocks (MB). Each MB carries information on a group of 16x16 pixels: luminance information is specified for 4 blocks of 8x8 pixels, whereas chrominance information is given by two "red" and "blue" color difference components at a resolution of only 8x8 pixels. These components and the codes representing their sampled values are as defined in ITU-R Recommendation 601 [BT601].
H.261コーディングは、グループ化の階層として編成されています。ビデオストリームは、一連の画像またはフレームで構成され、それ自体が一連のブロックグループ（GOB）として編成されます。このドキュメントでは、H.261の「画像」を「フレーム」と呼びます。各GOBは、11マクロブロック（MB）の3行のセットを保持します。各MBは、16x16ピクセルのグループに関する情報を保持します。輝度情報は、8x8ピクセルの4つのブロックに対して指定されますが、クロミナンス情報は、8x8ピクセルの解像度で2つの「赤」と「青」の色差コンポーネントによって提供されます。これらのコンポーネントとそれらのサンプル値を表すコードは、ITU-R勧告601 [BT601]で定義されています。
This grouping is used to specify information at each level of the hierarchy:
このグループ化は、階層の各レベルで情報を指定するために使用されます。
- At the frame level, one specifies information such as the delay from the previous frame, the image format, and various indicators.
- フレームレベルでは、前のフレームからの遅延、画像形式、さまざまなインジケーターなどの情報を指定します。
- At the GOB level, one specifies the GOB number and the default quantifier that will be used for the MBs.
- GOBレベルでは、MBに使用されるGOB番号とデフォルトの数量詞を指定します。
- At the MB level, one specifies which blocks are present and which did not change, and, optionally, a quantifier and motion vectors.
- MBレベルでは、存在するブロックと変化しなかったブロックを指定し、オプションで数量詞と動きベクトルを指定します。
Blocks that have changed are encoded by computing the discrete cosine transform (DCT) of their coefficients, which are then quantized and Huffman encoded (Variable Length Codes).
変更されたブロックは、それらの係数の離散コサイン変換（DCT）を計算することによってエンコードされ、量子化されてハフマンエンコードされます（可変長コード）。
The H.261 Huffman encoding includes a special "GOB start" pattern, which is a word of 16 bits, 0000 0000 0000 0001. This pattern is included at the beginning of each GOB header (and also at the beginning of each frame header) to mark the separation between two GOBs and is in fact used as an indicator that the current GOB is terminated. The encoding also includes a stuffing pattern, composed of seven zero bits followed by four bits with a value of one; that stuffing pattern can only be entered between the encoding of MBs, or just before the GOB separator.
H.261ハフマンエンコーディングには、16ビットのワードである0000 0000 0000 0001である特別な「GOBスタート」パターンが含まれています。このパターンは、各GOBヘッダーの先頭（および各フレームヘッダーの先頭）に含まれています。 2つのGOB間の分離をマークし、実際には現在のGOBが終了したことを示すインジケータとして使用されます。エンコーディングには、7つのゼロビットとそれに続く値が1の4ビットで構成されるスタッフィングパターンも含まれます。そのスタッフィングパターンは、MBのエンコーディングの間、またはGOBセパレータの直前にのみ入力できます。
H.261 codecs designed for operation over ISDN circuits produce a bit stream composed of several levels of encoding specified by H.261 and companion recommendations. The bits resulting from the Huffman encoding are arranged in 512-bit frames, containing 2 bits of synchronization, 492 bits of data and 18 bits of error correcting code. The 512-bit frames are then interlaced with an audio stream and transmitted over px 64 kbps circuits according to specification H.221 [H221].
ISDN回線での動作用に設計されたH.261コーデックは、H.261で指定されているいくつかのレベルのエンコーディングと関連する推奨事項で構成されるビットストリームを生成します。ハフマン符号化から得られたビットは、512ビットのフレームに配置され、2ビットの同期、492ビットのデータ、18ビットのエラー訂正コードを含みます。その後、512ビットフレームはオーディオストリームとインターレースされ、仕様H.221 [H221]に従ってpx 64 kbps回線で送信されます。
For transmitting over the Internet, we will directly consider the output of the Huffman encoding. All the bits produced by the Huffman encoding stage will be included in the packet. We will not carry the 512-bit frames, as protection against bit errors can be obtained by other means. Similarly, we will not attempt to multiplex audio and video signals in the same packets, as UDP and RTP provide a much more suitable way to achieve multiplexing.
インターネットで送信する場合、ハフマンエンコーディングの出力を直接考慮します。ハフマンエンコーディングステージで生成されたすべてのビットがパケットに含まれます。 512ビットフレームは、他の方法でビットエラーに対する保護を得ることができるため、転送しません。同様に、UDPとRTPは多重化を実現するためのより適切な方法を提供するため、オーディオとビデオ信号を同じパケットに多重化しようとはしません。
Directly transmitting the result of the Huffman encoding over an unreliable stream of UDP datagrams would, however, have poor error resistance characteristics. The result of the hierarchical structure of the H.261 bit stream is that one needs to receive the information present in the frame header to decode the GOBs, as well as the information present in the GOB header to decode the MBs. Without precautions, this would mean that one has to receive all the packets that carry an image in order to decode its components properly.
ただし、信頼性の低いUDPデータグラムのストリームを介してハフマンエンコーディングの結果を直接送信すると、エラー耐性が低下します。 H.261ビットストリームの階層構造の結果、GOBをデコードするにはフレームヘッダーにある情報を受信し、MBをデコードするにはGOBヘッダーにある情報を受信する必要があります。予防策がなければ、コンポーネントを適切にデコードするために、画像を運ぶすべてのパケットを受信する必要があることを意味します。
If each image could be carried in a single packet, this requirement would not create a problem. However, a video image or even one GOB by itself can sometimes be too large to fit in a single packet.
各画像を1つのパケットで運ぶことができる場合、この要件は問題を引き起こしません。ただし、ビデオ画像または1つのGOBだけでは、1つのパケットに収まりきらない場合があります。
Therefore, the MB is taken as the unit of fragmentation. Packets must start and end on an MB boundary; that is, an MB cannot be split across multiple packets. Multiple MBs may be carried in a single packet when they will fit within the maximal packet size allowed. This practice is recommended to reduce the packet send rate and packet overhead.
したがって、MBは断片化の単位と見なされます。パケットはMB境界で開始および終了する必要があります。つまり、MBを複数のパケットに分割することはできません。許可された最大パケットサイズ内に収まる場合、複数のMBが1つのパケットで伝送されます。この方法は、パケット送信速度とパケットオーバーヘッドを減らすために推奨されます。
To allow each packet to be processed independently for efficient resynchronization in the presence of packet losses, some state information from the frame header and GOB header is carried with each packet to allow the MBs in that packet to be decoded. This state information includes the GOB number in effect at the start of the packet, the macroblock address predictor (i.e., the last macroblock address (MBA) encoded in the previous packet), the quantizer value in effect prior to the start of this packet (GQUANT, MQUANT, or zero in the case of a beginning of GOB) and the reference motion vector data (MVD) for computing the true MVDs contained within this packet. The bit stream cannot be fragmented between a GOB header and MB 1 of that GOB.
パケット損失がある場合に効率的に再同期するために、各パケットを個別に処理できるようにするために、フレームヘッダーとGOBヘッダーからの状態情報が各パケットとともに伝送され、そのパケットのMBをデコードできます。この状態情報には、パケットの開始時に有効なGOB番号、マクロブロックアドレス予測子（つまり、前のパケットでエンコードされた最後のマクロブロックアドレス（MBA））、このパケットの開始前に有効な量子化値（ GQUANT、MQUANT、またはGOBの始まりの場合はゼロ）、およびこのパケットに含まれる真のMVDを計算するための参照モーションベクトルデータ（MVD）。 GOBヘッダーとそのGOBのMB 1の間でビットストリームをフラグメント化することはできません。
Moreover, since the compressed MB may not fill an integer number of octets, the data header contains two 3-bit integers, SBIT and EBIT, to indicate the number of unused bits in the first and last octets of the H.261 data, respectively.
さらに、圧縮されたMBは整数のオクテットを満たすことができないため、データヘッダーには2つの3ビット整数、SBITとEBITが含まれ、それぞれH.261データの最初と最後のオクテットの未使用ビット数を示します。 。
Each RTP packet starts with a fixed RTP header, as explained in RFC 3550 [RFC3550]. The following fields of the RTP fixed header used for H.261 video streams are further emphasized here:
RFC 3550 [RFC3550]で説明されているように、各RTPパケットは固定のRTPヘッダーで始まります。 H.261ビデオストリームに使用されるRTP固定ヘッダーの次のフィールドは、ここでさらに強調されています。
- Payload type. The assignment of an RTP payload type for this packet format is outside the scope of this document and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or, if that is not done, then a payload type in the dynamic range shall be chosen.
- ペイロードタイプ。このパケット形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外であり、ここでは指定しません。特定のクラスのアプリケーションのRTPプロファイルがこのエンコーディングのペイロードタイプを割り当てることが期待されます。それが行われない場合は、ダイナミックレンジのペイロードタイプが選択されます。
- The RTP timestamp encodes the sampling instant of the first video image contained in the RTP data packet. If a video image occupies more than one packet, the timestamp SHALL be the same on all of those packets. Packets from different video images MUST have a different timestamp so that frames may be distinguished by the timestamp. For H.261 video streams, the RTP timestamp is based on a 90-kHz clock. This clock rate is a multiple of the natural H.261 frame rate (i.e., 30000/1001 or approximately 29.97 Hz). That way, for each frame time, the clock is just incremented by the multiple, and this removes inaccuracy in calculating the timestamp. Furthermore, the initial value of the timestamp MUST be random (unpredictable) to make known-plaintext attacks on encryption more difficult; see RTP [RFC3550]. Note that if multiple frames are encoded in a packet (e.g., when there are very few changes between two images), it is necessary to calculate display times for the frames after the first, using the timing information in the H.261 frame header. This is required because the RTP timestamp only gives the display time of the first frame in the packet.
-RTPタイムスタンプは、RTPデータパケットに含まれる最初のビデオ画像のサンプリングインスタントをエンコードします。ビデオ画像が複数のパケットを占める場合、タイムスタンプはそれらすべてのパケットで同じである必要があります。フレームがタイムスタンプによって区別されるように、異なるビデオ画像からのパケットは異なるタイムスタンプを持つ必要があります。 H.261ビデオストリームの場合、RTPタイムスタンプは90 kHzクロックに基づいています。このクロックレートは、自然なH.261フレームレートの倍数です（つまり、30000/1001または約29.97 Hz）。このようにして、フレーム時間ごとに、クロックは倍数だけ増分され、これによりタイムスタンプの計算の不正確さが取り除かれます。さらに、暗号化に対する既知の平文攻撃をより困難にするために、タイムスタンプの初期値はランダム（予測不可能）でなければなりません（MUST）。 RTP [RFC3550]を参照してください。複数のフレームがパケットでエンコードされている場合（2つの画像間の変更がほとんどない場合など）、H.261フレームヘッダーのタイミング情報を使用して、最初のフレーム以降のフレームの表示時間を計算する必要があることに注意してください。これは、RTPタイムスタンプがパケットの最初のフレームの表示時間のみを提供するために必要です。
- The marker bit of the RTP header MUST be set to one in the last packet of a video frame; otherwise, it MUST be zero. Thus, it is not necessary to wait for a following packet (which contains the start code that terminates the current frame) to detect that a new frame should be displayed.
- RTPヘッダーのマーカービットは、ビデオフレームの最後のパケットで1に設定する必要があります。それ以外の場合は、ゼロでなければなりません。したがって、新しいフレームを表示する必要があることを検出するために、次のパケット（現在のフレームを終了する開始コードを含む）を待つ必要はありません。
The H.261 data SHALL follow the RTP header, as in the following:
H.261データは、次のように、RTPヘッダーに続く必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. RTP header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.261 header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.261 stream ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The H.261 header is defined as follows:
H.261ヘッダーは次のように定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SBIT |EBIT |I|V| GOBN | MBAP | QUANT | HMVD | VMVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the H.261 header have the following meanings:
H.261ヘッダーのフィールドには、次の意味があります。
Start bit position (SBIT): 3 bits
開始ビット位置（SBIT）：3ビット
Number of most significant bits that should be ignored in the first data octet.
最初のデータオクテットで無視する必要がある最上位ビットの数。
End bit position (EBIT): 3 bits
終了ビット位置（EBIT）：3ビット
Number of least significant bits that should be ignored in the last data octet.
最後のデータオクテットで無視する必要がある最下位ビットの数。
INTRA-frame encoded data (I): 1 bit
フレーム内エンコードデータ（I）：1ビット
Set to 1 if this stream contains only INTRA-frame coded blocks. Set to 0 if this stream may or may not contain INTRA-frame coded blocks. The meaning of this bit should not be changed during the course of the RTP session.
このストリームにフレーム内コード化ブロックのみが含まれる場合は、1に設定します。このストリームにフレーム内コード化ブロックが含まれる場合と含まれない場合は、0に設定します。このビットの意味は、RTPセッション中に変更しないでください。
Motion Vector flag (V): 1 bit
モーションベクトルフラグ（V）：1ビット
Set to 0 if motion vectors are not used in this stream. Set to 1 if motion vectors may or may not be used in this stream. The meaning of this bit should not be changed during the course of the session.
このストリームでモーションベクトルが使用されていない場合は、0に設定します。このストリームでモーションベクトルが使用される場合と使用されない場合は、1に設定します。このビットの意味は、セッション中に変更しないでください。
GOB number (GOBN): 4 bits
GOB番号（GOBN）：4ビット
Encodes the GOB number in effect at the start of the packet. Set to 0 if the packet begins with a GOB header.
パケットの開始時に有効なGOB番号をエンコードします。パケットがGOBヘッダーで始まる場合は0に設定します。
Macroblock address predictor (MBAP): 5 bits
マクロブロックアドレス予測（MBAP）：5ビット
Encodes the macroblock address predictor (i.e., the last MBA encoded in the previous packet). This predictor ranges from 0 - 32 (to predict the valid MBAs 1 - 33), but because the bit stream cannot be fragmented between a GOB header and MB 1, the predictor at the start of the packet shall not be 0. Therefore, the range is 1 - 32, which is biased by -1 to fit in 5 bits. For example, if MBAP is 0, the value of the MBA predictor is 1. Set to 0 if the packet begins with a GOB header.
マクロブロックアドレス予測子（つまり、前のパケットでエンコードされた最後のMBA）をエンコードします。この予測子の範囲は0〜32（有効なMBA 1〜33を予測するため）ですが、GOBヘッダーとMB 1の間でビットストリームをフラグメント化できないため、パケットの先頭の予測子は0になりません。したがって、範囲は1〜32で、5ビットに収まるように-1でバイアスされます。たとえば、MBAPが0の場合、MBAプレディクタの値は1です。パケットがGOBヘッダーで始まる場合は、0に設定します。
Quantizer (QUANT): 5 bits
量子化（QUANT）：5ビット
Quantizer value (MQUANT or GQUANT) in effect prior to the start of this packet. Set to 0 if the packet begins with a GOB header.
このパケットの開始前の有効な量子化値（MQUANTまたはGQUANT）。パケットがGOBヘッダーで始まる場合は0に設定します。
Horizontal motion vector data (HMVD): 5 bits
水平動きベクトルデータ（HMVD）：5ビット
Reference horizontal motion vector data (MVD). Set to 0 if V flag is 0 or if the packet begins with a GOB header, or when the MTYPE of the last MB encoded in the previous packet was not motion compensation (MC). HMVD is encoded as a 2s complement number, and '10000' corresponding to the value -16 is forbidden (motion vector fields range from +/-15).
参照水平動きベクトルデータ（MVD）。 Vフラグが0の場合、またはパケットがGOBヘッダーで始まる場合、または前のパケットでエンコードされた最後のMBのMTYPEが動き補償（MC）でない場合は、0に設定します。 HMVDは2の補数としてエンコードされ、値-16に対応する「10000」は禁止されています（動きベクトルフィールドは+/- 15の範囲です）。
Vertical motion vector data (VMVD): 5 bits
垂直動きベクトルデータ（VMVD）：5ビット
Reference vertical motion vector data (MVD). Set to 0 if V flag is 0 or if the packet begins with a GOB header, or when the MTYPE of the last MB encoded in the previous packet was not MC. VMVD is encoded as a 2s complement number, and '10000' corresponding to the value -16 SHALL not be used (motion vector fields range from +/-15).
垂直動きベクトルデータ（MVD）を参照します。 Vフラグが0の場合、またはパケットがGOBヘッダーで始まる場合、または前のパケットでエンコードされた最後のMBのMTYPEがMCでない場合は、0に設定します。 VMVDは2の補数としてエンコードされ、値-16に対応する「10000」は使用されません（モーションベクトルフィールドは+/- 15の範囲です）。
Note that the I and V flags are hint flags; i.e., they can be inferred from the bit stream. They are included to allow decoders to make optimizations that would not be possible if these hints were not provided before the bit stream was decoded. Therefore, these bits cannot change for the duration of the stream. A conforming implementation can always set V=1 and I=0.
IフラグとVフラグはヒントフラグです。つまり、ビットストリームから推測できます。これらは、ビットストリームがデコードされる前にこれらのヒントが提供されなかった場合には不可能であった最適化をデコーダーが行えるようにするために含まれています。したがって、これらのビットは、ストリームの期間中は変更できません。適合する実装では、常にV = 1およびI = 0を設定できます。
The H.261 stream SHALL be used without BCH error correction and without error correction framing.
H.261ストリームは、BCHエラー訂正なし、およびエラー訂正フレームなしで使用する必要があります（SHALL）。
Packetizers for hardware codecs can trivially figure out GOB boundaries, using the GOB-start pattern included in the H.261 data. (Note that software encoders already know the boundaries.) The cheapest packetization implementation is to packetize at the GOB level all the GOBs that fit in a packet. But when a GOB is too large, the packetizer has to parse it to do MB fragmentation. (Note that only the Huffman encoding must be parsed and that it is not necessary to decompress the stream fully, so this requires relatively little processing; examples of implementations can be found in some public H.261 codecs, such as IVS [IVS] and VIC [VIC].) It is recommended that MB level fragmentation be used when feasible in order to obtain more efficient packetization. Using this fragmentation scheme reduces the output packet rate and therefore reduces the overhead.
ハードウェアコーデックのパケタイザは、H.261データに含まれているGOB開始パターンを使用して、GOB境界を簡単に把握できます。 （ソフトウェアエンコーダーは既に境界を知っていることに注意してください。）最も安価なパケット化の実装は、パケットに収まるすべてのGOBをGOBレベルでパケット化することです。ただし、GOBが大きすぎる場合、パケッタイザはMBフラグメンテーションを行うためにそれを解析する必要があります。 （解析する必要があるのはハフマンエンコーディングのみであり、ストリームを完全に解凍する必要がないため、これは比較的少ない処理で済みます。実装の例は、IVS [IVS]やVIC [VIC]。）より効率的なパケット化を実現するために、可能な場合はMBレベルのフラグメンテーションを使用することをお勧めします。この断片化スキームを使用すると、出力パケットレートが低下するため、オーバーヘッドが減少します。
At the receiver, the data stream can be depacketized and directed to a hardware codec's input. If the hardware decoder operates at a fixed bit rate, synchronization may be maintained by inserting the stuffing pattern between MBs (i.e., between packets) when the packet arrival rate is slower than the bit rate.
受信側では、データストリームをデパケット化して、ハードウェアコーデックの入力に送ることができます。ハードウェアデコーダーが固定ビットレートで動作する場合、MB間（つまり、パケット間）にスタッフィングパターンを挿入することにより、パケット到着レートがビットレートよりも遅いときに同期を維持できます。
On the Internet, most packet losses are due to network congestion rather than to transmission errors. Using UDP, no mechanism is available at the sender to know whether a packet has been successfully received. It is up to the application (i.e., coder and decoder) to handle the packet loss. Each RTP packet includes a sequence number field that can be used to detect packet loss.
インターネットでは、ほとんどのパケット損失は送信エラーではなくネットワークの輻輳が原因です。 UDPを使用する場合、パケットが正常に受信されたかどうかを知るメカニズムは送信側では利用できません。パケット損失を処理するのはアプリケーション（つまり、コーダーとデコーダー）です。各RTPパケットには、パケット損失を検出するために使用できるシーケンス番号フィールドが含まれています。
H.261 uses the temporal redundancy of video to perform compression. This differential coding (or INTER-frame coding) is sensitive to packet loss. After a packet loss, parts of the image may remain corrupt until all corresponding MBs have been encoded in INTRA-frame mode (i.e., encoded independently of past frames). There are several ways to mitigate packet loss:
H.261は、ビデオの時間的冗長性を使用して圧縮を実行します。この差分コーディング（またはインターフレームコーディング）は、パケット損失の影響を受けます。パケット損失後、対応するすべてのMBがイントラフレームモードでエンコードされる（つまり、過去のフレームとは無関係にエンコードされる）まで、画像の一部が破損したままになることがあります。パケット損失を軽減する方法はいくつかあります。
(1) One way is to use only INTRA-frame encoding and MB-level conditional replenishment. That is, only MBs that change (beyond some threshold) are transmitted.
（1）1つの方法は、フレーム内エンコードとMBレベルの条件付き補充のみを使用することです。つまり、（しきい値を超えて）変化するMBのみが送信されます。
(2) Another way is to adjust the INTRA-frame encoding refreshment rate according to the packet loss observed by the receivers. The H.261 recommendation specifies that an MB be INTRA-frame encoded at least every 132 times it is transmitted. However, the INTRA-frame refreshment rate can be raised in order to speed the recovery when the measured loss rate is significant.
（2）別の方法は、受信機で観測されたパケット損失に応じて、イントラフレームエンコーディングのリフレッシュレートを調整することです。 H.261勧告は、MBが少なくとも132回送信されるたびにイントラフレームエンコードされることを指定しています。ただし、測定された損失率が大きい場合、回復を高速化するために、イントラフレームのリフレッシュレートを上げることができます。
(3) The fastest way to repair a corrupted image is to request an INTRA-frame coded image refreshment after a packet loss is detected. One means to accomplish this is for the decoder to send to the coder a list of packets lost. The coder can decide to encode every MB of every GOB of the following video frame in INTRA-frame mode (i.e., full INTRA-frame encoded). If the coder can deduce from the packet sequence numbers which MBs were affected by the loss, it can save bandwidth by sending only those MBs in INTRA-frame mode. This mode is particularly efficient in point-to-point connection or when the number of decoders is low.
（3）破損した画像を修復する最も速い方法は、パケット損失が検出された後にフレーム内コード化画像の更新を要求することです。これを実現する1つの方法は、デコーダーが失われたパケットのリストをコーダーに送信することです。コーダは、イントラフレームモードで次のビデオフレームのすべてのGOBのすべてのMBをエンコードすることを決定できます（つまり、完全なイントラフレームエンコード）。コーダーがパケットシーケンス番号から、損失の影響を受けたMBを推定できる場合、イントラフレームモードでそれらのMBのみを送信することにより、帯域幅を節約できます。このモードは、ポイントツーポイント接続またはデコーダーの数が少ない場合に特に効率的です。
The H.261-specific control packets FIR and NACK, as described in RFC 2032, SHALL NOT be used to request image refreshment. Old implementations are encouraged to use the methods described in this section. Image refreshment may be needed due to packet loss or due to application requirements. An example of application requirement may be the change of the speaker in a voice-activated multipoint video switching conference. There are two methods that can be used for requesting image refreshment. The first method is by using the Extended RTP Profile for RTCP-based Feedback and sending RTCP generic control packets, as described in RFC 4585 [RFC4585]. The second method is by using application protocol-specific commands, such as H.245 [ITU.H245] FastUpdateRequest.
RFC 2032で説明されているように、H.261固有の制御パケットFIRおよびNACKは、画像の更新を要求するために使用することはできません。古い実装では、このセクションで説明する方法を使用することをお勧めします。パケットの損失やアプリケーションの要件により、画像の更新が必要になる場合があります。アプリケーション要件の例としては、音声起動マルチポイントビデオスイッチング会議での発言者の変更があります。画像の更新を要求するために使用できる2つの方法があります。最初の方法は、RFC 4585 [RFC4585]で説明されているように、RTCPベースのフィードバックに拡張RTPプロファイルを使用してRTCP汎用制御パケットを送信することです。 2番目の方法は、H.245 [ITU.H245] FastUpdateRequestなどのアプリケーションプロトコル固有のコマンドを使用する方法です。
This section updates the H.261 media type described in RFC 3555 [RFC3555].
このセクションでは、RFC 3555 [RFC3555]で説明されているH.261メディアタイプを更新します。
This section specifies optional parameters that MAY be used to select optional features of the payload format. The parameters are specified here as part of the MIME subtype registration for the ITU-T H.261 codec. A mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] is also provided for those applications that use SDP. Multiple parameters SHOULD be expressed as a media type string, in the form of a semicolon-separated list of parameters.
このセクションでは、ペイロード形式のオプション機能を選択するために使用できるオプションパラメータを指定します。パラメータは、ITU-T H.261コーデックのMIMEサブタイプ登録の一部としてここで指定されます。 SDPを使用するアプリケーションには、セッション記述プロトコル（SDP）[RFC4566]へのパラメーターのマッピングも用意されています。複数のパラメーターは、セミコロンで区切られたパラメーターのリストの形式で、メディアタイプ文字列として表現する必要があります（SHOULD）。
This section describes the media types and names associated with this payload format. The section updates the previous registered version in RFC 3555 [RFC3555]. This registration uses the template defined in RFC 4288 [RFC4288]
このセクションでは、このペイロード形式に関連付けられているメディアタイプと名前について説明します。このセクションは、RFC 3555 [RFC3555]で以前に登録されたバージョンを更新します。この登録では、RFC 4288 [RFC4288]で定義されているテンプレートを使用します
MIME media type name: video
MIMEメディアタイプ名：ビデオ
MIME subtype name: H261
MIMEサブタイプ名：H261
Required parameters: None
必須パラメーター：なし
Optional parameters:
オプションのパラメーター：
CIF. This parameter has the format of parameter=value. It describes the maximum supported frame rate for CIF resolution. Permissible values are integer values 1 to 4, and it means that the maximum rate is 29.97/specified value.
CIF。このパラメーターの形式は、parameter = valueです。 CIF解像度でサポートされる最大フレームレートについて説明します。許容値は1〜4の整数値で、最大レートは29.97 /指定値であることを意味します。
QCIF. This parameter has the format of parameter=value. It describes the maximum supported frame rate for QCIF resolution. Permissible values are integer values 1 to 4, and it means that the maximum rate is 29.97/specified value.
QCIF。このパラメーターの形式は、parameter = valueです。 QCIF解像度でサポートされる最大フレームレートについて説明します。許容値は1〜4の整数値で、最大レートは29.97 /指定値であることを意味します。
D. Specifies support for still image graphics according to H.261, annex D. If supported, the parameter value SHALL be "1". If not supported, the parameter SHOULD NOT be used or SHALL have the value "0".
D. H.261、附属書Dに従って静止画像グラフィックのサポートを指定します。サポートされている場合、パラメーター値は「1」でなければなりません。サポートされていない場合、パラメーターは使用しないでください（SHOULD NOT）、または値「0」にする必要があります（SHALL）。
Encoding considerations:
エンコードに関する考慮事項：
This media type is framed and binary, see Section 4.8 in [RFC4288].
このメディアタイプはフレーム付きでバイナリです。[RFC4288]のセクション4.8をご覧ください。
Security considerations: See Section 8
セキュリティに関する考慮事項：セクション8を参照
Interoperability considerations:
相互運用性に関する考慮事項：
These are receiver options; current implementations will not send any optional parameters in their SDP. They will ignore the optional parameters and will encode the H.261 stream without annex D. Most decoders support at least QCIF resolutions, and they are expected to be available in almost every H.261-based video application.
これらはレシーバーオプションです。現在の実装では、SDPでオプションのパラメーターを送信しません。それらはオプションのパラメーターを無視し、附属書DなしでH.261ストリームをエンコードします。ほとんどのデコーダーは少なくともQCIF解像度をサポートしており、ほとんどすべてのH.261ベースのビデオアプリケーションで利用できると予想されます。
Published specification: RFC 4587
公開された仕様：RFC 4587
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Audio and video streaming and conferencing applications.
オーディオおよびビデオのストリーミングおよび会議アプリケーション。
Additional information: None
追加情報：なし
Person and email address to contact for further information:
詳細について連絡する人とメールアドレス：
Roni Even: roni.even@polycom.co.il
Roni Even：roni.even@polycom.co.il
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage:
使用上の制限：
This media type depends on RTP framing and thus is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
このメディアタイプはRTPフレーミングに依存し、これはRTP [RFC 3550]を介した転送に対してのみ定義されます。現在、他のフレーミングプロトコル内のトランスポートは定義されていません。
Author: Roni Even
作成者：Roni Even
Change controller:
コントローラを変更：
IETF Audio/Video Transport working group, delegated from the IESG.
IESGから委任されたIETF Audio / Video Transportワーキンググループ。
The MIME media type video/H261 string is mapped to fields in the Session Description Protocol (SDP) as follows:
MIMEメディアタイプvideo / H261文字列は、次のようにセッション記述プロトコル（SDP）のフィールドにマップされます。
o The media name in the "m=" line of SDP MUST be video.
o SDPの「m =」行のメディア名はビデオである必要があります。
o The encoding name in the "a=rtpmap" line of SDP MUST be H261 (the MIME subtype).
o SDPの「a = rtpmap」行のエンコーディング名はH261（MIMEサブタイプ）である必要があります。
o The clock rate in the "a=rtpmap" line MUST be 90000.
o 「a = rtpmap」行のクロックレートは90000でなければなりません。
o The optional parameters "CIF", "QCIF", and "D", if any, SHALL be included in the "a=fmtp" line of SDP. These parameters are expressed as a MIME media type string, in the form of as a semicolon-separated list of parameters
o オプションのパラメーター「CIF」、「QCIF」、および「D」がある場合は、SDPの「a = fmtp」行に含める必要があります。これらのパラメーターは、セミコロンで区切られたパラメーターのリストの形式で、MIMEメディアタイプの文字列として表現されます。
When H.261 is offered over RTP using SDP in an Offer/Answer model [RFC3264] the following considerations are necessary.
H.261が、オファー/アンサーモデル[RFC3264]でSDPを使用してRTP経由で提供される場合、次の考慮事項が必要です。
Codec options: (D) This option MUST NOT appear unless the sender of this SDP message is able to decode this option. This option SHALL be considered a receiver's capability even when it is sent in a "sendonly" offer.
コーデックオプション：（D）このSDPメッセージの送信者がこのオプションをデコードできる場合を除き、このオプションを表示してはなりません（MUST NOT）。このオプションは、「送信専用」オファーで送信された場合でも、受信者の機能と見なされるものとします（SHALL）。
Picture sizes and MPI:
画像サイズとMPI：
Supported picture sizes and their corresponding minimum picture interval (MPI) information for H.261 can be combined. All picture sizes may be advertised to the other party, or only a subset of it. Using the recvonly or sendrev direction attribute, a terminal SHOULD announce those picture sizes (with their MPIs) that it is willing to receive. For example, CIF=2 means that receiver can receive a CIF picture and that the frame rate SHALL be less then 15 frames per second.
H.261でサポートされている画像サイズと対応する最小画像間隔（MPI）情報を組み合わせることができます。すべての画像サイズは、相手に、またはそのサブセットのみにアドバタイズされます。端末は、recvonlyまたはsendrev方向属性を使用して、受信可能な画像サイズ（およびMPI）を通知する必要があります（SHOULD）。たとえば、CIF = 2は、レシーバーがCIFピクチャを受信でき、フレームレートが毎秒15フレーム未満であることを意味します。
When the direction attribute is sendonly, the parameters describe the capabilities of the stream that the sender can produce.
方向属性がsendonlyの場合、パラメーターは、送信者が生成できるストリームの機能を示します。
Implementations following this specification SHALL specify at least one supported picture size.
この仕様に従う実装は、サポートされている画像サイズを少なくとも1つ指定する必要があります。
If the receiver does not specify the picture size/MPI parameter, then it is safe to assume that it is an implementation that follows RFC 2032. In that case, it is RECOMMENDED to assume that such a receiver is able to support reception of QCIF resolution with MPI=1.
受信者が画像サイズ/ MPIパラメータを指定しない場合、それはRFC 2032に準拠した実装であると想定しても安全です。その場合、そのような受信者がQCIF解像度の受信をサポートできると想定することをお勧めします。 MPI = 1。
Parameters offered first are the most preferred picture mode to be received.
最初に提供されるパラメータは、受信される最も好ましい画像モードです。
An example of media representation in SDP is as follows CIF at 15 frames per second, QCIF at 30 frames per second and annex D
SDPでのメディア表現の例は、15フレーム/秒のCIF、30フレーム/秒のQCIF、および付録Dです。
m=video 49170/2 RTP/AVP 31
a=rtpmap:31 H261/90000
a=fmtp:31 CIF=2;QCIF=1;D=1
This means that the sender of this message can decode an H.261 bit stream with the following options and parameters: preferred resolution is CIF (its MPI is 2), but if that is not possible, then QCIF size is also supported. Still image using annex D MAY be used.
つまり、このメッセージの送信者は、次のオプションとパラメーターを使用してH.261ビットストリームをデコードできます。優先解像度はCIF（そのMPIは2）ですが、それが不可能な場合は、QCIFサイズもサポートされます。附属書Dを使用した静止画を使用してもよい。
The current document replaces RFC 2032. This section will address the major backward compatibility issues.
現在のドキュメントはRFC 2032に代わるものです。このセクションでは、主要な下位互換性の問題を扱います。
RFC 2032 defined two H.261-specific RTCP control packets, "Full INTRA-frame Request" and "Negative Acknowledgement". Support of these control packets was optional. The H.261-specific control packets differ from normal RTCP packets in that they are not transmitted to the normal RTCP destination transport address for the RTP session (which is often a multicast address). Instead, these control packets are sent directly via unicast from the decoder to the encoder. The destination port for these control packets is the same port that the encoder uses as a source port for transmitting RTP (data) packets. Therefore, these packets may be considered "reverse" control packets. This memo suggests generic methods to address the same requirement. The authors of the documents are not aware of products that support these control packets. Since these are optional features, new implementations SHALL ignore them, and they SHALL NOT be used by new implementations.
RFC 2032は、2つのH.261固有のRTCP制御パケット、「完全なイントラフレーム要求」と「否定応答」を定義しました。これらの制御パケットのサポートはオプションでした。 H.261固有の制御パケットは、RTPセッションの通常のRTCP宛先トランスポートアドレス（多くの場合、マルチキャストアドレス）に送信されないという点で、通常のRTCPパケットとは異なります。代わりに、これらの制御パケットは、ユニキャストを介してデコーダーからエンコーダーに直接送信されます。これらの制御パケットの宛先ポートは、エンコーダーがRTP（データ）パケットを送信するためのソースポートとして使用するポートと同じです。したがって、これらのパケットは「リバース」制御パケットと見なされます。このメモは、同じ要件に対処する一般的な方法を提案しています。ドキュメントの作成者は、これらの制御パケットをサポートする製品を認識していません。これらはオプション機能であるため、新しい実装はそれらを無視するものとし（SHALL）、新しい実装では使用しないものとします（SHALL）。
The document adds new optional parameters to the H261 payload type. Since these are optional parameters, we expect that old implementations ignore these parameters, whereas new implementations that receive the H261 payload type capabilities with no parameters will assume that it is an old implementation and will send H.261 at QCIF resolution and 30 frames per second.
このドキュメントでは、H261ペイロードタイプに新しいオプションパラメータを追加しています。これらはオプションのパラメーターであるため、古い実装はこれらのパラメーターを無視すると予想されますが、パラメーターなしでH261ペイロードタイプ機能を受信する新しい実装は、それが古い実装であると想定し、QCIF解像度および30フレーム/秒でH.261を送信します。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and in any appropriate RTP profile (e.g., [RFC3551]). This implies that confidentiality of the media streams is achieved by encryption. SRTP [RFC3711] may be used to provide both encryption and integrity protection of RTP flow. Because the data compression used with this payload format is applied end to end, encryption will be performed after compression, so there is no conflict between the two operations.
この仕様で定義されたペイロード形式を使用するRTPパケットは、RTP仕様[RFC3550]および適切なRTPプロファイル（[RFC3551]など）で説明されているセキュリティの考慮事項に従います。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。 SRTP [RFC3711]は、RTPフローの暗号化と完全性保護の両方を提供するために使用できます。このペイロード形式で使用されるデータ圧縮はエンドツーエンドで適用されるため、暗号化は圧縮後に実行されるため、2つの操作の間に競合はありません。
A potential denial-of-service threat exists for data encoding using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream that are complex to decode and cause the receiver to be overloaded. The usage of authentication of at least the RTP packet is RECOMMENDED. H.261 is vulnerable to such attacks because it is possible for an attacker to generate RTP packets containing frames that affect the decoding process of future frames. Therefore, the usage of data origin authentication and data integrity protection of at least the RTP packet is RECOMMENDED; for example, with SRTP.
受信側の計算負荷が均一でない圧縮技術を使用したデータエンコーディングには、潜在的なサービス拒否の脅威が存在します。攻撃者は、復号化が複雑な病理学的データグラムをストリームに挿入し、レシーバーを過負荷にする可能性があります。少なくともRTPパケットの認証の使用が推奨されます。 H.261は、攻撃者が将来のフレームのデコードプロセスに影響を与えるフレームを含むRTPパケットを生成する可能性があるため、このような攻撃に対して脆弱です。したがって、少なくともRTPパケットのデータ発信元認証とデータ整合性保護の使用が推奨されます。たとえば、SRTPを使用します。
Note that the appropriate mechanism to ensure confidentiality and integrity of RTP packets and their payloads is very dependent on the application and on the transport and signaling protocols employed. Thus, although SRTP is given as an example above, other possible choices exist.
RTPパケットとそのペイロードの機密性と整合性を保証する適切なメカニズムは、アプリケーションと、使用するトランスポートおよびシグナリングプロトコルに大きく依存することに注意してください。したがって、SRTPは上記の例として示されていますが、他の可能な選択肢が存在します。
This is to acknowledge the authors of RFC 2032, Thierry Turletti and Christian Huitema. Special thanks for the work done by Petri Koskelainen from Nokia and Nermeen Ismail from Cisco, who helped with drafting the text for the new MIME types.
これは、RFC 2032の作者であるティエリーターレッティとクリスチャンウイテマを認めることです。 NokiaのPetri KoskelainenとCiscoのNermeen Ismailが新しいMIMEタイプのテキストの草案作成を支援してくれた作業に特に感謝します。
The changes from the RFC 2032 are:
RFC 2032からの変更点は次のとおりです。
1. The H.261 MIME type is now in the payload specification.
1. H.261 MIMEタイプがペイロード仕様に含まれるようになりました。
2. Added optional parameters to the H.261 MIME type
2. H.261 MIMEタイプにオプションのパラメーターを追加
3. Deprecated the H.261 specific control packets
3. H.261固有の制御パケットの廃止
4. Editorial changes to be in line with RFC editing procedures
4. RFCの編集手順に沿った編集上の変更
[H261] International Telecommunications Union, "Video codec for audiovisual services at px 64 kbit/s", ITU Recommendation H.261, March 1993.
[H261]国際電気通信連合、「px 64 kbit / sのオーディオビジュアルサービス用ビデオコーデック」、ITU勧告H.261、1993年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「オファー/アンサーモデルとセッション記述プロトコル（SDP）」、RFC 3264、2002年6月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[RFC3555] Casner、S。およびP. Hoschka、「RTPペイロード形式のMIMEタイプ登録」、RFC 3555、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 4288、2005年12月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、2006年7月。
[ITU.H245] International Telecommunications Union, "CONTROL PROTOCOL FOR MULTIMEDIA COMMUNICATION", ITU Recommendation H.245, 2003.
[ITU.H245]国際電気通信連合、「マルチメディア通信の制御プロトコル」、ITU勧告H.245、2003年。
[INRIA] Turletti, T., "H.261 software codec for videoconferencing over the Internet", INRIA Research Report 1834, January 1993.
[INRIA] Turletti、T.、「インターネットを介したビデオ会議用のH.261ソフトウェアコーデック」、INRIA Research Report 1834、1993年1月。
[IVS] Turletti, T., "INRIA Videoconferencing tool (IVS)", available by anonymous ftp from zenon.inria.fr in the "rodeo/ivs/last_version" directory. See also URL <http://www.inria.fr/rodeo/ivs.html>.
[IVS] Turletti、T。、「INRIAビデオ会議ツール（IVS）」。「rodeo / ivs / last_version」ディレクトリのzenon.inria.frから匿名ftpで入手できます。 URL <http://www.inria.fr/rodeo/ivs.html>も参照してください。
[BT601] International Telecommunications Union, "Studio encoding parameters of digital television for standard 4:3 and wide-screen 16:9 aspect ratios", ITU-R Recommendation BT.601-5, October 1995.
[BT601] International Telecommunications Union、「標準の4：3およびワイドスクリーン16：9のアスペクト比のデジタルテレビのスタジオエンコーディングパラメータ」、ITU-R勧告BT.601-5、1995年10月。
[MICE] Sasse, MA., Bilting, U., Schultz, CD., and T. Turletti, "Remote Seminars through MultiMedia Conferencing: Experiences from the MICE project", Proc. INET'94/JENC5, Prague pp. 251/1-251/8, June 1994.
[MICE]マサチューセッツ州サッセ、ビルティング（U.）、シュルツ（CD）、およびT.ターレッティ、「マルチメディア会議によるリモートセミナー：MICEプロジェクトの経験」、Proc。 INET'94 / JENC5、プラハpp。251 / 1-251 / 8、1994年6月。
[VIC] MacCanne, S., "VIC Videoconferencing tool, available by anonymous ftp from ee.lbl.gov in the "conferencing/vic" directory".
[VIC] MacCanne、S。、「VICビデオ会議ツール。匿名ftpでee.lbl.govの「conferencing / vic」ディレクトリにあります」。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[H221] International Telecommunications Union, "Frame structure for a 64 to 1920 kbit/s channel in audiovisual teleservices", ITU Recommendation H.221, May 1999.
[H221]国際電気通信連合、「視聴覚テレサービスにおける64〜1920 kbit / sチャネルのフレーム構造」、ITU勧告H.221、1999年5月。
Author's Address
著者のアドレス
Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel
Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130イスラエル
EMail: roni.even@polycom.co.il
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP 78に含まれる権利、ライセンス、および制限の対象であり、ここに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。