[要約] 要約： RFC 7941は、RTP制御プロトコル（RTCP）ソース記述アイテムのためのRTPヘッダ拡張に関する仕様です。この仕様は、RTCPパケット内のソース記述アイテムを拡張するための方法を提供します。目的： このRFCの目的は、RTCPパケット内のソース記述アイテムを拡張するための一貫した方法を提供することです。これにより、RTPベースのアプリケーションでより詳細な情報を送信および受信できるようになります。
Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 7941 B. Burman
Category: Standards Track Ericsson
ISSN: 2070-1721 R. Even
Huawei Technologies
M. Zanaty
Cisco Systems
August 2016
RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items
RTP制御プロトコル（RTCP）ソース記述項目のRTPヘッダー拡張
Abstract
概要
Source Description (SDES) items are normally transported in the RTP Control Protocol (RTCP). In some cases, it can be beneficial to speed up the delivery of these items. The main case is when a new synchronization source (SSRC) joins an RTP session and the receivers need this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items.
ソース記述（SDES）アイテムは通常、RTP制御プロトコル（RTCP）で転送されます。場合によっては、これらのアイテムの配信を高速化することが有益な場合があります。主なケースは、新しい同期ソース（SSRC）がRTPセッションに参加し、受信者がこのソースのID、他のソースとの関係、またはその同期コンテキストを必要とする場合です。これらはすべて、SDESアイテムを使用して完全または部分的に識別できます。この最適化を有効にするために、このドキュメントでは、SDESアイテムを伝送できる新しいRTPヘッダー拡張を指定します。
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 http://www.rfc-editor.org/info/rfc7941.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7941で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. SDES Item Header Extension . . . . . . . . . . . . . . . 5
4.1.1. One-Byte Format . . . . . . . . . . . . . . . . . . . 6
4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 6
4.2. Usage of the SDES Item Header Extension . . . . . . . . . 6
4.2.1. One-Byte or Two-Byte Headers . . . . . . . . . . . . 6
4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 7
4.2.3. Transmission Considerations . . . . . . . . . . . . . 8
4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 9
4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 10
4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10
4.2.7. RTP Header Compression . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Registration of an SDES Base URN . . . . . . . . . . . . 11
5.2. Creation of the "RTP SDES Compact Header Extensions"
Sub-Registry . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Registration of SDES Item . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
This specification defines an RTP header extension [RFC3550][RFC5285] that can carry RTCP Source Description (SDES) items. Normally, the SDES items are carried in their own RTCP packet type [RFC3550]. By including selected SDES items in a header extension, the determination of relationship and synchronization context for new RTP streams (SSRCs) in an RTP session can be optimized. Which relationship and what information depends on the SDES items carried. This becomes a complement to using only RTCP for SDES item delivery.
この仕様は、RTCP Source Description（SDES）アイテムを伝送できるRTPヘッダー拡張[RFC3550] [RFC5285]を定義しています。通常、SDESアイテムは独自のRTCPパケットタイプ[RFC3550]で伝送されます。選択したSDESアイテムをヘッダー拡張に含めることにより、RTPセッションでの新しいRTPストリーム（SSRC）の関係と同期コンテキストの決定を最適化できます。どの関係とどの情報が、運ばれるSDESアイテムに依存します。これは、SDESアイテムの配信にRTCPのみを使用する場合の補足になります。
It is important to note that not all SDES items are appropriate to transmit using RTP header extensions. Some SDES items perform binding or identify synchronization contexts with strict timeliness requirements, while many other SDES items do not have such requirements. In addition, security and privacy concerns for the SDES item information need to be considered. For example, the Name and Location SDES items are highly sensitive from a privacy perspective and should not be transported over the network without strong security. No use case has identified that such information is required when the first RTP packets arrive. A delay of a few seconds before such information is available to the receiver appears acceptable. Therefore, only appropriate SDES items, such as CNAME, will be registered for use with this header extension.
すべてのSDESアイテムがRTPヘッダー拡張を使用して送信することが適切であるとは限らないことに注意することが重要です。一部のSDESアイテムはバインディングを実行するか、厳密な適時性要件で同期コンテキストを識別しますが、他の多くのSDESアイテムにはそのような要件はありません。さらに、SDESアイテム情報のセキュリティとプライバシーの問題を考慮する必要があります。たとえば、名前と場所のSDESアイテムはプライバシーの観点から非常に機密性が高いため、強力なセキュリティなしにネットワーク経由で転送しないでください。最初のRTPパケットが到着したときに、そのような情報が必要であることを示すユースケースはありません。受信者がこのような情報を利用できるようになるまでに数秒の遅延があります。したがって、CNAMEなどの適切なSDESアイテムのみが、このヘッダー拡張で使用するために登録されます。
Requirements language and terminology are defined in Section 2. Section 3 describes why this header extension is sometimes required or at least provides a significant improvement compared to waiting for regular RTCP packet transmissions of the information. Section 4 provides a specification of the header extension and usage recommendations. Section 5 defines a subspace of the header extension URN to be used for existing and future SDES items and registers the appropriate existing SDES items.
要件の言語と用語はセクション2で定義されています。セクション3は、このヘッダー拡張が必要な場合がある理由を説明しています。セクション4では、ヘッダー拡張の仕様と推奨される使用法について説明します。セクション5は、既存および将来のSDESアイテムに使用されるヘッダー拡張URNのサブスペースを定義し、適切な既存のSDESアイテムを登録します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document uses terminology defined in "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources" [RFC7656]. In particular, the following terms are used:
このドキュメントでは、「リアルタイム転送プロトコル（RTP）ソースのセマンティクスとメカニズムの分類」[RFC7656]で定義されている用語を使用しています。特に、次の用語が使用されます。
Media Source
メディアソース
RTP Stream
RTPストリーム
Media Encoder
メディアエンコーダー
Participant
参加者
SDES items are associated with a particular SSRC and thus with a particular RTP stream. The Source Description items provide various metadata associated with the SSRC. How important it is to have this data no later than when the first RTP packets is received depends on the item itself. The CNAME item is one item that is commonly needed either at reception of the first RTP packet for this SSRC or at least by the time the first media can be played out. If it is not available, the synchronization context cannot be determined; thus, any related streams cannot be correctly synchronized. Therefore, this is a valuable example for having this information early when a new RTP stream is received.
SDESアイテムは特定のSSRCに関連付けられているため、特定のRTPストリームに関連付けられています。 Source Descriptionアイテムは、SSRCに関連するさまざまなメタデータを提供します。最初のRTPパケットが受信されるまでにこのデータを取得することがどれほど重要であるかは、アイテム自体によって異なります。 CNAME項目は、このSSRCの最初のRTPパケットの受信時、または少なくとも最初のメディアを再生できるときまでに一般的に必要な項目の1つです。使用できない場合、同期コンテキストを特定できません。したがって、関連するストリームを正しく同期できません。したがって、これは新しいRTPストリームを受信したときにこの情報を早期に取得するための貴重な例です。
The main reason for new SSRCs in an RTP session is when media sources are added. This can be because either an endpoint is adding a new actual media source or additional participants in a multi-party session are added to the session. Another reason for a new SSRC can be an SSRC collision that forces both colliding parties to select new SSRCs.
RTPセッションでの新しいSSRCの主な理由は、メディアソースが追加されたときです。これは、エンドポイントが新しい実際のメディアソースを追加しているか、マルチパーティセッションの追加の参加者がセッションに追加されていることが原因である可能性があります。新しいSSRCのもう1つの理由は、SSRCの衝突であり、衝突する両方のパーティが新しいSSRCを選択する必要があります。
For the case of rapid media synchronization, one may use the RTP header extension for rapid synchronization of RTP flows [RFC6051]. This header extension carries the clock information present in the RTCP sender report (SR) packets. However, it assumes that the CNAME binding is known, which can be provided via signaling [RFC5576] in some cases, but not all. Thus, an RTP header extension for carrying SDES items like CNAME is a powerful combination to enable rapid synchronization in all cases.
高速メディア同期の場合、RTPフローの高速同期にRTPヘッダー拡張を使用できます[RFC6051]。このヘッダー拡張は、RTCP送信者レポート（SR）パケットに存在するクロック情報を伝達します。ただし、CNAMEバインディングが既知であることを前提としています。CNAMEバインディングは、[RFC5576]シグナリングを介して提供できる場合がありますが、すべてではありません。したがって、CNAMEなどのSDESアイテムを伝送するためのRTPヘッダー拡張は、すべてのケースで迅速な同期を可能にする強力な組み合わせです。
The "Rapid Synchronisation of RTP Flows" specification [RFC6051] does provide an analysis of the initial synchronization delay for different sessions depending on the number of receivers as well as on session bandwidth (Section 2.1 of [RFC6051]). These results are also applicable for other SDES items that have a similar time dependency until the information can be sent using RTCP. These figures can be used to determine the benefit of reducing the initial delay before information is available for some use cases.
「RTPフローの高速同期」仕様[RFC6051]は、受信者の数とセッション帯域幅に応じて、さまざまなセッションの初期同期遅延の分析を提供します（[RFC6051]のセクション2.1）。これらの結果は、RTCPを使用して情報を送信できるようになるまで、同様の時間依存性を持つ他のSDESアイテムにも適用できます。これらの数値は、一部のユースケースで情報が利用可能になる前の初期遅延を削減する利点を判断するために使用できます。
[RFC6051] also discusses the case of late joiners and defines an RTCP Feedback format to request synchronization information, which is another potential use case for SDES items in the RTP header extension. It would, for example, be natural to include a CNAME SDES item with the header extension containing the NTP-formatted reference clock to ensure synchronization.
[RFC6051]は、遅延ジョイナーの場合についても説明し、同期情報を要求するためのRTCPフィードバック形式を定義しています。これは、RTPヘッダー拡張のSDESアイテムのもう1つの潜在的な使用例です。たとえば、同期を確実にするために、NTP形式の参照クロックを含むヘッダー拡張子を持つCNAME SDESアイテムを含めるのは自然なことです。
The ongoing work on bundling Session Description Protocol (SDP) media descriptions [SDP-BUNDLE] has identified a new SDES item that can benefit from timely delivery. A corresponding RTP SDES compact header extension is therefore also defined and registered in that document:
セッション記述プロトコル（SDP）メディア記述のバンドルに関する進行中の作業[SDP-BUNDLE]は、タイムリーな配信から利益を得ることができる新しいSDESアイテムを識別しました。したがって、対応するRTP SDESコンパクトヘッダー拡張も定義され、そのドキュメントに登録されます。
MID: This is a media description identifier that matches the value of the SDP [RFC4566] a=mid attribute [RFC5888], to associate RTP streams multiplexed on the same transport with their respective SDP media description.
MID：これは、SDP [RFC4566] a = mid属性[RFC5888]の値と一致するメディア記述識別子であり、同じトランスポートで多重化されたRTPストリームをそれぞれのSDPメディア記述に関連付けます。
This section first specifies the SDES item RTP header extension format, followed by some usage considerations.
このセクションでは、最初にSDESアイテムのRTPヘッダー拡張形式を指定し、次に使用上の考慮事項をいくつか示します。
An RTP header extension scheme allowing for multiple extensions is defined in "A General Mechanism for RTP Header Extensions" [RFC5285]. That specification defines both short and long item headers. The short headers (one byte) are restricted to 1 to 16 bytes of data, while the long format (two bytes) supports a data length of 0 to 255 bytes. Thus, the RTP header extension formats are capable of supporting any SDES item from a data length perspective.
複数の拡張を可能にするRTPヘッダー拡張方式は、「RTPヘッダー拡張の一般的なメカニズム」[RFC5285]で定義されています。その仕様では、短いアイテムヘッダーと長いアイテムヘッダーの両方が定義されています。ショートヘッダー（1バイト）は1〜16バイトのデータに制限されていますが、ロングフォーマット（2バイト）は0〜255バイトのデータ長をサポートしています。したがって、RTPヘッダー拡張形式は、データ長の観点からSDESアイテムをサポートできます。
The ID field, independent of a short or long format, identifies both the type of RTP header extension and, in the case of the SDES item header extension, the type of SDES item. The mapping is done in signaling by identifying the header extension and SDES item type using a URN, which is defined in Section 5 ("IANA Considerations") for the known SDES items appropriate to use.
IDフィールドは、短い形式または長い形式に関係なく、RTPヘッダー拡張のタイプと、SDESアイテムヘッダー拡張の場合はSDESアイテムのタイプの両方を識別します。マッピングは、使用に適した既知のSDESアイテムのセクション5（「IANAに関する考慮事項」）で定義されているURNを使用してヘッダー拡張とSDESアイテムタイプを識別することにより、シグナリングで行われます。
The one-byte header format for an SDES item extension element consists of the one-byte header (defined in Section 4.2 of [RFC5285]), which consists of a 4-bit ID followed by a 4-bit length field (len) that identifies the number of data bytes (len value +1) following the header. The data part consists of len+1 bytes of UTF-8 [RFC3629] text. The type of text and its mapping to the SDES item type are determined by the ID field value.
SDESアイテム拡張要素の1バイトのヘッダー形式は、4バイトのIDとそれに続く4ビットの長さフィールド（len）で構成される1バイトのヘッダー（[RFC5285]のセクション4.2で定義）で構成されますヘッダーに続くデータバイト数（len値+1）を識別します。データ部分は、len + 1バイトのUTF-8 [RFC3629]テキストで構成されます。テキストのタイプとSDESアイテムタイプへのマッピングは、IDフィールド値によって決定されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len | SDES item text value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
図1
The two-byte header format for an SDES item extension element consists of the two-byte header (defined in Section 4.3 of [RFC5285]), which consists of an 8-bit ID followed by an 8-bit length field (len) that identifies the number of data bytes following the header. The data part consists of len bytes of UTF-8 text. The type of text and its mapping to the SDES item type are determined by the ID field value.
SDESアイテム拡張要素の2バイトのヘッダー形式は、2バイトのヘッダー（[RFC5285]のセクション4.3で定義）で構成され、8ビットのIDとそれに続く8ビットの長さフィールド（len）で構成されますヘッダーに続くデータバイト数を識別します。データ部分は、lenバイトのUTF-8テキストで構成されます。テキストのタイプとSDESアイテムタイプへのマッピングは、IDフィールド値によって決定されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len | SDES item text value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
図2
This section discusses various usage considerations: which form of the header extension to use, the packet expansion, and when to send SDES items in the header extension.
このセクションでは、使用するヘッダー拡張の形式、パケット拡張、ヘッダー拡張でSDESアイテムを送信するタイミングなど、さまざまな使用上の考慮事項について説明します。
The RTP header extensions for SDES items MAY use either the one-byte or two-byte header formats, depending on the text value size for the used SDES items and the requirement from any other header extensions used. The one-byte header SHOULD be used when all non-SDES item header extensions support the one-byte format and all SDES item text values contain at most 16 bytes. Note that the RTP header extension specification [RFC5285] does not allow mixing one-byte and two-byte headers for the same RTP stream (SSRC), so if any SDES item requires the two-byte header, then all other header extensions MUST also use the two-byte header format.
SDESアイテムのRTPヘッダー拡張は、使用されるSDESアイテムのテキスト値のサイズと使用される他のヘッダー拡張の要件に応じて、1バイトまたは2バイトのヘッダー形式を使用できます。 1バイトヘッダーは、すべての非SDESアイテムヘッダー拡張が1バイト形式をサポートし、すべてのSDESアイテムテキスト値に最大16バイトが含まれる場合に使用する必要があります（SHOULD）。 RTPヘッダー拡張仕様[RFC5285]では、同じRTPストリーム（SSRC）に1バイトヘッダーと2バイトヘッダーを混在させることはできないため、SDESアイテムが2バイトヘッダーを必要とする場合、他のすべてのヘッダー拡張も必須であることに注意してください。 2バイトのヘッダー形式を使用します。
For example, if using CNAMEs that are generated according to "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" [RFC7022], if using short-term persistent values, and if 96-bit random values prior to base64 encoding are sufficient, then they will fit into the one-byte header format.
たとえば、「RTP制御プロトコル（RTCP）正規名（CNAME）を選択するためのガイドライン」[RFC7022]に従って生成されたCNAMEを使用する場合、短期の永続値を使用する場合、およびbase64エンコーディングの前に96ビットのランダム値を使用する場合十分であれば、1バイトのヘッダー形式に適合します。
An RTP middlebox needs to take care choosing between one-byte headers and two-byte headers when creating the first packets for an outgoing stream (SSRC) with header extensions. First of all, it needs to consider all the header extensions that may potentially be used. Second, it needs to know the size of the SDES items that are going to be included and use two-byte headers if any are longer than 16 bytes. An RTP middlebox that forwards a stream, i.e., not mixing it or combining it with other streams, may be able to base its choice on the header size in incoming streams. This is assuming that the middlebox does not modify the stream or add additional header extensions to the stream it sends, in which case it needs to make its own decision.
RTPミドルボックスは、ヘッダー拡張を使用して発信ストリーム（SSRC）の最初のパケットを作成するときに、1バイトヘッダーと2バイトヘッダーのどちらを選択するかに注意する必要があります。まず、使用される可能性のあるすべてのヘッダー拡張を考慮する必要があります。次に、含まれるSDESアイテムのサイズを把握し、16バイトより長い場合は2バイトのヘッダーを使用する必要があります。ストリームを転送する、つまり他のストリームと混合したり組み合わせたりしないRTPミドルボックスは、着信ストリームのヘッダーサイズに基づいて選択できる場合があります。これは、middleboxがストリームを変更したり、追加のヘッダー拡張を送信ストリームに追加したりしないことを前提としています。この場合、独自の決定を行う必要があります。
The RTP packet size will clearly increase when a header extension is included. How much depends on the type of header extensions and their data content. The SDES items can vary in size. There are also some use cases that require transmitting multiple SDES items in the same packet to ensure that all relevant data reaches the receiver. An example of that is when CNAME, a MID, and the rapid time synchronization extension from RFC 6051 are all needed. Such a combination is quite likely to result in at least 16+3+8 bytes of data plus the headers, which will be another 7 bytes for one-byte headers, plus two bytes of header padding to make the complete header extension 32-bit word aligned, thus 36 bytes in total.
ヘッダー拡張が含まれている場合、RTPパケットサイズは明らかに増加します。ヘッダー拡張のタイプとそのデータコンテンツにどの程度依存します。 SDESアイテムはサイズが異なる場合があります。すべての関連データが受信側に確実に届くように、同じパケットで複数のSDESアイテムを送信する必要があるいくつかの使用例もあります。その例は、CNAME、MID、およびRFC 6051からの高速時刻同期拡張がすべて必要な場合です。このような組み合わせは、少なくとも16 + 3 + 8バイトのデータとヘッダーをもたらす可能性が非常に高く、1バイトのヘッダーの場合はさらに7バイト、完全なヘッダー拡張を32ビットにするための2バイトのヘッダーパディングになります。ワード境界で整列されているため、合計で36バイトです。
If the packet expansion cannot be taken into account when producing the RTP payload, it can cause an issue. An RTP payload that is created to meet a particular IP-level Maximum Transmission Unit (MTU), taking the addition of IP/UDP/RTP headers but not RTP header extensions into account, could exceed the MTU when the header extensions are present, thus resulting in IP fragmentation. IP fragmentation is known to negatively impact the loss rate due to middleboxes unwilling or not capable of dealing with IP fragments, as well as increasing the target surface for other types of packet losses.
RTPペイロードの生成時にパケット拡張を考慮できない場合、問題が発生する可能性があります。特定のIPレベルの最大伝送ユニット（MTU）を満たすために作成されたRTPペイロードは、IP / UDP / RTPヘッダーの追加を考慮し、RTPヘッダー拡張は考慮しないため、ヘッダー拡張が存在する場合にMTUを超える可能性があります。その結果、IPフラグメンテーションが発生します。 IPフラグメント化は、ミドルボックスがIPフラグメントを処理できない、または処理できないため、損失率に悪影響を与えることが知られており、他のタイプのパケット損失のターゲットサーフェスが増加します。
As this is a real issue, the media encoder and payload packetizer should be flexible and be capable of handling dynamically varying payload size restrictions to counter the packet expansion caused by header extensions. If that is not possible, some reasonable worst-case packet expansion should be calculated and used to reduce the RTP payload size of all RTP packets the sender transmits.
これは実際の問題であるため、メディアエンコーダーとペイロードパケタイザは柔軟であり、動的に変化するペイロードサイズの制限を処理して、ヘッダー拡張によるパケット拡張に対抗できる必要があります。それが不可能な場合は、妥当な最悪の場合のパケット拡張を計算して、送信者が送信するすべてのRTPパケットのRTPペイロードサイズを減らすために使用する必要があります。
The general recommendation is to only send header extensions when needed. This is especially true for SDES items that can be sent in periodic repetitions of RTCP throughout the whole session. Thus, the different usages (Section 4.2.4) have different recommendations. The following are some general considerations for getting the header extensions delivered to the receiver:
一般的な推奨事項は、必要な場合にのみヘッダー拡張を送信することです。これは、セッション全体を通してRTCPの定期的な繰り返しで送信できるSDESアイテムに特に当てはまります。したがって、使用方法（セクション4.2.4）ごとに推奨事項は異なります。以下は、ヘッダー拡張を受信側に配信するための一般的な考慮事項です。
1. The probability for packet loss and burst loss determine 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 getting all repetitions of the header extensions lost 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 SDES item information is needed, from the first received RTP data or only after some set of packets are received, can guide if the header extension(s) should be in all of the first N packets or be included only once per set of packets, for example, once per video frame.
3. 最初に受信したRTPデータから、またはいくつかのパケットセットを受信した後でのみ、SDESアイテム情報がどれだけ早く必要であるかによって、ヘッダー拡張を最初のNパケットすべてに含めるか、セットごとに1回だけ含めるかをガイドできます。パケットの、例えば、ビデオフレームごとに1回。
4. The use of RTP-level robustness mechanisms, such as RTP retransmission [RFC4588] or forward error correction [RFC5109], may treat packets differently from a robustness perspective, and SDES 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レベルの堅牢性メカニズムの使用は、堅牢性の観点からパケットを異なる方法で処理する可能性があり、SDESヘッダー拡張は、相対に対応する処理を取得するパケットに追加する必要があります情報を受け取ることの重要性。
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回の繰り返しで十分ですが、最適ではない場合があります。
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 to stop further repetitions. Feedback that can be used includes the RTCP Extended Report (XR) Loss RLE Report Block [RFC3611], which indicates successful delivery of particular packets. If the RTP/AVPF transport-layer feedback message for generic NACK [RFC4585] is used, it can indicate the 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.
ヘッダー拡張ターゲット配信確率が1-P ^ NになるようにNが選択されます。ここで、Pはパケット損失の確率です。ポイントツーポイントまたは小さな受信機の母集団の場合、RTCPなどのフィードバックを使用して、ヘッダー拡張の情報がすべての受信機に到達したことを判断し、それ以上の繰り返しを停止することもできます。使用できるフィードバックには、特定のパケットの正常な配信を示すRTCP拡張レポート（XR）損失RLEレポートブロック[RFC3611]が含まれます。ジェネリックNACK [RFC4585]のRTP / AVPFトランスポート層フィードバックメッセージが使用されている場合、RTPパケットをヘッダー拡張で配信できなかったことを示すことができるため、さらに繰り返す必要があることを示します。ヘッダー拡張付きのRTPパケットをカバーするレポート間隔で損失が示されない場合、通常のRTCPレポートブロックは配信成功のインジケーターを提供することもできます。 RTPヘッダー拡張パケットが送信された間隔で報告されたRTCPパケットの損失は、RTPヘッダー拡張パケット自体が失われたことを必ずしも意味しないことに注意してください。
A new SSRC joins an RTP session. As this SSRC is completely new for everyone, the goal is to ensure, with high probability, that all RTP session participants receive the information in the header extension. Thus, header extension transmission strategies that allow some margins in the delivery probability should be considered.
新しいSSRCがRTPセッションに参加します。このSSRCは誰にとってもまったく新しいものであるため、目標は、すべてのRTPセッション参加者がヘッダー拡張で情報を受信することを高い確率で保証することです。したがって、配信確率にある程度のマージンを許容するヘッダー拡張送信戦略を検討する必要があります。
In a multi-party RTP session where one or a small number of receivers join a session where the majority of receivers already have all necessary information, the use of header extensions to deliver relevant information should be tailored to reach the new receivers. The trigger to send header extensions can, for example, be either RTCP from a new receiver(s) or an explicit request like the Rapid Resynchronization Request defined in [RFC6051]. In centralized topologies where an RTP middlebox is present, it can be responsible for transmitting the known information, possibly stored, to the new session participant only and not repeat it to all the session participants.
1つまたは少数のレシーバーがセッションに参加するマルチパーティRTPセッションでは、大多数のレシーバーがすでに必要な情報をすべて持っている場合、関連情報を配信するためのヘッダー拡張の使用は、新しいレシーバーに到達するように調整する必要があります。ヘッダー拡張を送信するトリガーは、たとえば、新しい受信者からのRTCP、または[RFC6051]で定義されている高速再同期要求のような明示的な要求のいずれかです。 RTPミドルボックスが存在する集中トポロジでは、格納されている可能性のある既知の情報を新しいセッション参加者にのみ送信し、すべてのセッション参加者にそれを繰り返すのではありません。
If the SDES information is tightly coupled with the RTP data, and the SDES information needs to be updated, then the use of the RTP header extension is superior to RTCP. Using the RTP header extension ensures that the information is updated on reception of the related RTP media, ensuring synchronization between the two. Continued use of the old SDES information can lead to undesired effects in the application. Thus, header extension transmission strategies with high probability of delivery should be chosen.
SDES情報がRTPデータと密に結合されており、SDES情報を更新する必要がある場合、RTPヘッダー拡張の使用はRTCPよりも優れています。 RTPヘッダー拡張を使用すると、関連するRTPメディアの受信時に情報が更新され、2つの間の同期が保証されます。古いSDES情報を引き続き使用すると、アプリケーションに望ましくない影響が生じる可能性があります。したがって、配信の確率が高いヘッダー拡張送信戦略を選択する必要があります。
The RTP header extension information, i.e., SDES items, can and will be sent also in RTCP. Therefore, it is worth making some reflections on this interaction. As an alternative to the header extension, it is possible to schedule a non-regular RTCP packet transmission containing important SDES items, if one uses an RTP-/AVPF-based RTP profile. Depending on the mode in which one's RTCP feedback transmitter is working, extra RTCP packets may be sent as immediate or early packets, enabling more timely SDES information delivery.
RTPヘッダー拡張情報、つまりSDESアイテムは、RTCPでも送信できます。したがって、この相互作用について少し考えてみる価値があります。ヘッダー拡張の代わりに、RTP / AVPFベースのRTPプロファイルを使用する場合、重要なSDESアイテムを含む非通常のRTCPパケット送信をスケジュールすることができます。 RTCPフィードバック送信機が動作しているモードに応じて、追加のRTCPパケットが即時パケットまたは早期パケットとして送信され、よりタイムリーなSDES情報配信が可能になります。
There are, however, two aspects that differ between using RTP header extensions and any non-regular transmission of RTCP packets. First, as the RTCP packet is a separate packet, there is no direct relation and also no fate sharing between the relevant media data and the SDES information. The order of arrival for the packets will matter. With a header extension, the SDES items can be ensured to arrive if the media data to play out arrives. Second, it is difficult to determine if an RTCP packet is actually delivered, as the RTCP packets lack both a sequence number and a mechanism providing feedback on the RTCP packets themselves.
ただし、RTPヘッダー拡張の使用とRTCPパケットの通常でない送信の使用には、2つの側面があります。まず、RTCPパケットは別のパケットであるため、直接的な関係はなく、関連するメディアデータとSDES情報の間の運命共有もありません。パケットの到着順序が重要になります。ヘッダー拡張を使用すると、再生するメディアデータが到着した場合にSDESアイテムを確実に到着させることができます。第2に、RTCPパケットにはシーケンス番号とRTCPパケット自体にフィードバックを提供するメカニズムの両方がないため、RTCPパケットが実際に配信されたかどうかを判断することは困難です。
The SDES item may arrive both in RTCP and in RTP header extensions, potentially causing the value to flap back and forth at the time of updating. There are at least two reasons for these flaps. The first one is packet reordering, where a pre-update RTP or RTCP packet with an SDES item is delivered to the receiver after the first RTP/RTCP packet with the updated value. The second reason is the different code paths for RTP and RTCP in implementations. An update to the sender's SDES item parameter can take a different time to propagate to the receiver than the corresponding media data. For example, an RTCP packet with the SDES item included that may have been generated prior to the update can still reside in a buffer and be sent unmodified. The update of the item's value can, at the same time, cause RTP packets to be sent including the header extension, prior to the RTCP packet being sent.
SDESアイテムはRTCPとRTPヘッダー拡張の両方で到着する可能性があり、更新時に値が前後にフラップする可能性があります。これらのフラップには、少なくとも2つの理由があります。 1つ目はパケットの並べ替えで、SDESアイテムを含む更新前のRTPまたはRTCPパケットが、更新された値を含む最初のRTP / RTCPパケットの後に受信者に配信されます。 2番目の理由は、実装におけるRTPとRTCPの異なるコードパスです。送信者のSDESアイテムパラメータを更新すると、対応するメディアデータとは異なる時間が受信者に伝達される場合があります。たとえば、更新前に生成された可能性があるSDESアイテムが含まれたRTCPパケットは、引き続きバッファに常駐し、変更せずに送信できます。アイテムの値の更新と同時に、RTCPパケットが送信される前に、ヘッダー拡張を含むRTPパケットが送信される可能性があります。
However, most of these issues can be avoided by the receiver performing some checks before updating the receiver's stored value. To handle flaps caused by reordering, SDES items received in RTP packets with the same or a lower extended sequence number than the last change MUST NOT be applied, i.e., discard items that can be determined to be older than the current one. For compound RTCP packets, which will contain an SR packet (assuming an active RTP sender), the receiver can use the RTCP SR timestamp field to determine at what approximate time it was transmitted. If the timestamp is earlier than the last received RTP packet with a header extension carrying an SDES item, and especially if carrying a previously used value, the SDES item in the RTCP SDES packet can be ignored. Note that media processing and transmission pacing can easily cause the RTP header timestamp field as well as the RTCP SR timestamp field to not match with the actual transmission time.
ただし、これらの問題のほとんどは、受信機の格納値を更新する前に受信機がいくつかのチェックを実行することで回避できます。並べ替えによるフラップを処理するには、RTPパケットで受信したSDESアイテムが最後の変更と同じか、それよりも小さい拡張シーケンス番号で適用されてはいけません。つまり、現在のアイテムより古いと判断できるアイテムを破棄する必要があります。 SRパケットを含む複合RTCPパケットの場合（アクティブなRTP送信者を想定）、受信者はRTCP SRタイムスタンプフィールドを使用して、送信されたおおよその時間を判断できます。タイムスタンプが、SDESアイテムを運ぶヘッダー拡張を持つ最後に受信したRTPパケットよりも早い場合、特に以前に使用された値を運ぶ場合、RTCP SDESパケットのSDESアイテムは無視できます。メディア処理と送信ペーシングにより、RTPヘッダータイムスタンプフィールドとRTCP SRタイムスタンプフィールドが実際の送信時間と一致しなくなる可能性があることに注意してください。
When Robust Header Compression (ROHC) [RFC5225] is used with RTP, the RTP header extension [RFC5285] data itself is not part of what is being compressed and thus does not impact header compression performance. The extension indicator (X) bit in the RTP header is, however, compressed. It is classified as rarely changing, which may no longer be true for all RTP header extension usage, in turn leading to lower header compression efficiency.
RTPでRobust Header Compression（ROHC）[RFC5225]を使用する場合、RTPヘッダー拡張[RFC5285]データ自体は圧縮対象の一部ではないため、ヘッダー圧縮パフォーマンスに影響を与えません。ただし、RTPヘッダーの拡張インジケータ（X）ビットは圧縮されています。これはほとんど変更されないものとして分類されますが、RTPヘッダー拡張機能のすべての使用法には当てはまらなくなり、ヘッダーの圧縮効率が低下します。
This section details the following updates made by IANA:
このセクションでは、IANAによって行われた以下の更新について詳しく説明します。
o Creation of a new sub-registry reserved for RTCP SDES items with the URN subspace "urn:ietf:params:rtp-hdrext:sdes:" in the "RTP Compact Header Extensions" registry.
o 「RTP Compact Header Extensions」レジストリのURNサブスペース「urn：ietf：params：rtp-hdrext：sdes：」を使用して、RTCP SDESアイテム用に予約された新しいサブレジストリを作成します。
o Registration of the SDES items appropriate for use with the RTP header extension defined in this document.
o このドキュメントで定義されているRTPヘッダー拡張での使用に適したSDESアイテムの登録。
IANA has registered the following entry in the "RTP Compact Header Extensions" registry:
IANAは、「RTP Compact Header Extensions」レジストリに次のエントリを登録しました。
Extension URI: urn:ietf:params:rtp-hdrext:sdes
Description: Reserved as base URN for RTCP SDES items that are also
defined as RTP compact header extensions.
Contact: Authors of RFC 7941
Reference: RFC 7941
The reason to register a base URN for an SDES subspace is that the name represents an RTCP Source Description item, for which a specification is strongly recommended [RFC3550].
SDESサブスペースのベースURNを登録する理由は、名前がRTCP Source Descriptionアイテムを表すためです。そのため、仕様を強くお勧めします[RFC3550]。
IANA has created a sub-registry to the "RTP Compact Header Extensions" registry, with the same basic requirements, structure, and layout as the "RTP Compact Header Extensions" registry.
IANAは、「RTPコンパクトヘッダー拡張」レジストリと同じ基本要件、構造、およびレイアウトで、「RTPコンパクトヘッダー拡張」レジストリへのサブレジストリを作成しました。
o Registry name: RTP SDES Compact Header Extensions
o レジストリ名：RTP SDES Compact Header Extensions
o Specification: RFC 7941
o 仕様：RFC 7941
o Information required: Same as for the "RTP Compact Header Extensions" registry [RFC5285]
o 必要な情報：「RTP Compact Header Extensions」レジストリと同じ[RFC5285]
o Review process: Same as for the "RTP Compact Header Extensions" registry [RFC5285], with the following requirements added to the Expert Review [RFC5226]:
o レビュープロセス：「RTPコンパクトヘッダー拡張」レジストリ[RFC5285]と同じですが、エキスパートレビュー[RFC5226]に次の要件が追加されています。
1. Any registration using an extension URI that starts with "urn:ietf:params:rtp-hdrext:sdes:" (Section 5.1) MUST also have a registered Source Description item in the "RTP SDES item types" registry.
1. 「urn：ietf：params：rtp-hdrext：sdes：」で始まる拡張URIを使用した登録（セクション5.1）には、「RTP SDESアイテムタイプ」レジストリに登録されたソース説明アイテムが必要です。
2. Security and privacy considerations for the SDES item MUST be provided with the registration.
2. SDESアイテムのセキュリティとプライバシーに関する考慮事項は、登録時に提供する必要があります。
3. Information MUST be provided on why this SDES item requires timely delivery, motivating it to be transported in a header extension rather than as RTCP only.
3. このSDESアイテムがタイムリーな配信を必要とする理由に関する情報を提供する必要があり、RTCPのみとしてではなく、ヘッダー拡張で転送されるように動機付けます。
o Size and format of entries: Same as for the "RTP Compact Header Extensions" registry [RFC5285].
o エントリのサイズとフォーマット：「RTP Compact Header Extensions」レジストリ[RFC5285]と同じ。
o Initial assignments: See Section 5.3 of this document.
o 初期割り当て：このドキュメントのセクション5.3を参照してください。
IANA has registered the following SDES item in the newly formed "RTP SDES Compact Header Extensions" registry:
IANAは、新しく形成された「RTP SDES Compact Header Extensions」レジストリに次のSDESアイテムを登録しました。
Extension URI: urn:ietf:params:rtp-hdrext:sdes:cname
Description: Source Description: Canonical End-Point Identifier
(SDES CNAME)
Contact: Authors of RFC 7941
Reference: RFC 7941
Source Description items may contain data that are sensitive from a security perspective. There are SDES items that are or may be sensitive from a user privacy perspective, like CNAME, NAME, EMAIL, PHONE, LOC, and H323-CADDR. Some may contain sensitive information, like NOTE and PRIV, while others may be sensitive from profiling implementations for vulnerability or other reasons, like TOOL. The CNAME sensitivity can vary depending on how it is generated and what persistence it has. A short-term CNAME identifier generated using a random number generator [RFC7022] may have minimal security implications, while a CNAME of the form user@host has privacy concerns, and a CNAME generated from a Media Access Control (MAC) address has long-term tracking potentials.
ソース記述アイテムには、セキュリティの観点から機密性の高いデータが含まれている場合があります。 CNAME、NAME、EMAIL、PHONE、LOC、H323-CADDRなど、ユーザーのプライバシーの観点からデリケートな、またはデリケートなSDESアイテムがあります。 NOTEやPRIVなどの機密情報を含むものもあれば、脆弱性やその他の理由（TOOLなど）のために実装のプロファイリングから機密となるものもあります。 CNAMEの感度は、CNAMEの生成方法と永続性によって異なります。乱数ジェネレーター[RFC7022]を使用して生成された短期のCNAME識別子は、セキュリティへの影響が最小限である可能性がありますが、user @ host形式のCNAMEにはプライバシーの懸念があり、メディアアクセスコントロール（MAC）アドレスから生成されたCNAMEには長い用語追跡の可能性。
In RTP sessions where any type of confidentiality protection is enabled for RTCP, the SDES item header extensions MUST also be protected. This implies that to provide confidentiality, users of the Secure Real-time Transport Protocol (SRTP) need to implement and use encrypted header extensions per [RFC6904]. SDES items carried as RTP header extensions MUST then use commensurate strength algorithms and SHOULD use the same cryptographic primitives (algorithms, modes) as applied to RTCP packets carrying corresponding SDES items. If the security level is chosen to be different for an SDES item in RTCP and an RTP header extension, it is important to justify the exception and to consider the security properties as the worst in each aspect for the different configurations. It is worth noting that the current SRTP [RFC3711] only provides protection for the next trusted RTP/RTCP hop, which is not necessarily end to end.
RTCPに対してあらゆるタイプの機密保護が有効になっているRTPセッションでは、SDESアイテムヘッダー拡張も保護する必要があります。これは、機密性を提供するために、セキュアリアルタイムトランスポートプロトコル（SRTP）のユーザーが[RFC6904]に従って暗号化されたヘッダー拡張を実装して使用する必要があることを意味します。 RTPヘッダー拡張として運ばれるSDESアイテムは、対応する強度アルゴリズムを使用する必要があり、対応するSDESアイテムを運ぶRTCPパケットに適用されるものと同じ暗号プリミティブ（アルゴリズム、モード）を使用する必要があります。 RTCPのSDESアイテムとRTPヘッダー拡張のセキュリティレベルが異なるように選択されている場合、例外を正当化し、さまざまな構成の各側面でセキュリティプロパティを最悪と見なすことが重要です。現在のSRTP [RFC3711]は次の信頼できるRTP / RTCPホップの保護のみを提供することに注意してください。これは必ずしもエンドツーエンドではありません。
The general RTP header extension mechanism [RFC5285] does not itself contain any functionality that is a significant risk for a denial-of-service attack, neither from processing nor from storage requirements. The extension for SDES items defined in this document can potentially be a risk. The risk depends on the received SDES item and its content. If the SDES item causes the receiver to perform a large amount of processing, create significant storage structures, or emit network traffic, such a risk does exist. The CNAME SDES item in the RTP header extension is only a minor risk, as reception of a CNAME item will create an association between the stream carrying the SDES item and other RTP streams with the same SDES item. This usually results in time synchronizing the media streams; thus, some additional processing is performed. However, the application's media quality is likely more affected by an erroneous or changing association and media synchronization than the application quality impact caused by the additional processing.
一般的なRTPヘッダー拡張メカニズム[RFC5285]自体には、処理からもストレージ要件からも、サービス拒否攻撃の重大なリスクとなる機能は含まれていません。このドキュメントで定義されているSDESアイテムの拡張は、潜在的にリスクになる可能性があります。リスクは、受信したSDESアイテムとその内容によって異なります。 SDESアイテムによって受信者が大量の処理を実行したり、重要なストレージ構造を作成したり、ネットワークトラフィックを送信したりする場合は、このようなリスクが存在します。 CNAMEアイテムを受信すると、SDESアイテムを伝送するストリームと、同じSDESアイテムを持つ他のRTPストリームとの間に関連付けが作成されるため、RTPヘッダー拡張のCNAME SDESアイテムはわずかなリスクです。これにより、通常、メディアストリームが同期されます。したがって、いくつかの追加処理が実行されます。ただし、アプリケーションのメディア品質は、追加の処理によるアプリケーション品質の影響よりも、関連付けやメディアの同期の誤りまたは変更による影響が大きいと考えられます。
As the SDES items are used by the RTP-based application to establish relationships between RTP streams or between an RTP stream and information about the originating participant, there SHOULD be strong integrity protection and source authentication of the header extensions. If not, an attacker can modify the SDES item value to create erroneous relationship bindings in the receiving application. For information regarding options for securing RTP, see [RFC7201].
SDESアイテムは、RTPベースのアプリケーションがRTPストリーム間またはRTPストリームと元の参加者に関する情報間の関係を確立するために使用されるため、強力な整合性保護とヘッダー拡張のソース認証が必要です（SHOULD）。そうでない場合、攻撃者はSDESアイテムの値を変更して、受信アプリケーションで誤った関係バインディングを作成できます。 RTPを保護するためのオプションについては、[RFC7201]を参照してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[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, <http://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月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC5285] Singer、D。およびH. Desineni、「一般的なRTPヘッダー拡張メカニズム」、RFC 5285、DOI 10.17487 / RFC5285、2008年7月、<http://www.rfc-editor.org/info/rfc5285> 。
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, <http://www.rfc-editor.org/info/rfc6904>.
[RFC6904] Lennox、J。、「Secure Real-time Transport Protocol（SRTP）のヘッダー拡張の暗号化」、RFC 6904、DOI 10.17487 / RFC6904、2013年4月、<http://www.rfc-editor.org/ info / rfc6904>。
[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, <http://www.rfc-editor.org/info/rfc3611>.
[RFC3611]フリードマン、T。、編、カセレス、R、編、およびA.クラーク、編、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、DOI 10.17487 / RFC3611、2003年11月、 <http://www.rfc-editor.org/info/rfc3611>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。
[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, <http://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、<http://www.rfc-editor.org/info/rfc3711>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://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月、<http://www.rfc-editor.org/ info / rfc4566>。
[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, <http://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月、<http://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, <http://www.rfc-editor.org/info/rfc4588>.
[RFC4588]レイ、J。、レオン、D。、ミヤザキ、A。、ヴァルサ、V。、およびR.ハケンバーグ、「RTP Retransmission Payload Format」、RFC 4588、DOI 10.17487 / RFC4588、2006年7月、<http：/ /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, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5109] Li、A。、編、「Generic Forward Error CorrectionのRTPペイロードフォーマット」、RFC 5109、DOI 10.17487 / RFC5109、2007年12月、<http://www.rfc-editor.org/info/rfc5109> 。
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008, <http://www.rfc-editor.org/info/rfc5225>.
[RFC5225] Pelletier、G。およびK. Sandlund、「RObust Header Compression Version 2（ROHCv2）：Profiles for RTP、UDP、IP、ESP and UDP-Lite」、RFC 5225、DOI 10.17487 / RFC5225、2008年4月、<http ：//www.rfc-editor.org/info/rfc5225>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <http://www.rfc-editor.org/info/rfc5576>.
[RFC5576] Lennox、J.、Ott、J。、およびT. Schierl、「Session Description Protocol（SDP）のソース固有のメディア属性」、RFC 5576、DOI 10.17487 / RFC5576、2009年6月、<http：// www.rfc-editor.org/info/rfc5576>。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, <http://www.rfc-editor.org/info/rfc5888>.
[RFC5888] Camarillo、G。およびH. Schulzrinne、「セッション記述プロトコル（SDP）グループ化フレームワーク」、RFC 5888、DOI 10.17487 / RFC5888、2010年6月、<http://www.rfc-editor.org/info/ rfc5888>。
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, <http://www.rfc-editor.org/info/rfc6051>.
[RFC6051] Perkins、C。およびT. Schierl、「RTPフローの迅速な同期」、RFC 6051、DOI 10.17487 / RFC6051、2010年11月、<http://www.rfc-editor.org/info/rfc6051>。
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[RFC7022] Begen、A.、Perkins、C.、Wing、D。、およびE. Rescorla、「RTP制御プロトコル（RTCP）正規名（CNAME）の選択に関するガイドライン」、RFC 7022、DOI 10.17487 / RFC7022、2013年9月、<http://www.rfc-editor.org/info/rfc7022>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<http://www.rfc-editor.org/info/rfc7201>。
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.
[RFC7656] Lennox、J.、Gross、K.、Nandakumar、S.、Salgueiro、G。、およびB. Burman、編、「リアルタイムの転送プロトコル（RTP）ソースのセマンティクスとメカニズムの分類法」、 RFC 7656、DOI 10.17487 / RFC7656、2015年11月、<http://www.rfc-editor.org/info/rfc7656>。
[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-32, August 2016.
[SDP-BUNDLE] Holmberg、C.、Alvestrand、H。、およびC. Jennings、「Session Description Protocol（SDP）を使用したメディア多重化のネゴシエーション」、進行中の作業、draft-ietf-mmusic-sdp-bundle-negotiation- 2016年8月32日。
Acknowledgments
謝辞
The authors would like to thank the following individuals for feedback and suggestions: Colin Perkins, Ben Campbell, and Samuel Weiler.
著者は、フィードバックと提案を提供してくれたColin Perkins、Ben Campbell、Samuel Weilerに感謝したいと思います。
Authors' Addresses
著者のアドレス
Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Stockholm Sweden
Magnus Westerlund Ericsson Farogatan 6 SE-164 80ストックホルムスウェーデン
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com
Bo Burman Ericsson Gronlandsgatan 31 Stockholm 16480 Sweden
Bo Burman Ericsson Gronlandsgatan 31ストックホルムスウェーデン
Email: bo.burman@ericsson.com
Roni Even Huawei Technologies Tel Aviv Israel
Roni Even Huawei Technologiesテルアビブイスラエル
Email: roni.even@mail01.huawei.com
Mo Zanaty Cisco Systems 7100 Kit Creek RTP, NC 27709 United States of America
Mo Zanaty Cisco Systems 7100キットクリークRTP、NC 27709アメリカ合衆国
Email: mzanaty@cisco.com