[要約] RFC 2250は、MPEG1/MPEG2ビデオのためのRTPペイロード形式に関する仕様です。このRFCの目的は、MPEG1/MPEG2ビデオをRTPパケットにエンコードする方法を定義し、ネットワーク上でのビデオストリーミングの効率と品質を向上させることです。
Network Working Group D. Hoffman
Request for Comments: 2250 G. Fernando
Obsoletes: 2038 Sun Microsystems, Inc.
Category: Standards Track V. Goyal
Precept Software, Inc.
M. Civanlar
AT&T Labs - Research
January 1998
RTP Payload Format for MPEG1/MPEG2 Video
MPEG1 / MPEG2ビデオの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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF.
このメモは、MPEGビデオおよびオーディオストリームのパケット化スキームについて説明しています。提案された方式は、RTPでサポートされているトランスポートプロトコルを介してこのようなビデオまたはオーディオフローをトランスポートするために使用できます。 2つのアプローチについて説明します。 1つ目は、MPEGシステム環境との最大の相互運用性をサポートするように設計されています。 2つ目は、他のRTPカプセル化メディアストリームおよびIETFの将来の会議制御作業との最大の互換性を提供するように設計されています。
This memo is a revision of RFC 2038, an Internet standards track protocol. In this revision, the packet loss resilience mechanisms in Section 3.4 were extended to include additional picture header information required for MPEG2. A new section on security considerations for this payload type is added.
このメモは、インターネット標準追跡プロトコルであるRFC 2038の改訂版です。この改訂では、セクション3.4のパケット損失耐性メカニズムが拡張され、MPEG2に必要な追加の画像ヘッダー情報が含まれるようになりました。このペイロードタイプのセキュリティに関する考慮事項に関する新しいセクションが追加されました。
ISO/IEC JTC1/SC29 WG11 (also referred to as the MPEG committee) has defined the MPEG1 standard (ISO/IEC 11172)[1] and the MPEG2 standard (ISO/IEC 13818)[2]. This memo describes a packetization scheme to transport MPEG video and audio streams using the Real-time Transport Protocol (RTP), version 2 [3, 4].
ISO / IEC JTC1 / SC29 WG11（MPEG委員会とも呼ばれる）は、MPEG1標準（ISO / IEC 11172）[1]およびMPEG2標準（ISO / IEC 13818）[2]を定義しています。このメモは、リアルタイム転送プロトコル（RTP）、バージョン2 [3、4]を使用してMPEGビデオとオーディオストリームを転送するパケット化スキームについて説明しています。
The MPEG1 specification is defined in three parts: System, Video and Audio. It is designed primarily for CD-ROM-based applications, and is optimized for approximately 1.5 Mbits/sec combined data rates. The video and audio portions of the specification describe the basic format of the video or audio stream. These formats define the Elementary Streams (ES). The MPEG1 System specification defines an encapsulation of the ES that contains Presentation Time Stamps (PTS), Decoding Time Stamps and System Clock references, and performs multiplexing of MPEG1 compressed video and audio ES's with user data.
MPEG1仕様は、システム、ビデオ、オーディオの3つの部分で定義されています。これは主にCD-ROMベースのアプリケーション用に設計されており、合計で約1.5 Mビット/秒のデータレートに最適化されています。仕様のビデオとオーディオの部分は、ビデオまたはオーディオストリームの基本的な形式を説明しています。これらのフォーマットは、エレメンタリーストリーム（ES）を定義します。 MPEG1システム仕様は、プレゼンテーションタイムスタンプ（PTS）、デコードタイムスタンプ、システムクロックリファレンスを含むESのカプセル化を定義し、MPEG1圧縮ビデオおよびオーディオESとユーザーデータの多重化を実行します。
The MPEG2 specification is structured in a similar way. However, it hasn't been restricted only to CD-ROM applications. The MPEG2 System specification defines two system stream formats: the MPEG2 Transport Stream (MTS) and the MPEG2 Program Stream (MPS). The MTS is tailored for communicating or storing one or more programs of MPEG2 compressed data and also other data in relatively error-prone environments. The MPS is tailored for relatively error-free environments.
MPEG2仕様も同様に構成されています。ただし、CD-ROMアプリケーションに限定されていません。 MPEG2システム仕様では、MPEG2トランスポートストリーム（MTS）とMPEG2プログラムストリーム（MPS）の2つのシステムストリーム形式が定義されています。 MTSは、MPEG2圧縮データの1つ以上のプログラムや、比較的エラーが発生しやすい環境で他のデータを通信または保存するように調整されています。 MPSは、比較的エラーのない環境に合わせて調整されています。
We seek to achieve interoperability among 4 types of end-systems in the following specification. The 4 types are:
次の仕様では、4種類のエンドシステム間の相互運用性の実現を目指しています。 4つのタイプは次のとおりです。
1. Transmitting Interworking Unit (TIU)
1. Intermitting Interworking Unit（TIU）
Receives MPEG information from a native MTS system for distribution over packet networks using a native RTP-based system layer (such as an IP-based internetwork). Examples: real-time encoder, MTS satellite link to Internet, video server with MTS-encoded source material.
ネイティブのMTSシステムからMPEG情報を受信し、ネイティブのRTPベースのシステムレイヤー（IPベースのインターネットワークなど）を使用してパケットネットワーク経由で配信例：リアルタイムエンコーダ、インターネットへのMTS衛星リンク、MTSでエンコードされたソースマテリアルを備えたビデオサーバー。
2. Receiving Interworking Unit (RIU)
2. 受信インターワーキングユニット（RIU）
Receives MPEG information in real time from an RTP-based network for forwarding to a native MTS environment. Examples: Internet-based video server to MTS-based cable distribution plant.
RTPベースのネットワークからリアルタイムでMPEG情報を受信して、ネイティブのMTS環境に転送します。例：インターネットベースのビデオサーバーからMTSベースのケーブル配信プラント。
3. Transmitting Internet End-System (TAES)
3. インターネットエンドシステム（TAES）の送信
Transmits MPEG information generated or stored within the internet end-system itself, or received from internet-based computer networks. Example: video server.
インターネットエンドシステム自体で生成または保存された、またはインターネットベースのコンピューターネットワークから受信したMPEG情報を送信します。例：ビデオサーバー。
4. Receiving Internet End-System (RAES)
4. インターネットエンドシステム（RAES）の受信
Receives MPEG information over an RTP-based internet for consumption at the internet end-system or forwarding to traditional computer network. Example: desktop PC or workstation viewing training video.
RTPベースのインターネットを介してMPEG情報を受信し、インターネットエンドシステムで消費したり、従来のコンピューターネットワークに転送したりします。例：トレーニングビデオを表示するデスクトップPCまたはワークステーション。
Each of the 2 types of transmitters must work with each of the 2 types of receivers. Because it is probable that the TAES, and certain that the RAES, will be based on existing and planned internet-connected computers, it is highly desirable for the interoperable protocol to be based on RTP.
2種類のトランスミッタのそれぞれが、2種類のレシーバのそれぞれと連携する必要があります。 TAES、およびRAESは、既存および計画中のインターネットに接続されたコンピューターに基づく可能性が高いため、相互運用可能なプロトコルはRTPに基づくことが非常に望ましいです。
Because of the range of applications that might employ MPEG streams, we propose to define two payload formats.
MPEGストリームを使用する可能性のあるアプリケーションの範囲のため、2つのペイロード形式を定義することを提案します。
Much interest in the MPEG community is in the use of one of the MPEG System encodings, and hence, in Section 2 we propose encapsulations of MPEG1 System streams and MPEG2 Transport and Program Streams with RTP. This profile supports the full semantics of MPEG System and offers basic interoperability among all four end-system types.
MPEGコミュニティでは、MPEGシステムエンコーディングの1つを使用することに大きな関心が寄せられているため、セクション2では、RTPを使用したMPEG1システムストリームとMPEG2トランスポートおよびプログラムストリームのカプセル化を提案します。このプロファイルは、MPEGシステムの完全なセマンティクスをサポートし、4つすべてのエンドシステムタイプ間の基本的な相互運用性を提供します。
When operating only among internet-based end-systems (i.e., TAES and RAES) a payload format that provides greater compatibility with the Internet architecture is desired, deferring some of the system issues to other protocols being defined in the Internet community (such as the MMUSIC WG). In Section 3 we propose an encapsulation of compressed video and audio data (referred to in MPEG documentation as "Elementary Streams" (ES)) complying with either MPEG1 or MPEG2. Here, neither of the System standards of MPEG1 or MPEG2 are utilized. The ES's are directly encapsulated with RTP.
インターネットベースのエンドシステム（TAESとRAES）間でのみ動作する場合、インターネットアーキテクチャとの互換性を高めるペイロード形式が必要であり、システムの問題の一部をインターネットコミュニティで定義されている他のプロトコル（ MMUSIC WG）。セクション3では、MPEG1またはMPEG2のいずれかに準拠する圧縮ビデオおよびオーディオデータ（MPEGドキュメントでは「エレメンタリーストリーム」（ES）と呼ばれます）のカプセル化を提案します。ここでは、MPEG1またはMPEG2のシステム標準のどちらも使用されていません。 ESはRTPで直接カプセル化されます。
Throughout this specification, we make extensive use of MPEG terminology. The reader should consult the primary MPEG references for definitive descriptions of this terminology.
この仕様全体を通して、MPEG用語を幅広く使用しています。読者は、この用語の明確な説明について、主要なMPEGリファレンスを参照する必要があります。
Each RTP packet will contain a timestamp derived from the sender's 90KHz clock reference. This clock is synchronized to the system stream Program Clock Reference (PCR) or System Clock Reference (SCR) and represents the target transmission time of the first byte of the packet payload. The RTP timestamp will not be passed to the MPEG decoder. This use of the timestamp is somewhat different than normally is the case in RTP, in that it is not considered to be the media display or presentation timestamp. The primary purposes of the RTP timestamp will be to estimate and reduce any network-induced jitter and to synchronize relative time drift between the transmitter and receiver.
各RTPパケットには、送信者の90KHzクロックリファレンスから派生したタイムスタンプが含まれます。このクロックは、システムストリームのプログラムクロックリファレンス（PCR）またはシステムクロックリファレンス（SCR）に同期され、パケットペイロードの最初のバイトのターゲット送信時間を表します。 RTPタイムスタンプはMPEGデコーダに渡されません。このタイムスタンプの使用は、RTPの場合とは多少異なり、メディア表示またはプレゼンテーションのタイムスタンプとは見なされません。 RTPタイムスタンプの主な目的は、ネットワークに起因するジッターを推定して削減し、トランスミッターとレシーバー間の相対時間ドリフトを同期させることです。
For MPEG2 Transport Streams the RTP payload will contain an integral number of MPEG transport packets. To avoid end system inefficiencies, data from multiple small MTS packets (normally fixed in size at 188 bytes) are aggregated into a single RTP packet. The number of transport packets contained is computed by dividing RTP payload length by the length of an MTS packet (188).
MPEG2トランスポートストリームの場合、RTPペイロードには整数のMPEGトランスポートパケットが含まれます。エンドシステムの非効率を回避するために、複数の小さなMTSパケット（通常はサイズが188バイトに固定）からのデータが1つのRTPパケットに集約されます。含まれるトランスポートパケットの数は、RTPペイロードの長さをMTSパケットの長さで割ることによって計算されます（188）。
For MPEG2 Program streams and MPEG1 system streams there are no packetization restrictions; these streams are treated as a packetized stream of bytes.
MPEG2プログラムストリームとMPEG1システムストリームの場合、パケット化の制限はありません。これらのストリームは、パケット化されたバイトのストリームとして扱われます。
The RTP header fields are used as follows:
RTPヘッダーフィールドは次のように使用されます。
Payload Type: Distinct payload types should be assigned for MPEG1 System Streams, MPEG2 Program Streams and MPEG2 Transport Streams. See [4] for payload type assignments.
ペイロードタイプ：MPEG1システムストリーム、MPEG2プログラムストリーム、MPEG2トランスポートストリームには、個別のペイロードタイプを割り当てる必要があります。ペイロードタイプの割り当てについては、[4]を参照してください。
M bit: Set to 1 whenever the timestamp is discontinuous (such as might happen when a sender switches from one data source to another). This allows the receiver and any intervening RTP mixers or translators that are synchronizing to the flow to ignore the difference between this timestamp and any previous timestamp in their clock phase detectors.
Mビット：タイムスタンプが不連続な場合は常に1に設定されます（送信者があるデータソースから別のデータソースに切り替えた場合など）。これにより、レシーバーと、フローに同期しているすべての介在するRTPミキサーまたはトランスレーターが、クロックタイムディテクターのこのタイムスタンプと以前のタイムスタンプの違いを無視できます。
timestamp: 32 bit 90K Hz timestamp representing the target transmission time for the first byte of the packet.
timestamp：パケットの最初のバイトのターゲット送信時間を表す32ビットの90K Hzタイムスタンプ。
The following ES types may be encapsulated directly in RTP:
次のESタイプは、RTPに直接カプセル化できます。
(a) MPEG1 Video (ISO/IEC 11172-2) (b) MPEG2 Video (ISO/IEC
13818-2) (c) MPEG1 Audio (ISO/IEC 11172-3) (d) MPEG2 Audio
(ISO/IEC 13818-3)
A distinct RTP payload type is assigned to MPEG1/MPEG2 Video and MPEG1/MPEG2 Audio, respectively. Further indication as to whether the data is MPEG1 or MPEG2 need not be provided in the RTP or MPEG-specific headers of this encapsulation, as this information is available in the ES headers.
MPEG1 / MPEG2ビデオとMPEG1 / MPEG2オーディオには、それぞれ異なるRTPペイロードタイプが割り当てられます。この情報はESヘッダーで利用できるため、このカプセル化のRTPまたはMPEG固有のヘッダーにデータがMPEG1であるかMPEG2であるかをさらに示す必要はありません。
Presentation Time Stamps (PTS) of 32 bits with an accuracy of 90 kHz shall be carried in the fixed RTP header. All packets that make up a audio or video frame shall have the same time stamp.
固定RTPヘッダーでは、精度が90 kHzの32ビットのプレゼンテーションタイムスタンプ（PTS）が伝送されます。オーディオまたはビデオフレームを構成するすべてのパケットは、同じタイムスタンプを持つ必要があります。
MPEG1 Video can be distinguished from MPEG2 Video at the video sequence header, i.e. for MPEG2 Video a sequence_header() is followed by sequence_extension(). The particular profile and level of MPEG2 Video (MAIN_Profile@MAIN_Level, HIGH_Profile@HIGH_Level, etc) are determined by the profile_and_level_indicator field of the sequence_extension header of MPEG2 Video.
MPEG1ビデオは、ビデオシーケンスヘッダーでMPEG2ビデオと区別できます。つまり、MPEG2ビデオの場合、sequence_header()の後にsequence_extension()が続きます。 MPEG2ビデオの特定のプロファイルとレベル（MAIN_Profile @ MAIN_Level、HIGH_Profile @ HIGH_Levelなど）は、MPEG2ビデオのsequence_extensionヘッダーのprofile_and_level_indicatorフィールドによって決定されます。
The MPEG bit-stream semantics were designed for relatively error-free environments, and there is significant amount of dependency (both temporal and spatial) within the stream such that loss of some data make other uncorrupted data useless. The format as defined in this encapsulation uses application layer framing information plus additional information in the RTP stream-specific header to allow for certain recovery mechanisms. Appendix 1 suggests several recovery strategies based on the properties of this encapsulation.
MPEGビットストリームのセマンティクスは、比較的エラーのない環境向けに設計されており、ストリーム内にはかなりの依存性（時間的および空間的）があり、一部のデータが失われると他の破損していないデータが役に立たなくなります。このカプセル化で定義されている形式では、アプリケーション層のフレーミング情報に加えて、RTPストリーム固有のヘッダーの追加情報を使用して、特定の回復メカニズムを可能にします。付録1では、このカプセル化の特性に基づいたいくつかの回復戦略を提案しています。
Since MPEG pictures can be large, they will normally be fragmented into packets of size less than a typical LAN/WAN MTU. The following fragmentation rules apply:
MPEG画像は大きくなる可能性があるため、通常、標準的なLAN / WAN MTUよりも小さいサイズのパケットにフラグメント化されます。次の断片化規則が適用されます。
1. The MPEG Video_Sequence_Header, when present, will always be at the beginning of an RTP payload. 2. An MPEG GOP_header, when present, will always be at the beginning of the RTP payload, or will follow a Video_Sequence_Header. 3. An MPEG Picture_Header, when present, will always be at the beginning of a RTP payload, or will follow a GOP_header.
1. MPEG Video_Sequence_Headerは、存在する場合、常にRTPペイロードの先頭にあります。 2. MPEG GOP_headerが存在する場合、常にRTPペイロードの先頭にあるか、Video_Sequence_Headerの後に続きます。 3. MPEG Picture_Headerが存在する場合、常にRTPペイロードの先頭にあるか、GOP_headerの後に続きます。
Each ES header must be completely contained within the packet. Consequently, a minimum RTP payload size of 261 bytes must be supported to contain the largest single header defined in the ES (that is, the extension_data() header containing the quant_matrix_extension()). Otherwise, there are no restrictions on where headers may appear within packet payloads.
各ESヘッダーは、パケット内に完全に含まれている必要があります。したがって、ESで定義されている最大の単一ヘッダー（つまり、quant_matrix_extension()を含むextension_data()ヘッダー）を含めるには、261バイトの最小RTPペイロードサイズをサポートする必要があります。それ以外の場合、パケットペイロード内でヘッダーが表示される場所に制限はありません。
In MPEG, each picture is made up of one or more "slices," and a slice is intended to be the unit of recovery from data loss or corruption. An MPEG-compliant decoder will normally advance to the beginning of next slice whenever an error is encountered in the stream. MPEG slice begin and end bits are provided in the encapsulation header to facilitate this.
MPEGでは、各画像は1つ以上の「スライス」で構成され、スライスはデータの損失または破損からの回復の単位になることを目的としています。 MPEG準拠のデコーダーは、通常、ストリームでエラーが発生すると、次のスライスの先頭に進みます。これを容易にするために、MPEGスライスの開始ビットと終了ビットがカプセル化ヘッダーに用意されています。
The beginning of a slice must either be the first data in a packet (after any MPEG ES headers) or must follow after some integral number of slices in a packet. This requirement insures that the beginning of the next slice after one with a missing packet can be found without requiring that the receiver scan the packet contents. Slices may be fragmented across packets as long as all the above rules are met.
スライスの先頭は、パケット内の最初のデータ（MPEG ESヘッダーの後）であるか、またはパケット内のスライスの整数個の後に続く必要があります。この要件により、レシーバーがパケットの内容をスキャンすることなく、パケットが欠落しているスライスの次のスライスの先頭を確実に見つけることができます。上記のすべてのルールが満たされている限り、スライスはパケット間でフラグメント化されます。
An implementation based on this encapsulation assumes that the Video_Sequence_Header is repeated periodically in the MPEG bit-stream. In practice (though not required by MPEG standard) this is used to allow channel switching and to receive and start decoding a continuously relayed MPEG bit-stream at arbitrary points in the media stream. It is suggested that when playing back from an MPEG stream from a file format (where the Video_Sequence_Header may only be represented at the beginning of the stream) that the first Video_Sequence_Header (preceded by an end-of-stream indicator) be saved by the packetizer for periodic injection in to the network stream.
このカプセル化に基づく実装は、Video_Sequence_HeaderがMPEGビットストリームで定期的に繰り返されることを前提としています。実際には（MPEG標準では必須ではありませんが）、これを使用してチャネルを切り替え、メディアストリームの任意のポイントで継続的に中継されるMPEGビットストリームを受信してデコードを開始します。ファイル形式（Video_Sequence_Headerがストリームの先頭でのみ表される場合がある）からのMPEGストリームから再生する場合、最初のVideo_Sequence_Header（ストリームの終わりのインジケーターが前にある）がパケタイザーによって保存されることが推奨されます。ネットワークストリームに定期的に注入するため。
MPEG1 Audio can be distinguished from MPEG2 Audio from the MPEG ancillary_data() header. For either MPEG1 or MPEG2 Audio, distinct Presentation Time Stamps may be present for frames which correspond to either 384 samples for Layer-I, or 1152 samples for Layer-II or Layer-III. The actual number of bytes required to represent this number of samples will vary depending on the encoder parameters.
MPEG1オーディオは、MPEG ancillary_data()ヘッダーのMPEG2オーディオと区別できます。 MPEG1またはMPEG2オーディオの場合、レイヤーIの384サンプル、またはレイヤーIIまたはレイヤーIIIの1152サンプルのいずれかに対応するフレームに、異なるプレゼンテーションタイムスタンプが存在する場合があります。このサンプル数を表すために必要な実際のバイト数は、エンコーダーパラメーターによって異なります。
Multiple audio frames may be encapsulated within one RTP packet. In this case, an integral number of audio frames must be contained within the packet and the fragmentation header defined in Section 3.5 shall be set to 0.
複数のオーディオフレームを1つのRTPパケット内にカプセル化できます。この場合、整数のオーディオフレームがパケット内に含まれている必要があり、セクション3.5で定義されたフラグメンテーションヘッダーは0に設定されます。
Also, if relatively short packets are to be used, one frame may be so large that it may straddle multiple RTP packets. For example, for Layer-II MPEG audio sampled at a rate of 44.1 KHz each frame would represent a time slot of 26.1 msec. At this sampling rate if the compressed bit-rate is 384 kbits/sec (i.e. 48 kBytes/sec) then the average audio frame size would be 1.25 KBytes. If packets were to be 500 Bytes long, then each audio frame would straddle 3 RTP packets.
また、比較的短いパケットを使用する場合、1つのフレームが非常に大きくなるため、複数のRTPパケットにまたがることがあります。たとえば、44.1 KHzのレートでサンプリングされたLayer-II MPEGオーディオの場合、各フレームは26.1ミリ秒のタイムスロットを表します。このサンプリングレートで、圧縮ビットレートが384キロビット/秒（つまり、48キロバイト/秒）の場合、平均オーディオフレームサイズは1.25キロバイトになります。パケットの長さが500バイトである場合、各オーディオフレームは3つのRTPパケットにまたがります。
The audio fragmentation indicator header (See Section 3.5) shall be present for an MPEG1/2 Audio payload type to provide for this fragmentation.
オーディオフラグメンテーションインジケーターヘッダー（セクション3.5を参照）は、MPEG1 / 2オーディオペイロードタイプに存在して、このフラグメンテーションを提供します。
The RTP header fields are used as follows:
RTPヘッダーフィールドは次のように使用されます。
Payload Type: Distinct payload types should be assigned for video elementary streams and audio elementary streams. See [4] for payload type assignments.
ペイロードタイプ：ビデオエレメンタリストリームとオーディオエレメンタリストリームには、個別のペイロードタイプを割り当てる必要があります。ペイロードタイプの割り当てについては、[4]を参照してください。
M bit: For video, set to 1 on packet containing MPEG frame end code, 0 otherwise. For audio, set to 1 on first packet of a "talk-spurt," 0 otherwise.
Mビット：ビデオの場合、MPEGフレーム終了コードを含むパケットで1に設定し、それ以外の場合は0に設定します。オーディオの場合、「トークスパート」の最初のパケットで1に設定し、それ以外の場合は0に設定します。
PT: MPEG video or audio stream ID.
PT：MPEGビデオまたはオーディオストリームID。
timestamp: 32-bit 90K Hz timestamp representing presentation time of MPEG picture or audio frame. Same for all packets that make up a picture or audio frame. May not be monotonically increasing in video stream if B pictures present in stream. For packets that contain only a video sequence and/or GOP header, the timestamp is that of the subsequent picture.
タイムスタンプ：MPEG画像またはオーディオフレームのプレゼンテーション時間を表す32ビットの90K Hzタイムスタンプ。画像または音声フレームを構成するすべてのパケットで同じです。 Bピクチャがストリームに存在する場合、ビデオストリームで単調に増加しない場合があります。ビデオシーケンスやGOPヘッダーのみを含むパケットの場合、タイムスタンプは後続の画像のタイムスタンプです。
This header shall be attached to each RTP packet after the RTP fixed header.
このヘッダーは、RTP固定ヘッダーの後に各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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |T| TR | |N|S|B|E| P | | BFC | | FFC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AN FBV FFV
MBZ: Unused. Must be set to zero in current specification. This space is reserved for future use.
MBZ：未使用。現在の仕様ではゼロに設定する必要があります。このスペースは将来の使用のために予約されています。
T: MPEG-2 (Two) specific header extension present (1 bit). Set to 1 when the MPEG-2 video-specific header extension (see Section 3.4.1) follows this header. This extension may be needed for improved error resilience; however, its inclusion in an RTP packet is optional. (See Appendix 1.)
T：MPEG-2（2）固有のヘッダー拡張が存在します（1ビット）。 MPEG-2ビデオ固有のヘッダー拡張（セクション3.4.1を参照）がこのヘッダーに続く場合は、1に設定します。この拡張は、エラー耐性を向上させるために必要になる場合があります。ただし、RTPパケットへの組み込みはオプションです。 （付録1を参照してください。）
TR: Temporal-Reference (10 bits). The temporal reference of the current picture within the current GOP. This value ranges from 0-1023 and is constant for all RTP packets of a given picture.
TR：時間参照（10ビット）。現在のGOP内の現在の画像の時間参照。この値の範囲は0〜1023で、特定の画像のすべてのRTPパケットで一定です。
AN: Active N bit for error resilience (1 bit). Set to 1 when the following bit (N) is used to signal changes in the picture header information for MPEG-2 payloads. It must be set to 0 for MPEG-1 payloads or when N bit is not used.
AN：エラー耐性のためのアクティブNビット（1ビット）。次のビット（N）を使用してMPEG-2ペイロードの画像ヘッダー情報の変更を通知する場合は、1に設定します。 MPEG-1ペイロードの場合、またはNビットが使用されていない場合は、0に設定する必要があります。
N: New picture header (1 bit). Used for MPEG-2 payloads when the previous bit (AN) is set to 1. Otherwise, it must be set to zero. Set to 1 when the information contained in the previously transmitted Picture Headers can't be used to reconstruct a header for the current picture. This happens when the current picture is encoded using a different set of parameters than the previous pictures of the same type. The N bit must be constant for all RTP packets that belong to the same picture so that receipt of any packet from a picture allows detecting whether information necessary for reconstruction was contained in that picture (N = 1) or a previous one (N = 0).
N：新しい画像ヘッダー（1ビット）。前のビット（AN）が1に設定されている場合にMPEG-2ペイロードに使用されます。それ以外の場合は、ゼロに設定する必要があります。以前に送信された画像ヘッダーに含まれている情報を使用して現在の画像のヘッダーを再構築できない場合は、1に設定します。これは、現在の画像が同じタイプの以前の画像とは異なるパラメーターのセットを使用してエンコードされている場合に発生します。 Nビットは、同じ画像に属するすべてのRTPパケットで一定である必要があります。これにより、画像からパケットを受信すると、再構成に必要な情報がその画像（N = 1）に含まれていたか、以前の画像（N = 0）に含まれていたかを検出できます。 ）。
S: Sequence-header-present (1 bit). Normally 0 and set to 1 at the occurrence of each MPEG sequence header. Used to detect presence of sequence header in RTP packet.
S：シーケンスヘッダーの存在（1ビット）。通常は0で、各MPEGシーケンスヘッダーの発生時に1に設定されます。 RTPパケット内のシーケンスヘッダーの存在を検出するために使用されます。
B: Beginning-of-slice (BS) (1 bit). Set when the start of the packet payload is a slice start code, or when a slice start code is preceded only by one or more of a Video_Sequence_Header, GOP_header and/or Picture_Header.
B：スライスの始まり（BS）（1ビット）。パケットペイロードの開始がスライススタートコードである場合、またはスライススタートコードの前にVideo_Sequence_Header、GOP_header、Picture_Headerの1つ以上のみが存在する場合に設定されます。
E: End-of-slice (ES) (1 bit). Set when the last byte of the payload is the end of an MPEG slice.
E：スライスの終わり（ES）（1ビット）。ペイロードの最後のバイトがMPEGスライスの終わりであるときに設定されます。
P: Picture-Type (3 bits). I (1), P (2), B (3) or D (4). This value is constant for each RTP packet of a given picture. Value 000B is forbidden and 101B - 111B are reserved to support future extensions to the MPEG ES specification.
P：ピクチャタイプ（3ビット）。 I（1）、P（2）、B（3）またはD（4）。この値は、特定の画像の各RTPパケットに対して一定です。値000Bは禁止されており、101B-111BはMPEG ES仕様の将来の拡張をサポートするために予約されています。
FBV: full_pel_backward_vector BFC: backward_f_code FFV: full_pel_forward_vector FFC: forward_f_code Obtained from the most recent picture header, and are constant for each RTP packet of a given picture. For I frames none of these values are present in the picture header and they must be set to zero in the RTP header. For P frames only the last two values are present and FBV and BFC must be set to zero in the RTP header. For B frames all the four values are present.
FBV：full_pel_backward_vector BFC：backward_f_code FFV：full_pel_forward_vector FFC：forward_f_code最新の画像ヘッダーから取得され、特定の画像の各RTPパケットに対して一定です。 Iフレームの場合、これらの値は画像ヘッダーに存在せず、RTPヘッダーでゼロに設定する必要があります。 Pフレームの場合、最後の2つの値のみが存在し、FBVおよびBFCはRTPヘッダーでゼロに設定する必要があります。 Bフレームの場合、4つの値すべてが存在します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|E|f_[0,0]|f_[0,1]|f_[1,0]|f_[1,1]| DC| PS|T|P|C|Q|V|A|R|H|G|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X: Unused (1 bit). Must be set to zero in current specification. This space is reserved for future use.
X：未使用（1ビット）。現在の仕様ではゼロに設定する必要があります。このスペースは将来の使用のために予約されています。
E: Extensions present (1 bit). If set to 1, this header extension, including the composite display extension when D = 1, will be followed by one or more of the following extensions: quant matrix extension, picture display extension, picture temporal scalable extension, picture spatial scalable extension and copyright extension.
E：拡張機能が存在します（1ビット）。 1に設定すると、D = 1の場合のコンポジットディスプレイ拡張機能を含むこのヘッダー拡張機能の後に、次の拡張機能が1つ以上続きます：量子行列拡張機能、画像表示拡張機能、画像時間スケーラブル拡張機能、画像空間スケーラブル拡張機能および著作権拡張。
The first byte of these extensions data gives the length of the extensions in 32 bit words including the length field itself. Zero padding bytes are used at the end if required to align the extensions to 32 bit boundary.
これらの拡張データの最初のバイトは、長さフィールド自体を含む32ビットワードの拡張の長さを示します。拡張を32ビット境界に合わせる必要がある場合は、末尾にゼロパディングバイトが使用されます。
Since they may not be vital in decoding of a picture, the inclusion of any one of these extensions in an RTP packet is optional even when the MPEG-2 video-specific header extension is included in the packet (T = 1). (See Appendix 1.) If present, they should be copied from the corresponding extensions following the most recent MPEG-2 picture coding extension and they remain constant for each RTP packet of a given picture.
それらは画像のデコードに不可欠ではない可能性があるため、RTPパケットにこれらの拡張のいずれかを含めることは、MPEG-2ビデオ固有のヘッダー拡張がパケットに含まれている場合でもオプションです（T = 1）。 （付録1を参照してください。）存在する場合、最新のMPEG-2画像コーディング拡張機能に対応する拡張機能からコピーする必要があり、特定の画像の各RTPパケットに対して一定のままです。
The extension start code (32 bits) and the extension start code ID (4 bits) are included. Therefore the extensions are self identifying.
拡張スタートコード（32ビット）と拡張スタートコードID（4ビット）が含まれています。したがって、拡張機能は自己識別型です。
f_[0,0]: forward horizontal f_code (4 bits) f_[0,1]: forward vertical f_code (4 bits) f_[1,0]: backward horizontal f_code (4 bits) f_[1,1]: backward vertical f_code (4 bits) DC: intra_DC_precision (2 bits) PS: picture_structure (2 bits) T: top_field_first (1 bit) P: frame_predicted_frame_dct (1 bit) C: concealment_motion_vectors (1 bit) Q: q_scale type (1 bit) V: intra_vlc_format (1 bit) A: alternate scan (1 bit) R: repeat_first_field (1 bit) H: chroma_420_type (1 bit) G: progressive frame (1 bit) D: composite_display_flag (1 bit). If set to 1, next 32 bits following this one contains 12 zeros followed by 20 bits of composite display information.
f_ [0,0]：前方水平f_code（4ビット）f_ [0,1]：前方垂直f_code（4ビット）f_ [1,0]：後方水平f_code（4ビット）f_ [1,1]：後方垂直f_code（4ビット）DC：intra_DC_precision（2ビット）PS：picture_structure（2ビット）T：top_field_first（1ビット）P：frame_predicted_frame_dct（1ビット）C：concealment_motion_vectors（1ビット）Q：q_scaleタイプ（1ビット）V ：intra_vlc_format（1ビット）A：代替スキャン（1ビット）R：repeat_first_field（1ビット）H：chroma_420_type（1ビット）G：プログレッシブフレーム（1ビット）D：composite_display_flag（1ビット）。 1に設定した場合、これに続く32ビットには12個のゼロが含まれ、その後に20ビットの複合表示情報が続きます。
These values are copied from the most recent picture coding extension and are constant for each RTP packet of a given picture. Their meanings are as explained in the MPEG-2 standard.
これらの値は、最新の画像コーディング拡張機能からコピーされ、特定の画像の各RTPパケットに対して一定です。それらの意味は、MPEG-2標準で説明されているとおりです。
This header shall be attached to each RTP packet at the start of the payload and after any RTP headers for an MPEG1/2 Audio payload type.
このヘッダーは、ペイロードの開始時、およびMPEG1 / 2オーディオペイロードタイプのRTPヘッダーの後に、各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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | Frag_offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frag_offset: Byte offset into the audio frame for the data in this packet.
Frag_offset：このパケットのデータのオーディオフレームへのバイトオフセット。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [3], and any appropriate RTP profile (for example [4]). This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
この仕様で定義されたペイロード形式を使用するRTPパケットは、RTP仕様[3]および適切なRTPプロファイル（[4]など）で説明されているセキュリティ上の考慮事項の対象となります。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。このペイロード形式で使用されるデータ圧縮はエンドツーエンドで適用されるため、圧縮後に暗号化を実行して、2つの操作が競合しないようにすることができます。
A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. However, this encoding does not exhibit any significant non-uniformity.
受信側の計算負荷が均一でない圧縮技術を使用したデータエンコーディングには、潜在的なサービス拒否の脅威が存在します。攻撃者は、デコードが複雑な病理学的データグラムをストリームに挿入し、レシーバーに過負荷をかける可能性があります。ただし、このエンコーディングでは、大きな不均一性は発生しません。
As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [5] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
他のIPベースのプロトコルと同様に、状況によっては、受信側は、必要以上に多くのパケットを受信しただけで過負荷になる場合があります。ネットワーク層認証は、望ましくないソースからのパケットを破棄するために使用できますが、認証自体の処理コストが高すぎる可能性があります。マルチキャスト環境では、特定のソースのプルーニングがIGMP [5]の将来のバージョンとマルチキャストルーティングプロトコルに実装され、レシーバーが到達可能なソースを選択できるようになります。
A security review of this payload format found no additional considerations beyond those in the RTP specification.
このペイロード形式のセキュリティレビューでは、RTP仕様以外の考慮事項は見つかりませんでした。
Appendix 1. Error Recovery and Resynchronization Strategies.
付録1.エラー回復と再同期の戦略。
The following error recovery and resynchronization strategies are intended to be guidelines only. A compliant receiver is free to employ alternative (or no) strategies.
次のエラー回復と再同期の戦略は、ガイドラインのみを目的としています。準拠レシーバーは、代替（またはなし）戦略を自由に使用できます。
When initially decoding an RTP-encapsulated MPEG Elementary Stream, the receiver may discard all packets until the Sequence-header-present bit is set to 1. At this point, sufficient state information is contained in the stream to allow processing by an MPEG decoder.
最初にRTPカプセル化されたMPEGエレメンタリーストリームをデコードするとき、シーケンスヘッダー存在ビットが1に設定されるまで、レシーバーはすべてのパケットを破棄します。この時点で、MPEGデコーダーによる処理を可能にする十分な状態情報がストリームに含まれます。
Loss of packets containing the GOP_header and/or Picture_Header are detected by an unexpected change in the Temporal-Reference and Picture-Type values. Consider the following example GOP sequence:
GOP_headerやPicture_Headerを含むパケットの損失は、Temporal-Reference値とPicture-Type値の予期しない変更によって検出されます。次のGOPシーケンスの例を考えてみます。
In display order: 0B 1B 2I 3B 4B 5P 6B 7B 8P GOP_HDR 0B ... In stream order: 2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_HDR 2I ...
表示順：0B 1B 2I 3B 4B 5P 6B 7B 8P GOP_HDR 0B ...ストリーム順：2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_HDR 2I ...
Consider also two counters:
2つのカウンターも考慮してください。
ref_pic_temp (Reference Picture (I,P) Temporal Reference) dep_pic_temp (Dependent Picture (B) Temporal Reference)
ref_pic_temp（参照画像（I、P）時間参照）dep_pic_temp（依存画像（B）時間参照）
At each GOP beginning, set these counters to the temporal reference value of the corresponding picture type. For our example GOP sequence, ref_pic_temp = 2 and dep_pic_temp = 0. Keep incrementing BOTH counters by unity with each following picture. Ref_pic_temp should match the temporal references of the I and P frames, and dep_pic_temp should match the temporal references of the B frames.
各GOPの開始時に、これらのカウンターを対応する画像タイプの時間基準値に設定します。この例のGOPシーケンスでは、ref_pic_temp = 2およびdep_pic_temp = 0です。後続の各画像と一緒に、BOTHカウンターを1ずつ増分していきます。 Ref_pic_tempは、IおよびPフレームの時間参照と一致する必要があり、dep_pic_tempは、Bフレームの時間参照と一致する必要があります。
dep_pic_temp: - 0 1 2 3 4 5 6 7 8 9
In stream order: 2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_H 2I 0B 1B ...
ref_pic_temp: 2 3 4 5 6 7 8 9 10 ^ 11
-------------------------- | ^
Match Drop |
Mismatch
in ref_pic_temp
The loss of a GOP header can be detected by matching the appropriate counter (based on picture type) to the temporal reference value. A mismatch indicates a lost GOP header. If desired, a GOP header can be re-constructed using a "null" time_code, repeating the closed_gop flag from previous GOP headers, and setting the broken_link flag to 1.
GOPヘッダーの損失は、適切なカウンター（ピクチャタイプに基づく）を一時的な参照値と照合することで検出できます。不一致は、GOPヘッダーが失われたことを示します。必要に応じて、「null」のtime_codeを使用してGOPヘッダーを再構築し、以前のGOPヘッダーのclosed_gopフラグを繰り返し、broken_linkフラグを1に設定できます。
The loss of a Picture_Header can also be detected by a mismatch in the Temporal Reference contained in the RTP packet from the appropriate dep_pic_temp or ref_pic_temp counters at the receiver.
Picture_Headerの損失は、レシーバーの適切なdep_pic_tempまたはref_pic_tempカウンターからのRTPパケットに含まれるTemporal Referenceの不一致によっても検出できます。
For MPEG-1 payloads, after scanning to the next Beginning-of-slice the Picture_Header is reconstructed from the P, TR, FBV, BFC, FFV and FFC contained in that packet, and from stream-dependent default values.
MPEG-1ペイロードの場合、次のスライスの始めにスキャンした後、Picture_Headerは、そのパケットに含まれるP、TR、FBV、BFC、FFV、FFCから、およびストリーム依存のデフォルト値から再構築されます。
For MPEG-2, additional information is needed for the reconstruction. This information is provided by the MPEG-2 video specific header extension contained in that packet if the T bit is set to 1, or the Picture Header for the current picture may be available from previous packets belonging to the same picture. The transmitter's strategy for inclusion of the MPEG-2 video specific header extension may depend upon a number of factors. This header may not be needed when:
MPEG-2の場合、再構成には追加情報が必要です。この情報は、Tビットが1に設定されている場合、そのパケットに含まれるMPEG-2ビデオ固有のヘッダー拡張によって提供されます。または、現在の画像の画像ヘッダーは、同じ画像に属する以前のパケットから利用できる場合があります。 MPEG-2ビデオ固有のヘッダー拡張を含めるためのトランスミッターの戦略は、いくつかの要因によって異なります。このヘッダーは、次の場合には必要ない場合があります。
1. the information has been transmitted a sufficient number of times in previous packets to assure reception with the desired probability, or
1. 情報が前のパケットで十分な回数送信され、希望の確率で確実に受信されるようにする、または
2. the information is transmitted over a separate reliable channel, or
2. 情報が別の信頼できるチャネルを介して送信されている、または
3. expected loss rates are low enough that missed frames are not a concern, or
3. 予想される損失率が十分に低く、欠落したフレームが問題にならない、または
4. conserving bandwidth is more important than error resilience, etc.
4. 帯域幅の節約は、エラー耐性などよりも重要です。
If T=1 and E=0, there may be extensions present in the original video bitstream that are not included in the current packet. The transmitter may choose not to include extensions in a packet when they are not necessary for decoding or if one of the cases listed above for not including the MPEG-2 video specific header extension in a packet applies only to the extension data.
T = 1およびE = 0の場合、元のビデオビットストリームに現在のパケットに含まれていない拡張が存在する可能性があります。トランスミッターは、デコードに必要がない場合、またはMPEG-2ビデオ固有のヘッダー拡張をパケットに含めない上記のいずれかのケースが拡張データにのみ適用される場合、パケットに拡張を含めないことを選択できます。
If N=0, then the Picture Header from a previous picture of the same type (I,P or B) may be used so long as at least one packet has been received for every intervening picture of the same type and that the N bit was 0 for each of those pictures. This may involve:
N = 0の場合、同じタイプの前の画像（I、P、またはB）からの画像ヘッダーは、同じタイプの介在する画像ごとに少なくとも1つのパケットが受信され、Nビットがそれらの写真のそれぞれについて0でした。これには以下が含まれます。
1. Saving the relevant picture header information that can be obtained from the MPEG-2 video specific header extension or directly from the video bitstream for each picture type,
1. MPEG-2ビデオ固有のヘッダー拡張から、または各画像タイプのビデオビットストリームから直接取得できる関連する画像ヘッダー情報を保存します。
2. Keeping validity indicators for this saved information based on the received N bits and lost packets, and,
2. 受信したNビットと失われたパケットに基づいて、この保存された情報の有効性インジケーターを保持します。
3. Updating the data whenever a packet with N=1 is received.
3. N = 1のパケットを受信するたびにデータを更新します。
If the necessary information is not available from any of these sources, data deletion until a new picture start code is advised.
これらのソースのいずれからも必要な情報を入手できない場合は、新しい画像開始コードが通知されるまでデータを削除します。
Any time an RTP packet is lost (as indicated by a gap in the RTP sequence number), the receiver may discard all packets until the Beginning-of-slice bit is set. At this point, sufficient state information is contained in the stream to allow processing by an MPEG decoder starting at the next slice boundary (possibly after reconstruction of the GOP_header and/or Picture_Header as described above).
RTPパケットが失われると（RTPシーケンス番号のギャップで示されるように）、受信者はスライスの開始ビットが設定されるまですべてのパケットを破棄できます。この時点で、MPEGデコーダーによる次のスライス境界での処理を可能にするのに十分な状態情報がストリームに含まれています（おそらく上記のGOP_headerおよび/またはPicture_Headerの再構成後）。
References
参考文献
[1] ISO/IEC International Standard 11172; "Coding of moving pictures and associated audio for digital storage media up to about 1,5 Mbits/s", November 1993.
[1] ISO / IEC国際規格11172; 「約1.5 Mbit / sまでのデジタルストレージメディア用の動画と関連オーディオのコーディング」、1993年11月。
[2] ISO/IEC International Standard 13818; "Generic coding of moving pictures and associated audio information", November 1994.
[2] ISO / IEC国際規格13818; 「動画および関連するオーディオ情報の一般的なコーディング」、1994年11月。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[3] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、RFC 1889、1996年1月。
[4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[4] Schulzrinne、H。、「Minimal Controlを使用したオーディオおよびビデオ会議のRTPプロファイル」、RFC 1890、1996年1月。
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[5] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
Authors' Addresses
著者のアドレス
Gerard Fernando Sun Microsystems, Inc. Mail-stop UMPK14-305 2550 Garcia Avenue Mountain View, California 94043-1100 USA
Gerard Fernando Sun Microsystems、Inc.メールストップUMPK14-305 2550 Garcia Avenue Mountain View、California 94043-1100 USA
Phone: +1 415-786-6373 EMail: gerard.fernando@eng.sun.com Vivek Goyal Precept Software, Inc. 1072 Arastradero Rd, Palo Alto, CA 94304 USA
電話：+1 415-786-6373メール：Gerrard.Fernando@ing.sun.com Vivek Goel Percept Software、Is。 94304 1072 Castradero Radの彼、パロアルト
Phone: +1 415-845-5200
EMail: goyal@precept.com
Don Hoffman Sun Microsystems, Inc. Mail-stop UMPK14-305 2550 Garcia Avenue Mountain View, California 94043-1100 USA
Don Hoffman Sun Microsystems、Inc.メールストップUMPK14-305 2550 Garcia Avenue Mountain View、California 94043-1100 USA
Phone: +1 503-297-1580
EMail: don.hoffman@eng.sun.com
M. Reha Civanlar AT&T Labs - Research 100 Schutlz Drive, 3-213 Red Bank, NJ 07701-7033 USA
M. Reha Civanlar AT＆T Labs-Research 100 Schutlz Drive、3-213 Red Bank、NJ 07701-7033 USA
Phone: +1 732-345-3305
EMail: civanlar@research.att.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。