[要約] RFC 8285は、RTPヘッダー拡張の一般的なメカニズムを提供するためのものであり、RTPパケットに追加の情報を含めるための方法を定義しています。このRFCの目的は、RTPヘッダーの拡張機能を標準化し、さまざまなアプリケーションでの柔軟性と互換性を向上させることです。
Internet Engineering Task Force (IETF) D. Singer
Request for Comments: 8285 Apple, Inc.
Obsoletes: 5285 H. Desineni
Category: Standards Track Qualcomm
ISSN: 2070-1721 R. Even, Ed.
Huawei Technologies
October 2017
A General Mechanism for RTP Header Extensions
RTPヘッダー拡張の一般的なメカニズム
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 decentralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC 5285.
このドキュメントでは、RTP（リアルタイム転送プロトコル）のヘッダー拡張機能を使用するための一般的なメカニズムについて説明します。これは、各RTPパケットで少数の小さな拡張機能を使用するオプションを提供します。可能な拡張機能の範囲は大きく、登録は分散化されています。セッションで使用されている実際の拡張機能は、そのセッションのセットアップ情報で通知されます。このドキュメントはRFC 5285を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8285.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8285で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Notation ...........................................3
3. Design Goals ....................................................3
4. Packet Design ...................................................4
4.1. General ....................................................4
4.1.1. Transmission Considerations .........................5
4.1.2. Header Extension Type Considerations ................6
4.2. One-Byte Header ............................................8
4.3. Two-Byte Header ............................................9
5. SDP Signaling Design ...........................................10
6. SDP Signaling for Support of Mixed One-Byte and Two-Byte
Header Extensions ..........................................12
7. SDP Offer/Answer ...............................................13
8. BNF Syntax .....................................................17
9. Security Considerations ........................................17
10. IANA Considerations ...........................................18
10.1. Identifier Space for IANA to Manage ......................18
10.2. Registration of the SDP "extmap" Attribute ...............20
10.3. Registration of the SDP "extmap-allow-mixed" Attribute ...20
11. Changes from RFC 5285 .........................................21
12. References ....................................................21
12.1. Normative References .....................................21
12.2. Informative References ...................................23
Acknowledgments ...................................................24
Authors' Addresses ................................................25
The RTP specification [RFC3550] provides a capability to extend the RTP header. Section 5.3.1 of [RFC3550] defines the header extension format and rules for its use. 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ヘッダーを拡張する機能を提供します。 [RFC3550]のセクション5.3.1は、ヘッダー拡張形式とその使用規則を定義しています。既存のヘッダー拡張方式では、RTPパケットごとに最大1つの拡張を許可します。これは、16ビットの識別子と、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つの顕著な欠点があります。まず、1つの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 providing 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と実行される識別子の値をマッピングするためのセッション記述プロトコル（SDP）メソッドを提供することにより、2番目の欠点を取り除きますRTPパケット。
This header extension applies to RTP/AVP (the Audio/Visual Profile) and its extensions.
このヘッダー拡張は、RTP / AVP（オーディオ/ビジュアルプロファイル）とその拡張に適用されます。
This document obsoletes [RFC5285] and removes a limitation from RFC 5285 that did not allow sending both one-byte and two-byte header extensions in the same RTP stream.
このドキュメントは[RFC5285]を廃止し、同じRTPストリームで1バイトと2バイトの両方のヘッダー拡張の送信を許可しなかったRFC 5285からの制限を削除します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
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 collisions.
この設計の目標は、RTPパケットで複数の識別された拡張を使用できる単純なメカニズムを提供することです。これらの拡張を正式に登録する必要はありませんが、それでも衝突を回避します。
This mechanism provides an alternative to the practice of burying associated metadata into the media format bitstream. This has often been done in media data sent over fixed-bandwidth channels. Once this is done, a decoder for the specific media format needs to extract the metadata. Also, depending on the media format, the metadata can be added at the time of encoding the media so that the bit-rate used for the metadata is taken into account. But the metadata can be unknown at that time. Inserting metadata at a later time can cause a decode and re-encode to meet bit-rate requirements.
このメカニズムは、関連するメタデータをメディア形式のビットストリームに埋め込む方法の代替手段を提供します。これは、固定帯域幅チャネルを介して送信されるメディアデータでよく行われます。これが完了すると、特定のメディア形式のデコーダーがメタデータを抽出する必要があります。また、メディアのフォーマットによっては、メディアのエンコード時にメタデータを追加して、メタデータに使用されるビットレートを考慮に入れることができます。ただし、その時点でメタデータは不明な場合があります。後でメタデータを挿入すると、デコードと再エンコードがビットレート要件を満たす可能性があります。
In some cases, a more appropriate and higher-level mechanism may be available, and if so, it can be used. For cases where a higher-level mechanism is not available, it is better to provide a mechanism at the RTP level than to 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 16-bit identifier for the two forms of the RTP extension defined here 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拡張機能の2つの形式の16ビット識別子は、アーキテクチャ定数のみです（たとえば、ネットワークアナライザーで使用するため）。このヘッダー拡張が存在することを決定的に示すのは、ネゴシエーション/定義（SDPなど）です。
The RTP specification [RFC3550] states that RTP "is designed so that the header extension may be ignored by other interoperating implementations that have not been extended." The intent of this restriction is that RTP header extensions MUST NOT be used to extend RTP itself in a manner that is backward incompatible with non-extended implementations. For example, a header extension is not allowed to change the meaning or interpretation of the standard RTP header fields or of the RTP Control Protocol (RTCP). Header extensions MAY carry metadata in addition to the usual RTP header information, provided the RTP layer can function if that metadata is missing. For example, RTP header extensions can be used to carry data that's also sent in RTCP, as an optimization to lower latency, since they'll fall back to the original non-optimized behavior if the header extension is not present. The use of header extensions to convey information that will, if missing, disrupt the behavior of a higher-layer application that builds on top of RTP is only acceptable if this doesn't affect interoperability at the RTP layer. For example, applications that use the SDP BUNDLE extension with the Media Identification (MID) RTP header extension [SDP-BUNDLE] to correlate RTP streams with SDP "m=" lines likely won't work with full functionality if the MID is missing, but the operation of the RTP layer of those applications will be unaffected. Support for RTP header extensions based on this memo is negotiated using, for example, SDP Offer/Answer [RFC3264]; intermediaries aware of the RTP header extensions are advised to be cautious when removing or generating RTP header extensions. See Section 4.7 of [RFC7667].
RTP仕様[RFC3550]は、RTPが「拡張されていない他の相互運用実装によってヘッダー拡張が無視されるように設計されている」と述べています。この制限の目的は、RTPヘッダー拡張を使用して、拡張されていない実装と下位互換性のない方法でRTP自体を拡張してはならないことです。たとえば、ヘッダー拡張では、標準のRTPヘッダーフィールドやRTP制御プロトコル（RTCP）の意味や解釈を変更することはできません。ヘッダー拡張は、メタデータが欠落している場合にRTPレイヤーが機能できる場合、通常のRTPヘッダー情報に加えてメタデータを運ぶことができます（MAY）。たとえば、RTPヘッダー拡張を使用して、RTCPでも送信されるデータを運ぶことができます。これは、ヘッダー拡張が存在しない場合、最適化されていない元の動作にフォールバックするため、待ち時間を短縮する最適化です。欠落した場合にRTPの上に構築される上位層アプリケーションの動作を妨害する情報を伝達するためのヘッダー拡張の使用は、RTP層での相互運用性に影響しない場合にのみ許容されます。たとえば、メディア識別（MID）RTPヘッダー拡張でSDPバンドル拡張を使用するアプリケーション[SDP-BUNDLE]は、RTPストリームをSDP "m ="行と関連付けるため、MIDがない場合、完全な機能で動作しない可能性があります。ただし、これらのアプリケーションのRTPレイヤーの動作には影響しません。このメモに基づくRTPヘッダー拡張のサポートは、たとえばSDP Offer / Answer [RFC3264]を使用してネゴシエートされます。 RTPヘッダー拡張を認識している仲介者は、RTPヘッダー拡張を削除または生成するときに注意することをお勧めします。 [RFC7667]のセクション4.7をご覧ください。
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 can be present in some packets, not that they are in fact present in all (or indeed, any) packets.
優れたネットワークプラクティスと同様に、データは必要な場合にのみ送信する必要があります。ここで定義されているように、RTPヘッダー拡張は、パケットに1つ以上の拡張要素も含まれている場合にのみパケットに存在する必要があります（SHOULD）。拡張要素は、必要な場合にのみパケットに存在する必要があります（SHOULD）。拡張要素のシグナリング設定は、それらの要素が一部のパケットに存在できることのみを示しており、実際にはすべて（または実際にはすべて）のパケットに存在しているわけではありません。
Some general considerations for getting the header extensions delivered to the receiver are as follows:
ヘッダー拡張を受信側に配信するための一般的な考慮事項は次のとおりです。
1. The probability for packet loss and burst loss determines how many repetitions of the header extensions will be required to reach a targeted delivery probability, and if burst loss is likely, what distribution would be needed to avoid losing all repetitions of the header extensions in a single burst.
1. パケット損失とバースト損失の確率により、目標の配信確率に到達するために必要なヘッダー拡張の繰り返し数が決まります。バースト損失が発生する可能性がある場合は、単一のヘッダー拡張のすべての繰り返しが失われないようにするためにどの分布が必要ですか。バースト。
2. If a set of packets are all needed to enable decoding, there is commonly no reason for including the header extension in all of these packets, as they share fate. Instead, at most one instance of the header extension per independently decodable set of media data would be a more efficient use of the bandwidth.
2. デコードを有効にするために一連のパケットがすべて必要な場合、運命を共有するため、これらのすべてのパケットにヘッダー拡張を含める理由は通常ありません。代わりに、独立してデコード可能なメディアデータのセットごとに最大1つのヘッダー拡張のインスタンスを使用すると、帯域幅をより効率的に使用できます。
3. How early the header extension item information is needed, from the first received RTP data or only after some set of packets are received, can guide whether the header extension(s) should be (1) in all of the first N packets or (2) included only once per set of packets -- for example, once per video frame.
3. 最初に受信したRTPデータから、または一部のパケットセットを受信した後でのみ、ヘッダー拡張項目情報がどれだけ早く必要になるかによって、ヘッダー拡張を最初のNパケットすべてに含めるか、または（2 ）パケットのセットごとに1回だけ含まれます-たとえば、ビデオフレームごとに1回。
4. The use of RTP-level robustness mechanisms, such as RTP retransmission [RFC4588] or Forward Error Correction (e.g., [RFC5109]) may treat packets differently from a robustness perspective, and header extensions should be added to packets that get a treatment corresponding to the relative importance of receiving the information.
4. RTP再送信[RFC4588]や転送エラー訂正（[RFC5109]など）などのRTPレベルの堅牢性メカニズムを使用すると、堅牢性の観点からパケットの扱いが異なる可能性があります。情報を受け取ることの相対的な重要性。
As a summary, the number of header extension transmissions should be tailored to a desired probability of delivery, taking the receiver population size into account. For the very basic case, N repetitions of the header extensions should be sufficient but may not be optimal. N is selected so that the header extension target delivery probability reaches 1-P^N, where P is the probability of packet loss. For point-to-point or small receiver populations, it might also be possible to use feedback, such as RTCP, to determine when the information in the header extensions has reached all receivers and stop further repetitions. Feedback that can be used includes the RTCP Extended Report (XR) Loss RLE Report Block [RFC3611], which will indicate successful delivery of particular packets. If the RTP/AVPF transport-layer feedback messages for generic NACK [RFC4585] are used, they can indicate failure to deliver an RTP packet with the header extension, thus indicating the need for further repetitions. The normal RTCP report blocks can also provide an indicator of successful delivery, if no losses are indicated for a reporting interval covering the RTP packets with the header extension. Note that loss of an RTCP packet reporting on an interval where RTP header extension packets were sent does not necessarily mean that the RTP header extension packets themselves were lost.
要約すると、ヘッダー拡張送信の数は、受信者の人口サイズを考慮して、配信の希望確率に合わせて調整する必要があります。非常に基本的なケースでは、ヘッダー拡張のN回の繰り返しで十分ですが、最適ではない場合があります。ヘッダー拡張ターゲット配信確率が1-P ^ NになるようにNが選択されます。ここで、Pはパケット損失の確率です。ポイントツーポイントまたは小さなレシーバーの母集団の場合、RTCPなどのフィードバックを使用して、ヘッダー拡張の情報がすべてのレシーバーに到達したことを確認し、それ以上の繰り返しを停止することもできます。使用できるフィードバックには、RTCP拡張レポート（XR）損失RLEレポートブロック[RFC3611]が含まれます。これは、特定のパケットの正常な配信を示します。ジェネリックNACK [RFC4585]のRTP / AVPFトランスポート層フィードバックメッセージが使用される場合、それらはヘッダー拡張でRTPパケットを配信できないことを示し、それ以上の繰り返しの必要性を示します。ヘッダー拡張付きのRTPパケットをカバーするレポート間隔で損失が示されない場合、通常のRTCPレポートブロックは配信成功のインジケーターを提供することもできます。 RTPヘッダー拡張パケットが送信された間隔で報告されるRTCPパケットの損失は、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 ID value 0 is reserved for padding and MUST NOT be used as a local identifier.
パケットの各拡張要素には、ローカル識別子（ID）と長さがあります。ストリームに存在するローカル識別子は、帯域外でネゴシエートまたは定義されている必要があります。ローカル識別子の静的な割り当てはありません。それぞれの拡張機能には一意のIDが必要です。 ID値0はパディング用に予約されており、ローカル識別子として使用してはなりません。
An extension element with an ID value equal to 0 MUST NOT have an associated length field greater than 0. If such an extension element is encountered, its length field MUST be ignored, processing of the entire extension MUST terminate at that point, and only the extension elements present prior to the element with ID 0 and a length field greater than 0 SHOULD be considered.
ID値が0の拡張要素には、0より大きい長さフィールドが関連付けられていてはいけません。 ID 0および0より大きい長さフィールドを持つ要素の前に存在する拡張要素が考慮されるべきです（SHOULD）。
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 headers or only two-byte headers unless it is known that all recipients support mixing, by either SDP Offer/Answer [RFC3264] negotiation (see Section 6) or out-of-band knowledge. Each RTP packet with an RTP header extension following this specification will indicate whether it contains one-byte or two-byte header extensions through the use of the "defined by profile" field. Extension element types that do not match the header extension format, i.e., one-byte or two-byte, MUST NOT be used in that RTP packet. Transmitters SHOULD NOT use the two-byte header form when all extensions are small enough for the one-byte header form. Transmitters that intend to send the two-byte form SHOULD negotiate the use of IDs above 14 if they want to let the receivers know that they intend to use the two-byte form -- for example, if the RTP header extension is longer than 16 bytes. A transmitter may be aware that an intermediary may add RTP header extensions; in this case, the transmitter SHOULD use the two-byte form.
拡張機能には、1バイトヘッダーと2バイトヘッダーの2つのバリアントがあります。 （a）特定のRTPセッションの拡張の数が少なく、（b）拡張自体が小さいことが予想されるため、1バイトのヘッダー形式が優先され、すべての受信者がサポートする必要があります。すべての受信者がSDP Offer / Answer [RFC3264]ネゴシエーション（セクション6を参照）またはアウトオブバンド知識のいずれかによるミキシングをサポートしていることがわかっている場合を除き、ストリームには1バイトヘッダーまたは2バイトヘッダーのみを含める必要があります。この仕様に従うRTPヘッダー拡張を持つ各RTPパケットは、「プロファイルによって定義」フィールドを使用して、1バイトまたは2バイトのヘッダー拡張が含まれるかどうかを示します。ヘッダー拡張フォーマットに一致しない拡張要素タイプ、つまり1バイトまたは2バイトは、そのRTPパケットで使用してはなりません（MUST NOT）。トランスミッタは、すべての拡張が1バイトのヘッダーフォームに対して十分に小さい場合、2バイトのヘッダーフォームを使用しないでください。 2バイトフォームを送信するつもりのトランスミッターは、RTPヘッダー拡張が16より長い場合など、2バイトフォームを使用するつもりであることをレシーバーに知らせたい場合は、14を超えるIDの使用をネゴシエートする必要があります（SHOULD）。バイト。送信者は、仲介者がRTPヘッダー拡張を追加する場合があることを認識している場合があります。この場合、送信機は2バイト形式を使用する必要があります（SHOULD）。
A sequence of extension elements, possibly with padding, forms the header extension defined in the RTP specification. There are as many extension elements as will fit in the RTP header extension, as indicated by 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 needed), and parsing stops (1) at the end of the entire header extension or (2) in the "one-byte headers only" case, on encountering an identifier with the reserved value of 15 -- whichever happens earlier.
拡張要素のシーケンスは、おそらくパディングを伴って、RTP仕様で定義されたヘッダー拡張を形成します。 RTPヘッダー拡張の長さで示されるように、RTPヘッダー拡張に収まるだけの数の拡張要素があります。この長さは完全な32ビットワードで通知されるため、パディングバイトを使用して32ビット境界にパディングします。拡張全体がバイト単位で解析され、各拡張要素が検索されます（配置は必要ありません）。解析は、（1）ヘッダー拡張全体の最後で停止するか、（2）「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 does it supply 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 that one 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 are 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", MUST have the fixed bit pattern 0xBEDE (the pattern was picked for the trivial reason that the first version of this specification was written on May 25th -- the feast day of the Venerable Bede).
1バイトのヘッダー形式の拡張では、RTP仕様で「プロファイルによって定義されている」というラベルが付けられた、ヘッダー拡張のRTP仕様で必要な16ビット値には、固定ビットパターン0xBEDEが必要です（パターンはこの仕様の最初のバージョンが5月25日に書かれたというささいな理由-由緒あるBedeの祝日）。
Each extension element MUST start 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は、このエレメントのローカルIDで、1から14の範囲です。シグナリングセクションでは、これは有効範囲と呼ばれます。
The local identifier value 15 is reserved for a future extension and MUST NOT be used as an identifier. If the ID value 15 is encountered, its length field MUST be ignored, processing of the entire extension MUST terminate at that point, and only the extension elements present prior to the element with ID 15 SHOULD be considered.
ローカル識別子の値15は将来の拡張のために予約されており、識別子として使用してはならない（MUST NOT）。 ID値15に遭遇した場合、その長さフィールドは無視されなければならず（MUST）、拡張全体の処理はその時点で終了しなければならず（MUST）、ID 15の要素の前に存在する拡張要素のみが考慮されるべきです（SHOULD）。
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 (0) 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.) An example header extension, with three extension elements and some padding, follows:
4ビットの長さは、1バイトのヘッダーに続くこのヘッダー拡張要素のデータバイトから1を引いた数です。したがって、このフィールドの値ゼロ（0）は1バイトのデータが続くことを示し、値15（最大）は16バイトの要素データを示します。 （これにより、ラベルと識別子の一般的な長さである16バイトの値の搬送が可能になりますが、とにかくパディングされる長さゼロの値の可能性が失われます。）3つの拡張要素といくつかのパディングを含むヘッダー拡張の例、次のとおりです。
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 defined 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; this topic is 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 (zeros) by the sender and MUST be ignored by the receiver.
appbitsフィールドはアプリケーションに依存する4ビットであり、任意の値または意味になるように定義できます。このトピックはこの仕様の範囲外です。シグナリングの目的で、このフィールドはローカル識別子256に割り当てられた特別な拡張値として扱われます。このローカル識別子値（256）の構成またはシグナリングを通じて拡張が指定されていない場合、appbitsフィールドはすべて0に設定する必要があります（SHOULD）。 （ゼロ）送信者によって、そして受信者によって無視されなければなりません。
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 appbits field (above). Note that there is one ID space for both the one-byte form and the two-byte form. This means that the lower values (1-14) can be used in the 4-bit ID field in the one-byte header format with the same meanings.
8ビットのIDは、この要素のローカル識別子で、1〜255の範囲です。シグナリングセクションでは、範囲1〜256が有効範囲と呼ばれ、値1〜255は拡張要素を指し、値256は4ビットappbitsフィールド（上記）を指します。 1バイト形式と2バイト形式の両方に1つのIDスペースがあることに注意してください。これは、1バイトのヘッダー形式の4ビットのIDフィールドで同じ意味でより低い値（1〜14）を使用できることを意味します。
The 8-bit length field is the length of extension data in bytes, not including the ID and length fields. The value zero (0) indicates that there is no subsequent data.
8ビットの長さフィールドは、IDと長さフィールドを含まない、バイト単位の拡張データの長さです。値ゼロ（0）は、後続のデータがないことを示します。
An example header extension, with three extension elements and some padding, follows:
3つの拡張要素といくつかのパディングを含むヘッダー拡張の例を以下に示します。
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 an SDP Offer/Answer [RFC3264]. This section defines such signaling in SDP.
この拡張の存在の表示、およびヘッダー拡張で使用されるローカル識別子のより大きな名前空間へのマッピングは、帯域外で実行する必要があります-たとえば、SDP Offer / Answer [RFC3264]の一部として。このセクションでは、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 section (or only once if the mappings are session level). Mappings that do not conform to these rules MAY be presented, for instance, during SDP Offer/Answer [RFC3264] negotiation as described in the next section, but remapping to conformant values is necessary before they can be applied.
使用可能なマッピングは、有効な範囲のIDを使用する必要があり、この範囲の各IDは、各メディアセクションに対して1回のみ（またはマッピングがセッションレベルの場合は1回のみ）使用する必要があります。これらのルールに準拠していないマッピングは、たとえば、次のセクションで説明するSDPオファー/アンサー[RFC3264]ネゴシエーション中に提示される場合がありますが、それらを適用する前に、適合値への再マッピングが必要です。
Each extension is named by a URI. That URI MUST be absolute; it 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の形式で月日も含める必要があります（SHOULD）。要素の定義とURIの割り当ては、その日付またはその日付に非常に近いドメイン名の所有者によって承認されている必要があります。 （これにより、ドメイン名が所有権を変更するときの問題が回避されます。）リソースまたはドキュメントが複数の拡張を定義する場合、URIは、フラグメントまたはクエリ識別子（「＃」または「？」の後の文字など）を使用して、実際の拡張を識別しなければなりません（MUST）。 URIで）。
Rationale: The use of URIs provides for a large, unallocated space and gives documentation on the extension. The URIs do not have to be dereferencable, in order to permit confidential or experimental use, or to cover the case when extensions continue to be used after the organization that defined them ceases to exist.
理論的根拠：URIを使用すると、未割り当ての大きなスペースが提供され、拡張機能に関するドキュメントが提供されます。機密または実験的使用を許可するため、またはURIを定義した組織が存在しなくなった後も拡張機能が引き続き使用される場合をカバーするために、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 can, of course, be used for several streams and can appear with different <extensionattributes> for the same stream.)
同じ属性を持つ拡張URIは、同じストリーム、つまりセッションレベルまたはメディアレベルの単一のストリームの宣言に複数回適用してはなりません。 （もちろん、同じ拡張子を複数のストリームに使用でき、同じストリームに対して異なる<extensionattributes>で表示できます。）
For extensions defined in RFCs, the URI used SHOULD be a URN starting with "urn:ietf:params:rtp-hdrext:" followed by a registered, descriptive name.
RFCで定義された拡張の場合、使用されるURIは、「urn：ietf：params：rtp-hdrext：」で始まり、登録済みの説明的な名前が続くURNである必要があります（SHOULD）。
The registration requirements are detailed in Section 10 ("IANA Considerations").
登録要件については、セクション10（「IANAに関する考慮事項」）で詳しく説明しています。
An example where "avt-example-metadata" is the hypothetical name of a header extension might be:
「avt-example-metadata」がヘッダー拡張の架空の名前である例は次のとおりです。
urn:ietf:params:rtp-hdrext:avt-example-metadata
An example name not from the IETF 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 in each media section of the SDP or unique in the session for session-level SDP declarations.
マッピングは、メディアストリームごとに（SDPのメディアレベルセクションで、つまり "m ="行の後）、またはすべてのストリームに対してグローバルに（つまり、セッションで最初の "m ="行の前に）提供される場合があります。レベル）。定義は、すべてのセッションレベルまたはすべてのメディアレベルでなければなりません。 2つのスタイルを混在させることはできません。さらに、上記のように、使用されるIDは、SDPの各メディアセクションで一意であるか、セッションレベルのSDP宣言のセッションで一意である必要があります。
Each local identifier potentially used in the stream is mapped to an extension identified by a URI using an attribute of the form:
ストリームで使用される可能性のある各ローカル識別子は、次の形式の属性を使用して、URIで識別される拡張にマッピングされます。
a=extmap:<value>["/"<direction>] <URI> <extensionattributes>
where
ただし
o <value> is the local identifier (ID) of this extension and is an integer in the valid range (0 is reserved for padding in both forms, and 15 is reserved in the one-byte header form, as noted above).
o <値>はこの拡張のローカル識別子（ID）であり、有効範囲内の整数です（上記のように、0は両方の形式でパディング用に予約され、15は1バイトヘッダー形式で予約されています）。
o <direction> is one of "sendonly", "recvonly", "sendrecv", or "inactive" (without the quotes) with relation to the device being configured.
o <direction>は、構成するデバイスに関連して、「sendonly」、「recvonly」、「sendrecv」、または「inactive」（引用符なし）のいずれかです。
o <URI> is a URI, as above.
o 上記のように、<URI>はURIです。
The formal BNF syntax is presented in Section 8 of this specification.
正式なBNF構文は、この仕様のセクション8に示されています。
Example:
例：
a=extmap:1 http://example.com/082005/ext.htm#ttime
a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short
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 ("BEDE" or "100") indicated above.
STPシグナリングがRTPセッションに使用される場合、上記のマジックナンバー（「BEDE」または「100」）ではなく、このスタイルのヘッダー拡張が使用されていることを診断するのは「extmap」属性の存在です。 。
6. SDP Signaling for Support of Mixed One-Byte and Two-Byte Header Extensions
6. 1バイトと2バイトの混合ヘッダー拡張をサポートするためのSDPシグナリング
In order to allow for backward interoperability with systems that do not support the mixing of one-byte and two-byte header extensions, this document defines the "a=extmap-allow-mixed" Session Description Protocol (SDP) [RFC4566] attribute to indicate if the participant is capable of supporting this new mode. The attribute takes no value. This attribute can be used at the session level or the media level. A participant that proposes the use of this mode SHALL itself support the reception of mixed one-byte and two-byte header extensions.
1バイトと2バイトのヘッダー拡張の混合をサポートしないシステムとの後方相互運用性を可能にするために、このドキュメントでは、「a = extmap-allow-mixed」セッション記述プロトコル（SDP）[RFC4566]属性を参加者がこの新しいモードをサポートできるかどうかを示します。属性は値を取りません。この属性は、セッションレベルまたはメディアレベルで使用できます。このモードの使用を提案する参加者は、1バイトと2バイトの混合ヘッダー拡張の受信をサポートする必要があります。
If SDP Offer/Answer [RFC3264] is supported and used, the negotiation for mixed one-byte and two-byte extensions MUST be negotiated using SDP Offer/Answer per [RFC3264]. In the absence of negotiations using SDP Offer/Answer -- for example, when declarative SDP is used -- mixed headers MUST NOT occur unless the transmitter has some (out-of-band) knowledge that all potential recipients support this mode.
SDPオファー/アンサー[RFC3264]がサポートおよび使用されている場合、1バイトと2バイトの混合拡張のネゴシエーションは、[RFC3264]のSDPオファー/アンサーを使用してネゴシエートする必要があります。 SDPオファー/アンサーを使用したネゴシエーションがない場合（たとえば、宣言型SDPが使用されている場合）、すべての潜在的な受信者がこのモードをサポートすることを送信者が（帯域外で）認識していない限り、混合ヘッダーは発生してはなりません（MUST NOT）。
The formal definition of this attribute is:
この属性の正式な定義は次のとおりです。
Name: extmap-allow-mixed
名前：extmap-allow-mixed
Value: None
値：なし
Usage Level: session, media
使用レベル：セッション、メディア
Charset Dependent: No
依存する文字セット：いいえ
Example:
例：
a=extmap-allow-mixed
a = extmap-allow-mixed
When doing SDP Offer/Answer [RFC3264], an offering client that wishes to use both one-byte and two-byte extensions MUST include the attribute "a=extmap-allow-mixed" in the SDP offer. If "a=extmap-allow-mixed" is present in the SDP offer, the answerer that supports this mode and wishes to use it SHALL include the "a=extmap-allow-mixed" attribute in the answer. In the cases where the attribute has been excluded, both clients SHALL NOT use mixed one-byte and two-byte extensions in the same RTP stream but MAY use the one-byte or two-byte form exclusively (see Section 4.1.2).
SDPオファー/アンサー[RFC3264]を行う場合、1バイトと2バイトの両方の拡張を使用したいオファリングクライアントは、SDPオファーに属性「a = extmap-allow-mixed」を含める必要があります。 「a = extmap-allow-mixed」がSDPオファーに存在する場合、このモードをサポートし、それを使用したい回答者は、回答に「a = extmap-allow-mixed」属性を含める必要があります。属性が除外されている場合、両方のクライアントは同じRTPストリームで1バイトと2バイトの混合拡張を使用してはならず（SHALL NOT）、1バイトまたは2バイトの形式を排他的に使用できます（セクション4.1.2を参照）。
When used per [SDP-BUNDLE], this attribute is specified as the IDENTICAL category [SDP-MUX].
[SDP-BUNDLE]ごとに使用される場合、この属性はIDENTICALカテゴリ[SDP-MUX]として指定されます。
The simple signaling described above for the "extmap" attribute MAY be enhanced in an SDP Offer/Answer [RFC3264] context, to permit:
上記の「extmap」属性の単純なシグナリングは、SDPオファー/アンサー[RFC3264]コンテキストで拡張されて、以下を許可する場合があります。
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" as specified in [RFC3264].
方向属性は「extmap」に含めることができます。これがない場合、方向はもちろんストリームの方向から暗黙的に継承されるか、セッションレベルの属性または「非アクティブ」ストリームの拡張の場合は「sendrecv」になります。方向は、[RFC3264]で指定されている「sendonly」、「recvonly」、「sendrecv」、または「inactive」のいずれかである必要があります。
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.)
オファーまたはアンサーにセッションレベルのマッピングが含まれている（したがってメディアレベルのマッピングが含まれていない）場合、ストリームごとに異なる動作が必要な場合は、拡張マップ宣言のセット全体をメディアレベルのセクションに移動できます（MAY）。 SDP。 （この仕様では、識別子の管理を容易にするために、グローバル宣言とローカル宣言を混在させることはできません。）
If an extension map is offered as "sendrecv", explicitly or implicitly, and asymmetric behavior is desired, the SDP answer MAY be changed to modify or add direction qualifiers for that extension.
拡張マップが明示的または暗黙的に「sendrecv」として提供され、非対称の動作が必要な場合、SDP回答を変更して、その拡張の方向修飾子を変更または追加できます。
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. An answerer MAY want to respond that he supports the extension and does not want to receive it at the moment, but he may indicate a desire to receive it in a future offer and will mark the extension as "inactive".
拡張機能が「sendonly」としてマークされていて、回答者がそれを受信したい場合は、SDP回答で拡張機能を「recvonly」としてマークする必要があります。エクステンションを受信したくない、またはエクステンションを理解していない応答者は、それをSDP回答から削除する必要があります（SHOULD）。応答者は、拡張機能をサポートしており、現時点では受信したくないと応答することができますが、将来のオファーで受信することを望んでいる可能性があり、拡張機能を「非アクティブ」としてマークします。
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. An answerer MAY want to respond that he supports this extension but has no intention of sending it now; he may indicate a desire to send it in a future offer by marking the extension as "inactive".
拡張機能が「recvonly」としてマークされていて、回答者がそれを送信することを希望している場合、SDP回答で拡張機能を「sendonly」としてマークする必要があります。拡張機能を送信したくない、または拡張機能を送信できない応答者は、拡張機能をSDP応答から削除する必要があります（SHOULD）。回答者は、彼がこの拡張をサポートしているが、今はそれを送信するつもりはないことを返信したいと思うかもしれません。彼は、拡張機能を「非アクティブ」としてマークすることにより、将来のオファーでそれを送信したいという希望を示す場合があります。
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). The local identifiers MUST be unique in an RTP session, and the same identifier MUST be used for the same offered extension in the answer. A session update MAY change the direction qualifiers of extensions being used. A session update MAY add or remove extension(s). Identifier values in the valid range MUST NOT be altered (remapped).
オファーまたはアンサーに含まれる有効範囲内のローカル識別子は、メディアセクション（セッションレベルセクションを含む）ごとに複数回使用しないでください。ローカル識別子はRTPセッション内で一意である必要があり、同じ識別子を回答で提供される同じ拡張子に使用する必要があります。セッションの更新は、使用されている拡張の方向修飾子を変更してもよい（MAY）。セッションの更新により、拡張子を追加または削除する場合があります。有効な範囲の識別子の値を変更（再マップ）してはなりません（MUST NOT）。
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 renumbering is not permitted either).
このルールでは、一方が「sendonly」でもう一方が「recvonly」の場合でも、同じローカル識別子を同じメディアの2つの拡張子に使用することはできません。どちらか一方を「sendrecv」にすることはできないためです。 （再番号付けも許可されていないため）。
If a party wishes to offer mutually exclusive alternatives, then multiple extensions with the same identifier in the extended 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つを選択し、その拡張機能が使用できるように、有効な範囲の空き識別子に再マッピングする必要があります（SHOULD）。
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の範囲の識別子が提供される場合があります。回答者は、必要なものを選択し、それらを有効な範囲の空き識別子に再マッピングする必要があります（SHOULD）。
An answerer may copy an "extmap" for an identifier in the extended range into the answer to indicate to the offerer that it supports that extension. Of course, such an extension cannot be used, since there is no way to specify it in an extension header. If needed, the offerer or answerer can update the session to assign a valid identifier to that extension URI.
回答者は、拡張範囲内の識別子の「extmap」を回答にコピーして、その拡張をサポートしていることを提供者に示すことができます。もちろん、拡張ヘッダーでそれを指定する方法がないため、そのような拡張は使用できません。必要に応じて、提供者または回答者はセッションを更新して、その拡張URIに有効な識別子を割り当てることができます。
Rationale: The range 4096-4351 for these negotiation identifiers is deliberately restricted to allow expansion of the range of valid identifiers in the 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.
どちらのパーティも、ネゴシエートされたもの、または「非アクティブ」としてネゴシエートされたもの（たとえば、中間ノードの利益のため）以外の拡張をストリームに含めることができます（MAY）。送信者が発信したSDPの有効範囲内の識別子で表示された拡張機能のみを送信できます。
Example (port numbers, RTP profiles, payload IDs, 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
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
When using [SDP-BUNDLE] to bundle multiple "m=" lines, the "extmap" attribute falls under the SPECIAL category of [SDP-MUX]. All the "m=" lines in a BUNDLE group are considered to be part of the same local identifier (ID) space. If an RTP header extension, i.e., a particular extension URI and configuration using <extensionattributes>, is offered in multiple "m=" lines that are part of the same BUNDLE group, it MUST use the same ID in all of these "m=" lines. Each "m=" line in a BUNDLE group can include different RTP header extensions allowing, for example, audio and video sources to use different sets of RTP header extensions. A difference in configuration using any of the <extensionattributes> is important. Unless an RTP header extension explicitly states otherwise, any such difference SHALL be communicated to all receivers and SHALL cause assignment of different IDs. An RTP header extension that does not follow this rule MUST explicitly define what would constitute compatible configurations that can be sent with the same ID. The directionality of the RTP header extensions in each "m=" line of the BUNDLE group is handled in the same way as handling for non-bundled "m=" lines. This allows for specifying different directionality for each of the repeated extension URIs in a BUNDLE group.
[SDP-BUNDLE]を使用して複数の "m ="行をバンドルする場合、 "extmap"属性は[SDP-MUX]のSPECIALカテゴリに分類されます。バンドルグループ内のすべての「m =」行は、同じローカル識別子（ID）スペースの一部と見なされます。 RTPヘッダー拡張、つまり、特定の拡張URIと<extensionattributes>を使用した構成が、同じBUNDLEグループの一部である複数の「m =」行で提供される場合、これらすべての「m =」で同じIDを使用する必要があります。 "行。 BUNDLEグループの各「m =」行には、異なるRTPヘッダー拡張を含めることができます。これにより、たとえば、オーディオソースとビデオソースが異なるRTPヘッダー拡張のセットを使用できるようになります。 <extensionattributes>を使用した構成の違いは重要です。 RTPヘッダー拡張が明示的に別の方法で述べていない限り、そのような違いはすべての受信者に伝えられなければならず（SHALL）、異なるIDの割り当てを引き起こします（SHALL）。このルールに従わないRTPヘッダー拡張は、同じIDで送信できる互換性のある構成を構成するものを明示的に定義する必要があります。 BUNDLEグループの各「m =」行のRTPヘッダー拡張の方向性は、バンドルされていない「m =」行の処理と同じ方法で処理されます。これにより、BUNDLEグループ内の繰り返される拡張URIごとに異なる方向性を指定できます。
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 can be several.
以下の構文定義では、[RFC5234]に従ってABNFを使用しています。構文要素「URI」は[RFC3986]で定義されています（ここでは絶対URIのみが許可されています）。構文要素「extmap」は、[RFC4566]で定義されている属性です。つまり、「a =」は「extmap」定義の前にあります。特定の<extensionattributes>は、特定の拡張名を定義する仕様によって定義されます。いくつかあります。
Name: extmap
名前：extmap
Value: extmap-value
値：extmap-value
Syntax:
構文：
extmap-value = mapentry SP extensionname [SP extensionattributes]
extmap-value = mapentry SP拡張名[SP拡張属性]
mapentry = "extmap:" 1*5DIGIT ["/" direction]
extensionname = URI
extensionattributes = byte-string
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"
URI = <Defined in RFC 3986>
byte-string = <Defined in RFC 4566>
SP = <Defined in RFC 5234>
DIGIT = <Defined in RFC 5234>
This document defines only a place to transmit information; the security implications of each of the extensions must be discussed with those extensions.
このドキュメントでは、情報を送信する場所のみを定義しています。各拡張機能のセキュリティへの影響については、それらの拡張機能と話し合う必要があります。
Extension usage is negotiated using [RFC3264], so integrity protection and end-to-end authentication MUST be implemented. The security considerations of [RFC3264] MUST be followed to prevent, for example, extension-usage blocking.
拡張機能の使用は[RFC3264]を使用してネゴシエートされるため、整合性保護とエンドツーエンド認証を実装する必要があります。 [RFC3264]のセキュリティに関する考慮事項は、たとえば拡張機能の使用のブロックを防ぐために守らなければならない（MUST）。
Header extensions have the same security coverage as the RTP header itself. When the Secure Real-time Transport Protocol (SRTP) [RFC3711] is used to protect RTP sessions, the RTP payload can be both encrypted and integrity protected, while the RTP header is either unprotected or integrity protected. In order to prevent DoS attacks (for example, by changing the header extension) integrity protection SHOULD be used. Lower-layer security protection such as Datagram Transport Layer Security (DTLS) [RFC6347] MAY be used. RTP header extensions can carry sensitive information for which participants in multimedia sessions want confidentiality. RFC 6904 [RFC6904] provides a mechanism that extends the mechanisms of SRTP to selectively encrypt RTP header extensions in SRTP.
ヘッダー拡張には、RTPヘッダー自体と同じセキュリティカバレッジがあります。セキュアリアルタイムトランスポートプロトコル（SRTP）[RFC3711]を使用してRTPセッションを保護する場合、RTPペイロードは暗号化され、完全性保護されますが、RTPヘッダーは保護されないか、完全性保護されます。 DoS攻撃を防ぐために（たとえば、ヘッダー拡張を変更することによって）整合性保護を使用する必要があります（SHOULD）。データグラムトランスポート層セキュリティ（DTLS）[RFC6347]などの下位層セキュリティ保護を使用できます。 RTPヘッダー拡張は、マルチメディアセッションの参加者が機密性を必要とする機密情報を運ぶ可能性があります。 RFC 6904 [RFC6904]は、SRTPのメカニズムを拡張して、SRTPのRTPヘッダー拡張を選択的に暗号化するメカニズムを提供します。
The RTP application designer needs to consider their security needs, that includes cipher strength for SRTP packets in general and what that means for the integrity and confidentiality of the RTP header extensions. As defined by RFC 6904 [RFC6904], the encryption stream cipher for the header extension is dependent on the chosen SRTP cipher.
RTPアプリケーション設計者は、一般的なSRTPパケットの暗号強度や、RTPヘッダー拡張の整合性と機密性の意味など、セキュリティのニーズを考慮する必要があります。 RFC 6904 [RFC6904]で定義されているように、ヘッダー拡張の暗号化ストリーム暗号は、選択したSRTP暗号に依存しています。
Other options for securing RTP are discussed in [RFC7201].
RTPを保護するためのその他のオプションについては、[RFC7201]で説明されています。
This document updates the references in three IANA registries to point to this document instead of RFC 5285, and updates and adds new SDP attributes in Sections 10.2 and 10.3, respectively.
このドキュメントは、RFC 5285の代わりにこのドキュメントを指すように3つのIANAレジストリの参照を更新し、セクション10.2および10.3の新しいSDP属性をそれぞれ更新および追加します。
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 [RFC8126].
ネーミングURIフォームから仕様への参照へのマッピングは、IANAによって管理されます。このレジストリへの挿入は、[RFC8126]で定義されている「エキスパートレビュー」の要件に基づいています。
IANA will also maintain a server that contains all of the registered elements in a publicly accessible space.
IANAは、登録されたすべての要素を含むサーバーを、公的にアクセス可能なスペースに維持します。
Here is the formal declaration to comply with the IETF URN sub-namespace specification [RFC3553].
IETF URNサブ名前空間仕様[RFC3553]に準拠するための正式な宣言を以下に示します。
o Registry name: RTP Compact Header Extensions
o レジストリ名：RTP Compact Header Extensions
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 C. A short phrase describing the function of the extension
B.公開されている仕様への正式な参照C.拡張機能の機能を説明する短いフレーズ
D. Contact information for the organization or person making the registration
D.登録を行う組織または個人の連絡先情報
For extensions defined in RFCs, the URI SHOULD be of the form urn:ietf:params:rtp-hdrext:, and the formal reference is the RFC number of the RFC documenting the extension.
RFCで定義された拡張の場合、URIはurn：ietf：params：rtp-hdrext：の形式である必要があり、正式な参照は、拡張を文書化しているRFCのRFC番号です。
o Review process: Expert Review is REQUIRED. The expert reviewer 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 header extensions (specifically, that the header extension can be ignored or discarded without breaking the RTP layer);
2. 拡張がRTPの要件とヘッダー拡張のこの仕様に準拠していること（具体的には、RTPレイヤーを壊さずにヘッダー拡張を無視または破棄できること）。
3. that the extension specification is technically consistent (in itself and with RTP), complete, and comprehensible;
3. 拡張仕様は技術的に一貫しており（それ自体とRTPで）、完全で包括的です。
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;
6. 拡張機能は一般に適用可能（たとえば、ポイントツーマルチポイントセーフ）であり、仕様には制限が存在する場合、それが正しく記述されています。
7. that the suggested naming URI form is appropriately chosen and unique; and
7. 提案されたネーミングURIフォームは適切に選択され、一意であること。そして
8. that for multiplexed "m=" lines [SDP-BUNDLE], any RTP header extension with differences in configurations of <extensionattributes> that do not require assignment of different IDs MUST explicitly indicate this and provide rules for what would constitute compatible configurations that can be sent with the same ID.
8. 多重化された "m ="行[SDP-BUNDLE]の場合、異なるIDの割り当てを必要としない<extensionattributes>の構成が異なるRTPヘッダー拡張は、これを明示的に示し、互換性のある構成を構成するための規則を提供する必要があります。同じIDで送信されます。
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 初期割り当て：なし
IANA has updated the registration of the "extmap" SDP attribute [RFC4566] in the "att-field (both session and media level)" subregistry of the "Session Description Protocol (SDP) Parameters" registry.
IANAは、「Session Description Protocol（SDP）Parameters」レジストリの「att-field（session and media level）」サブレジストリにある「extmap」SDP属性[RFC4566]の登録を更新しました。
o Contact Name and email address: IETF, contacted via <mmusic@ietf.org> (or a successor address designated by the IESG)
o 連絡先の名前とメールアドレス：IETF、<mmusic@ietf.org>経由で連絡（またはIESGが指定した後継アドレス）
o Attribute Name: extmap
o 属性名：extmap
o Attribute Syntax: See Section 8 of RFC 8285.
o 属性構文：RFC 8285のセクション8をご覧ください。
o Attribute Semantics: The details of appropriate values are given in RFC 8285.
o 属性のセマンティクス：適切な値の詳細はRFC 8285に記載されています。
o Usage Level: Media or session level
o 使用レベル：メディアまたはセッションレベル
o Charset Dependent: No
o 依存する文字セット：いいえ
o Purpose: Defines the mapping from the extension numbers used in packet headers into extension names.
o 目的：パケットヘッダーで使用される内線番号から内線名へのマッピングを定義します。
o Offer/Answer (O/A) Procedures: See Section 7 of RFC 8285.
o オファー/アンサー（O / A）手順：RFC 8285のセクション7を参照してください。
o MUX Category: SPECIAL
o MUXカテゴリー：SPECIAL
o Reference: RFC 8285
o リファレンス：RFC 8285
IANA has registered one new SDP attribute in the "att-field (both session and media level)" subregistry of the "Session Description Protocol (SDP) Parameters" registry:
IANAは、「Session Description Protocol（SDP）Parameters」レジストリの「att-field（セッションとメディアレベルの両方）」サブレジストリに1つの新しいSDP属性を登録しました。
o Contact Name and email address: IETF, contacted via <mmusic@ietf.org> (or a successor address designated by the IESG)
o 連絡先の名前とメールアドレス：IETF、<mmusic@ietf.org>経由で連絡（またはIESGが指定した後継アドレス）
o Attribute Name: extmap-allow-mixed
o 属性名：extmap-allow-mixed
o Attribute Syntax: See Section 6 of RFC 8285.
o 属性構文：RFC 8285のセクション6をご覧ください。
o Attribute Semantics: See Section 6 of RFC 8285.
o 属性のセマンティクス：RFC 8285のセクション6をご覧ください。
o Attribute Value: None
o 属性値：なし
o Usage Level: Media or session level o Charset Dependent: No
o使用レベル：メディアまたはセッションレベルo文字セット依存：いいえ
o Purpose: Negotiate the use of one byte and two bytes in the same RTP stream.
o 目的：同じRTPストリームで1バイトと2バイトの使用をネゴシエートします。
o O/A Procedures: See Section 6 of RFC 8285.
o O / A手順：RFC 8285のセクション6を参照してください。
o MUX Category: IDENTICAL
o MUXカテゴリ：IDENTICAL
o Reference: RFC 8285
o リファレンス：RFC 8285
The major motivation for updating [RFC5285] was to allow having one-byte and two-byte RTP header extensions in the same RTP stream (but not in the same RTP packet). The support for this case is negotiated using a new SDP attribute, "extmap-allow-mixed", specified in this document.
[RFC5285]を更新する主な動機は、同じRTPストリーム（同じRTPパケットではない）に1バイトと2バイトのRTPヘッダー拡張を許可することでした。このケースのサポートは、このドキュメントで指定されている新しいSDP属性「extmap-allow-mixed」を使用してネゴシエートされます。
The other major change is to update the requirement from the RTP specifications [RFC3550] and [RFC5285] that the header extension "is designed so that the header extension may be ignored." This is described in Section 4.1.
その他の大きな変更は、RTP仕様[RFC3550]および[RFC5285]から、ヘッダー拡張が「ヘッダー拡張が無視されるように設計されている」という要件を更新することです。これについては、セクション4.1で説明します。
More text was added to Section 4.1.1 ("Transmission Considerations") to clarify when and how many times to send the RTP header extension to provide a higher probability of delivery.
より高い配信確率を提供するためにRTPヘッダー拡張を送信するタイミングと回数を明確にするために、セクション4.1.1（「送信に関する考慮事項」）にテキストが追加されました。
The Security Considerations section was expanded.
「セキュリティに関する考慮事項」セクションが拡張されました。
The rest of the changes are editorial.
残りの変更は編集用です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, DOI 10.17487/RFC2508, February 1999, <https://www.rfc-editor.org/info/rfc2508>.
[RFC2508] Casner、S。およびV. Jacobson、「Compressing IP / UDP / RTP headers for Low-Speed Serial Links」、RFC 2508、DOI 10.17487 / RFC2508、1999年2月、<https：//www.rfc-editor。 org / info / rfc2508>。
[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, DOI 10.17487/RFC3095, July 2001, <https://www.rfc-editor.org/info/rfc3095>.
[RFC3095] Bormann、C.、Burmeister、C.、Degermark、M。、福島、H.、Hannu、H.、Jonsson、LE。、Hakenberg、R.、Koren、T.、Le、K.、Liu、 Z.、Martensson、A。、宮崎、A.、Svanbro、K.、Wiebke、T。、吉村、T。、およびH. Zheng、「RObust Header Compression（ROHC）：Framework and 4 profiles：RTP、UDP、 ESP、および非圧縮」、RFC 3095、DOI 10.17487 / RFC3095、2001年7月、<https://www.rfc-editor.org/info/rfc3095>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https://www.rfc-editor.org / info / rfc3264>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004、<https://www.rfc-editor.org/info/rfc3711>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https://www.rfc-editor.org/ info / rfc4566>。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https：//www.rfc-editor .org / info / rfc5234>。
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, <https://www.rfc-editor.org/info/rfc6904>.
[RFC6904] Lennox、J。、「Secure Real-time Transport Protocol（SRTP）のヘッダー拡張の暗号化」、RFC 6904、DOI 10.17487 / RFC6904、2013年4月、<https://www.rfc-editor.org/ info / rfc6904>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <https://www.rfc-editor.org/info/rfc3550>。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <https://www.rfc-editor.org/info/rfc3553>.
[RFC3553] Mealling、M.、Masinter、L.、Hardie、T。、およびG. Klyne、「An Registered Protocol Parameters for IETF URN Sub-namespace for Registered Protocol Parameters」、BCP 73、RFC 3553、DOI 10.17487 / RFC3553、2003年6月、 <https://www.rfc-editor.org/info/rfc3553>。
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <https://www.rfc-editor.org/info/rfc3611>.
[RFC3611]フリードマン、T。、編、カセレス、R、編、およびA.クラーク、編、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、DOI 10.17487 / RFC3611、2003年11月、 <https://www.rfc-editor.org/info/rfc3611>。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<https://www.rfc-editor.org/info/rfc4585>。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <https://www.rfc-editor.org/info/rfc4588>.
[RFC4588]レイ、J。、レオン、D。、宮崎、A。、ヴァルサ、V。、およびR.ハケンバーグ、「RTP Retransmission Payload Format」、RFC 4588、DOI 10.17487 / RFC4588、2006年7月、<https：/ /www.rfc-editor.org/info/rfc4588>。
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <https://www.rfc-editor.org/info/rfc5109>.
[RFC5109] Li、A。、編、「Generic Forward Error CorrectionのRTPペイロードフォーマット」、RFC 5109、DOI 10.17487 / RFC5109、2007年12月、<https://www.rfc-editor.org/info/rfc5109> 。
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, <https://www.rfc-editor.org/info/rfc5285>.
[RFC5285] Singer、D。およびH. Desineni、「一般的なRTPヘッダー拡張のメカニズム」、RFC 5285、DOI 10.17487 / RFC5285、2008年7月、<https://www.rfc-editor.org/info/rfc5285> 。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <https://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<https://www.rfc-editor.org/info/rfc7201>。
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <https://www.rfc-editor.org/info/rfc7667>.
[RFC7667] Westerlund、M。およびS. Wenger、「RTPトポロジ」、RFC 7667、DOI 10.17487 / RFC7667、2015年11月、<https://www.rfc-editor.org/info/rfc7667>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[SDP-BUNDLE] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Work in Progress, draft-ietf-mmusic-sdp-bundle-negotiation-39, August 2017.
[SDP-BUNDLE] Holmberg、C.、Alvestrand、H。、およびC. Jennings、「Session Description Protocol（SDP）を使用したメディア多重化のネゴシエーション」、進行中の作業、draft-ietf-mmusic-sdp-bundle-negotiation- 2017年8月39日。
[SDP-MUX] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", Work in Progress, draft-ietf-mmusic-sdp-mux-attributes-16, December 2016.
[SDP-MUX] Nandakumar、S。、「多重化時のSDP属性のフレームワーク」、作業中、draft-ietf-mmusic-sdp-mux-attributes-16、2016年12月。
Acknowledgments
謝辞
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.
Brian LinkとJohn Lazzaroの両方が、このドキュメントの最初のドラフトに役立つコメントを提供しました。 Colin Perkinsは、詳細の確認と対処に役立ちました。 IETFで定義された拡張にURNを使用することは、Jonathan Lennoxによって提案され、Pete Cordellはパディングの表現を改善するのに役立ちました。 Dave Oranがレビューにフィードバックとテキストを提供しました。 Mike Dolanが2バイトのヘッダー形式を提供しました。 Magnus WesterlundとTom Taylorは、登録テキストの管理に尽力しました。
Authors' Addresses
著者のアドレス
David Singer Apple, Inc. 1 Infinite Loop Cupertino, CA 95014 United States of America
David Singer Apple、Inc. 1 Infinite Loop Cupertino、CA 95014アメリカ合衆国
Phone: +1 408 996 1010
Email: singer@apple.com
URI: https://support.apple.com/quicktime
Harikishan Desineni Qualcomm 10001 Pacific Heights Blvd. San Diego, CA 92121 United States of America
Harikishan Desineni Qualcomm 10001 Pacific Heights Blvd.サンディエゴ、カリフォルニア州92121アメリカ合衆国
Phone: +1 858 845 8996
Email: h3dnvb@gmail.com
Roni Even (editor) Huawei Technologies Tel Aviv Israel
Roni Even（editor）Huawei Technologies Tel Aviv Israel
Email: Roni.even@huawei.com