Network Working Group Y. Kikuchi
Request for Comments: 3016 Toshiba
Category: Standards Track T. Nomura
NEC
S. Fukunaga
Oki
Y. Matsui
Matsushita
H. Kimata
NTT
November 2000
RTP Payload Format for MPEG-4 Audio/Visual Streams
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 (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Multipurpose Internet Mail Extensions (MIME) type registrations and the use of Session Description Protocol (SDP).
この文書では、MPEG-4システムを使用せずに、MPEG-4オーディオおよびMPEG-4映像ビットストリームのそれぞれを運ぶためのリアルタイムトランスポートプロトコル（RTP）ペイロードフォーマットを説明しています。直接RTPパケットにMPEG-4オーディオ/ビジュアルビットストリームをマッピングするためには、RTPヘッダフィールドの使用のための仕様を提供し、また断片化ルールを指定します。また、MIME（Multipurpose Internet Mail Extensions）の登録を入力し、セッション記述プロトコルの使用（SDP）の仕様を提供します。
The RTP payload formats described in this document specify how MPEG-4 Audio [3][5] and MPEG-4 Visual streams [2][4] are to be fragmented and mapped directly onto RTP packets.
この文書に記載されたRTPペイロードフォーマットがどのようにMPEG-4オーディオを指定する[3] [5]及びMPEG-4映像ストリーム[2] [4]断片化とRTPパケットに直接マッピングされます。
These RTP payload formats enable transport of MPEG-4 Audio/Visual streams without using the synchronization and stream management functionality of MPEG-4 Systems [6]. Such RTP payload formats will be used in systems that have intrinsic stream management functionality and thus require no such functionality from MPEG-4 Systems. H.323 terminals are an example of such systems, where MPEG-4 Audio/Visual streams are not managed by MPEG-4 Systems Object Descriptors but by H.245. The streams are directly mapped onto RTP packets without using MPEG-4 Systems Sync Layer. Other examples are SIP and RTSP where MIME and SDP are used. MIME types and SDP usages of the RTP payload formats described in this document are defined to directly specify the attribute of Audio/Visual streams (e.g., media type, packetization format and codec configuration) without using MPEG-4 Systems. The obvious benefit is that these MPEG-4 Audio/Visual RTP payload formats can be handled in an unified way together with those formats defined for non-MPEG-4 codecs. The disadvantage is that interoperability with environments using MPEG-4 Systems may be difficult, other payload formats may be better suited to those applications.
これらのRTPペイロードフォーマットは、MPEG-4システムの同期化及びストリーム管理機能を使用せずに、MPEG-4オーディオ/ビジュアルストリームのトランスポートを可能に[6]。そのようなRTPペイロードフォーマットは、固有ストリーム管理機能を有し、したがって、MPEG-4システムからそのような機能を必要としないシステムで使用されるであろう。 H.323端末は、MPEG-4オーディオ/ビジュアルストリームはシステムはディスクリプタオブジェクトMPEG-4によって管理されるが、H.245によるされないようなシステムの一例です。ストリームは、直接MPEG-4システム同期層を用いずにRTPパケットにマッピングされます。他の例は、SIPおよびMIMEとSDPが使用されるRTSPです。 MIMEタイプと、この文書に記載されたRTPペイロードフォーマットのSDP用途を直接MPEG-4システムを使用せずにオーディオ/ビジュアルストリーム（例えば、メディアタイプ、パケットフォーマットとコーデック設定）の属性を指定するように定義されています。明白な利点は、これらのMPEG-4オーディオ/ビジュアルRTPペイロードフォーマットは、非MPEG-4コーデックのために定義されたフォーマットと一緒に統一的に扱うことができるということです。不利な点は、MPEG-4システムを用いて、環境との相互運用が困難であってもよいし、他のペイロードフォーマットは、それらのアプリケーションに適してもよいということです。
The semantics of RTP headers in such cases need to be clearly defined, including the association with MPEG-4 Audio/Visual data elements. In addition, it is beneficial to define the fragmentation rules of RTP packets for MPEG-4 Video streams so as to enhance error resiliency by utilizing the error resilience tools provided inside the MPEG-4 Video stream.
そのような場合にはRTPヘッダの意味は明確にMPEG-4オーディオ/ビジュアルデータ要素と関連を含む、定義される必要があります。また、MPEG-4ビデオストリームの内部に設けられた誤り耐性ツールを利用して誤り耐性を高めるようにMPEG-4ビデオストリームのRTPパケットの断片化規則を定義することが有益です。
MPEG-4 Visual is a visual coding standard with many new features: high coding efficiency; high error resiliency; multiple, arbitrary shape object-based coding; etc. [2]. It covers a wide range of bitrates from scores of Kbps to several Mbps. It also covers a wide variety of networks, ranging from those guaranteed to be almost error-free to mobile networks with high error rates.
MPEG-4ビジュアルは、多くの新機能を備えた視覚的なコーディング標準である：高い符号化効率;高いエラー回復力。複数の、任意形状オブジェクトベース符号化。等[2]。それはKbpsでの得点から数Mbpsのビットレートの広い範囲をカバーしています。また、ほとんど間違いがないことを保証するものとエラー率の高いモバイルネットワークに至るまで、ネットワークの多種多様をカバーしています。
With respect to the fragmentation rules for an MPEG-4 Visual bitstream defined in this document, since MPEG-4 Visual is used for a wide variety of networks, it is desirable not to apply too much restriction on fragmentation, and a fragmentation rule such as "a single video packet shall always be mapped on a single RTP packet" may be inappropriate. On the other hand, careless, media unaware fragmentation may cause degradation in error resiliency and bandwidth efficiency. The fragmentation rules described in this document are flexible but manage to define the minimum rules for preventing meaningless fragmentation while utilizing the error resilience functionalities of MPEG-4 Visual.
例えば、この文書で定義されたMPEG-4映像ビットストリームのための断片化規則に対するMPEG-4映像をネットワークの広範囲に使用されているので、断片化にあまり制限を適用しないことが望ましい、と断片化規則不適切かもしれ、「単一のビデオパケットは、常に単一のRTPパケットにマッピングされなければなりません」。一方、不注意、メディア気づかないフラグメンテーションは、エラー耐性と帯域幅の効率の低下を引き起こす可能性があります。この文書に記載された断片化規則は柔軟であるが、視覚MPEG-4の誤り耐性機能を利用しながら無意味断片化を防止するための最小限のルールを定義するために管理します。
The fragmentation rule recommends not to map more than one VOP in an RTP packet so that the RTP timestamp uniquely indicates the VOP time framing. On the other hand, MPEG-4 video may generate VOPs of very small size, in cases with an empty VOP (vop_coded=0) containing only
断片化規則は、RTPタイムスタンプを一意VOP時間枠を示すようにRTPパケットに複数のVOPをマッピングしないことをお勧めします。一方、MPEG-4ビデオは空VOP有する場合には（vop_coded = 0）のみを含む、非常に小さなサイズののVOPを生成することができます
VOP header or an arbitrary shaped VOP with a small number of coding blocks. To reduce the overhead for such cases, the fragmentation rule permits concatenating multiple VOPs in an RTP packet. (See fragmentation rule (4) in section 3.2 and marker bit and timestamp in section 3.1.)
VOPヘッダまたはコーディングブロック数の少ない任意形状VOP。このような場合のためのオーバーヘッドを低減するために、断片化規則は、RTPパケットに複数のVOPを連結可能にします。 （セクション3.2およびセクション3.1にマーカービットとタイムスタンプに断片化規則（4）を参照）。
While the additional media specific RTP header defined for such video coding tools as H.261 or MPEG-1/2 is effective in helping to recover picture headers corrupted by packet losses, MPEG-4 Visual has already error resilience functionalities for recovering corrupt headers, and these can be used on RTP/IP networks as well as on other networks (H.223/mobile, MPEG-2/TS, etc.). Therefore, no extra RTP header fields are defined in this MPEG-4 Visual RTP payload format.
H.261またはMPEG-1/2のようなビデオ符号化ツールのために定義された追加メディア特定RTPヘッダは、パケット損失によって損なわピクチャヘッダ、既に破損ヘッダを回復するための回復力官能誤りたビジュアルMPEG-4を回復するうえで有効であるが、これらはRTP / IPネットワーク上だけでなく、他のネットワーク（H.223 /モバイル、MPEG-2 / TSなど）で使用することができます。したがって、余分なRTPヘッダフィールドは、このMPEG-4ビジュアルRTPペイロードフォーマットで定義されていません。
MPEG-4 Audio is a new kind of audio standard that integrates many different types of audio coding tools. Low-overhead MPEG-4 Audio Transport Multiplex (LATM) manages the sequences of audio data with relatively small overhead. In audio-only applications, then, it is desirable for LATM-based MPEG-4 Audio bitstreams to be directly mapped onto the RTP packets without using MPEG-4 Systems.
MPEG-4オーディオは、オーディオ符号化ツールの多くの異なる種類を統合オーディオ規格の新しい種類です。低オーバーヘッドMPEG-4オーディオトランスポートマルチプレックス（LATM）は、比較的小さなオーバーヘッドでオーディオデータのシーケンスを管理します。音声専用アプリケーションでは、次に、それは直接MPEG-4システムを用いずにRTPパケットにマッピングするLATMベースのMPEG-4オーディオビットストリームのために望ましいです。
While LATM has several multiplexing features as follows;
次のようにLATMは、いくつかの多重化機能を備えていますが、
- Carrying configuration information with audio data, - Concatenation of multiple audio frames in one audio stream, - Multiplexing multiple objects (programs), - Multiplexing scalable layers,
- オーディオデータと構成情報を運ぶ、 - つのオーディオストリーム内の複数の音声フレームの連結、 - 多重化複数のオブジェクト（プログラム）、 - 多重スケーラブル層、
in RTP transmission there is no need for the last two features. Therefore, these two features MUST NOT be used in applications based on RTP packetization specified by this document. Since LATM has been developed for only natural audio coding tools, i.e., not for synthesis tools, it seems difficult to transmit Structured Audio (SA) data and Text to Speech Interface (TTSI) data by LATM. Therefore, SA data and TTSI data MUST NOT be transported by the RTP packetization in this document.
RTP送信で最後の二つの機能は必要ありません。したがって、これら2つの機能は、この文書で指定されたRTPパケットに基づくアプリケーションで使用してはいけません。 LATMはすなわち、ない合成ツールのために、唯一の自然オーディオ符号化ツールのために開発されているので、LATMによって音声インタフェース（TTSI）のデータに構造化されたオーディオ（SA）データとテキストを送信することは難しいようです。したがって、SAデータとTTSIデータは、この文書のRTPのパケットによって運ばれてはなりません。
For transmission of scalable streams, audio data of each layer SHOULD be packetized onto different RTP packets allowing for the different layers to be treated differently at the IP level, for example via some means of differentiated service. On the other hand, all configuration data of the scalable streams are contained in one LATM configuration data "StreamMuxConfig" and every scalable layer shares the StreamMuxConfig. The mapping between each layer and its configuration data is achieved by LATM header information attached to the audio data. In order to indicate the dependency information of the scalable streams, a restriction is applied to the dynamic assignment rule of payload type (PT) values (see section 4.2).
スケーラブルなストリームの送信のために、各層の音声データは、異なる層が差別化サービスのいくつかの手段を介して、例えば、IPレベルで異なる方法で処理することを可能にする異なるRTPパケットにパケット化されるべきです。一方、スケーラブルなストリームのすべての構成データは、1つのLATM構成データ「StreamMuxConfig」とすべてのスケーラブル層株式StreamMuxConfigに含まれています。各層とその構成データとの間のマッピングは、オーディオデータに付加LATMヘッダー情報によって達成されます。スケーラブルなストリームの依存関係情報を示すために、制限は、ペイロードタイプ（PT）の値の動的な割り当てルールに適用される（セクション4.2参照）。
For MPEG-4 Audio coding tools, as is true for other audio coders, if the payload is a single audio frame, packet loss will not impair the decodability of adjacent packets. Therefore, the additional media specific header for recovering errors will not be required for MPEG-4 Audio. Existing RTP protection mechanisms, such as Generic Forward Error Correction (RFC 2733) and Redundant Audio Data (RFC 2198), MAY be applied to improve error resiliency.
ペイロードは、単一のオーディオフレームである場合、他のオーディオコーダについても同様であるように、MPEG-4オーディオ符号化ツールのために、パケットロスが隣接パケットのデコード可能性を損なうことはありません。したがって、エラーを回復するための追加のメディア特定ヘッダはMPEG-4オーディオのために必要とされません。そのような一般的な前方誤り訂正（RFC 2733）と重複したオーディオデータ（RFC 2198）などの既存のRTP保護メカニズムは、エラー耐性を向上させるためにも適用することができます。
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 [7].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC-2119に記載されるように解釈される[7]。
This section specifies RTP packetization rules for MPEG-4 Visual content. An MPEG-4 Visual bitstream is mapped directly onto RTP packets without the addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary stream mode MUST be used so that configuration information will be carried to the same RTP port as the elementary stream. (see 6.2.1 "Start codes" of ISO/IEC 14496-2 [2][9][4]) The configuration information MAY additionally be specified by some out-of-band means. If needed for an H.323 terminal, H.245 codepoint "decoderConfigurationInformation" MUST be used for this purpose. If needed by systems using MIME content type and SDP parameters, e.g., SIP and RTSP, the optional parameter "config" MUST be used to specify the configuration information (see 5.1 and 5.2).
このセクションでは、MPEG-4ビジュアルコンテンツのためのRTPパケット化規則を指定します。 MPEG-4映像ビットストリームは、余分なヘッダフィールドの付加またはVisual構文要素の除去なしでRTPパケットに直接マッピングされます。構成情報はエレメンタリーストリームと同じRTPポートに運ばれるように、複合構成/エレメンタリーストリームモードを使用しなければなりません。構成情報は、さらに、いくつかのアウトオブバンドによって指定することができる（[4] [9] [2] ISO / IEC 14496-2の6.2.1「開始コード」を参照）。 H.323ターミナルのために必要な場合は、H.245コードポイント「decoderConfigurationInformation」この目的のために使用しなければなりません。 MIMEコンテンツタイプとSDPパラメータ、例えば、SIPおよびRTSPを使用するシステムが必要とする場合、オプションのパラメータ「設定」とは、（5.1と5.2を参照）の構成情報を指定するために使用されなければなりません。
When the short video header mode is used, the RTP payload format for H.263 SHOULD be used (the format defined in RFC 2429 is RECOMMENDED, but the RFC 2190 format MAY be used for compatibility with older implementations).
短いビデオヘッダ・モードを使用する場合、H.263のためのRTPペイロードフォーマットは、（RFC 2429で定義されたフォーマットが推奨されるが、RFC 2190形式が古い実装との互換性のために使用されるかもしれません）が使用されるべきです。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | RTP | MPEG-4 Visual stream (byte aligned) | Pay-| | load | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | V = 2 | P | X | CC | M | PT |シーケンス番号| RTP + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイムスタンプ|ヘッダー+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |同期ソース（SSRC）識別子| + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + |貢献ソース（CSRC）識別子| | .... | + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + | | RTP | MPEG-4ビジュアルストリーム（バイトアライン）| Pay- | |負荷| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | ：...オプションRTPパディング| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 1 - An RTP packet for MPEG-4 Visual stream
図1 - MPEG-4ビジュアルストリームのためのRTPパケット
Payload Type (PT): The assignment of an RTP payload type for this new 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 by means of an out of band signaling protocol (e.g., H.245, SIP, etc).
ペイロードタイプ（PT）：この新しいパケットフォーマットのためのRTPペイロードタイプの割り当ては、この文書の範囲外であり、ここで指定されません。これは、アプリケーションの特定のクラスのためのRTPプロファイルは、この符号化のためのペイロードタイプを割り当てるか、またはそれが次に行われていない場合、ダイナミックレンジにおけるペイロードタイプはバンドシグナリングプロトコルのうちによって選択されるものと期待されている（例えば、 、H.245、SIPなど）。
Extension (X) bit: Defined by the RTP profile used.
拡張（X）ビット：使用RTPプロファイルによって定義されています。
Sequence Number: Incremented by one for each RTP data packet sent, starting, for security reasons, with a random initial value.
シーケンス番号：ランダムな初期値で、セキュリティ上の理由から、開始、送信される各RTPデータパケットのための1ずつ増加。
Marker (M) bit: The marker bit is set to one to indicate the last RTP packet (or only RTP packet) of a VOP. When multiple VOPs are carried in the same RTP packet, the marker bit is set to one.
マーカ（M）ビット：マーカービットはVOPの最後のRTPパケット（または唯一のRTPパケット）を示すために1に設定されています。複数のVOPが同一のRTPパケットで運ばれる場合、マーカービットが1に設定されています。
Timestamp: The timestamp indicates the sampling instance of the VOP contained in the RTP packet. A constant offset, which is random, is added for security reasons.
タイムスタンプ：タイムスタンプはRTPパケットに含まれるVOPのサンプリング・インスタンスを示します。ランダムで一定のオフセットは、セキュリティ上の理由のために追加されます。
- When multiple VOPs are carried in the same RTP packet, the timestamp indicates the earliest of the VOP times within the VOPs carried in the RTP packet. Timestamp information of the rest of the VOPs are derived from the timestamp fields in the VOP header (modulo_time_base and vop_time_increment). - If the RTP packet contains only configuration information and/or Group_of_VideoObjectPlane() fields, the timestamp of the next VOP in the coding order is used. - If the RTP packet contains only visual_object_sequence_end_code information, the timestamp of the immediately preceding VOP in the coding order is used.
- 複数のVOPが同一のRTPパケットで運ばれる場合、タイムスタンプはRTPパケットで運ばのVOP内VOP時間の最も早いを示しています。 VOPの残りのタイムスタンプ情報は、VOPヘッダ（たmodulo_time_baseとvop_time_increment）のタイムスタンプフィールドから導出されます。 - RTPパケットのみの構成情報及び/又はGroup_of_VideoObjectPlane（）フィールドが含まれている場合、符号化順で次のVOPのタイムスタンプが使用されます。 - RTPパケットのみvisual_object_sequence_end_code情報が含まれている場合、符号化順で直前のVOPのタイムスタンプが使用されています。
The resolution of the timestamp is set to its default value of 90kHz, unless specified by an out-of-band means (e.g., SDP parameter or MIME parameter as defined in section 5).
（セクション5で定義されるように、例えば、SDPパラメータまたはMIMEパラメータ）アウト・オブ・バンドによって指定されない限り、タイムスタンプの分解能は、た90KHzのデフォルト値に設定されています。
Other header fields are used as described in RFC 1889 [8].
RFC 1889に記載されているように他のヘッダフィールドが使用されている[8]。
A fragmented MPEG-4 Visual bitstream is mapped directly onto the RTP payload without any addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary streams mode is used. The following rules apply for the fragmentation.
断片化されたMPEG-4映像ビットストリームは、余分なヘッダフィールドの任意の添加またはVisual構文要素の除去なしでRTPペイロードに直接マッピングされます。複合構成/エレメンタリストリームモードが使用されています。次の規則が断片化のために適用されます。
In the following, header means one of the following:
以下では、ヘッダは、次のいずれかを意味します。
- Configuration information (Visual Object Sequence Header, Visual Object Header and Video Object Layer Header) - visual_object_sequence_end_code - The header of the entry point function for an elementary stream (Group_of_VideoObjectPlane() or the header of VideoObjectPlane(), video_plane_with_short_header(), MeshObject() or FaceObject()) - The video packet header (video_packet_header() excluding next_resync_marker()) - The header of gob_layer() See 6.2.1 "Start codes" of ISO/IEC 14496-2 [2][9][4] for the definition of the configuration information and the entry point functions.
- コンフィギュレーション情報（ビジュアルオブジェクトシーケンスヘッダ、ビジュアルオブジェクトヘッダとビデオオブジェクト層ヘッダ） - visual_object_sequence_end_code - エレメンタリストリームのエントリポイント関数のヘッダ（Group_of_VideoObjectPlane（）またはVideoObjectPlane（）のヘッダ、video_plane_with_short_header（）、MeshObject（ ）またはFaceObject（）） - ビデオパケットヘッダ（video_packet_header（）を除くnext_resync_marker（）） - gob_layerのヘッダ（）[2] ISO / IEC 14496-2の6.2.1 "開始コード" を参照してください[9] [4 ]構成情報及びエントリポイント関数の定義について。
(1) Configuration information and Group_of_VideoObjectPlane() fields SHALL be placed at the beginning of the RTP payload (just after the RTP header) or just after the header of the syntactically upper layer function.
（1）構成情報およびGroup_of_VideoObjectPlane（）フィールドは、（単にRTPヘッダの後）、または単に構文的に上位レイヤ機能のヘッダの後RTPペイロードの先頭に置きます。
(2) If one or more headers exist in the RTP payload, the RTP payload SHALL begin with the header of the syntactically highest function. Note: The visual_object_sequence_end_code is regarded as the lowest function.
一つ以上のヘッダがRTPペイロードに存在する場合（2）、RTPペイロードは、構文的に最高関数のヘッダで始まりSHALL。注意：visual_object_sequence_end_codeは最低の関数とみなされます。
(3) A header SHALL NOT be split into a plurality of RTP packets.
（3）ヘッダは、RTPパケットを複数に分割することがないもの。
(4) Different VOPs SHOULD be fragmented into different RTP packets so that one RTP packet consists of the data bytes associated with a unique VOP time instance (that is indicated in the timestamp field in the RTP packet header), with the exception that multiple consecutive VOPs MAY be carried within one RTP packet in the decoding order if the size of the VOPs is small.
（4）種々のVOPは、異なるRTPパケットに断片化されるべきである1つのRTPパケットは、複数の連続したことを除いて、一意VOP時間インスタンス（それは、RTPパケットヘッダにタイムスタンプフィールドに示されている）に関連付けられたデータバイトで構成するようにVOPのサイズが小さい場合のVOPは、復号順に1つのRTPパケット内で実施することができます。
Note: When multiple VOPs are carried in one RTP payload, the timestamp of the VOPs after the first one may be calculated by the decoder. This operation is necessary only for RTP packets in which the marker bit equals to one and the beginning of RTP payload corresponds to a start code. (See timestamp and marker bit in section 3.1.)
注：複数のVOPは、1つのRTPペイロードで運ばれる場合、最初の後のVOPのタイムスタンプはデコーダによって計算することができます。この操作は、マーカービットが1に等しく、RTPペイロードの先頭にスタートコードに対応するRTPパケットのために必要です。 （セクション3.1でタイムスタンプとマーカービットを参照してください。）
(5) It is RECOMMENDED that a single video packet is sent as a single RTP packet. The size of a video packet SHOULD be adjusted in such a way that the resulting RTP packet is not larger than the path-MTU. Note: Rule (5) does not apply when the video packet is disabled by the coder configuration (by setting resync_marker_disable in the VOL header to 1), or in coding tools where the video packet is not supported. In this case, a VOP MAY be split at arbitrary byte-positions.
（5）単一のビデオパケットが単一のRTPパケットとして送信することが推奨されます。ビデオパケットのサイズは、得られたRTPパケットがパスMTUを超えないように調整されるべきです。注：ルールは、（5）ビデオパケットが（1にVOLヘッダ内resync_marker_disable設定することによって）コーダの設定によって無効にされたときに適用され、またはビデオパケットがサポートされていない符号化ツールではありません。この場合、VOPは任意のバイトの位置で分割することができます。
The video packet starts with the VOP header or the video packet header, followed by motion_shape_texture(), and ends with next_resync_marker() or next_start_code().
ビデオパケット）motion_shape_texture（続いて、VOPヘッダまたはビデオパケットヘッダで始まり、そしてnext_resync_marker（）またはnext_start_code（）で終了します。
Figure 2 shows examples of RTP packets generated based on the criteria described in 3.2
図2は、3.2で説明した基準に基づいて生成されたRTPパケットの例を示します
(a) is an example of the first RTP packet or the random access point of an MPEG-4 Visual bitstream containing the configuration information. According to criterion (1), the Visual Object Sequence Header(VS header) is placed at the beginning of the RTP payload, preceding the Visual Object Header and the Video Object Layer Header(VO header, VOL header). Since the fragmentation rule defined in 3.2 guarantees that the configuration information, starting with visual_object_sequence_start_code, is always placed at the beginning of the RTP payload, RTP receivers can detect the random access point by checking if the first 32-bit field of the RTP payload is visual_object_sequence_start_code.
（a）第一のRTPパケットまたは構成情報を含むMPEG-4映像のビットストリームのランダムアクセスポイントの一例です。基準によれば、（1）、（ヘッダVS）ビジュアルオブジェクトシーケンスヘッダは、ビジュアルオブジェクトヘッダとビデオオブジェクト層ヘッダ（VOヘッダ、VOLヘッダ）の前、RTPペイロードの先頭に配置されています。構成情報は、visual_object_sequence_start_code始まる、常にRTPペイロードの先頭に配置されていることを3.2保証に定義された断片化規則ので、RTP受信機は、RTPペイロードの最初の32ビットのフィールドであるかどうかをチェックすることによってランダムアクセスポイントを検出することができます。 visual_object_sequence_start_code。
(b) is another example of the RTP packet containing the configuration information. It differs from example (a) in that the RTP packet also contains a video packet in the VOP following the configuration information. Since the length of the configuration information is relatively short (typically scores of bytes) and an RTP packet containing only the configuration information may thus increase the overhead, the configuration information and the immediately following GOV and/or (a part of) VOP can be packetized into a single RTP packet as in this example.
（b）の設定情報を含むRTPパケットの別の例です。これは、（a）は、その中にRTPパケットは、構成情報次のVOPにおけるビデオパケットが含まれている例と異なります。構成情報の長さが比較的短いので（典型的にはバイトのスコア）のみ設定情報を含み、RTPパケットは、このようにオーバーヘッド、設定情報と直後GOVおよび/または（の一部）を増加させることができるVOPとすることができますこの例のように、単一のRTPパケットにパケット化。
(c) is an example of an RTP packet that contains Group_of_VideoObjectPlane(GOV). Following criterion (1), the GOV is placed at the beginning of the RTP payload. It would be a waste of RTP/IP header overhead to generate an RTP packet containing only a GOV whose length is 7 bytes. Therefore, (a part of) the following VOP can be placed in the same RTP packet as shown in (c).
（c）はGroup_of_VideoObjectPlane（GOV）を含有するRTPパケットの例です。基準以下の（1）、GOVは、RTPペイロードの先頭に配置されています。長さ7バイトでのみGOVを含むRTPパケットを生成するRTP / IPヘッダのオーバーヘッドの浪費であろう。 （c）に示すように、したがって、以下VOP（の一部）が同じRTPパケットに配置することができます。
(d) is an example of the case where one video packet is packetized into one RTP packet. When the packet-loss rate of the underlying network is high, this kind of packetization is recommended. Even when the RTP packet containing the VOP header is discarded by a packet loss, the other RTP packets can be decoded by using the HEC(Header Extension Code) information in the video packet header. No extra RTP header field is necessary.
（d）は、一つのビデオパケットが1つのRTPパケットにパケット化された場合の例です。基盤となるネットワークのパケット損失率が高い場合、パケットのこの種をお勧めします。 VOPヘッダを含むRTPパケットはパケットロスによって廃棄された場合でも、他のRTPパケットは、ビデオパケットヘッダにHEC（ヘッダ拡張コード）情報を用いて復号することができます。余分なRTPヘッダフィールドは必要ありません。
(e) is an example of the case where more than one video packet is packetized into one RTP packet. This kind of packetization is effective to save the overhead of RTP/IP headers when the bit-rate of the underlying network is low. However, it will decrease the packet-loss resiliency because multiple video packets are discarded by a single RTP packet loss. The optimal number of video packets in an RTP packet and the length of the RTP packet can be determined considering the packet-loss rate and the bit-rate of the underlying network.
（e）は、複数のビデオパケットが1つのRTPパケットにパケット化された場合の例です。パケットのこの種のは、基盤となるネットワークのビットレートが低い場合にはRTP / IPヘッダのオーバーヘッドを保存することが有効です。複数のビデオパケットは、単一のRTPパケット損失によって破棄されているのでしかし、それは、パケットロスの回復力が減少します。 RTPパケット及びRTPパケットの長さのビデオパケットの最適な数は、パケットロス率と、基礎となるネットワークのビットレートを考慮して決定することができます。
(f) is an example of the case when the video packet is disabled by setting resync_marker_disable in the VOL header to 1. In this case, a VOP may be split into a plurality of RTP packets at arbitrary byte-positions. For example, it is possible to split a VOP into fixed-length packets. This kind of coder configuration and RTP packet fragmentation may be used when the underlying network is guaranteed to be error-free. On the other hand, it is not recommended to use it in error-prone environment since it provides only poor packet loss resiliency.
（F）ビデオパケットは、この場合には1にVOLヘッダ内resync_marker_disable設定することにより無効になっている場合の例であり、VOPは、任意のバイトの位置で複数のRTPパケットに分割することができます。例えば、固定長パケットにVOPを分割することが可能です。基盤となるネットワークがエラーのないことが保証されている場合、コーダの設定およびRTPパケットの断片化のこの種を使用することができます。一方、唯一の貧しいパケットロス回復力を提供するので、エラーの発生しやすい環境で使用することは推奨されません。
Figure 3 shows examples of RTP packets prohibited by the criteria of 3.2.
図3は、3.2の基準によって禁止されたRTPパケットの例を示します。
Fragmentation of a header into multiple RTP packets, as in (a), will not only increase the overhead of RTP/IP headers but also decrease the error resiliency. Therefore, it is prohibited by the criterion (3).
複数のRTPパケットにヘッダの断片は、（A）のように、RTP / IPヘッダーのオーバーヘッドを増加させるだけでなく、エラー回復力を減少させるだけでなく、。従って、基準（3）によって禁止されています。
When concatenating more than one video packets into an RTP packet, VOP header or video_packet_header() shall not be placed in the middle of the RTP payload. The packetization as in (b) is not allowed by criterion (2) due to the aspect of the error resiliency. Comparing this example with Figure 2(d), although two video packets are mapped onto two RTP packets in both cases, the packet-loss resiliency is not identical. Namely, if the second RTP packet is lost, both video packets 1 and 2 are lost in the case of Figure 3(b) whereas only video packet 2 is lost in the case of Figure 2(d).
RTPパケットに複数のビデオパケットを連結する場合、VOPヘッダまたはvideo_packet_header（）はRTPペイロードの中央に配置されてはなりません。 （B）のように、パケットがエラーにより回復力の側面に基準（2）によって許可されていません。 2つのビデオパケットは両方の場合二つのRTPパケットにマッピングされているが、図2（D）と、本実施例を比較すると、パケット損失弾性が同一ではありません。第二のRTPパケットが失われた場合にのみ、ビデオパケット2は、図2（D）の場合に失われるのに対し、すなわち、両方のビデオパケット1及び2は、図3（B）の場合に失われます。
+------+------+------+------+
(a) | RTP | VS | VO | VOL |
|header|header|header|header|
+------+------+------+------+
+------+------+------+------+------------+
(b) | RTP | VS | VO | VOL |Video Packet|
|header|header|header|header| |
+------+------+------+------+------------+
+------+-----+------------------+
(c) | RTP | GOV |Video Object Plane|
|header| | |
+------+-----+------------------+
+------+------+------------+ +------+------+------------+
(d) | RTP | VOP |Video Packet| | RTP | VP |Video Packet|
|header|header| (1) | |header|header| (2) |
+------+------+------------+ +------+------+------------+
+------+------+------------+------+------------+------+------------+
(e) | RTP | VP |Video Packet| VP |Video Packet| VP |Video Packet|
|header|header| (1) |header| (2) |header| (3) |
+------+------+------------+------+------------+------+------------+
+------+------+------------+ +------+------------+
(f) | RTP | VOP |VOP fragment| | RTP |VOP fragment|
|header|header| (1) | |header| (2) | ___
+------+------+------------+ +------+------------+
Figure 2 - Examples of RTP packetized MPEG-4 Visual bitstream
図2 - RTPパケット化されたMPEG-4映像ビットストリームの例
+------+-------------+ +------+------------+------------+
(a) | RTP |First half of| | RTP |Last half of|Video Packet|
|header| VP header | |header| VP header | |
+------+-------------+ +------+------------+------------+
+------+------+----------+ +------+---------+------+------------+
(b) | RTP | VOP |First half| | RTP |Last half| VP |Video Packet|
|header|header| of VP(1) | |header| of VP(1)|header| (2) |
+------+------+----------+ +------+---------+------+------------+
Figure 3 - Examples of prohibited RTP packetization for MPEG-4 Visual bitstream
図3 - MPEG-4映像ビットストリームのための禁止RTPパケット化の例
This section specifies RTP packetization rules for MPEG-4 Audio bitstreams. MPEG-4 Audio streams MUST be formatted by LATM (Low-overhead MPEG-4 Audio Transport Multiplex) tool [5], and the LATM-based streams are then mapped onto RTP packets as described the three sections below.
このセクションでは、MPEG-4オーディオのビットストリームのためのRTPパケット化規則を指定します。 MPEG-4オーディオストリームはLATM（低オーバーヘッドMPEG-4音声伝送多重）ツール[5]でフォーマットする必要があり、3つのセクション後述のようにLATMベースのストリームは、次にRTPパケットにマッピングされます。
LATM-based streams consist of a sequence of audioMuxElements that include one or more audio frames. A complete audioMuxElement or a part of one SHALL be mapped directly onto an RTP payload without any removal of audioMuxElement syntax elements (see Figure 4). The first byte of each audioMuxElement SHALL be located at the first payload location in an RTP packet.
LATMベースのストリームは、1つ以上のオーディオフレームを含むaudioMuxElementsの配列からなります。完全audioMuxElementまたは1つの一部がaudioMuxElementシンタックス要素のいずれかを除去することなく、RTPペイロードに直接マッピングされるもの（図4参照）。各audioMuxElementの最初のバイトは、RTPパケットの最初のペイロード位置に配置することがSHALL。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number |RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp |Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |RTP : audioMuxElement (byte aligned) :Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | V = 2 | P | X | CC | M | PT |シーケンス番号| RTP + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイムスタンプ|ヘッダー+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |同期ソース（SSRC）識別子| + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + |貢献ソース（CSRC）識別子| | .... | + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + | | RTP：audioMuxElement（バイトアライン）：ペイロード| | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | ：...オプションRTPパディング| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 4 - An RTP packet for MPEG-4 Audio
図4 - MPEG-4オーディオのためのRTPパケット
In order to decode the audioMuxElement, the following muxConfigPresent information is required to be indicated by an out-of-band means. When SDP is utilized for this indication, MIME parameter "cpresent" corresponds to the muxConfigPresent information (see section 5.3).
audioMuxElementを復号するために、以下muxConfigPresent情報をアウトオブバンドによって示されることが必要です。 SDPは、この指示のために利用される場合、MIMEパラメータ「cpresent」はmuxConfigPresent情報（セクション5.3を参照）に相当します。
muxConfigPresent: If this value is set to 1 (in-band mode), the audioMuxElement SHALL include an indication bit "useSameStreamMux" and MAY include the configuration information for audio compression "StreamMuxConfig". The useSameStreamMux bit indicates whether the StreamMuxConfig element in the previous frame is applied in the current frame. If the useSameStreamMux bit indicates to use the StreamMuxConfig from the previous frame, but if the previous frame has been lost, the current frame may not be decodable. Therefore, in case of in-band mode, the StreamMuxConfig element SHOULD be transmitted repeatedly depending on the network condition. On the other hand, if muxConfigPresent is set to 0 (out-band mode), the StreamMuxConfig element is required to be transmitted by an out-of-band means. In case of SDP, MIME parameter "config" is utilized (see section 5.3).
muxConfigPresent：この値が1（インバンドモード）に設定されている場合、audioMuxElementが表示ビット「useSameStreamMux」を含むものとし、音声圧縮「StreamMuxConfig」の構成情報を含むことができます。 useSameStreamMuxビットは、前のフレームにおけるStreamMuxConfig要素が現在のフレームに適用されるかどうかを示します。 useSameStreamMuxビットは前のフレームからStreamMuxConfigを使用することを示している場合、しかし、前のフレームが失われた場合、現在のフレームが復号化可能ではないかもしれません。したがって、インバンドモードの場合には、StreamMuxConfig要素は、ネットワーク状態に応じて繰り返し送信されるべきです。 muxConfigPresentが0（帯域外モード）に設定されている一方、StreamMuxConfig要素は、アウトオブバンドによって送信される必要があります。 SDPの場合、MIMEパラメータ「設定」とは、（セクション5.3を参照）が利用されます。
Payload Type (PT): The assignment of an RTP payload type for this new 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 by means of an out of band signaling protocol (e.g., H.245, SIP, etc). In the dynamic assignment of RTP payload types for scalable streams, a different value SHOULD be assigned to each layer. The assigned values SHOULD be in order of enhance layer dependency, where the base layer has the smallest value.
ペイロードタイプ（PT）：この新しいパケットフォーマットのためのRTPペイロードタイプの割り当ては、この文書の範囲外であり、ここで指定されません。例えば、（アプリケーションの特定のクラスのためのRTPプロファイルが、この符号化のためのペイロードタイプを割り当てることが予想される、またはそれが次に行われていない場合、ダイナミックレンジにおけるペイロードタイプは、シグナリングプロトコル帯域外の手段によって選択されなければなりません、H.245、SIPなど）。スケーラブルなストリームのRTPペイロードタイプの動的割り当てにおいて、異なる値は、各レイヤに割り当てられるべきです。割り当てられた値は、ベース層は、最小値を有する強化層依存性、の順であるべきです。
Marker (M) bit: The marker bit indicates audioMuxElement boundaries. It is set to one to indicate that the RTP packet contains a complete audioMuxElement or the last fragment of an audioMuxElement.
マーカー（M）ビット：マーカービットはaudioMuxElement境界を示します。 RTPパケットは、完全なaudioMuxElementまたはaudioMuxElementの最後の断片が含まれていることを示すために1に設定されています。
Timestamp: The timestamp indicates the sampling instance of the first audio frame contained in the RTP packet. Timestamps are recommended to start at a random value for security reasons.
タイムスタンプ：タイムスタンプはRTPパケットに含まれる最初の音声フレームのサンプリングインスタンスを示します。タイムスタンプは、セキュリティ上の理由からランダムな値で開始することをお勧めします。
Unless specified by an out-of-band means, the resolution of the timestamp is set to its default value of 90 kHz.
アウト・オブ・バンドによって指定されない限り、タイムスタンプの分解能は90キロヘルツのデフォルト値に設定されています。
Sequence Number: Incremented by one for each RTP packet sent, starting, for security reasons, with a random value.
シーケンス番号：各RTPパケットを1ずつ増加は、ランダムな値で、セキュリティ上の理由から、開始、送られました。
Other header fields are used as described in RFC 1889 [8].
RFC 1889に記載されているように他のヘッダフィールドが使用されている[8]。
It is RECOMMENDED to put one audioMuxElement in each RTP packet. If the size of an audioMuxElement can be kept small enough that the size of the RTP packet containing it does not exceed the size of the path-MTU, this will be no problem. If it cannot, the audioMuxElement MAY be fragmented and spread across multiple packets.
各RTPパケットに1 audioMuxElementを置くことをお勧めします。 audioMuxElementの大きさは、それを含むRTPパケットのサイズがパスMTUのサイズを超えていないことを十分に小さく抑えることができるならば、これは問題ないでしょう。それができない場合は、audioMuxElementが断片化し、複数のパケットにまたがってもよい（MAY）。
The following sections describe the MIME type registrations for MPEG-4 Audio/Visual streams. MIME type registration and SDP usage for the MPEG-4 Visual stream are described in Sections 5.1 and 5.2, respectively, while MIME type registration and SDP usage for MPEG-4 Audio stream are described in Sections 5.3 and 5.4, respectively.
次のセクションでは、MPEG-4オーディオ/ビジュアルストリームのMIMEタイプの登録について説明します。 MPEG-4オーディオストリームのMIMEタイプの登録とSDP使い方は、それぞれ、セクション5.3および5.4に記載されている。MPEG-4ビジュアルストリームのMIMEタイプの登録とSDP使用は、それぞれ、セクション5.1および5.2に記載されています。
MIME media type name: video
MIMEメディアタイプ名：ビデオ
MIME subtype name: MP4V-ES
MIMEサブタイプ名：MP4V-ES
Required parameters: none
必須パラメータ：なし
Optional parameters:
オプションのパラメータ：
rate: This parameter is used only for RTP transport. It indicates the resolution of the timestamp field in the RTP header. If this parameter is not specified, its default value of 90000 (90kHz) is used.
料金：このパラメータは、RTPの輸送に使用されます。これは、RTPヘッダ内のタイムスタンプ・フィールドの解像度を示します。このパラメータが指定されていない場合は、90000（た90KHz）のデフォルト値が使用されます。
profile-level-id: A decimal representation of MPEG-4 Visual Profile and Level indication value (profile_and_level_indication) defined in Table G-1 of ISO/IEC 14496-2 [2][4]. This parameter MAY be used in the capability exchange or session setup procedure to indicate MPEG-4 Visual Profile and Level combination of which the MPEG-4 Visual codec is capable. If this parameter is not specified by the procedure, its default value of 1 (Simple Profile/Level 1) is used.
プロファイルレベルID：表G-1 ISO / IEC 14496-2の中で定義されたMPEG-4ビジュアルプロファイル及びレベル指示値（profile_and_level_indicationは）の10進表現[2] [4]。このパラメータは、MPEG-4映像コーデックが可能となっているMPEG-4ビジュアルのプロファイルとレベルの組み合わせを示すために、能力交換やセッションのセットアップ手順で使用されるかもしれません。このパラメータは、プロシージャによって指定されていない場合は、1（シンプルプロファイル/レベル1）のデフォルト値が使用されます。
config: This parameter SHALL be used to indicate the configuration of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be used to indicate the codec capability in the capability exchange procedure. It is a hexadecimal representation of an octet string that expresses the MPEG-4 Visual configuration information, as defined in subclause 6.2.1 Start codes of ISO/IEC14496-2 [2][4][9]. The configuration information is mapped onto the octet string in an MSB-first basis. The first bit of the configuration information SHALL be located at the MSB of the first octet. The configuration information indicated by this parameter SHALL be the same as the configuration information in the corresponding MPEG-4 Visual stream, except for first_half_vbv_occupancy and latter_half_vbv_occupancy, if exist, which may vary in the repeated configuration information inside an MPEG-4 Visual stream (See 6.2.1 Start codes of ISO/IEC14496-2).
設定：このパラメータは、対応するMPEG-4映像ビットストリームの構成を示すために使用されなければなりません。能力交換手順のコーデックの能力を示すために使用してはなりません。これは、ISO / IEC14496-2の副次6.2.1スタートコードで定義されるように、MPEG-4映像の構成情報を表すオクテット文字列の16進表現である[2] [4] [9]。構成情報は、MSB-1番目の基底におけるオクテットストリングにマッピングされます。構成情報の最初のビットは、最初のオクテットのMSBに配置さSHALL。 MPEG-4映像ストリーム内の繰り返し構成情報に変化し得る、存在する場合、このパラメータによって示される構成情報は、first_half_vbv_occupancyとlatter_half_vbv_occupancyを除いて、対応するMPEG-4映像ストリーム内の構成情報と同じでなければならない（参照ISO / IEC14496-2の6.2.1スタートコード）。
Example usages for these parameters are:
これらのパラメータの例の使用法は以下のとおりです。
- MPEG-4 Visual Simple Profile/Level 1: Content-type: video/mp4v-es; profile-level-id=1
- MPEG-4ビジュアルシンプルプロファイル/レベル1：コンテンツタイプ：ビデオ/ mp4v-ES;プロファイルレベルID = 1
- MPEG-4 Visual Core Profile/Level 2: Content-type: video/mp4v-es; profile-level-id=34
- MPEG-4ビジュアルコアプロファイル/レベル2：コンテンツタイプ：ビデオ/ mp4v-ES;プロファイルレベルID = 34
- MPEG-4 Visual Advanced Real Time Simple Profile/Level 1: Content-type: video/mp4v-es; profile-level-id=145
- MPEG-4ビジュアル高度なリアルタイムシンプルプロファイル/レベル1：コンテンツタイプ：ビデオ/ mp4v-ES;プロファイルレベルID = 145
Published specification: The specifications for MPEG-4 Visual streams are presented in ISO/IEC 14469-2 [2][4][9]. The RTP payload format is described in RFC 3016.
公開された仕様：MPEG-4映像ストリームがISO / IEC 14469から2に示されているの仕様[2] [4] [9]。 RTPペイロードフォーマットは、RFC 3016に記載されています。
Encoding considerations: Video bitstreams MUST be generated according to MPEG-4 Visual specifications (ISO/IEC 14496-2). A video bitstream is binary data and MUST be encoded for non-binary transport (for Email, the Base64 encoding is sufficient). This type is also defined for transfer via RTP. The RTP packets MUST be packetized according to the MPEG-4 Visual RTP payload format defined in RFC 3016.
エンコードの考慮事項：ビデオビットストリームはMPEG-4ビジュアル規格（ISO / IEC 14496-2）に応じて生成しなければなりません。ビデオビットストリームは、バイナリデータであり、（電子メールのために、Base64エンコーディングで十分である）非バイナリトランスポートのために符号化されなければなりません。このタイプは、RTPを介した転送のために定義されています。 RTPパケットは、RFC 3016で定義されたMPEG-4ビジュアルRTPペイロードフォーマットに従ってパケット化されなければなりません。
Security considerations: See section 6 of RFC 3016.
セキュリティの考慮事項：RFC 3016のセクション6を参照してください。
Interoperability considerations: MPEG-4 Visual provides a large and rich set of tools for the coding of visual objects. For effective implementation of the standard, subsets of the MPEG-4 Visual tool sets have been provided for use in specific applications. These subsets, called 'Profiles', limit the size of the tool set a decoder is required to implement. In order to restrict computational complexity, one or more Levels are set for each Profile. A Profile@Level combination allows:
相互運用性に関する注意事項：MPEG-4ビジュアルビジュアルオブジェクトの符号化のためのツールの大規模かつ豊富なセットを提供します。標準の効果的な実施のために、MPEG-4ビジュアルツールセットのサブセットは、特定の用途での使用のために提供されています。 「プロファイル」と呼ばれるこれらのサブセットは、デコーダを実装するのに必要とされるツールセットのサイズを制限します。計算の複雑さを制限するために、1つまたは複数のレベルは、プロファイルごとに設定されています。プロファイル@レベルの組み合わせができます。
o a codec builder to implement only the subset of the standard he needs, while maintaining interworking with other MPEG-4 devices included in the same combination, and
他のMPEG-4のデバイスとのインターワーキングを維持することが同じ組み合わせに含まれている間、彼が必要とする標準のサブセットのみを実装するためのコーデックビルダーO、及び
o checking whether MPEG-4 devices comply with the standard (' conformance testing').
O MPEG-4のデバイスは、標準的な（「適合性試験」）に準拠しているかどうかチェックします。
The visual stream SHALL be compliant with the MPEG-4 Visual Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id" in MIME content, or by arranging in the capability exchange/announcement procedure to set this parameter mutually to the same value.
視覚的な流れは、パラメータ「プロファイル・レベル-ID」で指定されたMPEG-4ビジュアルプロファイル@レベルに準拠するものとします。送信者と受信者間の相互運用性は、MIMEコンテンツ、または同じ値に相互にこのパラメータを設定する能力交換/アナウンス手順に配置することによって、パラメータ「プロファイルレベルID」を指定することによって達成することができます。
Applications which use this media type: Audio and visual streaming and conferencing tools, Internet messaging and Email applications.
オーディオとビジュアルのストリーミングおよび会議ツール、インターネットメッセージングと電子メールアプリケーション：このメディアタイプを使用するアプリケーション。
Additional information: none
追加情報：なし
Person & email address to contact for further information: The authors of RFC 3016. (See section 8.)
人と詳細のために連絡する電子メールアドレス：RFC 3016の作者（セクション8を参照）
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: The authors of RFC 3016. (See section 8.)
著者/変更コントローラ：RFC 3016の作者（セクション8を参照）
The MIME media type video/MP4V-ES string is mapped to fields in the Session Description Protocol (SDP), RFC 2327, as follows:
次のようにMIMEメディアタイプビデオ/ MP4V-ES文字列は、セッション記述プロトコル（SDP）、RFC 2327のフィールドにマッピングされます。
o The MIME type (video) goes in SDP "m=" as the media name.
O MIMEタイプ（ビデオ）メディア名としてSDP「m =」に進みます。
o The MIME subtype (MP4V-ES) goes in SDP "a=rtpmap" as the encoding name.
MIMEサブタイプ（MP4V-ES）Oエンコーディング名としてSDPの "a = rtpmap" に進みます。
o The optional parameter "rate" goes in "a=rtpmap" as the clock rate.
Oオプションのパラメータ「速度」はクロックレートとして「A = rtpmap」になります。
o The optional parameter "profile-level-id" and "config" go in the "a=fmtp" line to indicate the coder capability and configuration, respectively. These parameters are expressed as a MIME media type string, in the form of as a semicolon separated list of parameter=value pairs.
オプションのパラメータ「プロファイルレベルID」oおよび「設定」は、それぞれ、符号化能力および構成を示すために「A =のfmtp」行に行きます。これらのパラメータは、セミコロンは、パラメータ=値のペアのリストを分離としての形態において、MIMEメディアタイプ文字列として表されます。
The following are some examples of media representation in SDP:
SDPにおけるメディア表現のいくつかの例を以下に示します。
Simple Profile/Level 1, rate=90000(90kHz), "profile-level-id" and "config" are present in "a=fmtp" line: m=video 49170/2 RTP/AVP 98 a=rtpmap:98 MP4V-ES/90000 a=fmtp:98 profile-level-id=1;config=000001B001000001B509000001000000012 0008440FA282C2090A21F
M =ビデオ2分の49170 RTP / AVP 98 = rtpmap：98 MP4Vシンプルプロファイル/レベル1、速度= 90000（た90KHz）、 "プロファイルレベルID" と "設定" が "A =のfmtp" の行に存在します-ES / 90000 A =のfmtp：98プロファイルレベルID = 1;コンフィグ= 000001B001000001B509000001000000012 0008440FA282C2090A21F
Core Profile/Level 2, rate=90000(90kHz), "profile-level-id" is present in "a=fmtp" line: m=video 49170/2 RTP/AVP 98 a=rtpmap:98 MP4V-ES/90000 a=fmtp:98 profile-level-id=34
コアプロファイル/レベル2、レート= 90000（た90KHz）、 "プロファイルレベルID" は、 "A =のfmtp" の行に存在する：M =ビデオ2分の49170 RTP / AVP 98 = rtpmap：98 MP4V-ES / 90000 =のfmtp：98プロファイルレベルID = 34
Advance Real Time Simple Profile/Level 1, rate=90000(90kHz), "profile-level-id" is present in "a=fmtp" line: m=video 49170/2 RTP/AVP 98 a=rtpmap:98 MP4V-ES/90000 a=fmtp:98 profile-level-id=145
予めリアルタイムシンプルプロファイル/レベル1、速度= 90000（た90KHz）、 "プロファイルレベルID" は、 "A =のfmtp" の行に存在する：M =ビデオ2分の49170 RTP / AVP 98 = rtpmap：98 MP4V- ES / 90000 =のfmtp：98プロファイルレベルID = 145
MIME media type name: audio
MIMEメディアタイプ名：オーディオ
MIME subtype name: MP4A-LATM
MIMEサブタイプ名：MP4A-LATM
Required parameters: rate: the rate parameter indicates the RTP time stamp clock rate. The default value is 90000. Other rates MAY be specified only if they are set to the same value as the audio sampling rate (number of samples per second).
必須パラメータ：レート：レートパラメータは、RTPタイムスタンプのクロックレートを示します。デフォルト値は、それらがオーディオサンプリングレート（1秒あたりのサンプル数）と同じ値に設定されている場合にのみ、90000、他のレートを指定することもあります。
Optional parameters: profile-level-id: a decimal representation of MPEG-4 Audio Profile Level indication value defined in ISO/IEC 14496-1 ([6] and its amendments). This parameter indicates which MPEG-4 Audio tool subsets the decoder is capable of using. If this parameter is not specified in the capability exchange or session setup procedure, its default value of 30 (Natural Audio Profile/Level 1) is used.
オプションパラメータ：プロファイルレベルID：ISO / IEC 14496-1で定義されたMPEG-4オーディオプロファイルレベル表示値の10進表現（[6]及びその改正）。このパラメータは、MPEG-4オーディオツールは、デコーダが使用可能であるサブセットかを示します。このパラメータは、能力交換やセッションのセットアップ手順で指定されていない場合は、30（ナチュラルオーディオプロファイル/レベル1）のデフォルト値が使用されます。
object: a decimal representation of the MPEG-4 Audio Object Type value defined in ISO/IEC 14496-3 [5]. This parameter specifies the tool to be used by the coder. It CAN be used to limit the capability within the specified "profile-level-id".
目的：ISO / IEC 14496-3で定義されたMPEG-4オーディオオブジェクトタイプ値の10進表現[5]。このパラメータは、コーダが使用するツールを指定します。指定された「プロファイルレベルID」内の能力を制限するために使用することができます。
bitrate: the data rate for the audio bit stream.
ビットレート：オーディオのビットストリームのデータ・レート。
cpresent: a boolean parameter indicates whether audio payload configuration data has been multiplexed into an RTP payload (see section 4.1). A 0 indicates the configuration data has not been multiplexed into an RTP payload, a 1 indicates that it has. The default if the parameter is omitted is 1.
cpresent：ブールパラメータ（セクション4.1を参照）オーディオペイロード構成データをRTPペイロードに多重化されたかどうかを示します。 0は、構成データがRTPペイロードに多重化されていないことを示し、1は、それが有することを示します。パラメータが省略された場合、デフォルトは1です。
config: a hexadecimal representation of an octet string that expresses the audio payload configuration data "StreamMuxConfig", as defined in ISO/IEC 14496-3 [5] (see section 4.1). Configuration data is mapped onto the octet string in an MSB-first basis. The first bit of the configuration data SHALL be located at the MSB of the first octet. In the last octet, zero-padding bits, if necessary, SHALL follow the configuration data.
設定：[5]（セクション4.1を参照）ISO / IEC 14496-3で定義されるように、オーディオペイロード構成データ「StreamMuxConfig」を表しオクテットストリングの16進表現。コンフィギュレーション・データはMSBファーストの基礎でオクテット文字列にマッピングされます。コンフィギュレーション・データの最初のビットは、最初のオクテットのMSBに配置さSHALL。最後のオクテット、ゼロパディングビットでは、必要に応じて、コンフィギュレーションデータに従わなければなりません。
ptime: RECOMMENDED duration of each packet in milliseconds.
PTIME：ミリ秒単位の各パケットの推奨期間。
Published specification: Payload format specifications are described in this document. Encoding specifications are provided in ISO/IEC 14496-3 [3][5].
公開された仕様：ペイロードフォーマット仕様は、このドキュメントで説明されています。符号化仕様は、ISO / IEC 14496-3に設けられている[3] [5]。
Encoding considerations: This type is only defined for transfer via RTP.
エンコードの考慮事項：このタイプは、唯一のRTPを介した転送のために定義されています。
Security considerations: See Section 6 of RFC 3016.
セキュリティの考慮事項：RFC 3016のセクション6を参照してください。
Interoperability considerations: MPEG-4 Audio provides a large and rich set of tools for the coding of audio objects. For effective implementation of the standard, subsets of the MPEG-4 Audio tool sets similar to those used in MPEG-4 Visual have been provided (see section 5.1).
相互運用性に関する注意事項：MPEG-4オーディオは、オーディオオブジェクトの符号化のためのツールの大規模かつ豊富なセットを提供します。標準の効果的な実施のために、MPEG-4オーディオツールは、MPEG-4ビジュアルに使用されるものと同様のセットのサブセットは、（セクション5.1を参照）が提供されています。
The audio stream SHALL be compliant with the MPEG-4 Audio Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id" in MIME content, or by arranging in the capability exchange procedure to set this parameter mutually to the same value. Furthermore, the "object" parameter can be used to limit the capability within the specified Profile@Level in capability exchange.
オーディオストリームは、パラメータ「プロファイル・レベル-ID」で指定されたMPEG-4オーディオプロファイル@レベルに準拠するものとします。送信側と受信側との間の相互運用性、または同じ値に相互にこのパラメータを設定する能力交換手順に配置することにより、MIMEコンテンツにおけるパラメータ「プロファイルレベルID」を指定することによって達成することができます。さらに、「オブジェクト」パラメータは、能力交換で指定されたプロファイル@レベル内の能力を制限するために使用することができます。
Applications which use this media type: Audio and video streaming and conferencing tools.
オーディオとビデオストリーミングと会議ツール：このメディアタイプを使用するアプリケーション。
Additional information: none
追加情報：なし
Personal & email address to contact for further information: See Section 8 of RFC 3016.
パーソナル・メールアドレス詳細のために連絡する：RFC 3016のセクション8を参照してください。
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: See Section 8 of RFC 3016.
著者/変更コントローラ：RFC 3016のセクション8を参照してください。
The MIME media type audio/MP4A-LATM string is mapped to fields in the Session Description Protocol (SDP), RFC 2327, as follows:
次のようにMIMEメディアタイプオーディオ/ MP4A-LATMストリングは、セッション記述プロトコル（SDP）、RFC 2327のフィールドにマッピングされます。
o The MIME type (audio) goes in SDP "m=" as the media name.
O MIMEタイプ（オーディオ）は、メディア名としてSDP「m =」に進みます。
o The MIME subtype (MP4A-LATM) goes in SDP "a=rtpmap" as the encoding name.
O MIMEサブタイプ（MP4A-LATM）は、符号化名としてSDPの "a = rtpmap" に進みます。
o The required parameter "rate" goes in "a=rtpmap" as the clock rate.
O必要なパラメータ「速度」はクロックレートとして「A = rtpmap」になります。
o The optional parameter "ptime" goes in SDP "a=ptime" attribute.
Oオプションのパラメータ "PTIMEは、" SDP "A = PTIME" 属性になります。
o The optional parameter "profile-level-id" goes in the "a=fmtp" line to indicate the coder capability. The "object" parameter goes in the "a=fmtp" attribute. The payload-format-specific parameters
Oオプションのパラメータ「プロファイルレベルIDは」コーダ機能を示すために、「A =のfmtp」行に進みます。 「オブジェクト」パラメータは「A =のfmtp」属性になります。ペイロード・フォーマット固有のパラメータ
"bitrate", "cpresent" and "config" go in the "a=fmtp" line. These parameters are expressed as a MIME media type string, in the form of as a semicolon separated list of parameter=value pairs.
「ビットレート」、「cpresent」と「設定」を「A =のfmtp」の行に進みます。これらのパラメータは、セミコロンは、パラメータ=値のペアのリストを分離としての形態において、MIMEメディアタイプ文字列として表されます。
The following are some examples of the media representation in SDP:
以下SDPにおけるメディア表現のいくつかの例は以下のとおりです。
For 6 kb/s CELP bitstreams (with an audio sampling rate of 8 kHz), m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/8000 a=fmtp:96 profile-level-id=9;object=8;cpresent=0;config=9128B1071070 a=ptime:20
（8キロヘルツのオーディオサンプリングレートで）6キロバイト/ sのCELPビットストリームのための、= rtpmap M =オーディオ49230 RTP / AVP 96 A：96 MP4A-LATM / 8000 =のfmtp：96プロファイルレベルID = 9;オブジェクト= 8; cpresent = 0;コンフィグ= 9128B1071070 A = PTIME：20
For 64 kb/s AAC LC stereo bitstreams (with an audio sampling rate of 24 kHz),
64キロバイト/秒のAAC LCステレオビットストリームのために、（24キロヘルツのオーディオサンプリングレート）
m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/24000 a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0; config=9122620000
M =オーディオ49230 RTP / AVP 96 = rtpmap：96 MP4A-LATM / 24000 =のfmtp：96プロファイルレベルID = 1。ビットレート= 64000; cpresent = 0;コンフィグ= 9122620000
In the above two examples, audio configuration data is not multiplexed into the RTP payload and is described only in SDP. Furthermore, the "clock rate" is set to the audio sampling rate.
上記の2つの例では、オーディオコンフィギュレーションデータは、RTPペイロードに多重化されていないのみSDPに記載されています。さらに、「クロック・レートは、」オーディオのサンプリングレートに設定されています。
If the clock rate has been set to its default value and it is necessary to obtain the audio sampling rate, this can be done by parsing the "config" parameter (see the following example).
クロック・レートがデフォルト値に設定されていて、オーディオのサンプリングレートを取得する必要がある場合、これは「設定」パラメータ（次の例を参照）を解析することによって行うことができます。
m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/90000 a=fmtp:96 object=8; cpresent=0; config=9128B1071070
M =オーディオ49230 RTP / AVP 96 = rtpmap：96 MP4A-LATM / 90000 =のfmtp：96物体= 8。 cpresent = 0;コンフィグ= 9128B1071070
The following example shows that the audio configuration data appears in the RTP payload.
次の例では、オーディオ・コンフィギュレーション・データは、RTPペイロードに表示されていることを示しています。
m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/90000 a=fmtp:96 object=2; cpresent=1
M =オーディオ49230 RTP / AVP 96 = rtpmap：96 MP4A-LATM / 90000 =のfmtp：96物体= 2。 cpresent = 1
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [8]. 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 on the compressed data so there is no conflict between the two operations.
本明細書で定義されたペイロードフォーマットを使用して、RTPパケットは、RTP仕様[8]で説明したセキュリティ上の考慮の対象となっています。これは、メディアストリームの機密性は、暗号化によって達成されることを意味します。このペイロードフォーマットに使用されるデータ圧縮は、エンドツーエンド印加されるので、二つの操作の間に競合がないので、暗号化は、圧縮されたデータに対して実行することができます。
The complete MPEG-4 system allows for transport of a wide range of content, including Java applets (MPEG-J) and scripts. Since this payload format is restricted to audio and video streams, it is not possible to transport such active content in this format.
完全なMPEG-4システムでは、Javaアプレット（MPEG-J）およびスクリプトを含むコンテンツの広範囲の輸送を可能にします。このペイロード・フォーマットは、オーディオ及びビデオストリームに制限されているので、この形式のようなアクティブコンテンツを転送することは不可能です。
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
1ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
2 ISO/IEC 14496-2:1999, "Information technology - Coding of audio-visual objects - Part2: Visual".
2 ISO / IEC 14496-2：1999、 "情報技術 - オーディオビジュアルオブジェクトのコーディング - パート2：ビジュアル"。
3 ISO/IEC 14496-3:1999, "Information technology - Coding of audio-visual objects - Part3: Audio".
3 ISO / IEC 14496-3：1999、 "情報技術 - オーディオビジュアルオブジェクトのコーディング - 第3部：オーディオ"。
4 ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology - Coding of audio-visual objects - Part 2: Visual, Amendment 1: Visual extensions".
4 ISO / IEC 14496-2：1999 / Amd.1：2000、 "情報技術 - オーディオビジュアルオブジェクトのコーディング - パート2：ビジュアル、修正1：ビジュアルエクステンション"。
5 ISO/IEC 14496-3:1999/Amd.1:2000, "Information technology - Coding of audio-visual objects - Part3: Audio, Amendment 1: Audio extensions".
5 ISO / IEC 14496-3：1999 / Amd.1：2000、 "情報技術 - オーディオビジュアルオブジェクトのコーディング - 第3部：オーディオ、修正1：オーディオの拡張"。
6 ISO/IEC 14496-1:1999, "Information technology - Coding of audio-visual objects - Part1: Systems".
6 ISO / IEC 14496-1：1999、 "情報技術 - オーディオビジュアルオブジェクトのコーディング - パート1：システム"。
7 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
7ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
8 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson "RTP: A Transport Protocol for Real Time Applications", RFC 1889, January 1996.
8 Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobsonの "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
9 ISO/IEC 14496-2:1999/Cor.1:2000, "Information technology - Coding of audio-visual objects - Part2: Visual, Technical corrigendum 1".
9 ISO / IEC 14496-2：1999 / Cor.1：2000、 "情報技術 - オーディオビジュアルオブジェクトのコーディング - 第2部：ビジュアル、技術正誤表1"。
Yoshihiro Kikuchi Toshiba corporation 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki, 212-8582, Japan
よしひろ きくち としば こｒぽらちおん １、 こむかい としばーちょ、 さいわいーく、 かわさき、 ２１２ー８５８２、 じゃぱん
EMail: yoshihiro.kikuchi@toshiba.co.jp
メールアドレス：yoshihiro.kikuchi@toshiba.co.jp
Yoshinori Matsui Matsushita Electric Industrial Co., LTD. 1006, Kadoma, Kadoma-shi, Osaka, Japan
よしのり まつい まつした えぇｃｔりｃ いんづｓｔりあｌ こ。、 ＬＴＤ。 １００６、 かどま、 かどまーし、 おさか、 じゃぱん
EMail: matsui@drl.mei.co.jp
メールアドレス：matsui@drl.mei.co.jp
Toshiyuki Nomura NEC Corporation 4-1-1,Miyazaki,Miyamae-ku,Kawasaki,JAPAN
としゆき のむら ねＣ こｒぽらちおん ４ー１ー１、みやざき、みやまえーく、かわさき、じゃぱん
EMail: t-nomura@ccm.cl.nec.co.jp
メールアドレス：t-nomura@ccm.cl.nec.co.jp
Shigeru Fukunaga Oki Electric Industry Co., Ltd. 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan.
しげる ふくなが おき えぇｃｔりｃ いんづｓｔｒｙ こ。、 Ｌｔｄ。 １ー２ー２７ しろみ、 ちゅおーく、 おさか ５４０ー６０２５ じゃぱん。
EMail: fukunaga444@oki.co.jp
メールアドレス：fukunaga444@oki.co.jp
Hideaki Kimata Nippon Telegraph and Telephone Corporation 1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa, Japan
ひであき きまた にっぽん てぇｇらｐｈ あんｄ てぇｐほね こｒぽらちおん １ー１、 ひかりーのーおか、 よこすかーし、 かながわ、 じゃぱん
EMail: kimata@nttvdt.hil.ntt.co.jp
メールアドレス：kimata@nttvdt.hil.ntt.co.jp
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。