RFC5285 日本語訳
5285 A General Mechanism for RTP Header Extensions. D. Singer, H.Desineni. July 2008. (Format: TXT=36844 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Singer
Request for Comments: 5285 Apple, Inc.
Category: Standards Track H. Desineni
Qualcomm
July 2008
コメントを求めるワーキンググループD.歌手要求をネットワークでつないでください: 5285年のアップルInc.カテゴリ: 標準化過程H.Desineniクアルコム2008年7月
A General Mechanism for RTP Header Extensions
RTPヘッダー拡張子のための一般的機構
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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(レアル-時間Transportプロトコル)のヘッダー拡大機能を使用するために一般的機構を提供します。 それはそれぞれの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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 要件記法. . . . . . . . . . . . . . . . . . . . 2 3 目標. . . . . . . . . . . . . . . . . . . . . . . . . 2 4を設計してください。 パケットデザイン. . . . . . . . . . . . . . . . . . . . . . . . 3 4.1。 一般.34.2。 1バイトのヘッダー. . . . . . . . . . . . . . . . . . . . . 5 4.3。 2バイトのヘッダー. . . . . . . . . . . . . . . . . . . . . 6 5。 SDPシグナリングは.7 6を設計します。 .9 7に提供するか、または答えてください。 BNF構文. . . . . . . . . . . . . . . . . . . . . . . . . . 12 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 12 9。 IANA問題. . . . . . . . . . . . . . . . . . . . . 13 9.1。 IANAが.139.2を管理する識別子スペース。 SDP extmap Attribute. . . . . . . . . 14 10の登録。 承認. . . . . . . . . . . . . . . . . . . . . . . 15 11。 引用規格. . . . . . . . . . . . . . . . . . . . . 15
Singer & Desineni Standards Track [Page 1] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[1ページ]RFC5285RTPヘッダー拡大2008年7月
1. Introduction
1. 序論
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.
このメカニズムには、2つの目立っている欠点があります。 まず最初に、それは単一のRTPパケットで1個のヘッダーだけに拡大を可能にします。 2番目に、仕様は衝突を避けるためにどう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パケットで複数のヘッダー拡大要素を運ぶ後方のコンパチブル、そして、広げることができる手段を定義することによって、最初の欠点を取り除きます。 それはこれらの拡大要素がURIによって命名される定義、IETF仕様に基づき定義された拡大要素のためにIANA登録を定義して、および命名URIと識別子の間でRTPパケットで運ばれた値を写像するためのSession記述プロトコル(SDP)方法で2番目の欠点を取り除きます。
This header extension applies to RTP/AVP (the Audio/Visual Profile) and its extensions.
このヘッダー拡大はRTP/AVP(Audio/視覚のProfile)とその拡大に適用されます。
2. Requirements Notation
2. 要件記法
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Design Goals
3. デザイン目標
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.
このメカニズムはメディア形式ビットストリームに関連メタデータを埋める習慣への代替手段を提供します。 固定帯域幅チャンネルの上に送られたメディアデータでしばしばこれをしました。 これがいったん完了していると、特定のメディア形式のためのデコーダが、メタデータを抜粋するのに必要です。 また、メディア形式によって、メタデータが、メディアをコード化する時点で加えられる必要があるかもしれないので、メタデータに必要であるビット伝送速度は考慮に入れられます。 しかし、メタデータはその時、知られていないかもしれません。 後でメタデータを挿入するのはaを必要とすることができます。ビット伝送速度必要条件を満たすのを解読して、再コード化してください。
Singer & Desineni Standards Track [Page 2] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[2ページ]RFC5285RTPヘッダー拡大2008年7月
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レベルでメカニズムを提供するのは特定のフォームに関するメディアデータにメタデータを結ばせるより良いです。
4. Packet Design
4. パケットデザイン
4.1. General
4.1. 一般
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拡張子(以下では、1バイトの、そして、2バイトのヘッダーフォームのために、定義される)のために定義された値は建築定数にすぎません(例えば、ネットワークアナライザによる使用のための)。 それはこのヘッダー拡大が存在しているという決定的な指示である交渉/定義(例えば、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.
良いネットワーク習慣のように、必要であると、データは送られるだけであるべきです。 また、そのパケットが1つ以上の拡大要素を含んでいるなら、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
パケットのそれぞれの拡大要素には、ローカルの識別子(ID)と長さがあります。 流れにおける現在のローカルの識別子は、バンドの外で交渉されたに違いないか、または定義されたに違いありません。 静的割り付けが全くありません。
Singer & Desineni Standards Track [Page 3] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[3ページ]RFC5285RTPヘッダー拡大2008年7月
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がなければなりません。 値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.
拡大の2つの異形があります: 1バイトの、そして、2バイトのヘッダー。 (a) どんな与えられたRTPセッションでも、拡大の数が少なく、(b) 拡大自体が小さいと予想されて、1バイトのヘッダーフォームを好まれて、すべての受信機で支持しなければなりません。 流れは1バイトの、または、2バイトのヘッダーだけを含まなければなりません: 流れの中でそれらを混ぜてはいけません。 1バイトのヘッダーフォームには、すべての拡大が十分小さいときに、送信機SHOULD NOTは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〜16バイトを許容することに慎重に合図された長さの値に1を加えることによって、注意してください(その結果、長さの分野の0は、1バイトのデータが従うのを示します)。 これは16バイトのペイロードの重要な例を考慮します。 この添加は2バイトのヘッダーのために実行されません。そこでは、長さの分野が0〜255バイトのデータの長さを示します。
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]で、より遠くに探検されます。
Singer & Desineni Standards Track [Page 4] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[4ページ]RFC5285RTPヘッダー拡大2008年7月
4.2. One-Byte Header
4.2. 1バイトのヘッダー
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と長さを含む1バイトから始まります:
0
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| ID | len |
+-+-+-+-+-+-+-+-+
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が遭遇するなら、長さの分野は無視されるべきです、と全体の拡大の処理はその時、終えるべきであり、要素の前のID15の現在の拡大要素だけが考えました。
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バイトの値のキャリッジを可能にします。)(キャリッジはラベルと識別子の一般的な長さです)。
Singer & Desineni Standards Track [Page 5] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[5ページ]RFC5285RTPヘッダー拡大2008年7月
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ=3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID| L=0| データ| ID| L=1| データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...データ| 0 (パッド)| 0 (パッド)| ID| L=3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3. Two-Byte Header
4.3. 2バイトのヘッダー
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×100|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分野SHOULDを送付者がすべての0に用意ができて、受信機で無視しなければなりません。
Each extension element starts with a byte containing an ID and a byte containing a length:
1バイトがIDを含んでいて、1バイトが長さを含んでいるのからそれぞれの拡大要素は始動します:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Singer & Desineni Standards Track [Page 6] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[6ページ]RFC5285RTPヘッダー拡大2008年7月
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が4ビットの分野'appbits'(above)と拡大要素、および値の256参照を呼んでいて。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×10| 0×00| 長さ=3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID| L=0| ID| L=1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| 0 (パッド)| ID| L=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. SDP Signaling Design
5. SDPシグナリングデザイン
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を使用しなければなりません。メディア(かつてマッピングであるなら、セッションレベルがあるだけです)。 例えば、これらの規則に従わないマッピングは次のセクションで説明される申し出/答え交渉の間提示されるかもしれませんが、それらを適用できる前にconformant値に再写像するのが必要です。
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
各拡大はURIによって命名されます。 そのURIは、絶対でなければならなく、正確に拡大の形式と意味を特定します。 また、ドメイン名SHOULDを含むURIがフォームmmyyyyに月-日付を含んでいます。 URIの要素と課題の定義はオンであるか、またはまさしくそのであるドメイン名の所有者によって認可されたに違いありません。
Singer & Desineni Standards Track [Page 7] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[7ページ]RFC5285RTPヘッダー拡大2008年7月
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における'?')です。
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はすなわち、同じ流れ、セッションレベルにおいて一度適用するよりさらにかメディアレベルにおけるただ一つの流れのための宣言に現れてはいけません。 (同じ拡張子は、いくつかの流れにもちろん使用されて、同じ流れのために異なってparameterizedされているように見えるかもしれません。)
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.
URNが始動していたならRFCsで定義された拡大にURIがSHOULDを使用した、「つぼ:ietf:params: rtp-hdrext:、」 そして、登録されて、描写的である名前はあとに続きます。
The registration requirements are detailed in the IANA Considerations section, below.
登録要件は下のIANA Considerations部で詳細です。
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
つぼ: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
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.
すべての流れにマッピングをメディアの流れ(すなわち、SDPのメディアレベル部、「m=」線の後の)単位でグローバルに提供するかもしれません(すなわち、最初の「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>
a=extmap: <値の>、[「/「<指示>] <ユリ><extensionattributes>」
Singer & Desineni Standards Track [Page 8] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[8ページ]RFC5285RTPヘッダー拡大2008年7月
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)であり、"sendonly"の1つが"sendrecv"、または「recvonlyに」「不活発である」という(引用文なしで)有効枠包括的(0は両方のフォームでそっと歩くために予約されます、そして、15は1バイトのヘッダーフォームで予約されています、上で述べたように)と<指示>への整数です。
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'属性の存在です、すなわち、これが流行に合わせるヘッダー拡大の病気の特徴は使用されています、といずれのマジックナンバーも上で示しませんでした。
6. Offer/Answer
6. 提供するか、または答えてください。
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"です。指示は「recvonlyである」か、"sendrecv"の、または、「不活発である」"sendonly"の1つであるに違いありません。 "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"属性)と両立しない拡大指示を使用する誤りです。
Singer & Desineni Standards Track [Page 9] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[9ページ]RFC5285RTPヘッダー拡大2008年7月
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.)
申し出か答えがセッションレベルマッピング(そして、したがって、メディアレベルマッピングがない)を含んでいて、異なった振舞いが各流れのために望まれているなら、全体のセットの拡大地図宣言は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である」とマークされて、answererが、それを受けることを望んでいるなら、拡大をSDP答えで「recvonlyである」とマークしなければなりません。 拡大を受ける願望を全く持っていないか、または拡大SHOULDがSDP答えからそれを取り除くのを理解していないanswerer。
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である」とマークされて、answererが、それを送ることを望んでいるなら、拡大をSDP答えで「sendonlyである」とマークしなければなりません。 いいえを持っているanswererは望んでいるか、またはあります。SHOULDがそれを取り除く拡大に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).
同じメディアのための1つが「sendonlyに」さえ2つの拡大ともう片方にこの規則の下に「recvonlyに」同じローカルの識別子を使用できないことに注意してください、いずれか一方をsendrecvにするのがその時不可能であるだろうというときに(再付番が受入れられないので)。
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にある当時の倍数拡大を提供するかもしれません。 answererは、同じ識別子で提供された拡大の1つを高々選択して、その拡大が使用可能であるように有効枠の無料の識別子にそれをremapするはずです。
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の識別子を提供するかもしれません。 answererは有効枠の無料の識別子へのそれらを望まれているもの、およびremapに選ぶはずです。
Singer & Desineni Standards Track [Page 10] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[10ページ]RFC5285RTPヘッダー拡大2008年7月
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答え(例えば有効枠の自由な識別子価値の不足のため)に提供された識別子値を置くことができます。 もちろん有効枠の外に識別子がある拡張子を使用できません。 必要なら、申出人かanswererが、そのような拡大のためにスペースを作るためにセッションをアップデートできます。
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
a=extmap: 1URI-toffset a=extmap: 14のURI不鮮明なa=extmap: 4096URI gpsストリングa=extmap: 4096URI gpsバイナリーa=extmap: 4097URI-frametype 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:
answererはビデオだけの上に記号列の書式で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: a=sendrecv a=extmap: 1URI-toffset a=extmap: 2/recvonly URI gpsストリングa=extmap: 3URI-frametype m=オーディオ1/sendonly URI-toffset
Singer & Desineni Standards Track [Page 11] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[11ページ]RFC5285RTPヘッダー拡大2008年7月
7. BNF Syntax
7. BNF構文
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'が[RFC4566]で定義されるように属性である、すなわち、「=」はextmap定義に先行します。 特定のextensionattributesは特定の拡大名を定義する仕様で定義されます。 数個があるかもしれません。
extmap = mapentry SP extensionname [SP extensionattributes]
extmapはmapentry SP extensionnameと等しいです。[SP extensionattributes]
extensionname = URI
extensionnameは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>
RFC3986>で定義されたURI=<。
byte-string = <Defined in RFC 4566>
RFC4566>のバイトストリング=<Defined
SP = <Defined in RFC 5234>
SPはRFC5234>で定義された<と等しいです。
DIGIT = <Defined in RFC 5234>
RFC5234>で定義されたケタ=<。
8. Security Considerations
8. セキュリティ問題
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ヘッダー自体と同じセキュリティ適用範囲があります。 Secureレアル-時間Transportプロトコル(SRTP)[RFC3711]がRTPセッションを保護するのに使用されるとき、RTPペイロードはコード化されたかもしれません、そして、保全は保護されました、RTPヘッダーが保護がないか、または保全が保護されましたが。 したがって、明らかにされるなら警備上の問題を引き起こすヘッダー拡大に情報を置くのは不適当です、全体のRTPパケットが秘密性と保全能力の両方を提供する下層セキュリティプロトコルによって保護されない場合。
Singer & Desineni Standards Track [Page 12] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[12ページ]RFC5285RTPヘッダー拡大2008年7月
9. IANA Considerations
9. IANA問題
9.1. Identifier Space for IANA to Manage
9.1. IANAが管理する識別子スペース
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 Sub-名前空間仕様[RFC3553]によって必要とされた正式な宣言があります。
o Registry name: RTP Compact Header Extensions
o 登録名: RTPのコンパクトなヘッダー拡張子
o Specification: RFC 5285 and RFCs updating RFC 5285.
o 仕様: RFC5285とRFC5285をアップデートするRFCs。
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.
RFCsで定義された拡大においてURIはフォームつぼ: ietf:params:rtp-hdrextでは、: 正式な参照が拡大を記録するRFCのRFC番号であるということであることが推薦されます。
o Review process: Expert review is required. The expert review
should check the following requirements:
o 過程について調査してください: 専門のレビューが必要です。 専門のレビューは以下の要件をチェックするべきです:
1. that the specification is publicly available;
1. 仕様は公的に利用可能です。
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);
2. それ、拡大はRTPの要件とこの仕様に従います、拡大のために(流れが拡大であるならまだ解読可能であることは、著しく、無視されるか、または認識されません)。
3. that the extension specification is technically consistent (in
itself and with RTP), complete, and comprehensible;
3. ファイル拡張仕様書は、技術的に一貫(本来とRTPと)であって、完全で、分かりやすいです。
Singer & Desineni Standards Track [Page 13] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[13ページ]RFC5285RTPヘッダー拡大2008年7月
4. that the extension does not duplicate functionality in
existing IETF specifications (including RTP itself), or other
extensions already registered;
4. 拡大が既存のIETF仕様(RTP自身を含んでいる)、または他の拡大で機能性をコピーしないのは既に登録されました。
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 課題に頭文字をつけてください: なし。
9.2. Registration of the SDP extmap Attribute
9.2. SDP extmap Attributeの登録
This section contains the information required by [RFC4566] for an SDP attribute.
このセクションはSDP属性のために[RFC4566]によって必要とされた情報を含みます。
o contact name, email address, and telephone number:
o 名前、Eメールアドレス、および電話番号に連絡してください:
D. Singer
singer@apple.com
+1 408-974-3162
D.歌手 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
o 属性値はcharsetを受けることがあるか否かに関係なく、以下を結果と考えてください。 charset属性への対象でない
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 この属性のための適切な属性値の仕様: RFC5285を見てください。
Singer & Desineni Standards Track [Page 14] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[14ページ]RFC5285RTPヘッダー拡大2008年7月
10. Acknowledgments
10. 承認
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.
ブライアンLinkとジョンLazzaroの両方がこのドキュメントの初期の草稿に役に立つコメントを提供しました。 コリン・パーキンスは詳細を再検討して、対処することの助けになりました。 IETFが拡大を定義したので、URNsの使用はジョナサンレノックスによって提案されました、そして、ピートコーデルは詰め物言葉遣いを改良する際に手段になっていました。 デーヴ・オランはフィードバックとテキストをレビューに提供しました。 マイク・ドランは2バイトのヘッダーフォームを寄付しました。 マグヌスWesterlundとトム・テイラーは登録テキストを管理する際に手段になっていました。
11. Normative References
11. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン
[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.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 枠組みと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日
[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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、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] 食事、M.、Masinter、L.、ハーディー、T.、およびG.Klyne、「登録されたプロトコルパラメタのためのサブ名前空間のIETFつぼ」、BCP73、RFC3553(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] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[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、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
Singer & Desineni Standards Track [Page 15] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[15ページ]RFC5285RTPヘッダー拡大2008年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問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2008年1月。
Authors' Addresses
作者のアドレス
David Singer Apple, Inc. 1 Infinite Loop Cupertino, CA 95014 USA
デヴィッドカルパチーノ、歌手アップルInc.1無限ループカリフォルニア95014米国
Phone: +1 408 996 1010 EMail: singer@apple.com URI: http://www.apple.com/quicktime
以下に電話をしてください。 +1 1010年の408 996メール: singer@apple.com ユリ: http://www.apple.com/quicktime
Harikishan Desineni Qualcomm 5775 Morehouse Drive San Diego, CA 92126 USA
Harikishan Desineniクアルコム5775モアハウス・Driveカリフォルニア92126サンディエゴ(米国)
Phone: +1 858 845 8996 EMail: hd@qualcomm.com URI: http://www.qualcomm.com
以下に電話をしてください。 +1 8996年の858 845メール: hd@qualcomm.com ユリ: http://www.qualcomm.com
Singer & Desineni Standards Track [Page 16] RFC 5285 RTP Header Extensions July 2008
歌手とDesineni標準化過程[16ページ]RFC5285RTPヘッダー拡大2008年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Singer & Desineni Standards Track [Page 17]
歌手とDesineni標準化過程[17ページ]
一覧
スポンサーリンク
