Network Working Group D. Singer
Request for Comments: 5285 Apple, Inc.
Category: Standards Track H. Desineni
Qualcomm
July 2008
A General Mechanism for RTP Header Extensions
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session.
このドキュメントは、RTP（リアルタイムトランスポートプロトコル）のヘッダ拡張機能を使用する一般的なメカニズムを提供します。それは可能エクステンションの宇宙が大きく、登録が脱集中化された各RTPパケットに小さな拡張の小さな数を使用するオプションを提供します。セッションで使用されている実際の拡張子は、そのセッションのセットアップ情報で通知されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 5
4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 6
5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . . 7
6. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Identifier Space for IANA to Manage . . . . . . . . . . . 13
9.2. Registration of the SDP extmap Attribute . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . 15
The RTP specification [RFC3550] provides a capability to extend the RTP header. It defines the header extension format and rules for its use in Section 5.3.1. The existing header extension method permits at most one extension per RTP packet, identified by a 16-bit identifier and a 16-bit length field specifying the length of the header extension in 32-bit words.
RTP仕様[RFC3550]は、RTPヘッダを拡張する能力を提供します。これは、セクション5.3.1での使用のためのヘッダ拡張フォーマットとルールを定義します。既存のヘッダ拡張方法は、最大で1つの16ビット識別子によって識別されるRTPパケットあたりの拡張、及び32ビットワードのヘッダ拡張の長さを指定する16ビット長のフィールドを可能にします。
This mechanism has two conspicuous drawbacks. First, it permits only one header extension in a single RTP packet. Second, the specification gives no guidance as to how the 16-bit header extension identifiers are allocated to avoid collisions.
このメカニズムは、二つの目立つ欠点を有しています。まず、それは単一のRTPパケットにのみ1つのヘッダ拡張を可能にします。第二に、仕様は、16ビットのヘッダ拡張識別子が衝突を回避するために割り当てられる方法について何ら指針を与えません。
This specification removes the first drawback by defining a backward-compatible and extensible means to carry multiple header extension elements in a single RTP packet. It removes the second drawback by defining that these extension elements are named by URIs, defining an IANA registry for extension elements defined in IETF specifications, and a Session Description Protocol (SDP) method for mapping between the naming URIs and the identifier values carried in the RTP packets.
この仕様は、単一のRTPパケットに複数のヘッダ拡張要素を運ぶために下位互換性および拡張可能手段を定義することによって、第1の欠点を除去します。なお、第2のこれらの拡張要素がURIをによって命名されていることを定義することによって欠点、IETF仕様で定義された拡張要素のためのIANAレジストリを定義し、セッション記述プロトコル（SDP）で運ば命名URIと識別子の値との間のマッピングのための方法を削除しますRTPパケット。
This header extension applies to RTP/AVP (the Audio/Visual Profile) and its extensions.
このヘッダの拡張子は、RTP / AVP（オーディオ/ビジュアルプロファイル）とその拡張に適用されます。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The goal of this design is to provide a simple mechanism whereby multiple identified extensions can be used in RTP packets, without the need for formal registration of those extensions but nonetheless avoiding collision.
この設計の目標は、複数の識別機能拡張は、これらの拡張機能の正式な登録を必要とせずに、RTPパケットで使用されるが、それにもかかわらず、衝突を回避することができるシンプルなメカニズムを提供することです。
This mechanism provides an alternative to the practice of burying associated metadata into the media format bit stream. This has often been done in media data sent over fixed-bandwidth channels. Once this is done, a decoder for the specific media format is required to extract the metadata. Also, depending on the media format, the metadata may need to be added at the time of encoding the media so that the bit-rate required for the metadata is taken into account. But the metadata may not be known at that time. Inserting metadata at a later time can require a decode and re-encode to meet bit-rate requirements.
このメカニズムは、メディアフォーマットのビットストリームに関連するメタデータを埋め込むの実践に代わるものを提供します。これは、多くの場合、固定帯域幅チャネルを介して送信されたメディアデータに行われています。これが行われると、特定のメディアフォーマット用のデコーダは、メタデータを抽出するために必要とされます。また、メディアのフォーマットに応じて、メタデータは、メタデータに必要なビットレートが考慮されるように、メディアを符号化する時に添加する必要があるかもしれません。しかし、メタデータは、その時点で知られていない可能性が。後でメタデータを挿入するビットレート要件を満たすために、デコードおよび再エンコードを必要とすることができます。
In some cases, a more appropriate, higher-level mechanism may be available, and if so, it should be used. For cases where a higher-level mechanism is not available, it is better to provide a mechanism at the RTP level than have the metadata be tied to a specific form of media data.
いくつかの場合において、より適切な、より高いレベルのメカニズムが利用可能であってもよく、その場合、それが使用されるべきです。より高いレベルのメカニズムが利用できない場合のために、メタデータは、メディアデータの特定の形式に縛られる持っているよりRTPレベルのメカニズムを提供することに優れています。
The following design is fit into the "header extension" of the RTP extension, as described above.
上述したように、以下の設計では、RTPの拡張の「ヘッダ拡張」に適合しています。
The presence and format of this header extension and its contents are negotiated or defined out-of-band, such as through signaling (see below for SDP signaling). The value defined for an RTP extension (defined below for the one-byte and two-byte header forms) is only an architectural constant (e.g., for use by network analyzers); it is the negotiation/definition (e.g., in SDP) that is the definitive indication that this header extension is present.
このヘッダー拡張とその内容物の存在および形式は、（SDPシグナリングについては下記を参照）シグナリングを通じてとして、アウトオブバンドネゴシエートまたは定義されています。 （半角及び全角のヘッダフォームの下に定義された）RTPの拡張のために定義された値は、（ネットワークアナライザで使用するために、例えば）だけ建築定数です。それは、このヘッダ拡張が存在することを確定指示であるネゴシエーション/定義（例えば、SDP内）です。
This specification inherits the requirement from the RTP specification that the header extension "is designed so that the header extension may be ignored". To be specific, header extensions using this specification MUST only be used for data that can safely be ignored by the recipient without affecting interoperability, and MUST NOT be used when the presence of the extension has changed the form or nature of the rest of the packet in a way that is not compatible with the way the stream is signaled (e.g., as defined by the payload type). Valid examples might include metadata that is additional to the usual RTP information.
この仕様は、ヘッダ拡張子は「ヘッダ拡張を無視することができるように設計された」RTP仕様の要件を継承します。具体的には、この仕様を使用して、ヘッダの拡張だけで安全に相互運用性に影響を与えることなく、受信者によって無視することができるデータを使用しなければなりませんし、拡張の存在は、パケットの残りの部分の形や性質が変化したときに使用してはいけません（ペイロードタイプによって定義されるように、例えば）ストリームがシグナリングされる方法と互換性のない方法です。有効な例は通常のRTP情報に追加されたメタデータが含まれる場合があります。
The RTP header extension is formed as a sequence of extension elements, with possible padding. Each extension element has a local identifier and a length. The local identifiers may be mapped to a larger namespace in the negotiation (e.g., session signaling).
RTPヘッダ拡張が可能パディングと、拡張要素のシーケンスとして形成されています。各延長要素は、ローカル識別子と長さを有します。ローカル識別子は、ネゴシエーション（例えば、セッションシグナリング）が大きい名前空間にマッピングすることができます。
As is good network practice, data should only be transmitted when needed. The RTP header extension should only be present in a packet if that packet also contains one or more extension elements, as defined here. An extension element should only be present in a packet when needed; the signaling setup of extension elements indicates only that those elements may be present in some packets, not that they are in fact present in all (or indeed, any) packets.
優れたネットワークの練習であるので、必要なときに、データにのみ送信されるべきです。ここで定義されたように、そのパケットはまた、一つ以上の拡張要素が含まれている場合、RTPヘッダ拡張は、パケット内に存在しなければなりません。必要なときに拡張要素は、パケット内に存在する必要があります。拡張要素のシグナリング・セットアップは、これらの要素は、それらが実際にすべての（または実際に、任意の）パケットの中に存在しないことは、いくつかのパケットに存在してもよいことだけを示しています。
Each extension element in a packet has a local identifier (ID) and a length. The local identifiers present in the stream MUST have been negotiated or defined out-of-band. There are no static allocations of local identifiers. Each distinct extension MUST have a unique ID. The value 0 is reserved for padding and MUST NOT be used as a local identifier.
パケット内の各拡張要素は、ローカル識別子（ID）および長さを有します。ストリーム中に存在するローカル識別子は、アウトオブバンドネゴシエートまたは定義されていなければなりません。ローカル識別子の静的な割り当てはありません。各個別の拡張はユニークなIDを持たなければなりません。値0はパディングのために予約されており、ローカル識別子として使用してはなりません。
There are two variants of the extension: one-byte and two-byte headers. Since it is expected that (a) the number of extensions in any given RTP session is small and (b) the extensions themselves are small, the one-byte header form is preferred and MUST be supported by all receivers. A stream MUST contain only one-byte or two-byte headers: they MUST NOT be mixed within a stream. Transmitters SHOULD NOT use the two-byte form when all extensions are small enough for the one-byte header form.
1バイトと2バイトのヘッダ：拡張機能の二つの変種があります。 （a）は、任意の所与のRTPセッションにおける拡張の数が少ないと、（b）拡張自体が小さいことが予想されるため、1バイトのヘッダ形式が好ましく、全ての受信機によってサポートされなければなりません。ストリームは1バイトまたは2バイトのヘッダを含まなければなりません：彼らは、ストリーム内で混合してはなりません。すべての拡張機能は、1バイトのヘッダ形式のために十分に小さいとき、トランスミッタは、2バイトのフォームを使用しないでください。
A sequence of extension elements, possibly with padding, forms the header extension defined in the RTP specification. There are as many extension elements as fit into the length as indicated in the RTP header extension length. Since this length is signaled in full 32- bit words, padding bytes are used to pad to a 32-bit boundary. The entire extension is parsed byte-by-byte to find each extension element (no alignment is required), and parsing stops at the earlier of the end of the entire header extension, or, in one-byte headers, on encountering an identifier with the reserved value of 15.
拡張要素の配列は、おそらくパディングと、RTP仕様で定義されたヘッダ拡張を形成します。 RTPヘッダ拡張長さに示すように長さにフィット限り多くの拡張要素があります。この長さは、完全な32ビット・ワードでシグナリングされるので、パディングバイトは、32ビット境界にパッドに使用されます。全体の拡張は、各拡張要素を（全く位置合わせが必要とされない）を見つけるためにバイト単位で解析され、そして解析が有する識別子に遭遇に、1バイトのヘッダに、全体ヘッダ拡張の終了以前に停止し、または15の予約値。
In both forms, padding bytes have the value of 0 (zero). They may be placed between extension elements, if desired for alignment, or after the last extension element, if needed for padding. A padding byte does not supply the ID of an element, nor the length field. When a padding byte is found, it is ignored and the parser moves on to interpreting the next byte.
両方の形態では、パディングバイトは0（ゼロ）の値を有します。アライメントのための、または最後の延長要素の後、所望であればパディングに必要な場合、それらは、拡張要素の間に配置することができます。パディングバイトは要素のID、また長さフィールドを供給しません。パディングバイトが発見された場合、それは無視され、パーサは次のバイトの解釈に移ります。
Note carefully that the one-byte header form allows for data lengths between 1 and 16 bytes, by adding 1 to the signaled length value (thus, 0 in the length field indicates 1 byte of data follows). This allows for the important case of 16-byte payloads. This addition is not performed for the two-byte headers, where the length field signals data lengths between 0 and 255 bytes.
1バイトのヘッダ形式が信号の長さの値に1を加算し、1と16バイトのデータ長を可能にすることに慎重に注意してください（従って、長さフィールドに0がデータの1つのバイトは、以下を示します）。これは、16バイトのペイロードの重要なケースが可能になります。この添加は、0と255バイトの間の長さフィールド信号データ長2バイトヘッダ、行われません。
Use of RTP header extensions will reduce the efficiency of RTP header compression, since the header extension will be sent uncompressed unless the RTP header compression module is updated to recognize the extension header. If header extensions are present in some packets, but not in others, this can also reduce compression efficiency by requiring an update to the fixed header to be conveyed when header extensions start or stop being sent. The interactions of the RTP header extension and header compression is explored further in [RFC2508] and [RFC3095].
RTPヘッダ圧縮モジュールは、拡張ヘッダを認識するように更新されていない限り、ヘッダ拡張が圧縮されていない送信されるので、RTPヘッダ拡張を使用すると、RTPヘッダ圧縮の効率を低下させます。ヘッダ拡張は、いくつかのパケットに存在する場合はヘッダ拡張が開始または送信されて停止したときではなく、他に、これも搬送する固定ヘッダの更新を要求することにより、圧縮効率を低減することができます。 RTPヘッダ拡張ヘッダ圧縮の相互作用は、[RFC2508]及び[RFC3095]にさらに探求されています。
In the one-byte header form of extensions, the 16-bit value required by the RTP specification for a header extension, labeled in the RTP specification as "defined by profile", takes the fixed bit pattern 0xBEDE (the first version of this specification was written on the feast day of the Venerable Bede).
拡張の1バイトのヘッダ形式で、「プロファイルによって定義された」としてRTP仕様で標識されたヘッダ拡張のためのRTP仕様によって必要とされる16ビットの値は、固定ビットパターン0xBEDE（本明細書の最初のバージョンを取り）由緒あるビードの饗宴日に書かれていました。
Each extension element starts with a byte containing an ID and a length:
各延長要素は、IDおよび長さを含むバイトで始まります。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| ID | len |
+-+-+-+-+-+-+-+-+
The 4-bit ID is the local identifier of this element in the range 1-14 inclusive. In the signaling section, this is referred to as the valid range.
4ビットのIDは、範囲1-14包括におけるこの要素のローカル識別子です。シグナリングセクションでは、これは、有効範囲と呼ばれます。
The local identifier value 15 is reserved for future extension and MUST NOT be used as an identifier. If the ID value 15 is encountered, its length field should be ignored, processing of the entire extension should terminate at that point, and only the extension elements present prior to the element with ID 15 considered.
ローカル識別子の値15は、将来の拡張のために予約されており、識別子として使用してはいけません。 ID値15が発生した場合は、その長さフィールドは、全体の拡張の処理はその時点で終了する必要があり、無視され、ID 15を有する従来の要素に存在する唯一の拡張要素が考慮されるべきです。
The 4-bit length is the number minus one of data bytes of this header extension element following the one-byte header. Therefore, the value zero in this field indicates that one byte of data follows, and a value of 15 (the maximum) indicates element data of 16 bytes. (This permits carriage of 16-byte values, which is a common length of labels and identifiers, while losing the possibility of zero-length values -- which would often be padded anyway.)
4ビット長は数マイナス1バイトのヘッダに続くこのヘッダー拡張要素のデータバイトの1つです。したがって、このフィールドの値はゼロでは1バイトのデータが続くことを示し、及び15（最大）の値は、16バイトの要素のデータを示します。 （長さゼロの値の可能性失うしながらこれは、ラベルと識別子の共通の長さである16バイト値のキャリッジを、可能にする - 。多くの場合、とにかくパディングされます）
An example header extension, with three extension elements, some padding, and including the required RTP fields, follows:
例えばヘッダ拡張は、3つの拡張要素を、いくつかのパディング、および必要な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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xBE | 0xDE | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=0 | data | ID | L=1 | data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...data | 0 (pad) | 0 (pad) | ID | L=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the two-byte header form, the 16-bit value required by the RTP specification for a header extension, labeled in the RTP specification as "defined by profile", is defined as shown below.
以下に示すように、2バイトのヘッダ形式で、「プロファイルによって定義される」としてRTP仕様で標識されたヘッダ拡張のためのRTP仕様によって必要とされる16ビットの値は、定義されています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x100 |appbits|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The appbits field is 4 bits that are application-dependent and may be defined to be any value or meaning, and are outside the scope of this specification. For the purposes of signaling, this field is treated as a special extension value assigned to the local identifier 256. If no extension has been specified through configuration or signaling for this local identifier value 256, the appbits field SHOULD be set to all 0s by the sender and MUST be ignored by the receiver.
appbitsフィールドは、アプリケーション依存性であり、任意の値や意味であると定義され、本明細書の範囲外であることができる4ビットです。拡張子を構成によって指定されていないか、このローカル識別子の値256のためのシグナリングされた場合のシグナリングの目的のために、このフィールドはローカル識別子256に割り当てられた特別な拡張値として扱われ、appbitsフィールドがすべて0に設定されてください送信側と受信側は無視しなければなりません。
Each extension element starts with a byte containing an ID and a byte containing a length:
各延長要素は、IDおよび長さを含むバイトを含むバイトで始まります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 8-bit ID is the local identifier of this element in the range 1-255 inclusive. In the signaling section, the range 1-256 is referred to as the valid range, with the values 1-255 referring to extension elements, and the value 256 referring to the 4-bit field 'appbits' (above).
8ビットのIDは、包括範囲1〜255で、この要素のローカル識別子です。シグナリング手段において、範囲1-256は値1〜255が拡張要素を参照し、値256は4ビットのフィールド「appbits」（上記）を参照して、有効範囲と呼ばれます。
The 8-bit length field is the length of extension data in bytes not including the ID and length fields. The value zero indicates there is no data following.
8ビットの長さフィールドは、ID及び長フィールドを含まないバイト単位で拡張データの長さです。値ゼロはデータの次がないことを示します。
An example header extension, with three extension elements, some padding, and including the required RTP fields, follows:
例えばヘッダ拡張は、3つの拡張要素を、いくつかのパディング、および必要な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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x10 | 0x00 | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=0 | ID | L=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data | 0 (pad) | ID | L=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The indication of the presence of this extension, and the mapping of local identifiers used in the header extension to a larger namespace, MUST be performed out-of-band, for example, as part of a SIP offer/ answer exchange using SDP. This section defines such signaling in SDP.
この拡張の存在の指標、及びより大きな名前空間にヘッダ拡張で使用されるローカル識別子のマッピング、SDPを使用してSIPオファー/アンサー交換の一部として、例えば、アウトオブバンド行われなければなりません。このセクションでは、SDPでそのようなシグナルを定義します。
A usable mapping MUST use IDs in the valid range, and each ID in this range MUST be used only once for each media (or only once if the mappings are session level). Mappings that do not conform to these rules MAY be presented, for instance, during offer/answer negotiation as described in the next section, but remapping to conformant values is necessary before they can be applied.
使用可能なマッピングは、有効範囲内のIDを使用しなければなりません、及び（マッピングはセッションレベルであれば、一度だけ又は）この範囲内の各IDは、各メディアに対して一度だけ使用されなければなりません。これらの規則に準拠していないマッピングは、次のセクションで説明するようにオファー/アンサーネゴシエーション中に、例えば、提示、しかし、それらが適用される前に準拠した値に再マッピングする必要があるかもしれません。
Each extension is named by a URI. That URI MUST be absolute, and precisely identifies the format and meaning of the extension. URIs that contain a domain name SHOULD also contain a month-date in the form mmyyyy. The definition of the element and assignment of the URI MUST have been authorized by the owner of the domain name on or very close to that date. (This avoids problems when domain names change ownership.) If the resource or document defines several extensions, then the URI MUST identify the actual extension in use, e.g., using a fragment or query identifier (characters after a '#' or '?' in the URI).
各拡張は、URIによって命名されます。 URIは絶対的で、かつ正確拡張のフォーマットと意味を識別しなければならないこと。ドメイン名を含むURIは、フォームのmmyyyyの月・日を含むべきです。要素とURIの割り当ての定義は、上のドメイン名の所有者またはその日付に非常に近いによって認可されている必要があります。 （ドメイン名は、所有権を変更するときに問題を回避することができます。）リソースまたはドキュメントのいくつかの拡張が定義されている場合、URIは「＃」の後の断片またはクエリ識別子（文字を使用して、例えば、使用中の実際の拡張子を識別したりしなければなりません「？」 URIで）。
Rationale: the use of URIs provides for a large, unallocated space,
理論的根拠：URIの使用は、大きな、未割り当て領域を提供し、
and gives documentation on the extension. The URIs are not required to be de-referencable, in order to permit confidential or experimental use, and to cover the case when extensions continue to be used after the organization that defined them ceases to exist.
そして延長上のドキュメントを提供します。 URIは、機密情報や実験的な使用を可能にするために、拡張機能は、それらが存在しなく定義された組織の後に使用され続けたときにケースをカバーするために、非参照可能する必要はありません。
An extension URI with the same attributes MUST NOT appear more than once applying to the same stream, i.e., at session level or in the declarations for a single stream at media level. (The same extension may, of course, be used for several streams, and may appear differently parameterized for the same stream.)
同じ属性を持つ拡張URI、すなわち、セッションレベルまたは媒体レベルでの単一ストリームの宣言に、一度同じストリームに適用以上現れてはいけません。 （同じ拡張子は、当然のことながら、いくつかのストリームのために使用されてもよいし、同じストリームに対して異なるパラメータ化され表示されることがあります。）
For extensions defined in RFCs, the URI used SHOULD be a URN starting "urn:ietf:params:rtp-hdrext:" and followed by a registered, descriptive name.
RFCで定義された拡張のために、URIが「：IETF：paramsは：RTP-hdrext：URN」を開始URNされるべきであると登録され、記述名が続きます。
The registration requirements are detailed in the IANA Considerations section, below.
登録要件は、以下の、IANAの考慮事項のセクションで詳述されています。
An example (this is only an example), where 'avt-example-metadata' is the hypothetical name of a header extension, might be:
「AVT-例えば、メタデータは、」ヘッダ拡張の仮想的な名前であり、例は（これは一例に過ぎない）、であるかもしれません。
urn:ietf:params:rtp-hdrext:avt-example-metadata
URN：IETF：のparams：RTP-hdrext：AVT-例 - メタデータ
An example name not from the IETF (this is only an example) might be:
ないIETF（これは一例に過ぎない）から、例の名前は次のようになります。
http://example.com/082005/ext.htm#example-metadata
ｈっｔｐ：／／えぁｍｐぇ。こｍ／０８２００５／えｘｔ。ｈｔｍ＃えぁｍｐぇーめただた
The mapping may be provided per media stream (in the media-level section(s) of SDP, i.e., after an "m=" line) or globally for all streams (i.e., before the first "m=" line, at session level). The definitions MUST be either all session level or all media level; it is not permitted to mix the two styles. In addition, as noted above, the IDs used MUST be unique for each stream type for a given media, or for the session for session-level declarations.
マッピングは、セッションに、（「M =」行の後に、SDPのメディアレベル部（S）において、IE）またはグローバル最初の「M =」行の前にすべてのストリーム（すなわち、のためのメディアストリームごとに設けられていてもよいですレベル）。定義は、すべてのセッションレベルまたはすべてのメディアのレベルのいずれかでなければなりません。 2つのスタイルをミックスすることが許可されていません。上述のように加えて、使用されるIDは、所与のメディアのために、またはセッションレベルの宣言のためのセッションのそれぞれのストリームタイプに対して一意でなければなりません。
Each local identifier potentially used in the stream is mapped to a string using an attribute of the form:
潜在ストリームで使用される各ローカル識別子は、フォームの属性を使用して文字列にマッピングされます。
a=extmap:<value>["/"<direction>] <URI> <extensionattributes>
= extmap <値> "/" <方向> <URI> <extensionattributes>
where <URI> is a URI, as above, <value> is the local identifier (ID) of this extension and is an integer in the valid range inclusive (0 is reserved for padding in both forms, and 15 is reserved in the one-byte header form, as noted above), and <direction> is one of "sendonly", "recvonly", "sendrecv", or "inactive" (without the quotes).
ここで、<URI> URI、上記のように、<値>この拡張機能のローカル識別子（ID）であり、包括的有効範囲の整数（0は両方の形式でパディングのために予約され、そして15一に確保されています-byteヘッダ上述のようにフォーム）、及び<方向>は引用符「のsendrecv」、または「非アクティブ」（）、「recvonlyで」、「sendonlyで」の一つです。
The formal BNF syntax is presented in a later section of this specification.
正式なBNF構文は、この明細書の後のセクションで提示されます。
Example:
例：
a=extmap:1 http://example.com/082005/ext.htm#ttime
A = extmap：1 http://example.com/082005/ext.htm#ttime
a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short
A = extmap：2 / SENDRECV http://example.com/082005/ext.htm#xmeta短いです
When SDP signaling is used for the RTP session, it is the presence of the 'extmap' attribute(s) that is diagnostic that this style of header extensions is used, not the magic number indicated above.
SDPシグナリングがRTPセッションのために使用される場合、それはヘッダ拡張のこのスタイルが使用される診断である「extmap」属性（単数または複数）の存在ではなく、マジックナンバーは、上記に示しました。
The simple signaling described above may be enhanced in an offer/ answer context, to permit:
上記の簡単なシグナリングが可能にするために、オファー/アンサーコンテキストで強化することができます。
o asymmetric behavior (extensions sent in only one direction),
O非対称動作（一方向のみに送信される拡張子）、
o the offer of mutually exclusive alternatives, or
O相互に排他的な選択肢の提供、または
o the offer of more extensions than can be sent in a single session.
単一のセッションで送信することができる以上の拡張機能の提供、O。
A direction attribute MAY be included in an extmap; without it, the direction implicitly inherits, of course, from the stream direction, or is "sendrecv" for session-level attributes or extensions of "inactive" streams. The direction MUST be one of "sendonly", "recvonly", "sendrecv", or "inactive". A "sendonly" direction indicates an ability to send; a "recvonly" direction indicates a desire to receive; a "sendrecv" direction indicates both. An "inactive" direction indicates neither, but later re-negotiation may make an extension active.
方向属性がextmapに含まれるかもしれ。それなしで、方向が暗黙的にストリーム方向から、当然のことながら、継承、またはセッションレベルの属性または「非アクティブ」のストリームの拡張のための「SENDRECV」です。方向は「sendonlyの」、「がrecvonly」、「SENDRECV」の一つ、または「非アクティブ」でなければなりません。 「sendonlyで」方向は、送信する能力を示します。 「recvonlyで」方向は、受信する願望を示します。 「SENDRECV」方向は、両方を示しています。 「非アクティブ」の方向はどちらも示していないが、後で再交渉は、拡張子をアクティブにすることがあります。
Extensions, with their directions, may be signaled for an "inactive" stream. It is an error to use an extension direction incompatible with the stream direction (e.g., a "sendonly" attribute for a "recvonly" stream).
拡張機能は、その方向で、「非アクティブ」ストリームの合図をすることができます。ストリームの方向（例えば、「recvonlyで」ストリームのための「sendonlyの」属性）と互換性のない拡張方向を使用するとエラーになります。
If an offer or answer contains session-level mappings (and hence no media-level mappings), and different behavior is desired for each stream, then the entire set of extension map declarations may be moved into the media-level section(s) of the SDP. (Note that this specification does not permit mixing global and local declarations, to make identifier management easier.)
オファーまたは答えはセッション・レベルのマッピング（したがって無メディア・レベルのマッピング）が含まれ、そして異なる挙動は各ストリームのために所望される場合、拡張マップ宣言のセット全体は、メディアレベル部（S）の中に移動させてもよいですSDP。 （この仕様は、識別子管理を容易にするために、グローバルとローカルの宣言を混合許可していないことに注意してください。）
If an extension map is offered as "sendrecv", explicitly or implicitly, and asymmetric behavior is desired, the SDP may be modified to modify or add direction qualifiers for that extension. If an extension is marked as "sendonly" and the answerer desires to receive it, the extension MUST be marked as "recvonly" in the SDP answer. An answerer that has no desire to receive the extension or does not understand the extension SHOULD remove it from the SDP answer.
拡張マップを明示的または暗黙的に、「のsendrecv」として提供され、非対称動作が望まれる場合、SDPは、その伸長する方向修飾子を変更または追加するように修正されてもよいです。拡張子は「sendonlyで」としてマークされ、回答がそれを受信することを希望される場合は、拡張子が「recvonlyで」SDPの答えのようにマークする必要があります。拡張子を受信するための欲求を持っていないか、拡張子を理解していない回答には、SDPアンサーから削除する必要があります。
If an extension is marked as "recvonly" and the answerer desires to send it, the extension MUST be marked as "sendonly" in the SDP answer. An answerer that has no desire to, or is unable to, send the extension SHOULD remove it from the SDP answer.
拡張子は「がrecvonly」としてマークされ、回答がそれを送信することを希望される場合は、拡張子が「sendonlyで」SDPの答えのようにマークする必要があります。欲求を持っていない、または、SDPの答えからそれを削除する必要があります拡張子を送信することができません回答。
Local identifiers in the valid range inclusive in an offer or answer must not be used more than once per media section (including the session-level section). A session update MAY change the direction qualifiers of extensions under use. A session update MAY add or remove extension(s). Identifiers values in the valid range MUST NOT be altered (remapped).
申し出または回答に包括的で有効な範囲のローカル識別子は、（セッション・レベルのセクションを含む）メディアセクションごとに複数回使用することはできません。セッション更新は使用下の拡張の方向修飾子を変更することがあります。セッション更新は、拡張子（複数可）を追加または削除することができます。有効範囲内の識別子の値が変更されてはいけません（再マッピング）。
Note that, under this rule, the same local identifier cannot be used for two extensions for the same media, even when one is "sendonly" and the other "recvonly", as it would then be impossible to make either of them sendrecv (since re-numbering is not permitted either).
それ以来のsendrecvそれらのいずれかを（作ることは不可能であろうと、人は「sendonlyで」で、他の「がrecvonly」場合でも、このルールの下で、同じローカル識別子が同じメディアのための2つの拡張のために使用することはできない、ということに注意してください再番号付け）のいずれかが許可されていません。
If a party wishes to offer mutually exclusive alternatives, then multiple extensions with the same identifier in the (unusable) range 4096-4351 may be offered; the answerer should select at most one of the offered extensions with the same identifier, and remap it to a free identifier in the valid range, for that extension to be usable.
当事者が相互に排他的な選択肢を提供することを希望する場合は、（使用できない）の範囲4096から4351で同じ識別子を持つ複数の拡張子を提供することができます。回答は、同じ識別子を持つ提供の拡張機能の最大1つを選択し、使用できるように、その拡張子のために、有効な範囲内で自由識別子にそれを再マップする必要があります。
Similarly, if more extensions are offered than can be fit in the valid range, identifiers in the range 4096-4351 may be offered; the answerer should choose those that are desired, and remap them to a free identifier in the valid range.
同様に、より多くの拡張機能が有効な範囲内に収まることができるより提供されていた場合、4096から4351が提供されることがあり範囲内の識別子。回答が望まれているものを選択して、有効範囲内の空き識別子にそれらを再マッピングする必要があります。
It is always allowed to place the offered identifier value "as is" in the SDP answer (for example, due to lack of a free identifier value in the valid range). Extensions with an identifier outside the valid range cannot, of course, be used. If required, the offerer or answerer can update the session to make space for such an extension.
（有効範囲で自由識別子の値が不足しているため、例えば）SDPの答えに「そのまま」常に提供識別子の値を配置することが許可されています。有効範囲外の識別子を持つ拡張機能は、当然のことながら、使用することはできません。必要な場合は、オファー側またはアンサー側は、そのような拡張のためのスペースを作るために、セッションを更新することができます。
Rationale: the range 4096-4351 for these negotiation identifiers is deliberately restricted to allow expansion of the range of valid identifiers in future.
理論的根拠：これらの交渉識別子の範囲を4096から4351には、意図的に将来的には有効な識別子の範囲の拡大を可能にするために制限されています。
Either party MAY include extensions in the stream other than those negotiated, or those negotiated as "inactive", for example, for the benefit of intermediate nodes. Only extensions that appeared with an identifier in the valid range in SDP originated by the sender can be sent.
いずれの当事者は、例えば、中間ノードの利益のために、交渉された以外のストリームでの拡張機能、または「非アクティブ」として交渉さものを挙げることができます。送信者によって発信SDPでの有効範囲内の識別子で登場だけの拡張機能を送信することができます。
Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. all omitted for brevity):
例（等ポート番号、RTPプロファイル、ペイロードIDとrtpmaps、すべての簡略化のため省略）。
The offer:
提供：
a=extmap:1 URI-toffset a=extmap:14 URI-obscure a=extmap:4096 URI-gps-string a=extmap:4096 URI-gps-binary a=extmap:4097 URI-frametype m=video a=sendrecv m=audio a=sendrecv
= extmap：1 URI-TOFFSET A = extmap：14 URI-不明瞭A = extmap：4096 URI-GPS-列A = extmap：4096 URI-GPSバイナリA = extmap：4097 URI-フレームタイプM =映像A = SENDRECV M =オーディオA = SENDRECV
The answerer is interested in receiving GPS in string format only on video, but cannot send GPS at all. It is not interested in transmission offsets on audio, and does not understand the URI-obscure extension. It therefore moves the extensions from session level to media level, and adjusts the declarations:
回答はビデオのみで文字列形式でGPSを受信することに関心があるが、すべてではGPSを送信することはできません。それは、音声の伝送オフセットに興味を持っていない、とURI-あいまいな拡張を理解していません。したがって、セッションレベルからメディアレベルに拡張を移動し、宣言を調整します：
m=video a=sendrecv a=extmap:1 URI-toffset a=extmap:2/recvonly URI-gps-string a=extmap:3 URI-frametype m=audio a=sendrecv a=extmap:1/sendonly URI-toffset
M =映像A = SENDRECV A = extmap：1 URI-TOFFSET A = extmap：2 / recvonlyでURI-GPS-列A = extmap：3 URI-フレームタイプM =オーディオA = SENDRECV A = extmap：1 / sendonlyのURI-TOFFSET
The syntax definition below uses ABNF according to [RFC5234]. The syntax element 'URI' is defined in [RFC3986] (only absolute URIs are permitted here). The syntax element 'extmap' is an attribute as defined in [RFC4566], i.e., "a=" precedes the extmap definition. Specific extensionattributes are defined by the specification that defines a specific extension name; there may be several.
構文定義は、以下の[RFC5234]に従ってABNF使用します。構文要素「URI」は[RFC3986]で定義されている（唯一絶対URIはここで許可されて）。シンタックス要素「extmap」はすなわち、「=」extmap定義の前に、[RFC4566]で定義される属性です。特定extensionattributesは、特定の拡張子名を定義する仕様で定義されています。いくつかがあるかもしれません。
extmap = mapentry SP extensionname [SP extensionattributes]
extmap = mapentry SPがextensionName [SPのextensionattributes]
extensionname = URI
拡張名= URI
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"
方向= "sendonlyで" / "がrecvonly" / "のsendrecv" / "非アクティブ"
mapentry = "extmap:" 1*5DIGIT ["/" direction]
mapentry = "extmap：" 1 * 5DIGIT [ "/" 方向]
extensionattributes = byte-string
extensionattributes =バイト列
URI = <Defined in RFC 3986>
URI = <RFC 3986で定義されました>
byte-string = <Defined in RFC 4566>
<RFC 4566で定義>バイトの文字列=
SP = <Defined in RFC 5234>
SP = <RFC 5234で定義されました>
DIGIT = <Defined in RFC 5234>
<RFC 5234で定義> DIGIT =
This defines only a place to transmit information; the security implications of the extensions must be discussed with those extensions.
これは、情報を送信する唯一の場所を定義します。拡張子のセキュリティへの影響は、これらの拡張子で議論されなければなりません。
Care should be taken when defining extensions. Clearly, they should be solely informative, but even when the information is extracted, should not cause security concerns.
拡張子を定義するときには注意が必要です。明らかに、彼らは単に情報を提供する必要がありますが、情報が抽出された場合でも、セキュリティ上の問題が発生することはありません。
Header extensions have the same security coverage as the RTP header itself. When Secure Real-time Transport Protocol (SRTP) [RFC3711] is used to protect RTP sessions, the RTP payload may be both encrypted and integrity protected, while the RTP header is either unprotected or integrity protected. Therefore, it is inappropriate to place information in header extensions that cause security problems if disclosed, unless the entire RTP packet is protected by a lower-layer security protocol providing both confidentiality and integrity capability.
ヘッダ拡張は、RTPヘッダ自体と同じセキュリティカバレッジを持っています。セキュアリアルタイムトランスポートプロトコル（SRTP）[RFC3711]はRTPセッションを保護するために使用される場合、RTPペイロードは両方の暗号化されてもよいし、完全性が保護され、RTPヘッダは、保護された保護されていない、または完全性のいずれかです。したがって、全体のRTPパケットは機密性と完全性の両方を提供する下位層セキュリティプロトコルによって保護されていない限り、開示されている場合、セキュリティ上の問題を引き起こすヘッダ拡張内の情報を配置することは不適切です。
The mapping from the naming URI form to a reference to a specification is managed by IANA. Insertion into this registry is under the requirements of "Expert Review" as defined in [RFC5226].
明細書を参照に命名URI形式からマッピングは、IANAによって管理されています。このレジストリへの挿入は、[RFC5226]で定義されている「エキスパートレビュー」の要件の下にあります。
The IANA will also maintain a server that contains all of the registered elements in a publicly accessible space.
IANAはまた、公的にアクセス可能なスペースに登録されたすべての要素が含まれているサーバーを維持します。
Here is the formal declaration required by the IETF URN Sub-namespace specification [RFC3553].
ここでIETF URNサブ名前空間の仕様[RFC3553]によって必要とされる正式な宣言があります。
o Registry name: RTP Compact Header Extensions
Oレジストリ名：RTPコンパクトヘッダー拡張
o Specification: RFC 5285 and RFCs updating RFC 5285.
O仕様：RFC 5285およびRFC 5285を更新するRFC。
o Information required:
O情報が必要：
A. The desired extension naming URI
A. URIの命名希望の拡張子を
B. A formal reference to the publicly available specification
B.公的に利用可能な仕様に正式参照
C. A short phrase describing the function of the extension
C.拡張の機能を説明する短いフレーズ
D. Contact information for the organization or person making the registration
登録をする組織や人のためのD.連絡先情報
For extensions defined in RFCs, the URI is recommended to be of the form urn:ietf:params:rtp-hdrext:, and the formal reference is the RFC number of the RFC documenting the extension.
拡張を文書RFCのRFC番号がRTP-hdrext :,およびフォーマル基準である：IETF：paramsはRFCで定義された拡張のために、URIの形式のURNであることが推奨されます。
o Review process: Expert review is required. The expert review should check the following requirements:
Oのレビュープロセス：エキスパートレビューが必要です。専門家レビューは以下の要件を確認する必要があります：
2. that the extension complies with the requirements of RTP and this specification, for extensions (notably, that the stream is still decodable if the extension is ignored or not recognized);
拡張は、拡張のためのRTP及び本明細書の要件（特に、拡張が無視されるか、または認識されない場合、ストリームが依然として復号可能であること）に準拠していること2。
3. that the extension specification is technically consistent (in itself and with RTP), complete, and comprehensible;
拡張仕様は、（それ自体で及びRTPを用いて）、完全な、そして理解技術的に一致している3。
4. that the extension does not duplicate functionality in existing IETF specifications (including RTP itself), or other extensions already registered;
4.拡張子が、または他の拡張機能既に登録（RTP自体を含む）は、既存のIETF仕様の機能を複製しないこと。
5. that the specification contains a security analysis regarding the content of the header extension;
仕様はヘッダ拡張のコンテンツに関するセキュリティ分析を含んでいる5。
6. that the extension is generally applicable, for example point-to-multipoint safe, and the specification correctly describes limitations if they exist; and
拡張は、例えば、ポイント・ツー・マルチポイント安全な一般的に適用可能であり、それらが存在する場合、仕様が正しく制限について説明6。そして
7. that the suggested naming URI form is appropriately chosen and unique.
7.命名提案URIの形式が適切に選択し、一意であること。
o Size and format of entries: a mapping from a naming URI string to a formal reference to a publicly available specification, with a descriptive phrase and contact information.
エントリのOサイズとフォーマット：一般に入手可能な仕様に正式参照するネーミングURI文字列からマッピング、わかりやすいフレーズとコンタクト情報を持ちます。
o Initial assignments: none.
O初期の割り当て：なし。
This section contains the information required by [RFC4566] for an SDP attribute.
このセクションでは、SDP属性の[RFC4566]で必要な情報が含まれています。
o contact name, email address, and telephone number:
連絡先の名前、電子メールアドレス、および電話番号を○：
D. Singer
singer@apple.com
+1 408-974-3162
o attribute name (as it will appear in SDP): extmap
O属性名（それはSDPに表示される）：extmap
o long-form attribute name in English: generic header extension map definition
英語でのO長い形式の属性名：ジェネリックヘッダ拡張マップ定義
o type of attribute (session level, media level, or both): both
属性のO型（セッション・レベル、メディアレベル、または両方）の両方
o whether the attribute value is subject to the charset attribute: not subject to the charset attribute
charset属性の対象ではない：属性値は、charset属性の対象となるかどうかをO
o a one-paragraph explanation of the purpose of the attribute: This attribute defines the mapping from the extension numbers used in packet headers into extension names as documented in specifications and appropriately registered.
O属性の目的の1段落の説明：この属性は、仕様に文書化され、適切に登録された拡張子名にパケットヘッダに使用される内線番号のマッピングを定義します。
o a specification of appropriate attribute values for this attribute: see RFC 5285.
この属性の適切な属性値の仕様O：RFC 5285を参照してください。
Both Brian Link and John Lazzaro provided helpful comments on an initial draft of this document. Colin Perkins was helpful in reviewing and dealing with the details. The use of URNs for IETF-defined extensions was suggested by Jonathan Lennox, and Pete Cordell was instrumental in improving the padding wording. Dave Oran provided feedback and text in the review. Mike Dolan contributed the two-byte header form. Magnus Westerlund and Tom Taylor were instrumental in managing the registration text.
ブライアン・リンクとジョンラザロの両方が、この文書の最初の草案に役に立つコメントを提供しました。コリン・パーキンスは、見直しや詳細を扱うのに役立ちました。 IETF定義の拡張機能のためのURNの使用は、ジョナサン・レノックスによって示唆された、とピートコーデルは、パディング文言を向上させることに尽力しました。デイブ・オランはレビューにフィードバックし、テキストを提供しました。マイクドランは、2バイトのヘッダ形式に貢献しました。マグヌスウェスター、トム・テイラーは、登録テキストの管理に尽力しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508] Casner、S.とV. Jacobson氏、 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"、RFC 2508、1999年2月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
[RFC3553] Mealling、M.、Masinter、L.、ハーディー、T.、およびG. Klyne、 "登録プロトコル・パラメータのためのIETF URNサブ名前空間"、BCP 73、RFC 3553、2003年6月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
Authors' Addresses
著者のアドレス
David Singer Apple, Inc. 1 Infinite Loop Cupertino, CA 95014 USA
デビッド・シンガーアップル社1無限ループクパチーノ、CA 95014 USA
Phone: +1 408 996 1010 EMail: singer@apple.com URI: http://www.apple.com/quicktime
電話：+1 408 996 1010 Eメール：singer@apple.com URI：http://www.apple.com/quicktime
Harikishan Desineni Qualcomm 5775 Morehouse Drive San Diego, CA 92126 USA
Harikishan Desineniクアルコム5775 Morehuseドライブサンディエゴ、92126それ
Phone: +1 858 845 8996 EMail: hd@qualcomm.com URI: http://www.qualcomm.com
電話：+1 858 845 8996 Eメール：hd@qualcomm.com URI：http://www.qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。