[要約] RFC 6285は、マルチキャストRTPセッションの高速な取得を実現するためのユニキャストベースのプロトコルです。このRFCの目的は、ネットワーク上のリソースを最適化し、マルチキャストセッションの効率を向上させることです。
Internet Engineering Task Force (IETF) B. Ver Steeg
Request for Comments: 6285 A. Begen
Category: Standards Track Cisco
ISSN: 2070-1721 T. Van Caenegem
Alcatel-Lucent
Z. Vax
Magnum Semiconductor
June 2011
Unicast-Based Rapid Acquisition of Multicast RTP Sessions
ユニキャストベースのマルチキャストRTPセッションの迅速な獲得
Abstract
概要
When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information, and the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts.
RTPレシーバーがマルチキャストセッションに参加する場合、マルチキャストセッションで送信されるデータを処理する前に、特定の参照情報を取得および解析する必要がある場合があります。結合時間、参照情報の繰り返し（または外観）間隔の長さ、参照情報のサイズ、およびアプリケーションと輸送のプロパティに応じて、RTPレシーバーの前のタイム遅延はマルチキャストデータを有用に消費できます。買収遅延は変化し、大きくなる可能性があります。これは、ビデオ放送など、さまざまなマルチキャストセッションに頻繁に切り替えるレシーバーにとって望ましくない現象です。
In this document, we describe a method using the existing RTP and RTP Control Protocol (RTCP) machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem.
このドキュメントでは、取得遅延を減らす既存のRTPおよびRTP制御プロトコル（RTCP）機械を使用したメソッドについて説明します。この方法では、レシーバーへの参照情報を運ぶ補助ユニキャストRTPセッションは、マルチキャストストリームの前または付随するものです。このユニキャストRTPフローは、自然なビットレートよりも速い速度で送信して、取得をさらに加速できます。この機能の動機付けのユースケースは、リアルタイムの圧縮オーディオとビデオを運ぶマルチキャストアプリケーションです。ただし、この方法は、取得遅延が問題になるのに十分な長さである他のタイプのマルチキャストアプリケーションでも使用できます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション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/rfc6285.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6285で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 6
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Elements of Delay in Multicast Applications . . . . . . . . . 8
5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Acquisition . . . . . . . . . . 10
6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Synchronization of Primary Multicast Streams . . . . . . . 24
6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 25
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 31
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 34
7.3.1. Response Code Definitions . . . . . . . . . . . . . . 37
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 39
8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 40
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 41
8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 41
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 44
10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 48
11.2. Registration of SDP Attribute Values . . . . . . . . . . . 48
11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 48
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 48
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 49
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 50
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1. Normative References . . . . . . . . . . . . . . . . . . . 52
14.2. Informative References . . . . . . . . . . . . . . . . . . 54
Most multicast flows carry a stream of inter-related data. Receivers need to acquire certain information to start processing any data sent in the multicast session. This document refers to this information as Reference Information. The Reference Information is conventionally sent periodically in the multicast session (although its content can change over time) and usually consists of items such as a description of the schema for the rest of the data, references to which data to process, encryption information including keys, and any other information required to process the data in the multicast stream [IC2009].
ほとんどのマルチキャストフローには、相互に関連するデータのストリームがあります。受信者は、マルチキャストセッションで送信されたデータの処理を開始するために特定の情報を取得する必要があります。このドキュメントは、この情報を参照情報として参照しています。参照情報は、マルチキャストセッションで定期的に定期的に送信されます（そのコンテンツは時間とともに変更される可能性がありますが）。通常、残りのデータのスキーマの説明、処理するデータ、キーを含む暗号化情報などのアイテムで構成されています。、およびマルチキャストストリーム[IC2009]でデータを処理するために必要なその他の情報。
Real-time multicast applications require receivers to buffer data. Receivers may have to buffer data to smooth out the network jitter, to allow loss-repair methods such as Forward Error Correction and retransmission to recover the missing packets, and to satisfy the data-processing requirements of the application layer.
リアルタイムのマルチキャストアプリケーションでは、データをバッファするために受信機が必要です。受信機は、ネットワークジッターをスムーズにするためにデータをバッファリングする必要がある場合があり、順方向エラー修正や行方不明のパケットを回復するための再送信などの損失修正メソッドを許可し、アプリケーションレイヤーのデータ処理要件を満たす必要があります。
When a receiver joins a multicast session, it has no control over what point in the flow is currently being transmitted. Sometimes the receiver might join the session right before the Reference Information is sent in the session. In this case, the required waiting time is usually minimal. Other times, the receiver might join the session right after the Reference Information has been transmitted. In this case, the receiver has to wait for the Reference Information to appear again in the flow before it can start processing any multicast data. In some other cases, the Reference Information is not contiguous in the flow but dispersed over a large period, which forces the receiver to wait for the whole Reference Information to arrive before starting to process the rest of the data.
レシーバーがマルチキャストセッションに参加すると、フローのどのポイントが現在送信されているかを制御できません。レシーバーは、セッションで参照情報が送信される直前にセッションに参加する場合があります。この場合、必要な待機時間は通常最小限です。また、参照情報が送信された直後に、受信者がセッションに参加する場合があります。この場合、レシーバーは、マルチキャストデータの処理を開始する前に、参照情報がフローに再び表示されるのを待つ必要があります。他の場合には、参照情報はフローでは隣接していませんが、大きな期間にわたって分散しているため、受信者は残りのデータを処理し始める前に参照情報全体が到着するのを強制します。
The net effect of waiting for the Reference Information and waiting for various buffers to fill up is that receivers can experience significantly large delays in data processing. In this document, we refer to the difference between the time an RTP receiver wants to join the multicast session and the time the RTP receiver acquires all the necessary Reference Information as the Acquisition Delay. The acquisition delay might not be the same for different receivers; it usually varies depending on the join time, length of the Reference Information repetition (or appearance) interval, and size of the Reference Information, as well as the application and transport properties.
参照情報を待って、さまざまなバッファーがいっぱいになるのを待つことの正味の効果は、受信機がデータ処理に大幅に大きな遅延を経験できることです。このドキュメントでは、RTPレシーバーがマルチキャストセッションに参加したい時間と、RTPレシーバーが取得遅延として必要なすべての参照情報を取得する時間と、違いを参照してください。取得遅延は、異なるレシーバーで同じではない場合があります。通常、結合時間、参照情報の繰り返し（または外観）間隔の長さ、および参照情報のサイズ、およびアプリケーションと輸送のプロパティによって異なります。
The varying nature of the acquisition delay adversely affects the receivers that frequently switch among multicast sessions. While this problem equally applies to both any-source multicast (ASM) and source-specific multicast (SSM) applications, in this specification we address it for the SSM-based applications by describing a method that uses the fundamental tools offered by the existing RTP and RTCP protocols [RFC3550]. In this method, either the multicast source (or the distribution source in an SSM session) retains the Reference Information for a period after its transmission, or an intermediary network element (that we refer to as Retransmission Server) joins the multicast session and continuously caches the Reference Information as it is sent in the session and acts as a feedback target (see [RFC5760]) for the session. When an RTP receiver wishes to join the same multicast session, instead of simply issuing a Source Filtering Group Management Protocol (SFGMP) Join message, it sends a request to the feedback target for the session and asks for the Reference Information. The retransmission server starts a new unicast RTP (retransmission) session and sends the Reference Information to the RTP receiver over that session. If there is residual bandwidth, the retransmission server might burst the Reference Information faster than its natural rate. As soon as the receiver acquires the Reference Information, it can join the multicast session and start processing the multicast data. A simplified network diagram showing this method through an intermediary network element is depicted in Figure 1.
取得遅延のさまざまな性質は、マルチキャストセッションの間に頻繁に切り替わるレシーバーに悪影響を及ぼします。この問題は、あらゆるソースマルチキャスト（ASM）とソース固有のマルチキャスト（SSM）アプリケーションの両方に等しく適用されますが、この仕様では、既存のRTPが提供する基本ツールを使用する方法を記述することにより、SSMベースのアプリケーションに対処します。およびRTCPプロトコル[RFC3550]。この方法では、マルチキャストソース（またはSSMセッションの分布ソース）が送信後の期間の参照情報を保持するか、中間ネットワーク要素（再送信サーバーと呼ばれる）がマルチキャストセッションと継続的なキャッシュに結合します。セッションで送信された参照情報は、セッションのフィードバックターゲット（[RFC5760]を参照）として機能します。RTPレシーバーが同じマルチキャストセッションに参加したい場合、ソースフィルタリンググループ管理プロトコル（SFGMP）の参加メッセージを単に発行する代わりに、メッセージのフィードバックターゲットにリクエストを送信し、参照情報を要求します。再送信サーバーは、新しいユニキャストRTP（再送信）セッションを開始し、そのセッションでRTPレシーバーに参照情報を送信します。残留帯域幅がある場合、再送信サーバーは、その自然なレートよりも早く参照情報を破裂させる可能性があります。受信者が参照情報を取得するとすぐに、マルチキャストセッションに参加してマルチキャストデータの処理を開始できます。中間ネットワーク要素を介したこの方法を示す単純化されたネットワーク図を図1に示します。
This method potentially reduces the acquisition delay. We refer to this method as Unicast-Based Rapid Acquisition of Multicast RTP Sessions. A primary use case for this method is to reduce the channel-change times in IPTV networks where compressed video streams are multicast in different SSM sessions and viewers randomly join these sessions.
この方法により、獲得遅延が潜在的に減少します。この方法は、ユニキャストベースのマルチキャストRTPセッションの迅速な獲得と呼びます。この方法の主要なユースケースは、IPTVネットワークのチャネル変更時間を短縮することです。このネットワークでは、圧縮されたビデオストリームがさまざまなSSMセッションでマルチキャストであり、視聴者がこれらのセッションにランダムに参加します。
-----------------------
+--->| Intermediary |
| | Network Element |
| ...|(Retransmission Server)|
| : -----------------------
| :
| v
----------- ---------- ----------
| Multicast | | |---------->| Joining |
| Source |------->| Router |..........>| RTP |
| | | | | Receiver |
----------- ---------- ----------
|
| ----------
+---------------->| Existing |
| RTP |
| Receiver |
----------
-------> Multicast RTP Flow
.......> Unicast RTP Flow
Figure 1: Rapid Acquisition through an Intermediary Network Element
図1：中間ネットワーク要素を介した迅速な獲得
A principle design goal in this solution is to use the existing tools in the RTP/RTCP protocol family. This improves the versatility of the existing implementations and promotes faster deployment and better interoperability. To this effect, we use the unicast retransmission support of RTP [RFC4588] and the capabilities of RTCP to handle the signaling needed to accomplish the acquisition.
このソリューションの主要な設計目標は、RTP/RTCPプロトコルファミリーの既存のツールを使用することです。これにより、既存の実装の汎用性が向上し、展開が速くなり、相互運用性が向上します。この効果のために、RTP [RFC4588]のユニキャスト再送信サポートとRTCPの機能を使用して、取得を達成するために必要な信号を処理します。
A reasonable effort has been made in this specification to design a solution that reliably works in both engineered and best-effort networks. However, a proper congestion control combined with the desired behavior of this solution is difficult to achieve. Rather, this solution has been designed based on the assumption that the retransmission server and the RTP receivers have some knowledge about where the bottleneck between them is. This assumption does not generally hold unless both the retransmission server and the RTP receivers are in the same edge network. Thus, this solution should not be used across any best-effort path of the Internet. Furthermore, this solution should only be used in networks that are already carrying non-congestion-responsive multicast traffic and have throttling mechanisms in the retransmission servers to ensure the (unicast) burst traffic is a known constant upper-bound multiplier on the multicast load.
この仕様において、エンジニアリングネットワークとベストエフォルトネットワークの両方で確実に機能するソリューションを設計するために、合理的な努力が払われています。ただし、このソリューションの望ましい動作と組み合わされた適切な混雑制御を達成することは困難です。むしろ、このソリューションは、再送信サーバーとRTPレシーバーがボトルネックがどこにあるかについてある程度の知識を持っているという仮定に基づいて設計されています。この仮定は、再送信サーバーとRTPレシーバーの両方が同じEDGEネットワークにある場合を除き、通常は保持されません。したがって、このソリューションは、インターネットの最良のパスで使用しないでください。さらに、このソリューションは、非合成応答性の多リキャストトラフィックをすでに搭載しているネットワークでのみ使用する必要があり、再送信サーバーにスロットリングメカニズムがあり、（ユニキャスト）バーストトラフィックがマルチキャスト負荷の既知の一定の上限乗数であることを確認します。
In this memo, we describe a protocol that handles the rapid acquisition of a single multicast RTP session (called a primary multicast RTP session) carrying one or more RTP streams (called primary multicast streams). If desired, multiple instances of this protocol may be run in parallel to acquire multiple RTP sessions simultaneously.
このメモでは、1つ以上のRTPストリーム（プライマリマルチキャストストリームと呼ばれる）を運ぶ単一のマルチキャストRTPセッション（プライマリマルチキャストRTPセッションと呼ばれる）の迅速な取得を処理するプロトコルについて説明します。必要に応じて、このプロトコルの複数のインスタンスを並行して実行して、複数のRTPセッションを同時に取得できます。
When an RTP receiver requests the Reference Information from the retransmission server, it can opt to rapidly acquire a specific subset of the available RTP streams in the primary multicast RTP session. Alternatively, the RTP receiver can request the rapid acquisition of all of the RTP streams in that RTP session. Regardless of how many RTP streams are requested by the RTP receiver or how many will be actually sent by the retransmission server, only one unicast RTP session will be established by the retransmission server. This unicast RTP session is separate from the associated primary multicast RTP session. As a result, there are always two different RTP sessions in a single instance of the rapid acquisition protocol: (i) the primary multicast RTP session with its associated unicast feedback and (ii) the unicast RTP session.
RTPレシーバーが再送信サーバーから参照情報を要求すると、プライマリマルチキャストRTPセッションで利用可能なRTPストリームの特定のサブセットを迅速に取得することを選択できます。または、RTPレシーバーは、そのRTPセッションですべてのRTPストリームの迅速な取得を要求できます。RTPレシーバーによってRTPストリームが要求されるか、再送信サーバーによって実際に送信される数のRTPストリームの数に関係なく、再送信サーバーによって1つのユニキャストRTPセッションのみが確立されます。このユニキャストRTPセッションは、関連するプライマリマルチキャストRTPセッションとは別です。その結果、迅速な取得プロトコルの単一のインスタンスには、常に2つの異なるRTPセッションがあります。（i）関連するユニキャストフィードバックを備えたプライマリマルチキャストRTPセッションと（ii）ユニキャストRTPセッション。
If the RTP receiver wants to rapidly acquire multiple RTP sessions simultaneously, separate unicast RTP sessions will be established for each of them.
RTPレシーバーが複数のRTPセッションを同時に迅速に取得したい場合、それぞれに個別のユニキャストRTPセッションが確立されます。
The rest of this specification is as follows. Section 3 provides a list of the definitions frequently used in this document. In Section 4, we describe the delay components in generic multicast applications. Section 5 presents an overview of the protocol design considerations for rapid acquisition. We provide the protocol details of the rapid acquisition method in Sections 6 and 7. Sections 8 and 9 discuss the Session Description Protocol (SDP) signaling issues with examples and NAT-related issues, respectively. Finally, Section 10 discusses the security considerations, and Section 11 details the IANA considerations.
この仕様の残りは次のとおりです。セクション3では、このドキュメントで頻繁に使用される定義のリストを示します。セクション4では、ジェネリックマルチキャストアプリケーションの遅延コンポーネントについて説明します。セクション5では、迅速な獲得のためのプロトコル設計上の考慮事項の概要を示します。セクション6および7の迅速な取得方法のプロトコルの詳細を提供します。セクション8および9では、セッション説明プロトコル（SDP）のシグナル伝達の問題とNAT関連の問題についてそれぞれ説明します。最後に、セクション10でセキュリティ上の考慮事項について説明し、セクション11でIANAの考慮事項について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This document uses the following acronyms and definitions frequently:
このドキュメントでは、次の頭字語と定義を頻繁に使用します。
(Primary) SSM Session: The multicast session to which RTP receivers can join at a random point in time. A primary SSM session can carry multiple RTP streams.
（プライマリ）SSMセッション：RTPレシーバーがランダムな時点で参加できるマルチキャストセッション。プライマリSSMセッションでは、複数のRTPストリームを運ぶことができます。
Primary Multicast RTP Session: The multicast RTP session an RTP receiver is interested in acquiring rapidly. From the RTP receiver's viewpoint, the primary multicast RTP session has one associated unicast RTCP feedback stream to a Feedback Target, in addition to the primary multicast RTP stream(s).
プライマリマルチキャストRTPセッション：マルチキャストRTPセッションRTPレシーバーは、迅速に取得することに関心があります。RTPレシーバーの視点から、プライマリマルチキャストRTPセッションには、プライマリマルチキャストRTPストリームに加えて、1つの関連するユニキャストRTCPフィードバックストリームがフィードバックターゲットにあります。
Primary Multicast (RTP) Streams: The RTP stream(s) carried in the primary multicast RTP session.
プライマリマルチキャスト（RTP）ストリーム：プライマリマルチキャストRTPセッションで運ばれるRTPストリーム。
Source Filtering Group Management Protocol (SFGMP): Following the definition in [RFC4604], SFGMP refers to the Internet Group Management Protocol (IGMP) version 3 [RFC3376] and the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and IPv6 networks, respectively. However, the rapid acquisition method introduced in this document does not depend on a specific version of either of these group management protocols. In the remainder of this document, SFGMP will refer to any group management protocol that has Join and Leave functionalities.
ソースフィルタリンググループ管理プロトコル（SFGMP）：[RFC4604]の定義に従って、SFGMPはインターネットグループ管理プロトコル（IGMP）バージョン3 [RFC3376]とマルチキャストリスナーディスカバリープロトコル（MLD）バージョンバージョン2 [RFC3810]を指します。それぞれIPv6ネットワーク。ただし、このドキュメントで導入された迅速な獲得方法は、これらのグループ管理プロトコルのいずれのいずれでもある特定のバージョンに依存しません。このドキュメントの残りの部分では、SFGMPは、機能を結合して離れるグループ管理プロトコルを参照します。
Feedback Target (FT): Unicast RTCP feedback target as defined in [RFC5760]. FT_Ap denotes a specific feedback target running on a particular address and port.
フィードバックターゲット（FT）：[RFC5760]で定義されているユニキャストRTCPフィードバックターゲット。FT_APは、特定のアドレスとポートで実行されている特定のフィードバックターゲットを示します。
Retransmission (or Burst) Packet: An RTP packet that is formatted as defined in Section 4 of [RFC4588]. The payload of a retransmission or burst packet comprises the retransmission payload header followed by the payload of the original RTP packet.
再送信（またはバースト）パケット：[RFC4588]のセクション4で定義されているようにフォーマットされたRTPパケット。再送信またはバーストパケットのペイロードは、再送信ペイロードヘッダーに続いて元のRTPパケットのペイロードを含みます。
Reference Information: The set of certain media content and metadata information that is sufficient for an RTP receiver to start usefully consuming a media stream. The meaning, format, and size of this information are specific to the application and are out of the scope of this document.
参照情報：RTPレシーバーがメディアストリームを有用に消費し始めるのに十分な特定のメディアコンテンツとメタデータ情報のセット。この情報の意味、形式、およびサイズはアプリケーションに固有であり、このドキュメントの範囲外です。
Preamble Information: A more compact form of the whole or a subset of the Reference Information transmitted out-of-band.
プリアンブル情報：帯域外で送信される参照情報の全体のよりコンパクトな形式。
(Unicast) Burst (or Retransmission) RTP Session: The unicast RTP session used to send one or more unicast burst RTP streams and their associated RTCP messages. The terms "burst RTP session" and "retransmission RTP session" can be used interchangeably.
（ユニキャスト）バースト（または再送信）RTPセッション：1つ以上のユニキャストバーストRTPストリームとそれに関連するRTCPメッセージを送信するために使用されるユニキャストRTPセッション。「バーストRTPセッション」と「再送信RTPセッション」という用語は、同じ意味で使用できます。
(Unicast) Burst (Stream): A unicast stream of RTP retransmission packets that enable an RTP receiver to rapidly acquire the Reference Information associated with a primary multicast stream. Each burst stream is identified by its Synchronization Source (SSRC) identifier that is unique in the primary multicast RTP session. Following the session-multiplexing guidelines in [RFC4588], each unicast burst stream will use the same SSRC and Canonical Name (CNAME) as its primary multicast RTP stream.
（Unicast）バースト（ストリーム）：RTPレシーバーがプライマリマルチキャストストリームに関連付けられた参照情報を迅速に取得できるようにするRTP再送信パケットのユニキャストストリーム。各バーストストリームは、プライマリマルチキャストRTPセッションで一意の同期ソース（SSRC）識別子によって識別されます。[RFC4588]のセッションマルチプレックスガイドラインに続いて、各ユニキャストバーストストリームは、主要なマルチキャストRTPストリームと同じSSRCとCanonical Name（CNAME）を使用します。
Retransmission Server (RS): The RTP/RTCP endpoint that can generate the retransmission packets and the burst streams. The RS may also generate other non-retransmission packets to aid rapid acquisition.
再送信サーバー（RS）：再送信パケットとバーストストリームを生成できるRTP/RTCPエンドポイント。RSは、迅速な買収を支援するために、他の非再送信パケットを生成する場合もあります。
In a source-specific multicast (SSM) delivery system, there are three major elements that contribute to the acquisition delay when an RTP receiver switches from one multicast session to another one. These are:
ソース固有のマルチキャスト（SSM）配信システムでは、RTPレシーバーが1つのマルチキャストセッションから別のセッションに切り替えると、取得遅延に寄与する3つの主要な要素があります。これらは：
o Multicast-switching delay
o マルチキャストスイッチング遅延
o Reference Information latency
o 参照情報の遅延
o Buffering delays
o バッファリング遅延
Multicast-switching delay is the delay that is experienced when leaving the current multicast session (if any) and joining the new multicast session. In typical systems, the multicast join and leave operations are handled by a group management protocol. For example, the receivers and routers participating in a multicast session can use the Internet Group Management Protocol (IGMP) version 3 [RFC3376] or the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810]. In either of these protocols, when a receiver wants to join a multicast session, it sends a message to its upstream router and the routing infrastructure sets up the multicast forwarding state to deliver the packets of the multicast session to the new receiver. The join times vary depending on the proximity of the upstream router, the current state of the multicast tree, the load on the system, and the protocol implementation. Current systems provide join latencies, usually less than 200 milliseconds (ms). If the receiver had been participating in another multicast session before joining the new session, it needs to send a Leave message to its upstream router to leave the session. In common multicast routing protocols, the leave times are usually smaller than the join times; however, it is possible that the Leave and Join messages might get lost, in which case the multicast-switching delay inevitably increases.
マルチキャストスイッチング遅延は、現在のマルチキャストセッションを離れて（ある場合）、新しいマルチキャストセッションに参加したときに経験される遅延です。典型的なシステムでは、マルチキャスト結合および休暇操作は、グループ管理プロトコルによって処理されます。たとえば、マルチキャストセッションに参加するレシーバーとルーターは、インターネットグループ管理プロトコル（IGMP）バージョン3 [RFC3376]またはマルチキャストリスナーディスカバリープロトコル（MLD）バージョン2 [RFC3810]を使用できます。これらのプロトコルのいずれかで、受信者がマルチキャストセッションに参加したい場合、上流のルーターにメッセージを送信し、ルーティングインフラストラクチャがマルチキャスト転送状態を設定して、マルチキャストセッションのパケットを新しいレシーバーに配信します。結合時間は、上流のルーターの近接性、マルチキャストツリーの現在の状態、システムの負荷、およびプロトコルの実装によって異なります。現在のシステムは、通常200ミリ秒未満（MS）未満の結合レテンシーを提供します。レシーバーが新しいセッションに参加する前に別のマルチキャストセッションに参加していた場合、セッションを離れるためにアップストリームルーターに残しメッセージを送信する必要があります。一般的なマルチキャストルーティングプロトコルでは、休暇時間は通常、結合時間よりも小さくなります。ただし、休暇と結合メッセージが失われる可能性があります。その場合、マルチキャストスイッチング遅延が必然的に増加する可能性があります。
Reference Information latency is the time it takes the receiver to acquire the Reference Information. It is highly dependent on the proximity of the actual time the receiver joined the session to the next time the Reference Information will be sent to the receivers in the session, whether or not the Reference Information is sent contiguously, and the size of the Reference Information. For some multicast flows, there is a little or no interdependency in the data, in which case the Reference Information latency will be nil or negligible. For other multicast flows, there is a high degree of interdependency. One example of interest is the multicast flows that carry compressed audio/video. For these flows, the Reference Information latency can become quite large and be a major contributor to the overall delay.
参照情報の遅延とは、レシーバーが参照情報を取得するのにかかる時間です。これは、レシーバーがセッションに参加する実際の時間の近接性に大きく依存しています。参照情報が連続して送信されるかどうか、および参照情報のサイズを参照するかどうかにかかわらず、参照情報がセッションの受信機に送信されます。。一部のマルチキャストフローの場合、データには少しまたはまったく依存性がありません。その場合、参照情報の遅延はゼロまたは無視できます。他のマルチキャストフローの場合、高度な相互依存性があります。興味のある例の1つは、圧縮オーディオ/ビデオを運ぶマルチキャストフローです。これらのフローの場合、参照情報の遅延は非常に大きくなり、全体的な遅延に大きな貢献者になる可能性があります。
The buffering component of the overall acquisition delay is driven by the way the application layer processes the payload. In many multicast applications, an unreliable transport protocol such as UDP [RFC0768] is often used to transmit the data packets, and the reliability, if needed, is usually addressed through other means such as Forward Error Correction (e.g., [RFC6015]) and retransmission. These loss-repair methods require buffering at the receiver side to function properly. In many applications, it is also often necessary to de-jitter the incoming data packets before feeding them to the application. The de-jittering process also increases the buffering delays. Besides these network-related buffering delays, there are also specific buffering needs that are required by the individual applications. For example, standard video decoders typically require a certain amount, sometimes up to a few seconds, of coded video data to be available in the pre-decoding buffers prior to starting to decode the video bitstream.
全体的な取得遅延のバッファリングコンポーネントは、アプリケーションレイヤーがペイロードを処理する方法によって駆動されます。多くのマルチキャストアプリケーションでは、UDP [RFC0768]などの信頼性の低いトランスポートプロトコルがデータパケットを送信するためによく使用され、必要に応じて信頼性は、通常、フォワードエラー補正（例えば[RFC6015]）や他の手段を通じて対処されます。再送信。これらの損失修正方法は、適切に機能するためにレシーバー側でのバッファリングが必要です。多くのアプリケーションでは、アプリケーションに供給する前に、着信データパケットを除去することもしばしば必要です。除去プロセスは、バッファリングの遅延も増加させます。これらのネットワーク関連のバッファリングの遅延に加えて、個々のアプリケーションで必要な特定のバッファリングニーズもあります。たとえば、標準のビデオデコーダーには、通常、ビデオビットストリームのデコードを開始する前に、デコード前のバッファーで利用可能なコード化されたビデオデータの一定の量、時には数秒までの量が必要です。
This section is for informational purposes and does not contain requirements for implementations.
このセクションは情報提供の目的であり、実装の要件は含まれていません。
Rapid acquisition is an optimization of a system that is expected to continue to work correctly and properly whether or not the optimization is effective or even fails due to lost control and feedback messages, congestion, or other problems. This is fundamental to the overall design requirements surrounding the protocol definition and to the resource management schemes to be employed together with the protocol (e.g., Quality of Service (QoS) machinery, server load management, etc). In particular, the system needs to operate within a number of constraints:
迅速な獲得とは、最適化が効果的であるかどうかにかかわらず、正しく適切に機能し続けると予想されるシステムの最適化であるか、制御およびフィードバックメッセージ、混雑、またはその他の問題のために失敗するかどうかです。これは、プロトコルの定義を取り巻く全体的な設計要件と、プロトコル（たとえば、サービスの品質（QOS）機械、サーバー負荷管理など）とともに採用するリソース管理スキームの基本です。特に、システムはいくつかの制約内で動作する必要があります。
o First, a rapid acquisition operation must fail gracefully. The user experience must not be significantly worse for trying and failing to complete rapid acquisition compared to simply joining the multicast session.
o まず、迅速な買収操作は優雅に失敗する必要があります。単にマルチキャストセッションに参加する場合と比較して、ユーザーエクスペリエンスが迅速な買収を完了し、完了しようとしない場合、大幅に悪化してはなりません。
o Second, providing the rapid acquisition optimizations must not cause collateral damage to either the multicast session being joined or other multicast sessions sharing resources with the rapid acquisition operation. In particular, the rapid acquisition operation must avoid interference with the multicast session that might be simultaneously being received by other hosts. In addition, it must also avoid interference with other multicast and non-multicast sessions sharing the same network resources. These properties are possible but are usually difficult to achieve.
o 第二に、迅速な獲得の最適化を提供することは、結合されているマルチキャストセッションまたは他のマルチキャストセッションを迅速な買収運用と共有する他のマルチキャストセッションのいずれかに担保損傷を引き起こしてはなりません。特に、迅速な買収操作は、他のホストが同時に受け取る可能性のあるマルチキャストセッションへの干渉を避けなければなりません。さらに、同じネットワークリソースを共有する他のマルチキャストおよび非マルチキャストセッションとの干渉を避ける必要があります。これらのプロパティは可能ですが、通常は達成することは困難です。
One challenge is the existence of multiple bandwidth bottlenecks between the receiver and the server(s) in the network providing the rapid acquisition service. In commercial IPTV deployments, for example, bottlenecks are often present in the aggregation network connecting the IPTV servers to the network edge, the access links (e.g., DSL, Data Over Cable Service Interface Specification (DOCSIS)), and the home network of the subscribers. Some of these links might serve only a single subscriber, limiting congestion impact to the traffic of only that subscriber, but others can be shared links carrying multicast sessions of many subscribers. Also note that the state of these links can vary over time. The receiver might have knowledge of a portion of this network or might have partial knowledge of the entire network. The methods employed by the devices to acquire this network state information is out of the scope of this document. The receiver should be able to signal the server with the bandwidth that it believes it can handle. The server also needs to be able to rate limit the flow in order to stay within the performance envelope that it knows about. Both the server and receiver need to be able to inform the other of changes in the requested and delivered rates. However, the protocol must be robust in the presence of packet loss, so this signaling must include the appropriate default behaviors.
1つの課題は、迅速な取得サービスを提供するネットワーク内のレシーバーとサーバーの間に複数の帯域幅ボトルネックが存在することです。たとえば、商用IPTVの展開では、ボトルネックがIPTVサーバーをネットワークエッジに接続する集約ネットワーク、アクセスリンク（DSL、ケーブルサービスインターフェイス仕様（DOCSIS）を介したデータ）、およびホームネットワークのホームネットワークにしばしば存在します。加入者。これらのリンクのいくつかは、1人のサブスクライバーのみに役立つ場合があり、そのサブスクライバーのみのトラフィックに渋滞の影響を制限しますが、他のものは多くのサブスクライバーのマルチキャストセッションを運ぶ共有リンクを共有できます。また、これらのリンクの状態は時間とともに変化する可能性があることに注意してください。受信者は、このネットワークの一部の知識を持っているか、ネットワーク全体の部分的な知識を持っている可能性があります。このネットワーク状態情報を取得するためにデバイスによって採用されている方法は、このドキュメントの範囲外です。受信者は、処理できると考えている帯域幅でサーバーに信号を送ることができるはずです。また、サーバーは、知っているパフォーマンスエンベロープ内にとどまるために、フローを制限することもできる必要があります。サーバーとレシーバーの両方が、要求された料金と配信された料金の変更を他のものに通知できる必要があります。ただし、プロトコルはパケット損失の存在下で堅牢である必要があるため、このシグナル伝達には適切なデフォルトの動作が含まれている必要があります。
A second challenge is that for some uses (e.g., high-bitrate video) the unicast burst bitrate is high while the flow duration of the unicast burst is short. This is because the purpose of the unicast burst is to allow the RTP receiver to join the multicast quickly and thereby limit the overall resources consumed by the burst. Such high-bitrate, short-duration flows are not amenable to conventional admission-control techniques. For example, end-to-end per-flow signaled admission-control techniques such as Resource Reservation Protocol (RSVP) have too much latency and control channel overhead to be a good fit for rapid acquisition. Similarly, using a TCP (or TCP-like) approach with a 3-way handshake and slow-start to avoid inducing congestion would defeat the purpose of attempting rapid acquisition in the first place by introducing many round-trip times (RTTs) of delay.
2番目の課題は、いくつかの用途（例：高ビトレートビデオ）では、ユニキャストバーストの流れ時間が短い間、ユニキャストバーストビットレートが高くなることです。これは、ユニキャストバーストの目的は、RTPレシーバーがマルチキャストに迅速に参加できるようにし、それによりバーストによって消費される全体的なリソースを制限することであるためです。このような高ビトレートの短時間のフローは、従来の入場制御技術に適していません。たとえば、リソース予約プロトコル（RSVP）などのエンドツーエンドごとのシグナル付き入学制御手法は、迅速な獲得に適しているため、レイテンシおよびコントロールチャネルオーバーヘッドが多すぎます。同様に、3方向の握手とスロースタートでTCP（またはTCP様）アプローチを使用して、輻輳を誘発するのを避けることは、遅延の多くの往復時間（RTTS）を導入することにより、最初に迅速な獲得を試みる目的を打ち負かします。。
These observations lead to certain unavoidable requirements and goals for a rapid acquisition protocol. These are:
これらの観察結果は、迅速な買収プロトコルの特定の避けられない要件と目標につながります。これらは：
o The protocol must be designed to allow a deterministic upper bound on the extra bandwidth used (compared to just joining the multicast session). A reasonable size bound is e*B, where B is the nominal bandwidth of the primary multicast streams and e is an excess-bandwidth coefficient. The total duration of the unicast burst must have a reasonable bound; long unicast bursts devolve to the bandwidth profile of multi-unicast for the whole system.
o プロトコルは、使用される余分な帯域幅に決定論的な上限を許可するように設計する必要があります（マルチキャストセッションに参加するだけではありません）。合理的なサイズのバインドはE*Bです。ここで、Bはプライマリマルチキャストストリームの公称帯域幅であり、Eは過剰な帯域幅係数です。ユニキャストバーストの合計期間には、合理的なバウンドが必要です。長いユニキャストバーストは、システム全体のMulti-Unicastの帯域幅プロファイルに委ねられます。
o The scheme should minimize (or better eliminate) the overlap of the unicast burst and the primary multicast stream. This minimizes the window during which congestion could be induced on a bottleneck link compared to just carrying the multicast or unicast packets alone.
o スキームは、ユニキャストバーストとプライマリマルチキャストストリームのオーバーラップを最小限に抑える（または排除する）必要があります。これにより、マルチキャストパケットまたはユニキャストパケットを運ぶだけで、ボトルネックリンクに輻輳が誘導されるウィンドウが最小限に抑えられます。
o The scheme must minimize (or better eliminate) any gap between the unicast burst and the primary multicast stream, which has to be repaired later or, in the absence of repair, will result in loss being experienced by the application.
o スキームは、ユニキャストバーストとプライマリマルチキャストストリームとの間のギャップを最小限に抑える（または排除する）必要があります。これは、後で修復する必要があります。
In addition to the above, there are some other protocol design issues to be considered. First, there is at least one RTT of "slop" in the control loop. In starting a rapid acquisition burst, this manifests as the time between the client requesting the unicast burst and the burst description and/or the first unicast burst packets arriving at the receiver. For managing and terminating the unicast burst, there are two possible approaches for the control loop. First, the receiver can adapt to the unicast burst as received, converge based on observation, and explicitly terminate the unicast burst with a second control loop exchange (which takes a minimum of one RTT, just as starting the unicast burst does). Alternatively, the server generating the unicast burst can precompute the burst parameters based on the information in the initial request and tell the receiver the burst duration.
上記に加えて、考慮すべき他のプロトコル設計の問題がいくつかあります。まず、コントロールループには少なくとも1つのRTTが「スロップ」があります。迅速な買収バーストを開始する際、これは、クライアントがユニキャストバーストとバーストの説明、および/または受信機に到着する最初のユニキャストバーストパケットを要求する時間として現れます。ユニキャストバーストを管理および終了するために、コントロールループには2つの可能なアプローチがあります。まず、受信者は、受信通りユニキャストバーストに適応し、観測に基づいて収束し、ユニキャストバーストを2番目のコントロールループ交換で明示的に終了できます（ユニキャストバーストの開始と同じように、最低1つのRTTが必要です）。あるいは、ユニキャストバーストを生成するサーバーは、初期リクエストの情報に基づいてバーストパラメーターをプリピューし、バースト期間を受信者に伝えることができます。
The protocol described in the next section allows either method of controlling the rapid acquisition unicast burst.
次のセクションで説明するプロトコルは、迅速な取得ユニキャストバーストを制御する方法のいずれかを許可します。
We start this section with an overview of the Rapid Acquisition of Multicast RTP Sessions (RAMS) method.
このセクションは、マルチキャストRTPセッション（RAMS）メソッドの迅速な買収の概要から始めます。
[RFC5760] specifies an extension to the RTP Control Protocol (RTCP) to use unicast feedback in an SSM session. It defines an architecture that introduces the concept of Distribution Source, which, in an SSM context, distributes the RTP data and redistributes RTCP information to all RTP receivers. This RTCP information is retrieved from the Feedback Target, to which RTCP unicast feedback traffic is sent. One or more entities different from the Distribution Source MAY implement the feedback target functionality, and different RTP receivers MAY use different feedback targets.
[RFC5760]は、RTP制御プロトコル（RTCP）の拡張を指定して、SSMセッションでユニキャストフィードバックを使用します。SSMコンテキストでは、RTPデータを配布し、RTCP情報をすべてのRTP受信機に再分配する分布ソースの概念を導入するアーキテクチャを定義します。このRTCP情報は、RTCPユニキャストフィードバックトラフィックが送信されるフィードバックターゲットから取得されます。配布ソースとは異なる1つ以上のエンティティがフィードバックターゲット機能を実装する場合があり、異なるRTPレシーバーが異なるフィードバックターゲットを使用する場合があります。
This document builds further on these concepts to reduce the acquisition delay when an RTP receiver joins a multicast session at a random point in time by introducing the concept of the Burst Source and new RTCP feedback messages. The Burst Source has a cache where the most recent packets from the primary multicast RTP session are continuously stored. When an RTP receiver wants to receive a primary multicast stream, it can first request a unicast burst from the Burst Source before it joins the SSM session. In this burst, the packets are formatted as RTP retransmission packets [RFC4588] and carry Reference Information. This information allows the RTP receiver to start usefully consuming the RTP packets sent in the primary multicast RTP session.
このドキュメントは、これらの概念をさらに構築して、RTPレシーバーがバーストソースの概念と新しいRTCPフィードバックメッセージの概念を導入することにより、ランダムな時点でマルチキャストセッションに参加するときの取得遅延を減らすことを減らします。バーストソースには、プライマリマルチキャストRTPセッションの最新のパケットが継続的に保存されるキャッシュがあります。RTPレシーバーがプライマリマルチキャストストリームを受信したい場合、SSMセッションに参加する前に、バーストソースからユニキャストバーストを最初に要求できます。このバーストでは、パケットはRTP再送信パケット[RFC4588]としてフォーマットされ、参照情報が伝達されます。この情報により、RTPレシーバーは、プライマリマルチキャストRTPセッションで送信されたRTPパケットの有用な消費を開始できます。
Using an accelerated bitrate (as compared to the nominal bitrate of the primary multicast stream) for the unicast burst implies that at a certain point in time, the payload transmitted in the unicast burst is going to be the same as the payload in the associated multicast stream, i.e., the unicast burst will catch up with the primary multicast stream. At this point, the RTP receiver no longer needs to receive the unicast burst and can join the SSM session. This method is referred to as the Rapid Acquisition of Multicast RTP Sessions (RAMS).
ユニキャストバーストに加速ビットレート（プライマリマルチキャストストリームの公称ビットレートと比較して）を使用すると、特定の時点で、ユニキャストバーストに送信されるペイロードが関連するマルチキャストのペイロードと同じになることを意味します。ストリーム、つまり、ユニキャストバーストは、プライマリマルチキャストストリームに追いつきます。この時点で、RTPレシーバーはユニキャストバーストを受信する必要がなく、SSMセッションに参加できます。この方法は、マルチキャストRTPセッション（RAMS）の迅速な買収と呼ばれます。
This document defines extensions to [RFC4585] for an RTP receiver to request a unicast burst as well as for additional control messaging that can be leveraged during the acquisition process.
このドキュメントでは、RTPレシーバーがユニキャストバーストを要求し、取得プロセス中にレバレッジできる追加の制御メッセージを要求するために[RFC4585]の拡張機能を定義しています。
As shown in Figure 2, the main entities involved in rapid acquisition and the message flows are:
図2に示すように、迅速な買収に関与する主なエンティティとメッセージフローは次のとおりです。
o Multicast Source
o マルチキャストソース
o Feedback Target (FT)
o フィードバックターゲット（FT）
o Burst/Retransmission Source (BRS)
o バースト/再送信ソース（BRS）
o RTP Receiver (RTP_Rx)
o RTPレシーバー（RTP_RX）
----------- --------------
| |------------------------------------>| |
| |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| |
| | | |
| Multicast | ---------------- | |
| Source | | Retransmission | | |
| |-------->| Server (RS) | | |
| |.-.-.-.->| | | |
| | | ------------ | | |
----------- | | Feedback | |<.=.=.=.=.| |
| | Target (FT)| |<~~~~~~~~~| RTP Receiver |
PRIMARY MULTICAST | ------------ | | (RTP_Rx) |
RTP SESSION with | | | |
UNICAST FEEDBACK | | | |
| | | |
- - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- -
| | | |
UNICAST BURST | ------------ | | |
(or RETRANSMISSION) | | Burst/ | |<~~~~~~~~>| |
RTP SESSION | | Retrans. | |.........>| |
| |Source (BRS)| |<.=.=.=.=>| |
| ------------ | | |
| | | |
---------------- --------------
-------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages
.......> Unicast RTP Flow
Figure 2: Flow Diagram for Unicast-Based Rapid Acquisition
図2：ユニキャストベースの迅速な獲得のためのフロー図
As defined in [RFC5760], the feedback target (FT) is the entity to which the RTP_Rx sends its RTCP feedback messages indicating packet loss by means of an RTCP NACK message or indicating RTP_Rx's desire to rapidly acquire the primary multicast RTP session by means of an RTCP feedback message defined in this document. While the Burst/ Retransmission Source (BRS) is responsible for responding to these messages and for further RTCP interaction with the RTP_Rx in the case of a rapid acquisition process, it is assumed in the remainder of this document that these two logical entities (FT and BRS) are combined in a single physical entity and they share state. In the remainder of the text, the term Retransmission Server (RS) is used whenever appropriate, to refer to this single physical entity.
[RFC5760]で定義されているように、フィードバックターゲット（FT）は、RTP_RXがRTCP NACKメッセージによるパケットの損失を示すRTCPフィードバックメッセージを送信するエンティティであるか、RTP_RXがプライマリマルチキャストRTPセッションを迅速に取得したいというRTP_RXの要望を示すエンティティです。このドキュメントで定義されているRTCPフィードバックメッセージ。バースト/再送信ソース（BRS）は、これらのメッセージへの応答と、迅速な取得プロセスの場合にRTP_RXとのさらなるRTCPの相互作用を担当しますが、この2つの論理エンティティ（FTとFTとBRS）は単一の物理的エンティティで結合され、状態を共有します。テキストの残りの部分では、この単一の物理エンティティを参照するために、適切な場合はいつでも、再送信サーバー（RS）という用語が使用されます。
The FT is involved in the primary multicast RTP session and receives unicast feedback for that session as in [RFC5760]. The BRS is involved in the unicast burst (or retransmission) RTP session and transmits the unicast burst and retransmission packets formatted as RTP retransmission packets [RFC4588] in a single separate unicast RTP session to each RTP_Rx. In the unicast burst RTP session, as in any other RTP session, the BRS and RTP_Rx regularly send the periodic sender and receiver reports, respectively.
FTはプライマリマルチキャストRTPセッションに関与しており、[RFC5760]のように、そのセッションのユニキャストフィードバックを受け取ります。BRSは、ユニキャストバースト（または再送信）RTPセッションに関与しており、各RTP_RXへの単一のユニキャストRTPセッションで、RTP再送信パケット[RFC4588]としてフォーマットされたユニキャストバーストおよび再送信パケットを送信します。ユニキャストバーストRTPセッションでは、他のRTPセッションと同様に、BRSとRTP_RXはそれぞれ定期的な送信者と受信機のレポートを定期的に送信します。
The unicast burst is started by an RTCP feedback message that is defined in this document based on the common packet format provided in [RFC4585]. An RTP retransmission is triggered by an RTCP NACK message defined in [RFC4585]. Both of these messages are sent to the FT of the primary multicast RTP session and can start the unicast burst/retransmission RTP session.
ユニキャストバーストは、[RFC4585]で提供される一般的なパケット形式に基づいて、このドキュメントで定義されているRTCPフィードバックメッセージによって開始されます。RTPの再送信は、[RFC4585]で定義されたRTCP NACKメッセージによってトリガーされます。これらのメッセージは両方とも、プライマリマルチキャストRTPセッションのFTに送信され、Unicastバースト/再送信RTPセッションを開始できます。
In the extended RTP profile for RTCP-based feedback (RTP/Audio-Visual Profile with Feedback (AVPF)), there are certain rules that apply to scheduling of both of these messages sent to the FT in the primary multicast RTP session; these are detailed in Section 3.5 of [RFC4585]. One of the rules states that in a multi-party session such as the SSM sessions we are considering in this specification, an RTP_Rx cannot send an RTCP feedback message for a minimum of one second after joining the session (i.e., Tmin=1.0 second). While this rule has the goal of avoiding problems associated with flash crowds in typical multi-party sessions, it defeats the purpose of rapid acquisition. Furthermore, when RTP receivers delay their messages requesting a burst by a deterministic or even a random amount, it still does not make a difference since such messages are not related and their timings are independent from each other. Thus, in this specification, we initialize Tmin to zero and allow the RTP receivers to send a burst request message right at the beginning. For the subsequent messages (e.g., updated requests) during rapid acquisition, the timing rules of [RFC4585] still apply.
RTCPベースのフィードバックの拡張RTPプロファイル（RTP/Audio-Visualプロファイルを使用した（AVPF））には、プライマリマルチキャストRTPセッションでFTに送信されたこれらのメッセージの両方のスケジューリングに適用される特定のルールがあります。これらは[RFC4585]のセクション3.5で詳しく説明されています。規則の1つは、この仕様で検討しているSSMセッションなどのマルチパーティセッションでは、RTP_RXがセッションに参加した後（つまり、TMIN = 1.0秒）RTCPフィードバックメッセージを最低1秒間送信できないと述べています。。このルールには、典型的なマルチパーティセッションでフラッシュクラウドに関連する問題を回避するという目標がありますが、迅速な買収の目的を打ち負かします。さらに、RTP受信機が決定論的またはランダムな量でバーストを要求するメッセージを遅らせると、そのようなメッセージは関連しておらず、タイミングが互いに独立しているため、違いはありません。したがって、この仕様では、TMINを初期化してゼロになり、RTPレシーバーが最初にバーストリクエストメッセージを送信できるようにします。迅速な買収中に後続のメッセージ（たとえば、更新された要求）の場合、[RFC4585]のタイミングルールが引き続き適用されます。
Figure 3 depicts an example of messaging flow for rapid acquisition. The RTCP feedback messages are explained below. The optional messages are indicated in parentheses, and they might or might not be present during rapid acquisition. In a scenario where rapid acquisition is performed by a feedback target co-located with the media sender, the same method (with the identical message flows) still applies.
図3は、迅速な獲得のためのメッセージングフローの例を示しています。RTCPフィードバックメッセージを以下で説明します。オプションのメッセージは括弧内に示されており、迅速な獲得中に存在する場合とそうでない場合があります。メディア送信者と共同住宅されたフィードバックターゲットによって迅速な獲得が実行されるシナリオでは、同じ方法（同一のメッセージフローを使用）がまだ適用されます。
-------------------------
| Retransmission Server |
----------- | ------ ------------ | -------- ------------
| Multicast | | | FT | | Burst/Ret. | | | | | RTP |
| Source | | | | | Source | | | Router | | Receiver |
| | | ------ ------------ | | | | (RTP_Rx) |
----------- | | | | -------- ------------
| ------------------------- | |
| | | | |
|-- RTP Multicast ---------->--------------->| |
|-. RTCP Multicast -.-.-.-.->-.-.-.-.-.-.-.->| |
| | | | |
| | |********************************|
| | |* PORT MAPPING SETUP *|
| | |********************************|
| | | | |
| |<~~~~~~~~~~~~~~~~~~~~~~~~~ RTCP RAMS-R ~~~|
| | | | |
| | |********************************|
| | |* UNICAST SESSION ESTABLISHED *|
| | |********************************|
| | | | |
| | |~~~ RTCP RAMS-I ~~~~~~~~~~~~~~~>|
| | | | |
| | |... Unicast RTP Burst .........>|
| | | | |
| |<~~~~~~~~~~~~~~~~~~~~~~~~ (RTCP RAMS-R) ~~|
| | | | |
| | |~~ (RTCP RAMS-I) ~~~~~~~~~~~~~~>|
| | | | |
| | | | |
| | | |<= SFGMP Join ==|
| | | | |
|-- RTP Multicast ------------------------------------------->|
|-. RTCP Multicast -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>|
| | | | |
| | | | |
| | |<~~~~~~~~~~~~~~~ RTCP RAMS-T ~~~|
| | | | |
: : : : :
| | |<.=.= Unicast RTCP Reports .=.=>|
: : : for the unicast session :
| | | | |
-------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages
=======> SFGMP Messages
.......> Unicast RTP Flow
Figure 3: Message Flows for Unicast-Based Rapid Acquisition
図3：ユニキャストベースの迅速な獲得のメッセージフロー
This document defines the expected behaviors of the RS and RTP_Rx. It is instructive to consider independently operating implementations on the RS and RTP_Rx that request the burst, describe the burst, start the burst, join the multicast session, and stop the burst. These implementations send messages to each other, but provisions are needed for the cases where the control messages get lost, or reordered, or are not being delivered to their destinations.
このドキュメントでは、RSとRTP_RXの予想される動作を定義しています。バーストを要求し、バーストを説明し、バーストを開始し、マルチキャストセッションに参加し、バーストを停止するRSおよびRTP_RXで独立して操作する実装を考慮することは有益です。これらの実装は互いにメッセージを送信しますが、制御メッセージが失われたり、再注文されたり、目的地に配信されていない場合には規定が必要です。
The following steps describe rapid acquisition in detail:
次の手順では、迅速な買収を詳細に説明しています。
1. Port Mapping Setup: For the primary multicast RTP session, the RTP and RTCP destination ports are declaratively specified (refer to Section 8 for examples in SDP). However, the RTP_Rx needs to choose its RTP and RTCP receive ports for the unicast burst RTP session. Since this unicast session is established after the RTP_Rx has sent a RAMS Request (RAMS-R) message as unicast feedback in the primary multicast RTP session, the RTP_Rx MUST first set up the port mappings between the unicast and multicast sessions and send this mapping information to the FT along with the RAMS-R message so that the BRS knows how to communicate with the RTP_Rx.
1. ポートマッピングセットアップ：プライマリマルチキャストRTPセッションの場合、RTPおよびRTCP宛先ポートが宣言的に指定されています（SDPの例についてはセクション8を参照）。ただし、RTP_RXは、Unicast Burst RTPセッションのRTPおよびRTCP受信ポートを選択する必要があります。このユニキャストセッションは、RTP_RXがプライマリマルチキャストRTPセッションでユニキャストフィードバックとしてRAMSリクエスト（RAMS-R）メッセージを送信した後に確立されているため、RTP_RXは最初にユニキャストとマルチキャストセッションの間のポートマッピングを設定し、このマッピング情報を送信する必要があります。FTにRAMS-Rメッセージとともに、BRSがRTP_RXと通信する方法を知っているようにします。
The details of this setup procedure are explained in [RFC6284]. Other NAT-related issues are left to Section 9 to keep the present discussion focused on the RAMS message flows.
このセットアップ手順の詳細は、[RFC6284]で説明されています。他のNAT関連の問題は、現在の議論をRamsメッセージの流れに焦点を合わせ続けるためにセクション9に任されています。
2. Request: The RTP_Rx sends a rapid acquisition request (RAMS-R) for the primary multicast RTP session to the unicast feedback target of that session. The request contains the SSRC identifier of the RTP_Rx (aka SSRC of packet sender) and can contain the media sender SSRC identifier(s) of the primary multicast stream(s) of interest (aka SSRC of media source). The RAMS-R message can contain parameters that constrain the burst, such as the buffer and bandwidth limits.
2. リクエスト：RTP_RXは、プライマリマルチキャストRTPセッションの迅速な取得要求（RAMS-R）をそのセッションのユニキャストフィードバックターゲットに送信します。リクエストには、RTP_RXのSSRC識別子（パケット送信者のSSRC）が含まれており、主要なマルチキャストストリーム（SSRCの別名SSRCのSSRC）のメディア送信者SSRC識別子を含めることができます。RAMS-Rメッセージには、バッファーや帯域幅の制限など、バーストを制限するパラメーターを含めることができます。
Before joining the SSM session, the RTP_Rx learns the addresses for the multicast source, group, and RS by out-of-band means. If the RTP_Rx desires to rapidly acquire only a subset of the primary multicast streams available in the primary multicast RTP session, the RTP_Rx MUST also acquire the SSRC identifiers for the desired RTP streams out-of-band. Based on this information, the RTP_Rx populates the desired SSRC(s) in the RAMS-R message.
SSMセッションに参加する前に、RTP_RXは、マルチキャストソース、グループ、およびRSのアドレスを帯域外の手段ごとに学習します。RTP_RXがプライマリマルチキャストRTPセッションで利用可能なプライマリマルチキャストストリームのサブセットのみを迅速に取得したい場合、RTP_RXは、目的のRTPストリームのSSRC識別子を帯域外で取得する必要があります。この情報に基づいて、RTP_RXはRAMS-Rメッセージの目的のSSRC（S）に入力されます。
When the FT successfully receives the RAMS-R message, the BRS responds to it by accepting or rejecting the request. Immediately before the BRS sends any RTP or RTCP packet(s) described below, it establishes the unicast burst RTP session.
FTがRAMS-Rメッセージを正常に受信すると、BRSはリクエストを受け入れるか拒否することにより応答します。BRSが以下に説明するRTPまたはRTCPパケットを送信する直前に、ユニキャストバーストRTPセッションを確立します。
3. Response: The BRS sends RAMS Information (RAMS-I) message(s) to the RTP_Rx to convey the status for the burst(s) requested by the RTP_Rx.
3. 応答：BRSはRAMS情報（RAMS-I）メッセージをRTP_RXに送信して、RTP_RXが要求したバーストのステータスを伝えます。
If the primary multicast RTP session associated with the FT_Ap (a specific feedback target running on a particular address and port) on which the RAMS-R message was received contains only a single primary multicast stream, the BRS SHALL always use the SSRC of the RTP stream associated with the FT_Ap in the RAMS-I message(s) regardless of the media sender SSRC requested in the RAMS-R message. In such cases the 'ssrc' attribute MAY be omitted from the media description. If the requested SSRC and the actual media sender SSRC do not match, the BRS MUST explicitly populate the correct media sender SSRC in the initial RAMS-I message (see Section 7.3).
RAMS-Rメッセージが受信されたFT_AP（特定のアドレスとポートで実行されている特定のフィードバックターゲット）に関連付けられたプライマリマルチキャストRTPセッションには、単一のプライマリマルチキャストストリームのみが含まれている場合、BRSは常にRTPのSSRCを使用しますRAMS-Rメッセージで要求されたメディア送信者SSRCに関係なく、RAMS-IメッセージのFT_APに関連付けられたストリーム。そのような場合、メディアの説明から「SSRC」属性を省略できます。要求されたSSRCと実際のメディア送信者SSRCが一致しない場合、BRSは最初のRAMS-Iメッセージで正しいメディア送信者SSRCを明示的に設定する必要があります（セクション7.3を参照）。
The FT_Ap could also be associated with an RTP session that carries two or more primary multicast streams. If the RTP_Rx wants to issue a collective request to receive the whole primary multicast RTP session, it does not need the 'ssrc' attributes to be described in the media description.
FT_APは、2つ以上のプライマリマルチキャストストリームを運ぶRTPセッションにも関連付けられている可能性があります。RTP_RXが、プライマリマルチキャストRTPセッション全体を受け取るために集合的なリクエストを発行したい場合、メディアの説明で「SSRC」属性を説明する必要はありません。
If the FT_Ap is associated with two or more RTP sessions, RTP_Rx's request will be ambiguous. To avoid any ambiguity, each FT_Ap MUST be only associated with a single RTP session.
FT_APが2つ以上のRTPセッションに関連付けられている場合、RTP_RXのリクエストは曖昧になります。あいまいさを避けるために、各FT_APは単一のRTPセッションにのみ関連付けられている必要があります。
If the RTP_Rx is willing to rapidly acquire only a subset of the primary multicast streams, the RTP_Rx MUST list all the media sender SSRC(s) denoting the stream(s) it wishes to acquire in the RAMS-R message. Upon receiving such a message, the BRS MAY accept the request for all or a subset of the media sender SSRC(s) that match the RTP stream(s) it serves. The BRS MUST reject all other requests with an appropriate response code.
RTP_RXがプライマリマルチキャストストリームのサブセットのみを迅速に取得することをいとわない場合、RTP_RXは、RAMS-Rメッセージで取得したいストリームを示すすべてのメディア送信者SSRCをリストする必要があります。そのようなメッセージを受信すると、BRSは、サービスを提供するRTPストリームに一致するメディア送信者SSRCのすべてまたはサブセットのリクエストを受け入れることができます。BRSは、適切な応答コードで他のすべてのリクエストを拒否する必要があります。
* Reject Responses: The BRS MUST take into account any limitations that may have been specified by the RTP_Rx in the RAMS-R message when making a decision regarding the request. If the RTP_Rx has requested to acquire the whole primary multicast RTP session but the BRS cannot provide a rapid acquisition service for any of the primary multicast streams, the BRS MUST reject the request via a single RAMS-I message with a collective reject response code, which is defined as 510 in Section 11.6 and whose media sender SSRC field is set to one of SSRCs served by this FT_Ap. Upon receiving this RAMS-I message, the RTP_Rx abandons the rapid acquisition attempt and can immediately join the multicast session by sending an SFGMP Join message towards its upstream multicast router.
* 拒否応答：BRSは、リクエストに関する決定を下す際に、RAMS-RメッセージのRTP_RXによって指定された可能性のある制限を考慮する必要があります。RTP_RXがプライマリマルチキャストRTPセッション全体を取得することを要求したが、BRSがプライマリマルチキャストストリームのいずれにも迅速な取得サービスを提供できない場合、BRSは、集合的な応答コードを備えた単一のRAMS-Iメッセージを介して要求を拒否する必要があります。セクション11.6の510と定義され、メディアセンダーSSRCフィールドは、このFT_APが提供するSSRCの1つに設定されています。このRams-Iメッセージを受信すると、RTP_RXは迅速な買収の試みを放棄し、SFGMP結合メッセージを上流のマルチキャストルーターに送信することにより、すぐにマルチキャストセッションに参加できます。
In all other cases, the BRS MUST send a separate RAMS-I message with the appropriate 5xx-level response code (as defined in Section 11.6) for each primary multicast stream that has been requested by the RTP_Rx but cannot be served by the BRS. There could be multiple reasons why the BRS has rejected the request; however, the BRS chooses the most appropriate response code to inform the RTP_Rx.
他のすべてのケースで、BRSは、RTP_RXによって要求されているがBRSが提供できない各プライマリマルチキャストストリームについて、適切な5XXレベルの応答コード（セクション11.6で定義されている）を使用して、別のRAMS-Iメッセージを送信する必要があります。BRSがリクエストを拒否した理由は複数あります。ただし、BRSは、RTP_RXを通知するために最も適切な応答コードを選択します。
Upon receiving a reject response indicating a transient problem such as insufficient BRS or network resources, if the RTP_Rx wants to retry sending the same request, the RTP_Rx MUST follow the RTCP timer rules of [RFC4585] to allow the transient problems to go away. However, if the reject response indicates a non-transient problem (such as the ones reported by response codes 504, 505, and 506), the RTP_Rx MUST NOT attempt a retry. Different response codes have different scopes. Refer to Section 7.3.1 for details.
RTP_RXが同じリクエストを送信したい場合、RTP_RXが再試行したい場合、RTP_RXは[RFC4585]のRTCPタイマールールに従い、一時的な問題がなくなることを許可する必要がある場合、拒否応答を受信すると、RTP_RXが再び再送信したい場合。ただし、拒否応答が非転移の問題（応答コード504、505、および506で報告されている問題など）を示している場合、RTP_RXは再試行を試みてはなりません。異なる応答コードには異なるスコープがあります。詳細については、セクション7.3.1を参照してください。
The BRS can employ a policing mechanism against the broken RTP_Rx implementations that are not following these rules. See Section 10 for details.
BRSは、これらのルールに従っていない壊れたRTP_RX実装に対するポリシングメカニズムを採用できます。詳細については、セクション10を参照してください。
* Accept Responses: The BRS MUST send at least one separate RAMS-I message with the appropriate response code (either zero indicating a private response or response code 200 indicating success as listed in Section 11.6) for each primary multicast stream that has been requested by the RTP_Rx and will be served by the BRS. Such RAMS-I messages comprise fields that can be used to describe the individual unicast burst streams. When there is a RAMS-R request for multiple primary multicast streams, the BRS MUST include all the individual RAMS-I messages corresponding to that RAMS-R request in the same compound RTCP packet if these messages fit in the same packet. Note that if the BRS is sending only the preamble information but not the whole unicast burst stream, it will not accept the request but will send a response code 511 instead, as defined in Section 11.6.
* 応答を受け入れる：BRSは、適切な応答コード（ゼロを示すゼロのいずれか）を使用して、少なくとも1つの個別のRAMS-Iメッセージを送信する必要があります。RTP_RXとBRSが提供します。このようなRams-Iメッセージは、個々のユニキャストバーストストリームを説明するために使用できるフィールドで構成されています。複数のプライマリマルチキャストストリームに対してRAMS-Rリクエストがある場合、BRSには、これらのメッセージが同じパケットに適合する場合、同じ化合物RTCPパケットでそのRAMS-R要求に対応するすべての個々のRAMS-Iメッセージを含める必要があります。BRSがプリアンブル情報のみを送信しているが、ユニキャストバーストストリーム全体ではなく送信している場合、リクエストを受け入れるのではなく、セクション11.6で定義されているように、代わりに応答コード511を送信することに注意してください。
The RAMS-I message carries the RTP sequence number of the first packet transmitted in the respective RTP stream to allow the RTP_Rx to detect any missing initial packet(s). When the BRS accepts a request for a primary multicast stream, this field MUST always be populated in the RAMS-I message(s) sent for this particular primary multicast stream. It is RECOMMENDED that the BRS sends a RAMS-I message at the start of the burst so that the RTP_Rx can quickly detect any missing initial packet(s).
RAMS-Iメッセージは、それぞれのRTPストリームに送信された最初のパケットのRTPシーケンス番号を伝達し、RTP_RXが欠落している初期パケットを検出できるようにします。BRSがプライマリマルチキャストストリームのリクエストを受け入れる場合、このフィールドは、この特定のプライマリマルチキャストストリームに送信されるRAMS-Iメッセージに常に入力する必要があります。RTP_RXが欠落している初期パケットをすばやく検出できるように、BRSがバーストの開始時にRams-Iメッセージを送信することをお勧めします。
It is possible that the RAMS-I message for a primary multicast stream can get delayed or lost, and the RTP_Rx can start receiving RTP packets before receiving a RAMS-I message. An RTP_Rx implementation MUST NOT assume it will quickly receive the initial RAMS-I message. For redundancy purposes, it is RECOMMENDED that the BRS repeats the RAMS-I messages multiple times as long as it follows the RTCP timer rules defined in [RFC4585].
プライマリマルチキャストストリームのRams-Iメッセージが遅延または紛失する可能性があり、RTP_RXがRAMS-Iメッセージを受信する前にRTPパケットの受信を開始できる可能性があります。RTP_RXの実装は、最初のRAMS-Iメッセージをすばやく受信すると仮定してはなりません。冗長性のために、BRSは、[RFC4585]で定義されているRTCPタイマールールに従う限り、RAMS-Iメッセージを複数回繰り返すことをお勧めします。
4. Unicast Burst: For the primary multicast stream(s) for which the request is accepted, the BRS starts sending the unicast burst(s) that comprises one or more RTP retransmission packets sent in the unicast burst RTP session. In some applications, the BRS can send preamble information data to the RTP_Rx in addition to the requested burst to prime the media decoder(s). However, for the BRS to send the preamble information in a particular format, explicit signaling from the RTP_Rx is required. In other words, the BRS MUST NOT send preamble information in a particular format unless the RTP_Rx has signaled support for that format in the RAMS-R message through a public or private extension as defined in Section 7.1.
4. ユニキャストバースト：リクエストが受け入れられるプライマリマルチキャストストリームの場合、BRSは、ユニキャストバーストRTPセッションで送信された1つ以上のRTP再送信パケットを含むユニキャストバーストの送信を開始します。一部のアプリケーションでは、BRSは、メディアデコーダーをプライムするために要求されたバーストに加えて、PREAMBLE情報データをRTP_RXに送信できます。ただし、BRSが特定の形式でプリアンブル情報を送信するには、RTP_RXからの明示的なシグナリングが必要です。言い換えれば、rtp_rxがセクション7.1で定義されているように、パブリックまたはプライベート拡張機能を介してRAMS-Rメッセージのその形式のサポートを信号していない限り、BRSは特定の形式でプリアンブル情報を送信してはなりません。
The format of this preamble data is RTP-payload specific and not specified here.
このプリアンブルデータの形式はRTP-Payload固有であり、ここでは指定されていません。
5. Updated Request: The RTP_Rx MAY send an updated RAMS-R message (as unicast feedback in the primary multicast RTP session) with a different value for one or more fields of an earlier RAMS-R message. The BRS MUST be able to detect whether a burst is already planned for or being transmitted to this particular RTP_Rx for this particular media sender SSRC. If there is an existing burst planned for or being transmitted, the newly arriving RAMS-R is an updated request; otherwise, it is a new request. It is also possible that the RTP_Rx has sent an improperly formatted RAMS-R message or used an invalid value in the RAMS-R message. If notified by the BRS using a 4xx-level response code (as defined in Section 11.6) and only after following the timing rules of [RFC4585], the RTP_Rx MAY resend its corrected request.
5. 更新されたリクエスト：RTP_RXは、以前のRAMS-Rメッセージの1つ以上のフィールドに対して異なる値で、更新されたRAMS-Rメッセージ（プライマリマルチキャストRTPセッションでユニキャストフィードバックとして）を送信する場合があります。BRSは、この特定のメディア送信者SSRCのこの特定のRTP_RXに対してすでに予定されているか、またはこの特定のRTP_RXに送信されているかどうかを検出できる必要があります。既存のバーストが計画されている、または送信されている場合、新しく到着したRAMS-Rは更新された要求です。それ以外の場合は、新しいリクエストです。また、RTP_RXが不適切にフォーマットされたRAMS-Rメッセージを送信したり、RAMS-Rメッセージで無効な値を使用したりする可能性もあります。4xxレベルの応答コード（セクション11.6で定義されている）を使用してBRSによって通知され、[RFC4585]のタイミングルールに従った後にのみ通知された場合、RTP_RXは修正された要求を再送信する場合があります。
The BRS determines the identity of the requesting RTP_Rx by looking at its canonical name identifier (CNAME item in the source description (SDES)). Thus, the RTP_Rx MUST choose a method that ensures it uses a unique CNAME identifier. Such methods are provided in [RFC6222]. In addition to one or more fields with updated values, an updated RAMS-R message may also include the fields whose values did not change.
BRSは、その標準名識別子（ソース説明（SDES）のCNAMEアイテム）を見ることにより、要求するRTP_RXのIDを決定します。したがって、RTP_RXは、一意のCNAME識別子を使用することを保証するメソッドを選択する必要があります。このような方法は[RFC6222]で提供されています。値が更新された1つ以上のフィールドに加えて、更新されたRAMS-Rメッセージには、値が変わらなかったフィールドも含まれる場合があります。
Upon receiving an updated request, the BRS can use the updated values for sending/shaping the burst or refine the values and use the refined values for sending/shaping the burst. Subsequently, the BRS MAY send an updated RAMS-I message in the unicast burst RTP session to indicate the changes it made.
更新された要求を受信すると、BRSは更新された値を使用してバーストを送信/形成するか、値を洗練し、バーストの送信/形状に洗練された値を使用できます。その後、BRSは、Unicast Burst RTPセッションで更新されたRams-Iメッセージを送信して、変更した変更を示します。
It is an implementation-dependent decision for an RTP_RX whether and when to send an updated request. However, note that the updated request messages can get delayed and arrive at the BRS after the initial unicast burst was completed. In this case, the updated request message can trigger a new unicast burst, and by then if the RTP_Rx has already started receiving multicast data, a congestion is likely to occur. In this case, the RTP_Rx can detect this only after a delay, and then it can try to terminate the new burst. However, in the meantime, the RTP_Rx can experience packet loss or other problems. This and other similar corner cases SHOULD be carefully examined if updated requests are to be used.
これは、RTP_RXの実装依存の決定であり、更新されたリクエストを送信するかどうかです。ただし、最初のユニキャストバーストが完了した後、更新されたリクエストメッセージが遅れてBRSに到達する可能性があることに注意してください。この場合、更新されたリクエストメッセージは新しいユニキャストバーストをトリガーする可能性があり、それまでにRTP_RXがすでにマルチキャストデータの受信を開始している場合、うっ血が発生する可能性があります。この場合、RTP_RXは遅延後にのみこれを検出でき、新しいバーストを終了しようとすることができます。ただし、その間に、RTP_RXはパケットの損失またはその他の問題を経験する可能性があります。更新されたリクエストを使用する場合は、これと他の同様のコーナーケースを慎重に調べる必要があります。
6. Updated Response: The BRS can send more than one RAMS-I message in the unicast burst RTP session, e.g., to update the value of one or more fields in an earlier RAMS-I message. The updated RAMS-I messages might or might not be a direct response to a RAMS-R message. The BRS can also send updated RAMS-I messages to signal the RTP_Rx in real time to join the SSM session when the BRS had already sent an initial RAMS-I message, e.g., at the start of the burst. The RTP_Rx depends on the BRS to learn the join time, which can be conveyed by the first RAMS-I message or can be sent/revised in a later RAMS-I message. If the BRS is not capable of determining the join time in the initial RAMS-I message, the BRS MUST send another RAMS-I message (with the join time information) later.
6. 更新された応答：BRSは、ユニキャストバーストRTPセッションで複数のRams-Iメッセージを送信できます。たとえば、以前のRams-Iメッセージで1つ以上のフィールドの値を更新できます。更新されたRAMS-Iメッセージは、RAMS-Rメッセージに対する直接的な応答である場合とそうでない場合があります。BRSは、更新されたRAMS-Iメッセージを送信してRTP_RXをリアルタイムで信号してSSMセッションに参加して、BRSが初期のRAMS-Iメッセージ、たとえばバーストの開始時に送信していたときにSSMセッションに参加することもできます。RTP_RXはBRSに依存して参加時間を学習します。これは、最初のRams-Iメッセージで伝えることができます。BRSが最初のRams-Iメッセージの結合時間を決定できない場合、BRSは後で別のRams-Iメッセージ（結合時間情報付き）を送信する必要があります。
7. Multicast Join Signaling: The RAMS-I message allows the BRS to signal explicitly when the RTP_Rx needs to send the SFGMP Join message. The RTP_Rx SHOULD use this information from the most recent RAMS-I message unless it has more accurate information. If the request is accepted, this information MUST be conveyed in at least one RAMS-I message, and its value MAY be updated by subsequent RAMS-I messages.
7. マルチキャスト結合シグナリング：RAMS-Iメッセージにより、RTP_RXがSFGMP参加メッセージを送信する必要がある場合、BRSが明示的に信号を送信できます。RTP_RXは、より正確な情報がない限り、最新のRAMS-Iメッセージからこの情報を使用する必要があります。リクエストが受け入れられた場合、この情報は少なくとも1つのRams-Iメッセージで伝えられ、その値は後続のRams-Iメッセージによって更新される場合があります。
There can be missing packets if the RTP_Rx joins the multicast session too early or too late. For example, if the RTP_Rx starts receiving the primary multicast stream while it is still receiving the unicast burst at a high excess bitrate, this can result in an increased risk of packet loss. Or, if the RTP_Rx joins the multicast session some time after the unicast burst is finished, there can be a gap between the burst and multicast data (a number of RTP packets might be missing). In both cases, the RTP_Rx can issue retransmission requests (via RTCP NACK messages sent as unicast feedback in the primary multicast RTP session) [RFC4585] to the FT entity of the RS to fill the gap. The BRS might or might not respond to such requests. When it responds and the response causes significant changes in one or more values reported earlier to the RTP_Rx, an updated RAMS-I SHOULD be sent to the RTP_Rx.
RTP_RXがマルチキャストセッションに早すぎたり遅すぎたりすると、パケットが欠落している可能性があります。たとえば、rtp_rxが単キャストバーストを受けている間にプライマリマルチキャストストリームの受信を開始している場合、これによりパケット損失のリスクが高くなる可能性があります。または、Unicastバーストが終了してからしばらくしてRTP_RXがマルチキャストセッションに参加した場合、バーストデータとマルチキャストデータの間にギャップがある可能性があります（多くのRTPパケットが欠落している可能性があります）。どちらの場合も、RTP_RXは再送信要求（プライマリマルチキャストRTPセッションでユニキャストフィードバックとして送信されたRTCP NACKメッセージを介して）[RFC4585]をRSのFTエンティティに発行してギャップを埋めることができます。BRSは、そのようなリクエストに応答する場合としない場合があります。それが応答し、応答がRTP_RXに以前に報告された1つ以上の値に大きな変化を引き起こす場合、更新されたRAMS-IをRTP_RXに送信する必要があります。
8. Multicast Receive: After the join, the RTP_Rx starts receiving the primary multicast stream(s).
8. マルチキャスト受信：結合後、RTP_RXはプライマリマルチキャストストリームの受信を開始します。
9. Terminate: The BRS can know when it needs to ultimately stop the unicast burst based on its parameters. However, the RTP_Rx may need to ask the BRS to terminate the burst prematurely or at a specific sequence number. For this purpose, the RTP_Rx uses the RAMS Termination (RAMS-T) message sent as RTCP feedback in the unicast burst RTP session. A separate RAMS-T message is sent for each primary multicast stream served by the BRS unless an RTCP BYE message has been sent in the unicast burst RTP session as described in Step 10. For the burst requests that were rejected by the BRS, there is no need to send a RAMS-T message.
9. 終了：BRSは、パラメーターに基づいてユニキャストバーストを最終的に停止する必要があることを知ることができます。ただし、RTP_RXは、BRSにバーストを早期または特定のシーケンス番号で終了するように依頼する必要がある場合があります。この目的のために、RTP_RXは、ユニキャストバーストRTPセッションでRTCPフィードバックとして送信されたRAMS終端（RAMS-T）メッセージを使用します。ステップ10で説明されているように、Unicast Burst RTPセッションでRTCP Byeメッセージが送信されない限り、BRSが提供するプライマリマルチキャストストリームごとに別のRAMS-Tメッセージが送信されます。BRSによって拒否されたバーストリクエストについては、Rams-Tメッセージを送信する必要はありません。
If the RTP_Rx wants to terminate a burst prematurely, it MUST send a RAMS-T message for the SSRC of the primary multicast stream it wishes to terminate. This message is sent in the unicast burst RTP session. Upon receiving this message, the BRS MUST terminate the unicast burst. If the RTP_Rx requested to acquire the entire primary multicast RTP session but wants to terminate this request before it learns the individual media sender SSRC(s) via RAMS-I message(s) or RTP packets, the RTP_Rx cannot use RAMS-T message(s) and thus MUST send an RTCP BYE message in the unicast burst RTP session to terminate the request.
RTP_RXがバーストを早期に終了したい場合、終了したいプライマリマルチキャストストリームのSSRCにRAMS-Tメッセージを送信する必要があります。このメッセージは、ユニキャストバーストRTPセッションで送信されます。このメッセージを受信すると、BRSはユニキャストバーストを終了する必要があります。RTP_RXがプライマリマルチキャストRTPセッション全体の取得を要求したが、RAMS-IメッセージまたはRTPパケットを介して個々のメディアセンダーSSRCを学習する前にこのリクエストを終了したい場合、RTP_RXはRAMS-Tメッセージを使用できません（s）したがって、リクエストを終了するために、ユニキャストバーストRTPセッションでRTCP Byeメッセージを送信する必要があります。
Otherwise, the default behavior for the RTP_Rx is to send a RAMS-T message in the unicast burst RTP session immediately after it joins the multicast session and has started receiving multicast packets. In that case, the RTP_Rx MUST send a RAMS-T message with the sequence number of the first RTP packet received in the primary multicast stream. Then, the BRS MUST terminate the respective burst after it sends the unicast burst packet whose Original Sequence Number (OSN) field in the RTP retransmission payload header matches this number minus one. If the BRS has already sent that unicast burst packet when the RAMS-T message arrives, the BRS MUST terminate the respective burst immediately.
それ以外の場合、RTP_RXのデフォルトの動作は、マルチキャストセッションに参加してマルチキャストパケットの受信を開始した直後に、ユニキャストバーストRTPセッションでRAMS-Tメッセージを送信することです。その場合、RTP_RXは、プライマリマルチキャストストリームで受信した最初のRTPパケットのシーケンス番号でRAMS-Tメッセージを送信する必要があります。次に、BRSは、RTP再送信ペイロードヘッダーの元のシーケンス番号（OSN）フィールドがこの数値を引いたものと一致するユニキャストバーストパケットを送信した後、それぞれのバーストを終了する必要があります。RAMS-Tメッセージが届いたときにBRSがすでにそのユニキャストバーストパケットを送信している場合、BRSはそれぞれのバーストをすぐに終了する必要があります。
If an RTCP BYE message has not been issued yet as described in Step 10, the RTP_Rx MUST send at least one RAMS-T message for each primary multicast stream served by the BRS. The RAMS-T message(s) MUST be sent to the BRS in the unicast burst RTP session. Against the possibility of a message loss, it is RECOMMENDED that the RTP_Rx repeats the RAMS-T messages multiple times as long as it follows the RTCP timer rules defined in [RFC4585].
ステップ10で説明されているように、RTCP Byeメッセージがまだ発行されていない場合、RTP_RXは、BRSが提供する各プライマリマルチキャストストリームに対して少なくとも1つのRAMS-Tメッセージを送信する必要があります。Rams-Tメッセージは、Unicast Burst RTPセッションのBRSに送信する必要があります。メッセージの損失の可能性に対して、RTP_RXは、[RFC4585]で定義されているRTCPタイマールールに従う限り、RAMS-Tメッセージを複数回繰り返すことをお勧めします。
The binding between RAMS-T and ongoing bursts is achieved through RTP_Rx's CNAME identifier and packet sender and media sender SSRCs. Choosing a globally unique CNAME makes sure that the RAMS-T messages are processed correctly.
RAMS-Tと進行中のバーストの間のバインディングは、RTP_RXのCNAME識別子およびパケット送信者およびメディアセンダーSSRCSを通じて達成されます。グローバルに一意のCNAMEを選択すると、RAMS-Tメッセージが正しく処理されていることを確認します。
10. Terminate with RTCP BYE: When the RTP_Rx is receiving one or more burst streams, if the RTP_Rx becomes no longer interested in acquiring any of the primary multicast streams, the RTP_Rx SHALL issue an RTCP BYE message for the unicast burst RTP session and another RTCP BYE message for the primary multicast RTP session. These RTCP BYE messages are sent to the BRS and FT logical entities, respectively.
10. RTCP BYEで終了：RTP_RXが1つ以上のバーストストリームを受信している場合、RTP_RXがプライマリマルチキャストストリームの取得に関心がなくなった場合、RTP_RXはUnicastバーストRTPセッションと別のRTCP ByEBY ByEBYのRTCP Byeメッセージを発行するものとします。プライマリマルチキャストRTPセッションのメッセージ。これらのRTCP Byeメッセージは、それぞれBRSおよびFT論理エンティティに送信されます。
Upon receiving an RTCP BYE message, the BRS MUST terminate the rapid acquisition operation and cease transmitting any further burst packets and retransmission packets. If support for [RFC5506] has been signaled, the RTCP BYE message MAY be sent in a reduced-size RTCP packet. Otherwise, Section 6.1 of [RFC3550] mandates the RTCP BYE message always be sent with a sender or receiver report in a compound RTCP packet. If no data has been received, an empty receiver report MUST be still included. With the information contained in the receiver report, the RS can figure out how many duplicate RTP packets have been delivered to the RTP_Rx (note that this will be an upper-bound estimate as one or more packets might have been lost during the burst transmission). The impact of duplicate packets and measures that can be taken to minimize the impact of receiving duplicate packets will be addressed in Section 6.4.
RTCP Byeメッセージを受信すると、BRSは迅速な取得操作を終了し、バーストパケットと再送信パケットの送信を停止する必要があります。[RFC5506]のサポートがシグナルになっている場合、RTCP Byeメッセージは、縮小サイズのRTCPパケットで送信される場合があります。それ以外の場合、[RFC3550]のセクション6.1は、RTCP Byeメッセージを、化合物RTCPパケットの送信者または受信者レポートで常に送信することを義務付けています。データが受信されていない場合は、空の受信者レポートをまだ含める必要があります。レシーバーレポートに含まれる情報を使用すると、RSはRTP_RXに配信された重複したRTPパケットの数を把握できます（バースト送信中に1つ以上のパケットが失われた可能性があるため、これは上限の推定値になることに注意してください）。重複したパケットと、重複パケットの受信の影響を最小限に抑えるために取ることができる測定の影響については、セクション6.4で説明します。
Since an RTCP BYE message issued for the unicast burst RTP session terminates that session and ceases transmitting any further packets in that session, there is no need for sending explicit RAMS-T messages, which would only terminate their respective bursts.
ユニキャストバーストRTPセッションに対して発行されたRTCPバイのメッセージは、そのセッションを終了し、そのセッションでそれ以上のパケットの送信を停止するため、それぞれのバーストのみを終了する明示的なRAMS-Tメッセージを送信する必要はありません。
For the purpose of gathering detailed information about RTP_Rx's rapid acquisition experience, [MULTICAST-ACQ] defines an RTCP Extended Report (XR) Block. This report is designed to be payload-independent; thus, it can be used by any multicast application that supports rapid acquisition.
RTP_RXの迅速な買収エクスペリエンスに関する詳細情報を収集する目的で、[Multicast-ACQ]はRTCP拡張レポート（XR）ブロックを定義します。このレポートは、ペイロードに依存しないように設計されています。したがって、迅速な獲得をサポートするマルチキャストアプリケーションでは使用できます。
When an RTP_RX acquires multiple primary multicast streams, it might need to synchronize them for playout. This synchronization is achieved by the help of the RTCP sender reports [RFC3550]. If the playout will start before the RTP_Rx has joined the multicast session, the RTP_Rx needs to receive the information reflecting the synchronization among the primary multicast streams early enough so that it can play out the media in a synchronized fashion.
RTP_RXが複数のプライマリマルチキャストストリームを取得する場合、プレイアウト用に同期する必要がある場合があります。この同期は、RTCP送信者レポート[RFC3550]の助けによって達成されます。RTP_RXがマルチキャストセッションに参加する前にプレイアウトが開始される場合、RTP_RXは、プライマリマルチキャストストリーム間の同期を反映した情報を、同期したファッションでメディアを再生できるようにする必要があります。
The suggested approach is to use the RTP header extension mechanism [RFC5285] and convey the synchronization information in a header extension as defined in [RFC6051]. Per [RFC4588], "if the original RTP header carried an RTP header extension, the retransmission packet SHOULD carry the same header extension". Thus, as long as the multicast source emits a header extension with the synchronization information frequently enough, there is no additional task that needs to be carried out by the BRS. The synchronization information will be sent to the RTP_Rx along with the burst packets. The frequent header extensions sent in the primary multicast RTP sessions also allow rapid synchronization of the RTP streams for the RTP receivers that do not support RAMS or that directly join the multicast session without running RAMS. Thus, in RAMS applications, it is RECOMMENDED that the multicast sources frequently send synchronization information by using header extensions following the rules presented in [RFC6051]. The regular sender reports are still sent in the unicast session by following the rules of [RFC3550].
推奨されるアプローチは、RTPヘッダー拡張メカニズム[RFC5285]を使用し、[RFC6051]で定義されているヘッダー拡張機能の同期情報を伝えることです。[RFC4588]に従って、「元のRTPヘッダーがRTPヘッダー拡張機能を搭載した場合、再送信パケットは同じヘッダー拡張機能を搭載する必要があります」。したがって、マルチキャストソースが同期情報を使用してヘッダー拡張機能を発している限り、BRSが実行する必要がある追加タスクはありません。同期情報は、バーストパケットとともにRTP_RXに送信されます。プライマリマルチキャストRTPセッションで送信される頻繁なヘッダー拡張機能により、RAMSをサポートしていないRTPレシーバーやRAMを実行せずにマルチキャストセッションに直接参加するRTPレシーバーのRTPストリームの迅速な同期も可能になります。したがって、RAMSアプリケーションでは、[RFC6051]で提示されたルールに従ってヘッダー拡張機能を使用して、マルチキャストソースが同期情報を頻繁に送信することをお勧めします。通常の送信者レポートは、[RFC3550]のルールに従ってユニキャストセッションで引き続き送信されます。
This section provides informative guidelines about how the BRS can shape the transmission of the unicast burst and how congestion can be dealt with in the RAMS process. When the RTP_Rx detects that the unicast burst is causing severe congestion, it can prefer to send a RAMS-T message immediately to stop the unicast burst.
このセクションでは、BRSがユニキャストバーストの伝達をどのように形成できるか、およびRAMSプロセスで混雑をどのように処理できるかについての有益なガイドラインを提供します。RTP_RXがユニキャストバーストが深刻な輻輳を引き起こしていることを検出すると、ユニキャストバーストを停止するためにすぐにRAMS-Tメッセージを送信することを好むことができます。
A higher bitrate for the unicast burst naturally conveys the Reference Information and media content to the RTP_Rx faster. This way, the RTP_Rx can start consuming the data sooner, which results in a faster acquisition. A higher bitrate also represents a better utilization of the BRS resources. As the burst may continue until it catches up with the primary multicast stream, the higher the bursting bitrate, the less data the BRS needs to transmit. However, a higher bitrate for the burst also increases the chances for congestion-caused packet loss. Thus, as discussed in Section 5, there has to be an upper bound on the bandwidth used by the burst.
ユニキャストバーストのより高いビットレートは、リファレンス情報とメディアコンテンツをRTP_RXに自然に速く伝えます。このようにして、RTP_RXはより早くデータの消費を開始できるため、獲得が速くなります。また、より高いビットレートは、BRSリソースのより良い利用を表しています。バーストがプライマリマルチキャストストリームに追いつくまで続く可能性があるため、バーストビットレートが高くなるほど、BRSが送信する必要があるデータは少なくなります。ただし、バーストのビットレートが高いほど、混雑が原因でパケットの損失の可能性が高まります。したがって、セクション5で説明したように、バーストで使用される帯域幅に上限が必要です。
When the BRS transmits the unicast burst, it is expected to take into account all available information to prevent any packet loss that might take place during the bursting as a result of buffer overflow on the path between the RS and RTP_Rx and at the RTP_Rx itself. The bursting bitrate can be determined by taking into account the following information, when available:
BRSがユニキャストバーストを送信すると、RSとRTP_RXの間のパスでのバッファーオーバーフローの結果としてバースト中に発生する可能性のあるパケット損失を防ぐために、利用可能なすべての情報を考慮に入れることが期待されます。破裂ビットレートは、利用可能な場合は次の情報を考慮して決定できます。
(a) Information obtained via the RAMS-R message, such as Max RAMS Buffer Fill Requirement and/or Max Receive Bitrate (see Section 7.2).
(a) Max Rams Buffer Fill要件やMaxを受信するなど、RAMS-Rメッセージを介して取得された情報（セクション7.2を参照）。
(b) Information obtained via RTCP receiver reports provided by the RTP_Rx in the retransmission session, allowing in-session bitrate adaptations for the burst. When these receiver reports indicate packet loss, this can indicate a certain congestion state in the path from the RS to the RTP_Rx.
(b) 再送信セッションでRTP_RXによって提供されたRTCPレシーバーレポートを介して得られた情報が得られ、バーストのセッション内ビットレートの適応が可能になります。これらのレシーバーレポートがパケットの損失を示している場合、これはRSからRTP_RXまでのパス内の特定の混雑状態を示すことができます。
(c) Information obtained via RTCP NACKs provided by the RTP_Rx in the primary multicast RTP session, allowing in-session bitrate adaptations for the burst. Such RTCP NACKs are transmitted by the RTP_Rx in response to packet loss detection in the burst. NACKs can indicate a certain congestion state on the path from the RS to RTP_Rx.
(c) プライマリマルチキャストRTPセッションでRTP_RXによって提供されたRTCP NACKを介して取得された情報により、バーストのセッション内ビットレート適応が可能になります。このようなRTCP NACKは、バーストでのパケット損失検出に応じてRTP_RXによって送信されます。Nacksは、RSからRTP_RXまでのパス上の特定の混雑状態を示すことができます。
(d) There can be other feedback received from the RTP_Rx, e.g., in the form of Explicit Congestion Notification - Congestion Experienced (ECN-CE) markings [ECN-FOR-RTP] that can influence in-session bitrate adaptation.
(d) rtp_rxから受け取った他のフィードバックは、たとえば、セッション内ビットレートの適応に影響を与える可能性のある明示的なうっ血通知 - 経験豊富な（ECN-CE）マーキング[ECN-for-RTP]の形で受け取ることができます。
(e) Information obtained via updated RAMS-R messages, allowing in-session bitrate adaptations, if supported by the BRS.
(e) 更新されたRAMS-Rメッセージを介して取得された情報。BRSによってサポートされている場合、セッション内ビットレートの適応が可能になります。
(f) Transport protocol-specific information. For example, when Datagram Congestion Control Protocol (DCCP) is used to transport the RTP burst, the ACKs from the DCCP client can be leveraged by the BRS / DCCP server for burst shaping and congestion control.
(f) 輸送プロトコル固有の情報。たとえば、データグラムの混雑制御プロトコル（DCCP）を使用してRTPバーストの輸送に使用すると、DCCPクライアントのACKをBRS / DCCPサーバーでレバレッジでき、バーストシェーピングと輻輳制御ができます。
(g) Preconfigured settings for each RTP_Rx or a set of RTP_Rxs that indicate the upper-bound bursting bitrates for which no packet loss will occur as a result of congestion along the path of the RS to RTP_Rx. For example, in managed IPTV networks, where the bottleneck bandwidth along the end-to-end path is known and where the network between the RS and this link is provisioned and dimensioned to carry the burst streams, the bursting bitrate does not exceed the provisioned value. These settings can also be dynamically adapted using application-aware knowledge.
(g) 各RTP_RXの事前に設定された設定またはRSの経路に沿った輻輳の結果としてパケット損失が発生しない上限バーストビットレートを示すRTP_RXSのセット。たとえば、マネージドIPTVネットワークでは、エンドツーエンドパスに沿ったボトルネックの帯域幅が知られており、RSとこのリンク間のネットワークがバーストストリームを運ぶようにプロビジョニングおよび寸法化されている場合、バーストビットレートはプロビジョニング付きのプロビジョニングを超えません価値。これらの設定は、アプリケーション認識の知識を使用して動的に調整することもできます。
The BRS chooses the initial burst bitrate as follows:
BRSは、次のように初期バーストビットレートを選択します。
o When using RAMS in environments as described in (g), the BRS MUST transmit the burst packets at an initial bitrate higher than the nominal bitrate but within the engineered or reserved bandwidth limit.
o （g）に記載されている環境でRAMSを使用する場合、BRSは、名目ビットレートよりも高い初期ビットレートで、エンジニアリングまたは予約された帯域幅の制限内でバーストパケットを送信する必要があります。
o When the BRS cannot determine a reliable bitrate value for the unicast burst (using (a) through (g)), it is desirable for the BRS to choose an appropriate initial bitrate not above the nominal bitrate and increase it gradually unless a congestion is detected.
o BRSがユニキャストバーストの信頼できるビットレート値を決定できない場合（（a）〜（g）を使用）、BRSが公称ビットレートを超えない適切な初期ビットレートを選択し、混雑が検出されない限り徐々に増加することが望ましい。
In both cases, during the burst transmission, the BRS MUST continuously monitor for packet losses as a result of congestion by means of one or more of the mechanisms described in (b) through (f). When the BRS relies on RTCP receiver reports, sufficient bandwidth needs to be provided to RTP_Rx for RTCP transmission in the unicast burst RTP session. To achieve a reasonable fast adaptation against congestion, it is recommended that the RTP_Rx sends a receiver report at least once every two RTTs between the RS and RTP_Rx. Although the specific heuristics and algorithms that deduce a congestion state and how the BRS acts subsequently are outside the scope of this specification, the following two methods are the best practices:
どちらの場合も、バースト伝送中に、BRSは（b）〜（f）に記載されている1つ以上のメカニズムを使用して、混雑の結果としてパケット損失を継続的に監視する必要があります。BRSがRTCPレシーバーレポートに依存している場合、ユニキャストバーストRTPセッションでRTCP伝送のためにRTP_RXに十分な帯域幅を提供する必要があります。混雑に対する合理的な迅速な適応を実現するには、RTP_RXがRSとRTP_RXの間に少なくとも2回のRTTにレシーバーレポートを送信することをお勧めします。混雑状態を推定する特定のヒューリスティックとアルゴリズムと、BRSがその後この仕様の範囲外にある方法を推定するものですが、次の2つの方法がベストプラクティスです。
o Upon detection of a significant amount of packet loss, which the BRS attributes to congestion, the BRS decreases the burst bitrate. The rate by which the BRS increases and decreases the bitrate for the burst can be determined by a TCP-friendly bitrate adaptation algorithm for RTP over UDP or, in the case of (f), by the congestion control algorithms defined in DCCP [RFC5762].
o BRSが混雑に起因するかなりの量のパケット損失を検出すると、BRSはバーストビットレートを減少させます。BRSがバーストのビットレートを増加および減少させる速度は、UDPを介したRTPのTCPフレンドリーなビットレート適応アルゴリズム、または（F）の場合、DCCP [RFC5762]で定義されている混雑制御アルゴリズムによって決定できます。。
o If the congestion is persistent and the BRS has to reduce the burst bitrate to a point where the RTP_Rx buffer might underrun or the burst will consume too many resources, the BRS terminates the burst and transmits a RAMS-I message to RTP_Rx with the appropriate response code. It is then up to RTP_Rx to decide when to join the multicast session.
o 混雑が持続し、BRSがバーストビットレートをRTP_RXバッファーがアンダーランするか、バーストがあまりにも多くのリソースを消費するポイントに減らす必要がある場合、BRSはバーストを終了し、適切な応答でRTP_RXにRAMS-Iメッセージを送信します。コード。その後、マルチキャストセッションにいつ参加するかを決定するのはRTP_RXまでです。
Even though there is no congestion experienced during the burst, congestion may anyway arise near the end of the burst as the RTP_Rx eventually needs to join the multicast session. During this brief period, both the burst packets and the multicast packets can be simultaneously received by the RTP_Rx, thus enhancing the risk of congestion.
バースト中に輻輳は発生していませんが、RTP_RXが最終的にマルチキャストセッションに参加する必要があるため、とにかくバーストの終わり近くに混雑が発生する可能性があります。この短い期間中、バーストパケットとマルチキャストパケットの両方を同時にRTP_RXが受信できるため、混雑のリスクが高まります。
Since the BRS signals the RTP_Rx when the BRS expects the RTP_Rx to send the SFGMP Join message, the BRS can have a rough estimate of when the RTP_Rx will start receiving multicast packets in the SSM session. The BRS can keep on sending burst packets but reduces the bitrate accordingly at the appropriate instant by taking the bitrate of the whole SSM session into account. If the BRS ceases transmitting the burst packets before the burst catches up, any gap resulting from this imperfect switch-over by the RTP_Rx can be later repaired by requesting retransmissions for the missing packets from the RS. The retransmissions can be shaped by the BRS to make sure that they do not cause collateral loss in the primary multicast RTP session and the unicast burst RTP session.
BRSはRTP_RXにSFGMPの結合メッセージを送信するRTP_RXがRTP_RXに信号を送るため、BRSはRTP_RXがSSMセッションでマルチキャストパケットの受信を開始するときの大まかな推定値を持つことができます。BRSはバーストパケットを送信し続けることができますが、SSMセッション全体のビットレートを考慮して、適切な瞬間にビットレートを減少させます。BRSがバーストが追いつく前にバーストパケットを送信するのを止めた場合、RSから欠落したパケットの再送信を要求することにより、RTP_RXによるこの不完全なスイッチオーバーから生じるギャップを後で修復できます。再送信は、BRSによって形成され、プライマリマルチキャストRTPセッションとユニキャストバーストRTPセッションで付随的な損失を引き起こさないことを確認できます。
In this section, we examine the implications of losing the RAMS-R, RAMS-I, or RAMS-T messages and other failure cases.
このセクションでは、Rams-R、Rams-I、またはRams-Tメッセージおよびその他の障害のケースを失うことの意味を調べます。
When the RTP_Rx sends a RAMS-R message to initiate a rapid acquisition but the message gets lost and the FT does not receive it, the RTP_Rx will get neither a RAMS-I message nor a unicast burst. In this case, the RTP_Rx MAY resend the request when it is eligible to do so based on the RTCP timer rules defined in [RFC4585]. Or, after a reasonable amount of time, the RTP_Rx can time out (based on the previous observed response times) and immediately join the SSM session.
RTP_RXがRAMS-Rメッセージを送信して迅速な買収を開始するが、メッセージが失われ、FTがそれを受け取らない場合、RTP_RXはRAMS-Iメッセージもユニキャストバーストも取得しません。この場合、RTP_RXは、[RFC4585]で定義されているRTCPタイマールールに基づいてそうする資格がある場合、リクエストを再送信できます。または、合理的な時間の後、RTP_RXは（以前の観測された応答時間に基づいて）タイムアウトし、すぐにSSMセッションに参加できます。
In the case where RTP_Rx starts receiving a unicast burst but does not receive a corresponding RAMS-I message within a reasonable amount of time, the RTP_Rx can either discard the burst data or decide not to interrupt the unicast burst and be prepared to join the SSM session at an appropriate time it determines or as indicated in a subsequent RAMS-I message (if available). If the network is subject to packet loss, it is RECOMMENDED that the BRS repeats the RAMS-I messages multiple times based on the RTCP timer rules defined in [RFC4585].
RTP_RXがユニキャストバーストの受信を開始し始めたが、合理的な時間内に対応するRAMS-Iメッセージを受信しない場合、RTP_RXはバーストデータを破棄するか、ユニキャストバーストを中断しないことを決定し、SSMに参加する準備をすることができますセッションそれが決定する適切な時期に、またはその後のRams-Iメッセージ（利用可能な場合）で示されているようにセッション。ネットワークがパケット損失の対象となる場合、BRSは[RFC4585]で定義されているRTCPタイマールールに基づいて、RAMS-Iメッセージを複数回繰り返すことをお勧めします。
In the failure cases where the RAMS-I message is lost or the RAMS-R message is lost and the RTP_Rx gives up, the RTP_Rx MUST still terminate the burst(s) it requested by following the rules described in Section 6.2.
RAMS-Iメッセージが失われるか、RAMS-Rメッセージが失われ、RTP_RXがgives折る障害の場合、RTP_RXは、セクション6.2で説明されている規則に従って要求されたバーストを終了する必要があります。
In the case where a RAMS-T message sent by the RTP_Rx does not reach its destination, the BRS can continue sending burst packets even though the RTP_Rx no longer needs them. If an RTP_Rx is receiving burst packets it no longer needs after sending a RAMS-T message, it is RECOMMENDED that the RTP_Rx repeats the RAMS-T message multiple times based on the RTCP timer rules defined in [RFC4585]. The BRS MUST be provisioned to terminate the burst when it can no longer send the burst packets faster than it receives the primary multicast stream packets.
RTP_RXによって送信されたRAMS-Tメッセージが宛先に到達しない場合、RTP_RXがそれらを必要としなくなった場合でも、BRSはバーストパケットを送信し続けることができます。RTP_RXがRAMS-Tメッセージを送信した後に必要としないバーストパケットを受信している場合、RTP_RXは[RFC4585]で定義されたRTCPタイマールールに基づいてRAMS-Tメッセージを複数回繰り返すことをお勧めします。BRSは、バーストパケットをプライマリマルチキャストストリームパケットを受信するよりも速く送信できなくなった場合に、バーストを終了するためにプロビジョニングする必要があります。
Section 6.3.5 of [RFC3550] explains the rules pertaining to timing out an SSRC. When the BRS accepts to serve the requested burst(s) and establishes the retransmission session, the BRS needs to check the liveness of the RTP_Rx via the RTCP messages and reports the RTP_Rx sends. The default rules explained in [RFC3550] apply in RAMS as well.
[RFC3550]のセクション6.3.5では、SSRCのタイミングに関連する規則について説明します。BRSが要求されたバーストを提供することを受け入れ、再送信セッションを確立する場合、BRSはRTCPメッセージを介してRTP_RXの活性を確認する必要があり、RTP_RXが送信するRTP_RXの報告を報告する必要があります。[RFC3550]で説明されているデフォルトのルールもRAMSで適用されます。
This section defines the formats of the RTCP transport-layer feedback messages that are exchanged between the retransmission server (RS) and RTP receiver (RTP_Rx) during rapid acquisition. These messages are referred to as the RAMS Messages. They are payload-independent and MUST be used by all RTP-based multicast applications that support rapid acquisition regardless of the payload they carry.
このセクションでは、迅速な取得中に再送信サーバー（RS）とRTPレシーバー（RTP_RX）の間で交換されるRTCP輸送層フィードバックメッセージの形式を定義します。これらのメッセージは、Ramsメッセージと呼ばれます。それらはペイロードに依存しないものであり、携帯するペイロードに関係なく、迅速な獲得をサポートするすべてのRTPベースのマルチキャストアプリケーションで使用する必要があります。
Payload-specific feedback messages are not defined in this document. However, further optional payload-independent and payload-specific information can be included in the exchange.
このドキュメントでは、ペイロード固有のフィードバックメッセージは定義されていません。ただし、さらにオプションのペイロード独立およびペイロード固有の情報を交換に含めることができます。
The common packet format for the RTCP feedback messages is defined in Section 6.1 of [RFC4585] and is also sketched in Figure 4.
RTCPフィードバックメッセージの一般的なパケット形式は、[RFC4585]のセクション6.1で定義されており、図4にもスケッチされています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Figure 4: The Common Packet Format for the RTCP Feedback Messages
図4：RTCPフィードバックメッセージの一般的なパケット形式
Each feedback message has a fixed-length field for version, padding, feedback message type (FMT), packet type (PT), length, SSRC of packet sender, SSRC of media source, and a variable-length field for feedback control information (FCI).
各フィードバックメッセージには、バージョン、パディング、フィードバックメッセージタイプ（FMT）、パケットタイプ（PT）、長さ、パケット送信者のSSRC、メディアソースのSSRC、およびフィードバック制御情報の可変長フィールド（FCI）。
In the RAMS messages, the PT field is set to RTPFB (205) and the FMT field is set to RAMS (6). Individual RAMS messages are identified by a sub-field called sub-feedback message type (SFMT). Any Reserved field SHALL be set to zero and ignored.
RAMSメッセージでは、PTフィールドはRTPFB（205）に設定され、FMTフィールドはRAMS（6）に設定されます。個々のRAMSメッセージは、サブフィードバックメッセージタイプ（SFMT）と呼ばれるサブフィールドによって識別されます。予約済みのフィールドはゼロに設定され、無視されます。
Depending on the specific scenario and timeliness/importance of a RAMS message, it can be desirable to send it in a reduced-size RTCP packet [RFC5506]. However, unless support for [RFC5506] has been signaled, compound RTCP packets MUST be used by following [RFC3550] rules.
特定のシナリオとラムズメッセージの適時性/重要性に応じて、縮小サイズのRTCPパケット[RFC5506]で送信することが望ましい場合があります。ただし、[RFC5506]のサポートが合図されていない限り、[RFC3550]ルールに従うことにより、化合物RTCPパケットを使用する必要があります。
Following the rules specified in [RFC3550], all integer fields in the messages defined below are carried in network-byte order, that is, most significant byte (octet) first, also known as big-endian. Unless otherwise stated, numeric constants are in decimal (base 10).
[RFC3550]で指定されたルールに従って、以下に定義されたメッセージのすべての整数フィールドは、ネットワークバイト順序で運ばれます。つまり、最も重要なバイト（Octet）が最初に、Big-Endianとしても知られています。特に明記しない限り、数値定数は10進数です（ベース10）。
To improve the functionality of the RAMS method in certain applications, it can be desirable to define new fields in the RAMS Request, Information, and Termination messages. Such fields MUST be encoded as Type-Length-Value (TLV) elements as described below and sketched in Figure 5:
特定のアプリケーションでRAMSメソッドの機能を改善するには、RAMSリクエスト、情報、および終了メッセージの新しいフィールドを定義することが望ましい場合があります。このようなフィールドは、以下に説明し、図5にスケッチするように、型長値（TLV）要素としてエンコードする必要があります。
o Type: A single-octet identifier that defines the type of the parameter represented in this TLV element.
o タイプ：このTLV要素で表されるパラメーターのタイプを定義する単一オクテット識別子。
o Length: A two-octet field that indicates the length (in octets) of the TLV element excluding the Type and Length fields and the 8-bit Reserved field between them. This length does not include any padding that is required for alignment.
o 長さ：TLV要素の長さ（オクテット内）を、タイプと長さのフィールドとそれらの間の8ビット予約フィールドを除く2オクテットのフィールド。この長さには、アライメントに必要なパディングは含まれていません。
o Value: Variable-size set of octets that contains the specific value for the parameter.
o 値：パラメーターの特定の値を含むオクテットの可変サイズセット。
In the extensions, the Reserved field SHALL be set to zero and ignored. If a TLV element does not fall on a 32-bit boundary, the last word MUST be padded to the boundary using further bits set to zero.
拡張機能では、予約済みフィールドはゼロに設定され、無視されます。TLV要素が32ビットの境界に当てはまらない場合、最後の単語は、さらにゼロに設定されたビットを使用して境界にパディングする必要があります。
An RTP_Rx or BRS MAY include vendor-neutral and private extensions in any RAMS message. The RTP_Rx or BRS MUST place such extensions after the mandatory fields and mandatory TLV elements (if any) and MAY place such extensions in any order. The RTP_Rx or BRS MUST NOT include multiple TLV elements with the same Type value in a RAMS message.
RTP_RXまたはBRSには、RAMSメッセージにベンダー中立およびプライベートエクステンションが含まれる場合があります。RTP_RXまたはBRSは、必須フィールドと必須のTLV要素（ある場合）の後にこのような拡張機能を配置する必要があり、そのような拡張機能を任意の順序で配置する必要があります。RTP_RXまたはBRSには、RAMSメッセージに同じタイプ値を持つ複数のTLV要素を含めてはなりません。
The support for extensions (unless specified otherwise) is OPTIONAL. An RTP_Rx or BRS receiving a vendor-neutral or private extension that it does not understand MUST ignore that extension.
拡張機能のサポートは（特に指定されていない限り）オプションです。理解できないベンダーの中立またはプライベートエクステンションを受け取るRTP_RXまたはBRSは、その拡張機能を無視する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Structure of a TLV Element
図5：TLV要素の構造
If the goal in defining new TLV elements is to extend the functionality in a vendor-neutral manner, they MUST be registered with IANA through the guidelines provided in Section 11.5.
新しいTLV要素を定義する目標が、機能をベンダーに中立な方法で拡張することである場合、セクション11.5で提供されるガイドラインを通じてIANAに登録する必要があります。
The current document defines several vendor-neutral extensions in the subsequent sections.
現在のドキュメントでは、後続のセクションでいくつかのベンダー中立拡張機能を定義しています。
It is desirable to allow vendors to use private extensions in a TLV format. For interoperability, such extensions must not collide with each other.
ベンダーがTLV形式でプライベート拡張機能を使用できるようにすることが望ましいです。相互運用性のために、このような拡張機能は互いに衝突してはなりません。
A certain range of TLV Types (between and including 128 and 254 ) is reserved for private extensions (refer to Section 11.5). IANA management for these extensions is unnecessary, and they are the responsibility of individual vendors.
特定の範囲のTLVタイプ（128と254を含む）は、プライベートエクステンション用に予約されています（セクション11.5を参照）。これらの拡張機能のIANA管理は不要であり、個々のベンダーの責任です。
The structure that MUST be used for the private extensions is depicted in Figure 6. Here, the enterprise numbers are as listed on http://www.iana.org. This will ensure the uniqueness of the private extensions and avoid any collision.
プライベートエクステンションに使用する必要がある構造を図6に示します。ここでは、エンタープライズ数はhttp://www.iana.orgにリストされています。これにより、プライベートエクステンションの独自性が確保され、衝突を回避できます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Structure of a Private Extension
図6：プライベートエクステンションの構造
The RAMS Request (RAMS-R) message is identified by SFMT=1. This message is sent as unicast feedback in the primary multicast RTP session by the RTP_Rx to request rapid acquisition of a primary multicast RTP session or one or more primary multicast streams belonging to the same primary multicast RTP session. In the RAMS-R message, the RTP_Rx MUST set both the packet sender SSRC and media sender SSRC fields to its own SSRC since the media sender SSRC may not be known. The RTP_Rx MUST provide explicit signaling as described below to request stream(s). This minimizes the chances of accidentally requesting a wrong primary multicast stream.
RAMSリクエスト（RAMS-R）メッセージは、SFMT = 1で識別されます。このメッセージは、RTP_RXによってプライマリマルチキャストRTPセッションでユニキャストフィードバックとして送信され、プライマリマルチキャストRTPセッションまたは同じプライマリマルチキャストRTPセッションに属する1つ以上のプライマリマルチキャストストリームの迅速な取得を要求します。RAMS-Rメッセージでは、RTP_RXは、メディア送信者SSRCが知られていないため、パケット送信者SSRCとメディア送信者SSRCフィールドの両方を独自のSSRCに設定する必要があります。RTP_RXは、以下に説明するように、ストリームを要求するために明示的なシグナリングを提供する必要があります。これにより、間違ったプライマリマルチキャストストリームを誤って要求する可能性が最小限に抑えられます。
The FCI field MUST contain only one RAMS Request. The FCI field has the structure depicted in Figure 7.
FCIフィールドには、1つのRamsリクエストのみを含める必要があります。FCIフィールドには、図7に示されている構造があります。
The semantics of the RAMS-R message is independent of the payload type carried in the primary multicast RTP session.
RAMS-Rメッセージのセマンティクスは、プライマリマルチキャストRTPセッションで運ばれるペイロードタイプとは無関係です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Requested Media Sender SSRC(s) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: FCI Field Syntax for the RAMS Request Message
図7：RAMSリクエストメッセージのFCIフィールド構文
o Requested Media Sender SSRC(s): Mandatory TLV element that lists the media sender SSRC(s) requested by the RTP_Rx. The BRS MUST ignore the media sender SSRC specified in the header of the RAMS-R message.
o 要求されたメディア送信者SSRC（S）：RTP_RXが要求したメディア送信者SSRCをリストする必須のTLV要素。BRSは、RAMS-Rメッセージのヘッダーで指定されたメディア送信者SSRCを無視する必要があります。
If the Length field is set to zero (i.e., no media sender SSRC is listed), it means that the RTP_Rx is requesting to rapidly acquire the entire primary multicast RTP session. Otherwise, the RTP_Rx lists the individual media sender SSRCs in this TLV element and sets the Length field of the TLV element to 4*n, where n is the number of SSRC entries.
長さフィールドがゼロに設定されている場合（つまり、メディアセンダーSSRCがリストされていない）、RTP_RXがプライマリマルチキャストRTPセッション全体を迅速に取得することを要求していることを意味します。それ以外の場合、RTP_RXは、このTLV要素の個々のメディア送信者SSRCをリストし、TLV要素の長さフィールドを4*nに設定します。ここで、nはSSRCエントリの数です。
Type: 1
タイプ：1
o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element that denotes the minimum milliseconds of data that the RTP_Rx desires to have in its buffer before allowing the data to be consumed by the application.
o Min Rams Buffer Fill要件（32ビット）：アプリケーションによってデータを消費する前に、RTP_RXがバッファーに希望するデータの最小ミリ秒を示すオプションのTLV要素。
The RTP_Rx can have knowledge of its buffering requirements. These requirements can be application and/or device specific. For instance, the RTP_Rx might need to have a certain amount of data in its application buffer to handle transmission jitter and/or to be able to support error-control methods. If the BRS is told the minimum buffering requirement of the receiver, the BRS can tailor the burst(s) more precisely, e.g., by choosing an appropriate starting point. The methods used by the RTP_Rx to determine this value are application specific and thus out of the scope of this document.
RTP_RXは、バッファリング要件の知識を持つことができます。これらの要件は、アプリケーションおよび/またはデバイス固有のものです。たとえば、RTP_RXには、送信ジッターを処理したり、エラー制御方法をサポートできるように、アプリケーションバッファーに一定量のデータが必要になる場合があります。BRSが受信機の最小バッファリング要件を通知された場合、BRSは、適切な開始点を選択することにより、より正確にバーストを調整できます。この値を決定するためにRTP_RXで使用される方法は、アプリケーション固有であり、したがってこのドキュメントの範囲外です。
If specified, the amount of backfill that will be provided by the unicast bursts and any payload-specific information MUST NOT be smaller than the specified value. Otherwise, the backfill will not be able to build up the desired level of buffer at the RTP_Rx and can cause buffer underruns.
指定されている場合、ユニキャストバーストとペイロード固有の情報によって提供されるバックフィルの量は、指定された値よりも小さくてはなりません。それ以外の場合、バックフィルはRTP_RXで目的のレベルのバッファーを構築できず、バッファーアンダーランを引き起こす可能性があります。
Type: 2
タイプ：2
o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element that denotes the maximum milliseconds of data that the RTP_Rx can buffer without losing the data due to buffer overflow.
o Max Rams Buffer Fill要件（32ビット）：バッファオーバーフローのためにデータを失うことなくRTP_RXがバッファすることができるデータの最大ミリ秒を示すオプションのTLV要素。
The RTP_Rx can have knowledge of its buffering requirements. These requirements can be application or device specific. For instance, one particular RTP_Rx might have more physical memory than another RTP_Rx and thus can buffer more data. If the BRS knows the buffering ability of the receiver, the BRS can tailor the burst(s) more precisely. The methods used by the receiver to determine this value are application specific and thus out of the scope of this document.
RTP_RXは、バッファリング要件の知識を持つことができます。これらの要件は、アプリケーションまたはデバイス固有のものです。たとえば、ある特定のRTP_RXは、別のRTP_RXよりも多くの物理メモリを持っている可能性があるため、より多くのデータをバッファリングできます。BRSが受信機のバッファリング能力を知っている場合、BRSはバーストをより正確に調整できます。受信機がこの値を決定するために使用する方法はアプリケーション固有であり、したがってこのドキュメントの範囲外です。
If specified, the amount of backfill that will be provided by the unicast bursts and any payload-specific information MUST NOT be larger than this value. Otherwise, the backfill may cause buffer overflows at the RTP_Rx.
指定されている場合、ユニキャストバーストとペイロード固有の情報によって提供されるバックフィルの量は、この値よりも大きくなければなりません。それ以外の場合、埋め戻しはRTP_RXでバッファオーバーフローを引き起こす可能性があります。
Type: 3
タイプ：3
o Max Receive Bitrate (64 bits): Optional TLV element that denotes the maximum bitrate (in bits per second) at which the RTP_Rx can process the aggregation of the unicast burst(s) and any payload-specific information that will be provided by the BRS. The limits can include local receiver limits as well as network limits that are known to the receiver.
o 最大受信ビットレート（64ビット）：RTP_RXがユニキャストバーストの集約とBRSによって提供されるペイロード固有の情報を処理できる最大ビットレート（1秒あたりビット）を示すオプションのTLV要素。制限には、ローカルレシーバーの制限と、受信機に知られているネットワーク制限が含まれます。
If specified, the total bitrate of the unicast burst(s) plus any payload-specific information MUST NOT be larger than this value. Otherwise, congestion and packet loss are more likely to occur.
指定されている場合、ユニキャストバーストの合計ビットレートとペイロード固有の情報は、この値よりも大きくなければなりません。そうしないと、混雑とパケットの損失が発生する可能性が高くなります。
Type: 4
タイプ：4
o Preamble-only Allowed (0 bits): Optional TLV element that indicates that the RTP_Rx is willing to receive only the preamble information for the desired primary multicast stream(s) in case the BRS cannot send the unicast burst stream(s). (In such cases, the BRS will not accept the request, but will send a response code 511 in the RAMS-I message as defined in Section 11.6.) Note that the RTP_Rx signals the particular preamble format(s) it supports through a public or a private extension in the same RAMS-R message.
o PREAMBLEのみの許可（0ビット）：RTP_RXが、BRSがユニキャストバーストストリームを送信できない場合に、目的のプライマリマルチキャストストリームのプリアンブル情報のみを受け取ることをいとわないことを示すオプションのTLV要素。（そのような場合、BRSはリクエストを受け入れませんが、セクション11.6で定義されているRams-Iメッセージに応答コード511を送信します。）RTP_RXは、公開されている特定のプリアンブル形式（s）がサポートする特定のプリアンブル形式を信号していることに注意してください。または同じRAMS-Rメッセージのプライベートエクステンション。
If this TLV element does not exist in the RAMS-R message, the BRS MUST NOT respond to the RAMS-R message by sending the preamble information only. Since this TLV element does not carry a Value field, the Length field MUST be set to zero.
このTLV要素がRAMS-Rメッセージに存在しない場合、BRSはプリアンブル情報のみを送信してRAMS-Rメッセージに応答してはなりません。このTLV要素には値フィールドが含まれていないため、長さフィールドはゼロに設定する必要があります。
Type: 5
タイプ：5
o Supported Enterprise Number(s): Optional TLV element that indicates the enterprise number(s) that the RTP_Rx implementation supports. Similar to the private extensions, the enterprise numbers here are as listed on http://www.iana.org. This TLV element, if exists, provides a hint to the BRS about which private extensions the RTP_Rx can potentially support. Note that an RTP_Rx does not necessarily support all the private extensions under a particular enterprise number. Unless the BRS explicitly knows which private extensions an RTP_Rx supports (through this or some out-of-band means), the BRS SHOULD NOT use private extensions in the RAMS-I messages. The BRS SHOULD rather use only vendor-neutral extensions. The Length field of this TLV element is set to 4*n, where n is the number of enterprise number entries.
o サポートされているエンタープライズ番号：RTP_RX実装がサポートするエンタープライズ番号を示すオプションのTLV要素。プライベートエクステンションと同様に、ここのエンタープライズ番号はhttp://www.iana.orgにリストされています。このTLV要素は、存在する場合、RTP_RXが潜在的にサポートできるプライベートエクステンションについてのBRSにヒントを提供します。RTP_RXは、特定のエンタープライズ番号の下ですべてのプライベートエクステンションを必ずしもサポートしていないことに注意してください。BRSがRTP_RXがどのプライベートエクステンションをサポートしているかを明示的に知っていない限り（これまたは一部の帯域外の手段を介して）、BRSはRAMS-Iメッセージでプライベート拡張機能を使用してはなりません。BRSは、むしろベンダーに中立な拡張機能のみを使用する必要があります。このTLV要素の長さフィールドは4*nに設定されています。ここで、nはエンタープライズ番号エントリの数です。
Type: 6
タイプ：6
The RAMS Information (RAMS-I) message is identified by SFMT=2. This message is used to describe the unicast burst that will be sent for rapid acquisition. It also includes other useful information for the RTP_Rx as described below.
RAMS情報（RAMS-I）メッセージは、SFMT = 2で識別されます。このメッセージは、迅速な買収のために送信されるユニキャストバーストを説明するために使用されます。また、以下に説明するように、RTP_RXの他の有用な情報も含まれています。
A separate RAMS-I message with the appropriate response code is sent in the unicast burst RTP session by the BRS for each primary multicast stream that has been requested by the RTP_Rx. In each of these RAMS-I messages, the media sender SSRC and packet sender SSRC fields are both set to the SSRC of the BRS, which equals the SSRC of the respective primary multicast stream.
適切な応答コードを含む別のRams-Iメッセージは、RTP_RXによって要求された各プライマリマルチキャストストリームのBRSによってUnicastバーストRTPセッションで送信されます。これらのRAMS-Iメッセージのそれぞれで、メディア送信者SSRCおよびパケット送信者SSRCフィールドはどちらもBRSのSSRCに設定されており、これはそれぞれのプライマリマルチキャストストリームのSSRCに等しくなります。
The FCI field MUST contain only one RAMS Information message. The FCI field has the structure depicted in Figure 8.
FCIフィールドには、1つのRAMS情報メッセージのみを含める必要があります。FCIフィールドには、図8に示されている構造があります。
The semantics of the RAMS-I message is independent of the payload type carried in the primary multicast RTP session.
Rams-Iメッセージのセマンティクスは、プライマリマルチキャストRTPセッションで運ばれるペイロードタイプとは無関係です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=2 | MSN | Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FCI Field Syntax for the RAMS Information Message
図8：RAMS情報メッセージのFCIフィールド構文
A RAMS-I message has the following fields:
Rams-Iメッセージには次のフィールドがあります。
o Message Sequence Number (MSN) (8 bits) : Mandatory field that denotes the sequence number of the RAMS-I message for the particular media sender SSRC specified in the message header. The MSN value SHALL be set to zero when a new RAMS request is received. During rapid acquisition, the same RAMS-I message MAY be repeated for redundancy purposes without incrementing the MSN value. If an updated RAMS-I message will be sent (either with new information or updated information), the MSN value SHALL be incremented by one. In the MSN field, the regular wrapping rules apply. Note that if the RTP_Rx has sent an updated request, it MUST check every RAMS-I message entirely, regardless of whether or not the MSN value has changed.
o メッセージシーケンス番号（MSN）（8ビット）：メッセージヘッダーで指定された特定のメディア送信者SSRCのRAMS-Iメッセージのシーケンス番号を示す必須フィールド。新しいRamsリクエストを受信すると、MSN値はゼロに設定されます。迅速な獲得中、MSN値を増やすことなく、冗長性のために同じRams-Iメッセージを繰り返すことができます。更新されたRAMS-Iメッセージが送信される場合（新しい情報または更新された情報を使用）、MSN値は1つで増加するものとします。MSNフィールドでは、通常のラッピングルールが適用されます。RTP_RXが更新された要求を送信した場合、MSN値が変更されたかどうかに関係なく、すべてのRams-Iメッセージを完全に確認する必要があることに注意してください。
o Response (16 bits): Mandatory field that denotes the response code for this RAMS-I message. This document defines several initial response codes in Section 7.3.1 and registers them with IANA in Section 11.6. If a new vendor-neutral response code will be defined, it MUST be registered with IANA through the guidelines specified in Section 11.6. If the new response code is intended to be used privately by a vendor, there is no need for IANA management. Instead, the vendor MUST use the private extension mechanism (Section 7.1.2) to convey its message and MUST indicate this by putting zero in the Response field.
o 応答（16ビット）：このRams-Iメッセージの応答コードを示す必須フィールド。このドキュメントは、セクション7.3.1のいくつかの初期応答コードを定義し、セクション11.6のIANAでそれらを登録します。新しいベンダーに中立な応答コードが定義される場合、セクション11.6で指定されたガイドラインを通じてIANAに登録する必要があります。新しい応答コードがベンダーが個人的に使用することを意図している場合、IANA管理は必要ありません。代わりに、ベンダーはプライベートエクステンションメカニズム（セクション7.1.2）を使用してメッセージを伝え、応答フィールドにゼロを配置することでこれを示す必要があります。
When the RTP_Rx receives a RAMS-I message with a response code that it does not understand, the RTP_Rx MUST send a RAMS-T message immediately to the BRS.
RTP_RXが理解できない応答コードを含むRAMS-Iメッセージを受信する場合、RTP_RXはすぐにRAMS-TメッセージをBRSに送信する必要があります。
The following TLV elements have been defined for the RAMS-I messages:
次のTLV要素は、Rams-Iメッセージに対して定義されています。
o Media Sender SSRC (32 bits): Optional TLV element that specifies the media sender SSRC of the unicast burst stream. If the FT_Ap that received the RAMS-R message is associated with a single primary multicast stream but the requested media sender SSRC does not match the SSRC of the RTP stream associated with this FT_Ap, the BRS includes this TLV element in the initial RAMS-I message to let the RTP_Rx know that the media sender SSRC has changed. If the two SSRCs match, there is no need to include this TLV element.
o Media Sender SSRC（32ビット）：ユニキャストバーストストリームのメディア送信者SSRCを指定するオプションのTLV要素。RAMS-Rメッセージを受信したFT_APが単一のプライマリマルチキャストストリームに関連付けられているが、要求されたメディア送信者SSRCがこのFT_APに関連付けられたRTPストリームのSSRCと一致しない場合、BRSには初期RAMS-IにこのTLV要素が含まれます。Media Sender SSRCが変更されたことをRTP_RXに知らせるメッセージ。2つのSSRCが一致する場合、このTLV要素を含める必要はありません。
Type: 31
タイプ：31
o RTP Seqnum of the First Packet (16 bits): TLV element that specifies the RTP sequence number of the first packet that will be sent in the respective unicast RTP stream. This allows the RTP_Rx to know whether one or more packets sent by the BRS have been dropped at the beginning of the stream. If the BRS accepts the RAMS request, this element exists. If the BRS rejects the RAMS request, this element SHALL NOT exist.
o 最初のパケットのRTP Seqnum（16ビット）：それぞれのユニキャストRTPストリームで送信される最初のパケットのRTPシーケンス番号を指定するTLV要素。これにより、RTP_RXは、BRSから送信された1つまたは複数のパケットがストリームの開始時に削除されたかどうかを知ることができます。BRSがRamsリクエストを受け入れると、この要素が存在します。BRSがRamsリクエストを拒否した場合、この要素は存在しないものとします。
Type: 32
タイプ：32
o Earliest Multicast Join Time (32 bits): TLV element that specifies the delta time (in ms) between the arrival of the first RTP packet in the unicast RTP stream (which could be a burst packet or a payload-specific packet) and the earliest time instant when an RTP_Rx MAY send an SFGMP Join message to join the multicast session. A zero value indicated in this element means that the RTP_Rx MAY send the SFGMP Join message right away. If the RTP_Rx does not want to wait until the earliest multicast join time, it MAY send a RAMS-T message, and after a reasonable amount of time, it MAY join the SSM session.
o 初期のマルチキャスト結合時間（32ビット）：ユニキャストRTPストリーム（バーストパケットまたはペイロード固有のパケットである可能性がある）と最も早い段階での最初のRTPパケットの到着の間にデルタ時間（MSで）を指定するTLV要素RTP_RXがSFGMP参加メッセージを送信してマルチキャストセッションに参加する場合があります。この要素に示されているゼロ値は、RTP_RXがSFGMP参加メッセージをすぐに送信できることを意味します。RTP_RXが初期のマルチキャストの結合時間まで待たない場合、Rams-Tメッセージを送信する可能性があり、合理的な時間の後、SSMセッションに参加する可能性があります。
If the RAMS request has been accepted, the BRS sends this element at least once so that the RTP_Rx knows when to join the multicast session. If the burst request has been rejected as indicated in the Response field, this element MUST indicate a zero value. In that case, it is up to the RTP_Rx when or whether to join the multicast session.
Ramsリクエストが受け入れられた場合、BRSはこの要素を少なくとも一度は送信して、RTP_RXがマルチキャストセッションにいつ参加するかを知っています。応答フィールドに示されているようにバースト要求が拒否された場合、この要素はゼロ値を示す必要があります。その場合、マルチキャストセッションにいつまたは参加するかは、RTP_RX次第です。
When the BRS serves two or more bursts and sends a separate RAMS-I message for each burst, the join times specified in these RAMS-I messages SHOULD correspond to more or less the same time instant, and the RTP_Rx sends the SFGMP Join message based on the earliest join time.
BRSが2つ以上のバーストを提供し、バーストごとに個別のRAMS-Iメッセージを送信する場合、これらのRAMS-Iメッセージで指定された結合時間は、同時に多かれ少なかれ同じ時間に対応する必要があり、RTP_RXはSFGMP JOINメッセージベースを送信します初期の参加時間に。
Type: 33
タイプ：33
o Burst Duration (32 bits): Optional TLV element that denotes the time the burst will last (in ms), i.e., the difference between the expected transmission times of the first and the last burst packets that the BRS is planning to send in the respective unicast RTP stream. In the absence of additional stimulus, the BRS will send a burst of this duration. However, the burst duration can be modified by subsequent events, including changes in the primary multicast stream and reception of RAMS-T messages.
o バースト期間（32ビット）：バーストが持続する時間（MS）、つまりBRSがそれぞれに送信する予定の最初のバーストパケットの予想される伝送時間の差を示すオプションのTLV要素ユニキャストRTPストリーム。追加の刺激がない場合、BRSはこの期間のバーストを送信します。ただし、バースト期間は、プライマリマルチキャストストリームの変更やRams-Tメッセージの受信など、後続のイベントによって変更できます。
The BRS MUST terminate the flow in the timeframe indicated by this burst duration or the duration established by those subsequent events even if it does not get a RAMS-T or a BYE message from the RTP_Rx. It is OPTIONAL to send this element in a RAMS-I message when the burst request is accepted. If the burst request has been rejected as indicated in the Response field, this element MAY be omitted or indicate a zero value.
BRSは、このバースト期間またはその後のイベントによって確立された期間で示される時間枠のフローを終了する必要があります。バーストリクエストが受け入れられたときに、この要素をRams-Iメッセージに送信することはオプションです。応答フィールドに示されているようにバースト要求が拒否された場合、この要素は省略またはゼロ値を示す場合があります。
Type: 34
タイプ：34
o Max Transmit Bitrate (64 bits): Optional TLV element that denotes the maximum bitrate (in bits per second) that will be used by the BRS for the RTP stream associated with this RAMS-I message.
o MAX送信ビットレート（64ビット）：このRAMS-Iメッセージに関連付けられたRTPストリームにBRSによって使用される最大ビットレート（1秒あたりビット）を示すオプションのTLV要素。
Type: 35
タイプ：35
1xx-Level Response Codes: These response codes are sent for informational purposes.
1XXレベルの応答コード：これらの応答コードは、情報目的で送信されます。
o 100: This is used when the BRS wants to update a value that was sent earlier to the RTP_Rx.
o 100：これは、BRSが以前にRTP_RXに送信された値を更新する場合に使用されます。
2xx-Level Response Codes: These response codes are sent to indicate success.
2XXレベルの応答コード：これらの応答コードは、成功を示すために送信されます。
o 200: This is used when the server accepts the RAMS request.
o 200：これは、サーバーがRamsリクエストを受け入れるときに使用されます。
o 201: This is used when the unicast burst has been completed and the BRS wants to notify the RTP_Rx.
o 201：これは、ユニキャストバーストが完了し、BRSがRTP_RXに通知したいときに使用されます。
4xx-Level Response Codes: These response codes are sent to indicate that the message sent by the RTP_Rx is either improperly formatted or contains an invalid value. The rules the RTP_Rx needs to follow upon receiving one of these response codes are outlined in Step 5 in Section 6.2. The 4xx-level response codes are also used as status codes in the Multicast Acquisition Report Block [MULTICAST-ACQ] in order to collect RTP_Rx-based error conditions.
4XXレベルの応答コード：これらの応答コードは、RTP_RXによって送信されたメッセージが不適切にフォーマットされているか、無効な値を含んでいることを示すために送信されます。RTP_RXがこれらの応答コードのいずれかを受信するときに従う必要があるルールは、セクション6.2のステップ5で概説されています。4XXレベルの応答コードは、RTP_RXベースのエラー条件を収集するために、マルチキャスト取得レポートブロック[Multicast-ACQ]のステータスコードとしても使用されます。
o 400: This is used when the RAMS-R message is improperly formatted.
o 400：これは、RAMS-Rメッセージが不適切にフォーマットされているときに使用されます。
o 401: This is used when the minimum RAMS buffer fill requirement value indicated in the RAMS-R message is invalid.
o 401：これは、RAMS-Rメッセージに示されている最小RAMSバッファー充填要件値が無効である場合に使用されます。
o 402: This is used when the maximum RAMS buffer fill requirement value indicated in the RAMS-R message is invalid.
o 402：これは、RAMS-Rメッセージに示されている最大RAMSバッファー充填要件値が無効である場合に使用されます。
o 403: This is used when the maximum receive bitrate value indicated in the RAMS-R message is insufficient.
o 403：これは、RAMS-Rメッセージに示されている最大受信ビットレート値が不十分な場合に使用されます。
o 404: This is used when the RAMS-T message is improperly formatted.
o 404：これは、Rams-Tメッセージが不適切にフォーマットされているときに使用されます。
5xx-Level Response Codes: These response codes are sent to indicate an error on the BRS side. The rules the RTP_Rx needs to follow upon receiving one of these response codes are outlined in Step 3 in Section 6.2. The 5xx-level response codes are also used as status codes in the Multicast Acquisition Report Block [MULTICAST-ACQ] in order to collect BRS-based error conditions.
5XXレベルの応答コード：これらの応答コードは、BRS側のエラーを示すために送信されます。RTP_RXがこれらの応答コードのいずれかを受信するときに従う必要があるルールは、セクション6.2のステップ3で概説されています。5XXレベルの応答コードは、BRSベースのエラー条件を収集するために、マルチキャスト取得レポートブロック[Multicast-ACQ]のステータスコードとしても使用されます。
o 500: This is used when the BRS has experienced an internal error and cannot accept the RAMS request.
o 500：これは、BRSが内部エラーを経験し、Ramsリクエストを受け入れられない場合に使用されます。
o 501: This is used when the BRS does not have enough bandwidth to send the unicast burst stream.
o 501：これは、BRSにユニキャストバーストストリームを送信するのに十分な帯域幅がない場合に使用されます。
o 502: This is used when the BRS terminates the unicast burst stream due to network congestion.
o 502：これは、BRSがネットワークの輻輳のためにユニキャストバーストストリームを終了するときに使用されます。
o 503: This is used when the BRS does not have enough CPU resources to send the unicast burst stream.
o 503：これは、BRSにユニキャストバーストストリームを送信するのに十分なCPUリソースがない場合に使用されます。
o 504: This is used when the BRS does not support sending a unicast burst stream.
o 504：これは、BRSがユニキャストバーストストリームの送信をサポートしていない場合に使用されます。
o 505: This is used when the requesting RTP_Rx is not eligible to receive a unicast burst stream.
o 505：これは、リクエストRTP_RXがユニキャストバーストストリームを受信する資格がない場合に使用されます。
o 506: This is used when RAMS functionality is not enabled for the requested multicast stream.
o 506：これは、要求されたマルチキャストストリームに対してRAMS機能が有効になっていない場合に使用されます。
o 507: This is used when the BRS cannot find a valid starting point for the unicast burst stream that satisfies the RTP_Rx's requirements.
o 507：これは、BRSがRTP_RXの要件を満たすユニキャストバーストストリームの有効な開始点を見つけることができない場合に使用されます。
o 508: This is used when the BRS cannot find the essential reference information for the requested multicast stream.
o 508：これは、BRSが要求されたマルチキャストストリームの重要な参照情報を見つけることができない場合に使用されます。
o 509: This is used when the BRS cannot match the requested SSRC to any of the streams it is serving.
o 509：これは、BRSが要求されたSSRCを提供するストリームのいずれかに一致させない場合に使用されます。
o 510: This is used when the BRS cannot serve the requested entire session.
o 510：これは、BRSが要求されたセッション全体を提供できない場合に使用されます。
o 511: This is used when the BRS sends only the preamble information but not the whole unicast burst stream.
o 511：これは、BRSがプリアンブル情報のみを送信するが、ユニキャストバーストストリーム全体ではない場合に使用されます。
o 512: This is used when the RAMS request is denied due to a policy for the requested multicast stream, the RTP_Rx, or this particular BRS.
o 512：これは、要求されたマルチキャストストリーム、RTP_RX、またはこの特定のBRSのポリシーにより、Ramsリクエストが拒否されたときに使用されます。
The RAMS Termination (RAMS-T) message is identified by SFMT=3.
RAMS終端（RAMS-T）メッセージは、SFMT = 3で識別されます。
The RAMS Termination is used to assist the BRS in determining when to stop the burst. A separate RAMS-T message is sent in the unicast burst RTP session by the RTP_Rx for each primary multicast stream that has been served by the BRS. Each of these RAMS-T message's media sender SSRC field SHALL BE populated with the SSRC of the media stream to be terminated. If the media sender SSRC populated in the RAMS-T message does not match the SSRC of the burst served by the BRS, BRS SHALL ignore the RAMS-T message.
ラムズ終了は、BRSがバーストを停止するタイミングを決定するのを支援するために使用されます。BRSが提供する各プライマリマルチキャストストリームのRTP_RXによって、ユニキャストバーストRTPセッションで別のRams-Tメッセージが送信されます。これらのRAMS-Tメッセージのメディア送信者SSRCフィールドのそれぞれには、終了するメディアストリームのSSRCが入力されます。RAMS-Tメッセージに入っているメディア送信者SSRCがBRSが提供するバーストのSSRCと一致しない場合、BRSはRAMS-Tメッセージを無視するものとします。
If the RTP_Rx wants the BRS to stop a burst prematurely, it sends a RAMS-T message as described below. Upon receiving this message, the BRS stops the respective burst immediately. If the RTP_Rx wants the BRS to terminate all of the bursts, it needs to send all of the respective RAMS-T messages in a single compound RTCP packet.
RTP_RXがBRSにバーストを早めに停止することを望んでいる場合、以下に説明するようにRAMS-Tメッセージを送信します。このメッセージを受信すると、BRSはそれぞれのバーストをすぐに停止します。RTP_RXがBRSにすべてのバーストを終了することを望んでいる場合、それぞれのRAMS-Tメッセージを1つの化合物RTCPパケットに送信する必要があります。
The default behavior for the RTP_Rx is to send a RAMS-T message immediately after it joined the multicast session and started receiving multicast packets. In that case, the RTP_Rx includes the sequence number of the first RTP packet received in the primary multicast stream in the RAMS-T message. With this information, the BRS can decide when to terminate the unicast burst.
RTP_RXのデフォルトの動作は、マルチキャストセッションに参加してマルチキャストパケットの受信を開始した直後にRAMS-Tメッセージを送信することです。その場合、RTP_RXには、RAMS-Tメッセージのプライマリマルチキャストストリームで受信した最初のRTPパケットのシーケンス番号が含まれています。この情報を使用すると、BRSはユニキャストバーストをいつ終了するかを決定できます。
The FCI field MUST contain only one RAMS Termination. The FCI field has the structure depicted in Figure 9.
FCIフィールドには、1つのRAMS終端のみを含める必要があります。FCIフィールドには、図9に示されている構造があります。
The semantics of the RAMS-T message is independent of the payload type carried in the primary multicast RTP session.
Rams-Tメッセージのセマンティクスは、プライマリマルチキャストRTPセッションで運ばれるペイロードタイプとは無関係です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: FCI field syntax for the RAMS Termination message
図9：RAMS終端メッセージのFCIフィールド構文
o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional TLV element that specifies the extended RTP sequence number of the first packet received from the SSM session for a particular primary multicast stream. The low 16 bits contain the sequence number of the first packet received from the SSM session, and the most significant 16 bits extend that sequence number with the corresponding count of sequence number cycles, which can be maintained according to the algorithm in Appendix A.1 of [RFC3550].
o 最初のマルチキャストパケットの拡張RTP Seqnum（32ビット）：特定のプライマリマルチキャストストリームのSSMセッションから受信した最初のパケットの拡張RTPシーケンス番号を指定するオプションのTLV要素。低い16ビットには、SSMセッションから受信した最初のパケットのシーケンス番号が含まれており、最も重要な16ビットは、付録A.1のアルゴリズムに従って維持できるシーケンス数サイクルの対応するカウントでそのシーケンス番号を拡張します。[RFC3550]。
Type: 61
タイプ：61
The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585]. Here we add the following syntax to the 'rtcp-fb' attribute (the feedback type and optional parameters are all case sensitive):
「RTCP-FB」属性の構文は[RFC4585]で定義されています。ここでは、「RTCP-FB」属性に次の構文を追加します（フィードバックタイプとオプションのパラメーターはすべてケースに敏感です）：
(In the following ABNF [RFC5234], rtcp-fb-nack-param is used as defined in [RFC4585].)
（次のABNF [RFC5234]では、RTCP-FB-NACK-PARAMは[RFC4585]で定義されているように使用されます。）
rtcp-fb-nack-param =/ SP "rai"
rtcp-fb-nack-param =/ sp "rai"
The following parameter is defined in this document for use with 'nack':
次のパラメーターは、「NACK」で使用するためにこのドキュメントで定義されています。
o 'rai' stands for Rapid Acquisition Indication and indicates the use of RAMS messages as defined in Section 7.
o 「RAI」は、迅速な獲得適応の略で、セクション7で定義されているRAMSメッセージの使用を示しています。
This document also defines a new media-level SDP attribute ('rams-updates') that indicates whether or not the BRS supports updated request messages. This attribute is used in a declarative manner and no Offer/Answer Model behavior is specified. If the BRS supports updated request messages and this attribute is included in the SDP description, the RTP_Rx can send updated requests. The BRS might or might not be able to accept value changes in every field in an updated RAMS-R message. However, if the 'rams-updates' attribute is not included in the SDP description, the RTP_Rx SHALL NOT send updated requests. The RTP_Rx MAY still repeat its initial request without changes, though.
このドキュメントは、BRSが更新された要求メッセージをサポートするかどうかを示す新しいメディアレベルのSDP属性（「Rams-Updates」）を定義します。この属性は宣言的な方法で使用され、オファー/回答モデルの動作は指定されていません。BRSが更新された要求メッセージをサポートし、この属性がSDP説明に含まれている場合、RTP_RXは更新された要求を送信できます。BRSは、更新されたRAMS-Rメッセージのすべてのフィールドの価値の変更を受け入れる場合とできない場合があります。ただし、「Rams-Updates」属性がSDP説明に含まれていない場合、RTP_RXは更新されたリクエストを送信してはなりません。ただし、RTP_RXは、変更なしで最初のリクエストを繰り返す場合があります。
The use of SDP to describe the RAMS entities normatively requires support for:
RAMSエンティティを記述するためにSDPを使用するには、次のサポートが必要です。
o The SDP grouping framework and flow identification (FID) semantics [RFC5888]
o SDPグループ化フレームワークとフロー識別（FID）セマンティクス[RFC5888]
o The RTP/AVPF profile [RFC4585]
o RTP/AVPFプロファイル[RFC4585]
o The RTP retransmission payload format [RFC4588]
o RTP再送信ペイロードフォーマット[RFC4588]
o The RTCP extensions for SSM sessions with unicast feedback [RFC5760]
o ユニキャストフィードバックを使用したSSMセッション用のRTCP拡張[RFC5760]
o The 'multicast-rtcp' attribute [RFC6128]
o 「マルチキャストRTCP」属性[RFC6128]
o Multiplexing RTP and RTCP on a single port on both endpoints in the unicast session [RFC5761]
o ユニキャストセッションの両方のエンドポイントの単一ポートでのRTPとRTCPを多重化[RFC5761]
o The 'portmapping-req' attribute [RFC6284]
o 'portmapping-req'属性[RFC6284]
Support for the source-specific media attributes [RFC5576] can also be needed when the 'ssrc' attribute is to be used for the media descriptions.
ソース固有のメディア属性[RFC5576]のサポートは、「SSRC」属性をメディアの説明に使用する場合にも必要です。
This section provides a declarative SDP [RFC4566] example (for the RTP_Rx side) for enabling rapid acquisition of multicast RTP sessions.
このセクションでは、マルチキャストRTPセッションの迅速な獲得を可能にするための宣言的なSDP [RFC4566]の例（RTP_RX側）を提供します。
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=Rapid Acquisition Example
t=0 0
a=group:FID 1 2
a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream
c=IN IP4 233.252.0.2/255
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:98 MP2T/90000
a=multicast-rtcp:42000
a=rtcp:43000 IN IP4 192.0.2.1
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack rai
a=ssrc:123321 cname:iptv-ch32@rams.example.com
a=rams-updates
a=portmapping-req:54000 IN IP4 192.0.2.1
a=mid:1
m=video 51000 RTP/AVPF 99
i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1
a=sendonly
a=rtpmap:99 rtx/90000
a=rtcp-mux
a=rtcp:51500
a=fmtp:99 apt=98;rtx-time=5000
a=portmapping-req:55000
a=mid:2
Figure 10: Example SDP for a Single-Channel RAMS Scenario
図10：シングルチャネルラムズシナリオのSDPの例
In this example SDP description, we have a primary multicast (source) stream and a unicast retransmission stream. The source stream is multicast from a distribution source (with a source IP address of 198.51.100.1) to the multicast destination address of 233.252.0.2 and port 41000. The corresponding RTCP traffic is multicast to the same multicast destination address at port 42000. Here, we are assuming that the multicast RTP and RTCP ports are carefully chosen so that different RTP and RTCP streams do not collide with each other.
この例のSDP説明では、プライマリマルチキャスト（ソース）ストリームとユニキャスト再送信ストリームがあります。ソースストリームは、配布ソース（ソースIPアドレス198.51.100.1）から233.252.0.2およびポート41000のマルチキャスト宛先アドレスまでのマルチキャストです。対応するRTCPトラフィックは、ポート42000の同じマルチキャスト宛先アドレスへのマルチキャストです。、マルチキャストRTPおよびRTCPポートが慎重に選択されているため、異なるRTPおよびRTCPストリームが互いに衝突しないと仮定しています。
The feedback target (FT_Ap) residing on the RS (with an address of 192.0.2.1) at port 43000 is declared with the "a=rtcp" line [RFC3605]. The support for the conventional retransmission is indicated through the "a=rtcp-fb:98 nack" line. The RTP receiver(s) can report missing packets on the source stream to the feedback target and request retransmissions. The SDP above includes the "a=sendonly" line for the media description of the retransmission stream since the retransmissions are sent in only one direction.
ポート43000のRS（192.0.2.1のアドレス付き）に存在するフィードバックターゲット（FT_AP）は、「A = RTCP」ライン[RFC3605]で宣言されています。従来の再送信のサポートは、「a = rtcp-fb：98 nack」行を通じて示されています。RTPレシーバーは、ソースストリーム上の欠落しているパケットをフィードバックターゲットに報告し、再送信を要求できます。上記のSDPには、再送信が1つの方向にのみ送信されるため、再送信ストリームのメディアの説明の「a = sendonly」行が含まれています。
The support for rapid acquisition is indicated through the "a=rtcp-fb:98 nack rai" line. The parameter 'rtx-time' applies to both the conventional retransmissions and rapid acquisition. However, when rapid acquisition is enabled, the standard definition for the parameter 'rtx-time' given in [RFC4588] is not followed. Instead, when rapid acquisition support is enabled, 'rtx-time' specifies the time in milliseconds that the BRS keeps an RTP packet in its cache available for retransmission (measured from the time the packet was received by the BRS, not from the time indicated in the packet timestamp).
迅速な買収のサポートは、「A = RTCP-FB：98 NACK RAI」ラインを通じて示されています。パラメーター「RTX-Time」は、従来の再送信と迅速な獲得の両方に適用されます。ただし、迅速な獲得が有効になっている場合、[RFC4588]に与えられたパラメーター「RTX-Time」の標準定義には従われません。代わりに、迅速な取得サポートが有効になっている場合、「RTX-Time」は、BRSが再送信に利用できるキャッシュにRTPパケットを保持するミリ秒単位での時間を指定します（パケットがBRSが受信した時から、示された時間からではなく、パケットタイムスタンプで）。
Once an RTP_Rx has acquired an SDP description, it can ask for rapid acquisition before it joins a primary multicast RTP session. To do so, it sends a RAMS-R message to the feedback target of that primary multicast RTP session. If the FT_Ap is associated with only one RTP stream, the RTP_Rx does not need to learn the SSRC of that stream via an out-of-band method. If the BRS accepts the rapid acquisition request, it will send a RAMS-I message with the correct SSRC identifier. If the FT_Ap is associated with a multi-stream RTP session and the RTP_Rx is willing to request rapid acquisition for the entire session, the RTP_Rx again does not need to learn the SSRCs via an out-of-band method. However, if the RTP_Rx intends to request a particular subset of the primary multicast streams, it must learn their SSRC identifiers and list them in the RAMS-R message. Since this RTP_Rx has not yet received any RTP packets for the primary multicast stream(s), the RTP_Rx must in this case learn the SSRC value(s) from the 'ssrc' attribute of the media description [RFC5576]. In addition to the SSRC value, the 'cname' source attribute must also be present in the SDP description [RFC5576].
RTP_RXがSDPの説明を取得すると、プライマリマルチキャストRTPセッションに参加する前に、迅速な買収を要求できます。そのために、そのプライマリマルチキャストRTPセッションのフィードバックターゲットにRAMS-Rメッセージを送信します。FT_APが1つのRTPストリームのみに関連付けられている場合、RTP_RXは帯域外のメソッドを介してそのストリームのSSRCを学習する必要はありません。BRSが迅速な取得要求を受け入れると、正しいSSRC識別子を使用してRams-Iメッセージが送信されます。FT_APがマルチストリームRTPセッションに関連付けられており、RTP_RXがセッション全体の迅速な取得を要求することをいとわない場合、RTP_RXは帯域外の方法を介してSSRCを学習する必要はありません。ただし、RTP_RXがプライマリマルチキャストストリームの特定のサブセットを要求する場合、SSRC識別子を学習し、RAMS-Rメッセージにリストする必要があります。このRTP_RXは、プライマリマルチキャストストリームのRTPパケットをまだ受信していないため、この場合、RTP_RXはメディア説明[RFC5576]の「SSRC」属性からSSRC値を学習する必要があります。SSRC値に加えて、「CNAME」ソース属性もSDP説明[RFC5576]に存在する必要があります。
Listing the SSRC values for the primary multicast streams in the SDP file does not create a problem in SSM sessions when an SSRC collision occurs. This is because in SSM sessions, an RTP_Rx that observed an SSRC collision with a media sender must change its own SSRC [RFC5760] by following the rules defined in [RFC3550].
SDPファイルのプライマリマルチキャストストリームのSSRC値をリストすると、SSRC衝突が発生した場合、SSMセッションで問題は発生しません。これは、SSMセッションでは、メディア送信者とのSSRC衝突を観察したRTP_RXは、[RFC3550]で定義されているルールに従うことにより、独自のSSRC [RFC5760]を変更する必要があるためです。
A feedback target that receives a RAMS-R message becomes aware that the RTP_Rx wants to rapidly catch up with a primary multicast RTP session. If the necessary conditions are satisfied (as outlined in Section 7 of [RFC4585]) and available resources exist, the BRS can react to the RAMS-R message by sending any transport-layer (and optional payload-specific, when allowed) feedback message(s) and starting the unicast burst.
RAMS-Rメッセージを受信するフィードバックターゲットは、RTP_RXがプライマリマルチキャストRTPセッションに迅速に追いつきたいことを認識します。必要な条件が満たされている場合（[RFC4585]のセクション7で概説されているように）、利用可能なリソースが存在する場合、BRSは輸送層（および許可された場合、オプションのペイロード固有）を送信することでRAMS-Rメッセージに反応できます。（s）ユニキャストバーストの開始。
In this section, we considered the simplest scenario where the primary multicast RTP session carried only one stream and the RTP_Rx wanted to rapidly acquire this stream only. Best practices for scenarios where the primary multicast RTP session carries two or more streams or the RTP_Rx wants to acquire one or more streams from multiple primary multicast RTP sessions at the same time are presented in [RAMS-SCENARIOS].
このセクションでは、プライマリマルチキャストRTPセッションが1つのストリームのみを搭載し、RTP_RXがこのストリームのみを迅速に取得したいと考えていた最も単純なシナリオを検討しました。プライマリマルチキャストRTPセッションが2つ以上のストリームを運ぶシナリオのベストプラクティスまたはRTP_RXは、複数のプライマリマルチキャストRTPセッションから同時に1つ以上のストリームを取得したいと考えています。
For a variety of reasons, one or more Network Address Port Translators (NAPT, hereafter simply called NAT) can exist between the RTP_Rx and RS. NATs have a variety of operating characteristics for UDP traffic [RFC4787]. For a NAT to permit traffic from the BRS to arrive at the RTP_Rx, the NAT(s) must first either:
さまざまな理由で、1つ以上のネットワークアドレスポート翻訳者（NAPT、以下NATと呼ばれる）がRTP_RXとRSの間に存在する可能性があります。NATには、UDPトラフィックのさまざまな動作特性があります[RFC4787]。NATがBRSからのトラフィックがRTP_RXに到着することを許可するには、最初にNAT（S）が必要です。
a. See UDP (or DCCP) traffic sent from the RTP_Rx (which is on the 'inside' of the NAT) to the BRS (which is on the 'outside' of the NAT). This traffic has the same transport address as the subsequent response traffic, or
a. RTP_RX（NATの「内部」にある）からBRS（NATの「外側」にある）に送信されたUDP（またはDCCP）トラフィックを参照してください。このトラフィックは、後続の応答トラフィックと同じ輸送アドレスを持っています。
b. Be configured to forward certain ports (e.g., using HTML configuration or Universal Plug and Play (UPnP) Internet Gateway Device (IGD) [UPnP-IGD]). Details of this are out of the scope of this document.
b. 特定のポートを転送するように構成されています（例：HTML構成またはユニバーサルプラグアンドプレイ（UPNP）インターネットゲートウェイデバイス（IGD）[UPNP-IGD]を使用して）。この詳細は、このドキュメントの範囲外です。
For both (a) and (b), the RTP_Rx is responsible for maintaining the NAT's state if it wants to receive traffic from the BRS on that port. For (a), the RTP_Rx MUST send UDP traffic to keep the NAT binding alive, at least every 30 seconds [RFC4787]. While (a) is more like an automatic/dynamic configuration, (b) is more like a manual/static configuration.
（a）と（b）の両方について、RTP_RXは、そのポートのBRSからトラフィックを受け取りたい場合、NATの状態を維持する責任があります。（a）の場合、RTP_RXは、少なくとも30秒ごとにNATバインドを生かし続けるためにUDPトラフィックを送信する必要があります[RFC4787]。（a）は自動/動的構成に似ていますが、（b）はマニュアル/静的構成に似ています。
When the RTP_Rx sends a request (RAMS-R) message to the FT as unicast feedback in the primary multicast RTP session and the request is received by the FT, a new unicast burst RTP session will be established between the BRS and RTP_Rx.
RTP_RXがプライマリマルチキャストRTPセッションでユニキャストフィードバックとしてリクエスト（RAMS-R）メッセージをFTに送信し、FTがリクエストを受信すると、BRSとRTP_RXの間に新しいユニキャストバーストRTPセッションが確立されます。
While the FT and BRS ports on the RS are already signaled via out-of-band means (e.g., SDP), the RTP_Rx needs to convey the RTP and RTCP ports it wants to use on its side for the new session. Since there are two RTP sessions (one multicast and one unicast) involved during this process and one of them is established upon a feedback message sent in the other one, this requires an explicit port mapping method.
RSのFTおよびBRSポートは既に帯域外の手段（SDPなど）を介してシグナルを既に合わせていますが、RTP_RXは、新しいセッションに使用したいRTPおよびRTCPポートを伝える必要があります。このプロセス中に2つのRTPセッション（1つのマルチキャストと1つのユニキャスト）が関与しており、そのうちの1つはもう1つで送信されたフィードバックメッセージに確立されるため、これには明示的なポートマッピング方法が必要です。
Applications using RAMS MUST support the method presented in [RFC6284] both on the RS and RTP_Rx side to allow RTP receivers to use their desired ports and to support RAMS behind NAT devices. The port mapping message exchange needs to take place whenever the RTP_Rx intends to make use of the RAMS protocol for rapidly acquiring a specific multicast RTP session prior to joining the associated SSM session.
RAMSを使用したアプリケーションは、RSおよびRTP_RX側の両方で[RFC6284]で提示されている方法をサポートして、RTPレシーバーが目的のポートを使用し、NATデバイスの背後にあるRAMSをサポートできるようにする必要があります。RTP_RXがRAMSプロトコルを利用して、関連するSSMセッションに参加する前に特定のマルチキャストRTPセッションを迅速に取得する場合はいつでも、ポートマッピングメッセージ交換が行われる必要があります。
Applications that are using RAMS make heavy use of the unicast feedback mechanism described in [RFC5760], the payload format defined in [RFC4588], and the port mapping solution specified in [RFC6284]. Thus, these applications are subject to the general security considerations discussed in those documents. In particular, the threats and risks discussed in [RFC5760] need to be considered carefully. In this section, we give an overview of the guidelines and suggestions described in these specifications from a RAMS perspective. We also discuss the security considerations that explicitly apply to applications using RAMS.
RAMを使用しているアプリケーションは、[RFC5760]で説明されているユニキャストフィードバックメカニズム、[RFC4588]で定義されたペイロード形式、および[RFC6284]で指定されたポートマッピングソリューションを豊富に使用します。したがって、これらのアプリケーションは、これらのドキュメントで説明されている一般的なセキュリティ上の考慮事項の対象となります。特に、[RFC5760]で議論されている脅威とリスクを慎重に考慮する必要があります。このセクションでは、ラムズの観点からこれらの仕様に記載されているガイドラインと提案の概要を説明します。また、RAMSを使用してアプリケーションに明示的に適用されるセキュリティ上の考慮事項についても説明します。
First of all, much of the session description information is available in the SDP descriptions that are distributed to the media senders, retransmission servers, and RTP receivers. Adequate security measures are RECOMMENDED to ensure the integrity and authenticity of the SDP descriptions so that transport addresses of the media senders, distribution sources, feedback targets, and other session-specific information can be protected. See [RFC4566] for details.
まず、セッションの説明情報の多くは、メディア送信者、再送信サーバー、およびRTPレシーバーに配布されるSDPの説明で利用できます。メディアの送信者、流通源、フィードバック目標、およびその他のセッション固有の情報を保護できるように、SDPの説明の整合性と信頼性を確保するために、適切なセキュリティ対策が推奨されます。詳細については、[RFC4566]を参照してください。
Compared to an RTCP NACK message that triggers one or more retransmissions, a RAMS Request (RAMS-R) message can trigger a new burst stream to be sent by the retransmission server. Depending on the application-specific requirements and conditions existing at the time of the RAMS-R reception by the retransmission server, the resulting burst stream can potentially contain a large number of retransmission packets. Since these packets are sent faster than the nominal rate, RAMS consumes more resources on the retransmission servers, RTP receivers, and the network. In particular, this can make denial-of-service (DoS) attacks more intense and hence more harmful than attacks that target ordinary retransmission sessions.
1つ以上の再送信をトリガーするRTCP NACKメッセージと比較して、RAMSリクエスト（RAMS-R）メッセージは、再送信サーバーによって送信される新しいバーストストリームをトリガーする可能性があります。再送信サーバーによるRAMS-R受信時に存在するアプリケーション固有の要件と条件に応じて、結果として生じるバーストストリームには、多数の再送信パケットが含まれる可能性があります。これらのパケットは名目レートよりも速く送信されるため、Ramsは再送信サーバー、RTPレシーバー、およびネットワークでより多くのリソースを消費します。特に、これにより、サービス拒否（DOS）攻撃は、通常の再送信セッションをターゲットにする攻撃よりも激しいため、より有害になります。
As RAMS messages are sent as RTCP messages, counter-measures SHOULD be taken to prevent tampered or spoofed RTCP packets, following the suggestions given in [RFC4588]. Tampered RAMS-R messages can trigger inappropriate burst streams or alter the existing burst streams in an inappropriate way. For example, if the Max Receive Bitrate field is altered by a tampered RAMS-R message, the updated burst can overflow the buffer at the receiver side or, oppositely, can slow down the burst to the point that it becomes useless. Tampered RAMS Termination (RAMS-T) messages can terminate valid burst streams prematurely resulting in gaps in the received RTP packets. RAMS Information (RAMS-I) messages contain fields that are critical for a successful rapid acquisition. Any tampered information in the RAMS-I message can easily cause an RTP receiver to make wrong decisions. Consequently, the RAMS operation can fail.
RAMSメッセージはRTCPメッセージとして送信されるため、[RFC4588]で与えられた提案に従って、RTCPパケットの改ざんまたはスプーフィングを防ぐためにカウンター測定を行う必要があります。改ざんされたRAMS-Rメッセージは、不適切なバーストストリームをトリガーしたり、既存のバーストストリームを不適切な方法で変更したりする可能性があります。たとえば、最大受信ビットレートフィールドが改ざんされたRAMS-Rメッセージによって変更された場合、更新されたバーストは、レシーバー側のバッファーにオーバーフローするか、反対に、バーストを速度が低下する可能性があります。改ざんされたRAMS終了（RAMS-T）メッセージは、有効なバーストストリームを早期的に終了し、受信したRTPパケットのギャップをもたらす可能性があります。RAMS情報（RAMS-I）メッセージには、迅速な獲得が成功するために重要なフィールドが含まれています。Rams-Iメッセージの改ざんされた情報があれば、RTPレシーバーが間違った決定を下すことができます。したがって、ラムズの操作が失敗する可能性があります。
RTCP BYE messages are similar to RAMS-T messages in the sense that they can be used to stop an existing burst. The CNAME of an RTP receiver is used to bind the RTCP BYE message to an existing burst. Thus, one should be careful if the CNAMEs are reasonably easy to guess and off-path attacks can be performed. Also note that the CNAMEs might be redistributed to all participants in the multicast group (as in ASM or the simple feedback model of [RFC5760]).
RTCP Byeメッセージは、既存のバーストを停止するために使用できるという意味で、Rams-Tメッセージに似ています。RTPレシーバーのCNAMEを使用して、RTCP Byeメッセージを既存のバーストにバインドします。したがって、CNAMEの推測がかなり簡単で、パスオフパス攻撃を実行できる場合は、注意する必要があります。また、CNAMEはマルチキャストグループのすべての参加者に再配布される可能性があることに注意してください（ASMまたは[RFC5760]の単純なフィードバックモデルのように）。
The retransmission server has to consider if values indicated in a RAMS-R message are reasonable. For example, a request demanding a large value of many seconds in the Min RAMS Buffer Fill Requirement element should, unless special use cases exist, likely be rejected since it is likely to be an attempt to prolong a DoS attack on the retransmission server, RTP receiver, and/or the network. The Max Receive Bitrate could also be set to a very large value to try to get the retransmission server to cause massive congestion by bursting at a bitrate that will not be supported by the network. An RTP_Rx should also consider if the values for the Earliest Multicast Join Time and Burst Duration indicated by the retransmission server in a RAMS-I message are reasonable. For example, if the burst packets stop arriving and the join time is still significantly far into the future, this could be a sign of a man-in-the-middle attack where the RAMS-I message has been manipulated by an attacker.
再送信サーバーは、RAMS-Rメッセージに示されている値が妥当かどうかを考慮する必要があります。たとえば、Min Rams Buffer Fill要素の数秒の大きな値を要求するリクエストは、特別なユースケースが存在しない限り、再送信サーバーに対するDOS攻撃を延長する試みである可能性が高いため、拒否される可能性があります。レシーバー、および/またはネットワーク。最大受信ビットレートは、ネットワークでサポートされないビットレートで破裂することにより、再送信サーバーに大規模な輻輳を引き起こすようにするために、非常に大きな価値に設定することもできます。RTP_RXは、RAMS-Iメッセージの再送信サーバーが示す初期のマルチキャスト結合時間とバースト期間の値が合理的であるかどうかを考慮する必要があります。たとえば、バーストパケットが到着を停止し、参加時間が依然として将来的にはるかに大きくなっている場合、これは攻撃者によってRams-Iメッセージが操作されている中間攻撃の兆候になる可能性があります。
A basic mitigation against DoS attacks introduced by an attacker injecting tampered RAMS messages is source address validation [RFC2827]. Also, most of the DoS attacks can be prevented by the integrity and authenticity checks enabled by Secure RTP (SRTP) [RFC3711]. However, an attack can still be started by legitimate endpoints that send several valid RAMS-R messages to a particular feedback target in a synchronized fashion and in a very short amount of time. Since a RAMS operation can temporarily consume a large amount of resources, a series of the RAMS-R messages can temporarily overload the retransmission server. In these circumstances, the retransmission server can, for example, reject incoming RAMS requests until its resources become available again. One means to ameliorate this threat is to apply a per-endpoint policing mechanism on the incoming RAMS requests. A reasonable policing mechanism should consider application-specific requirements and minimize false negatives.
改ざんされたRAMSメッセージを注入する攻撃者によって導入されたDOS攻撃に対する基本的な緩和は、ソースアドレスの検証[RFC2827]です。また、ほとんどのDOS攻撃は、Secure RTP（SRTP）[RFC3711]によって有効な整合性および信頼性チェックによって防止できます。ただし、攻撃は、いくつかの有効なRAMS-Rメッセージを同期された方法で、非常に短い時間で特定のフィードバックターゲットに送信する正当なエンドポイントによって開始できます。Ramsの操作は一時的に大量のリソースを消費できるため、Rams-Rメッセージのシリーズは、再送信サーバーに一時的に過負荷になる可能性があります。これらの状況では、たとえば再送信サーバーは、リソースが再び利用可能になるまで、着信ラムズの要求を拒否することができます。この脅威を改善するための1つの手段は、入ってくるラムズリクエストにエンドポイントごとのポリシングメカニズムを適用することです。合理的なポリシングメカニズムは、アプリケーション固有の要件を考慮し、偽陰性を最小限に抑える必要があります。
In addition to the DoS attacks, man-in-the-middle and replay attacks will also be harmful. RAMS-R messages do not carry any information that allows the retransmission server to detect duplication or replay attacks. Thus, the possibility of a replay attack using a captured valid RAMS-R message exists unless a mitigation method such as Secure RTCP (SRTCP) is used. Similarly, RAMS-T messages can be replayed. The RAMS-I has a sequence number that makes replay attacks less likely but not impossible. Man-in-the-middle attacks that are capable of capturing, injecting, or modifying the RAMS messages can easily accomplish the attacks described above. Thus, cryptographic integrity and authentication is the only reliable protection. To protect the RTCP messages from man-in-the-middle and replay attacks, the RTP receivers and retransmission server SHOULD perform a Datagram Transport Layer Security (DTLS)-SRTP handshake [RFC5764] over the RTCP channel. Because there is no integrity-protected signaling channel between an RTP receiver and the retransmission server, the retransmission server MUST maintain a list of certificates owned by legitimate RTP receivers, or their certificates MUST be signed by a trusted Certificate Authority. Once the DTLS-SRTP security is established, non-SRTCP-protected messages received from a particular RTP receiver are ignored by the retransmission server. To reduce the impact of DTLS-SRTP overhead when communicating with different feedback targets on the same retransmission server, it is RECOMMENDED that RTP receivers and the retransmission server both support TLS Session Resumption without Server-side State [RFC5077]. To help scale SRTP to handle many RTP receivers asking for retransmissions of identical data, implementors may consider using the same SRTP key for SRTP data sent to the receivers [SRTP-EKT] and be aware that such key sharing allows those receivers to impersonate the sender. Thus, source address validation remains important.
DOS攻撃に加えて、中間者とリプレイの攻撃も有害です。RAMS-Rメッセージは、再送信サーバーが重複またはリプレイ攻撃を検出できるようにする情報を掲載していません。したがって、安全なRTCP（SRTCP）などの緩和方法が使用されない限り、キャプチャされた有効なRAMS-Rメッセージを使用したリプレイ攻撃の可能性が存在します。同様に、Rams-Tメッセージを再生できます。Rams-Iにはシーケンス番号があり、リプレイ攻撃の可能性が低くなりますが、不可能ではありません。ラムズメッセージをキャプチャ、注入、または変更できる中間攻撃は、上記の攻撃を簡単に達成できます。したがって、暗号化の完全性と認証は唯一の信頼できる保護です。Man-in-the-Middleおよびリプレイ攻撃からRTCPメッセージを保護するために、RTP受信機と再送信サーバーは、RTCPチャネルでDatagram Transport Layer Security（DTLS）-SRTPハンドシェイク[RFC5764]を実行する必要があります。RTPレシーバーと再送信サーバーの間に整合性保護されたシグナリングチャネルがないため、再送信サーバーは正当なRTP受信機が所有する証明書のリストを維持する必要があります。DTLS-SRTPセキュリティが確立されると、特定のRTPレシーバーから受信された非SRTCP保護されたメッセージは、再送信サーバーによって無視されます。同じ再送信サーバーで異なるフィードバックターゲットと通信するときにDTLS-SRTPオーバーヘッドの影響を減らすために、RTP受信機と再送信サーバーはどちらもサーバー側の状態なしでTLSセッション再開をサポートすることをお勧めします[RFC5077]。SRTPをスケーリングして、同一のデータの再送信を求める多くのRTP受信機を処理するのに役立つために、実装者は受信機に送信されたSRTPデータに同じSRTPキーを使用することを検討し、そのようなキー共有により、それらの受信機が送信者になりすましていることを認識することができます。。したがって、ソースアドレスの検証は依然として重要です。
[RFC4588] RECOMMENDS that cryptography mechanisms be used for the retransmission payload format to provide protection against known plain-text attacks. As discussed in [RFC4588], the retransmission payload format sets the timestamp field in the RTP header to the media timestamp of the original packet, and this does not compromise the confidentiality. Furthermore, if cryptography is used to provide security services on the original stream, then the same services, with equivalent cryptographic strength, MUST be provided on the retransmission stream per [RFC4588].
[RFC4588]は、既知のプレーンテキスト攻撃に対する保護を提供するために、再送信ペイロード形式に暗号化メカニズムを使用することを推奨しています。[RFC4588]で説明したように、再送信ペイロードフォーマットは、RTPヘッダーのタイムスタンプフィールドを元のパケットのメディアタイムスタンプに設定しますが、これは機密性を損なうことはありません。さらに、暗号化を使用して元のストリームでセキュリティサービスを提供する場合、同等の暗号強度を持つ同じサービスを、[RFC4588]ごとに再送信ストリームに提供する必要があります。
Finally, a retransmission server that has become subverted by an attacker is almost impossible to protect against as such a server can perform a large number of different actions to deny service to receivers.
最後に、攻撃者によって破壊された再送信サーバーは、そのようなサーバーがレシーバーへのサービスを拒否するために多数の異なるアクションを実行できるため、保護することはほとんど不可能です。
The following contact information is used for all registrations in this document:
次の連絡先情報は、このドキュメントのすべての登録に使用されます。
Ali Begen abegen@cisco.com Note that the "RAMS" (value 2) in the Multicast Acquisition Method Registry refers to the method described in Section 6 of this document.
Ali Begen abegen@cisco.comマルチキャスト取得方法レジストリの「ラムズ」（値2）は、このドキュメントのセクション6で説明されている方法を指していることに注意してください。
This document registers a new attribute name in SDP.
このドキュメントは、SDPの新しい属性名を登録します。
SDP Attribute ("att-field"): Attribute name: rams-updates Long form: Support for Updated RAMS Request Messages Type of name: att-field Type of attribute: Media level Subject to charset: No Purpose: See this document Reference: [RFC6285] Values: None
SDP属性（ "att-field"）：属性名：rams-updates long form：uppated rams requestメッセージタイプタイプ：att-fieldタイプの属性：メディアレベルcharset：なし目的：このドキュメントリファレンスを参照：[RFC6285]値：なし
This document registers a new value for the 'nack' attribute to be used with the 'rtcp-fb' attribute in SDP. For more information about the 'rtcp-fb' attribute, refer to Section 4.2 of [RFC4585].
このドキュメントは、SDPの「RTCP-FB」属性で使用される「NACK」属性の新しい値を登録します。「RTCP-FB」属性の詳細については、[RFC4585]のセクション4.2を参照してください。
Value name: rai Long name: Rapid Acquisition Indication Usable with: nack Reference: [RFC6285]
値名：Rai Long Name：迅速な獲得の表示使用可能：NACKリファレンス：[RFC6285]
Within the RTPFB range, the following format (FMT) value is registered:
RTPFB範囲内で、次の形式（FMT）値が登録されています。
Name: RAMS Long name: Rapid Acquisition of Multicast Sessions Value: 6 Reference: [RFC6285]
名前：ラムズロングネーム：マルチキャストセッションの迅速な買収値：6リファレンス：[RFC6285]
This document creates a new sub-registry for the sub-feedback message type (SFMT) values to be used with the FMT value registered for RAMS messages. The registry is called the SFMT Values for RAMS Messages Registry. This registry is managed by the IANA according to the Specification Required policy of [RFC5226].
このドキュメントは、RAMSメッセージに登録されたFMT値で使用するサブフィードバックメッセージタイプ（SFMT）値の新しいサブレジストリを作成します。レジストリは、RAMSメッセージレジストリのSFMT値と呼ばれます。このレジストリは、[RFC5226]の仕様が必要なポリシーに従ってIANAによって管理されます。
The length of the SFMT field in the RAMS messages is a single octet, allowing 256 values. The registry is initialized with the following entries:
RamsメッセージのSFMTフィールドの長さは単一のオクテットで、256の値が可能になります。レジストリは次のエントリで初期化されます。
Value Name Reference
----- -------------------------------------------------- ------------
0 Reserved [RFC6285]
1 RAMS Request [RFC6285]
2 RAMS Information [RFC6285]
3 RAMS Termination [RFC6285]
4-254 Unassigned - Specification Required
255 Reserved [RFC6285]
The SFMT values 0 and 255 are reserved for future use.
SFMT値0および255は、将来の使用のために予約されています。
Any registration for an unassigned SFMT value needs to contain the following information:
割り当てられていないSFMT値の登録は、次の情報を含める必要があります。
o Contact information of the one doing the registration, including at least name, address, and email.
o 少なくとも名前、住所、電子メールを含む登録を行う人の連絡先情報。
o A detailed description of what the new SFMT represents and how it shall be interpreted.
o 新しいSFMTが表すものとそれがどのように解釈されるかについての詳細な説明。
New RAMS functionality is intended to be introduced by using the extension mechanism within the existing RAMS message types not by introducing new message types unless it is absolutely necessary.
新しいRAMS機能は、絶対に必要でない限り、新しいメッセージタイプを導入することではなく、既存のRAMSメッセージタイプ内の拡張メカニズムを使用して導入することを目的としています。
This document creates a new IANA TLV space registry for the RAMS extensions. The registry is called the RAMS TLV Space Registry. This registry is managed by the IANA according to the Specification Required policy of [RFC5226].
このドキュメントは、RAMS拡張機能の新しいIANA TLVスペースレジストリを作成します。レジストリは、Rams TLVスペースレジストリと呼ばれます。このレジストリは、[RFC5226]の仕様が必要なポリシーに従ってIANAによって管理されます。
The length of the Type field in the TLV elements is a single octet, allowing 256 values. The Type values 0 and 255 are reserved for future use. The Type values between (and including) 128 and 254 are reserved for private extensions.
TLV要素のタイプフィールドの長さは単一のオクテットで、256の値が許可されています。タイプ値0および255は、将来の使用のために予約されています。128と254の間（および含む）タイプ値は、プライベートエクステンション用に予約されています。
The registry is initialized with the following entries:
レジストリは次のエントリで初期化されます。
Type Description Reference
---- ----------------------------------------------- -------------
0 Reserved [RFC6285]
1 Requested Media Sender SSRC(s) [RFC6285]
2 Min RAMS Buffer Fill Requirement [RFC6285]
3 Max RAMS Buffer Fill Requirement [RFC6285]
4 Max Receive Bitrate [RFC6285]
5 Request for Preamble Only [RFC6285]
6 Supported Enterprise Number(s) [RFC6285]
7-30 Unassigned - Specification Required
31 Media Sender SSRC [RFC6285]
32 RTP Seqnum of the First Packet [RFC6285]
33 Earliest Multicast Join Time [RFC6285]
34 Burst Duration [RFC6285]
35 Max Transmit Bitrate [RFC6285]
36-60 Unassigned - Specification Required
61 Extended RTP Seqnum of First Multicast Packet [RFC6285]
62-127 Unassigned - Specification Required
128-254 Reserved for Private Use
255 Reserved [RFC6285]
Any registration for an unassigned Type value needs to contain the following information:
割り当てられていないタイプの値の登録は、次の情報を含める必要があります。
o Contact information of the one doing the registration, including at least name, address, and email.
o 少なくとも名前、住所、電子メールを含む登録を行う人の連絡先情報。
o A detailed description of what the new TLV element represents and how it shall be interpreted.
o 新しいTLV要素が表すものとそれがどのように解釈されるかについての詳細な説明。
This document creates a new IANA TLV space registry for the RAMS response codes. The registry is called the RAMS Response Code Space Registry. This registry is managed by the IANA according to the Specification Required policy of [RFC5226].
このドキュメントは、RAMS応答コードの新しいIANA TLVスペースレジストリを作成します。レジストリは、RAMS応答コードスペースレジストリと呼ばれます。このレジストリは、[RFC5226]の仕様が必要なポリシーに従ってIANAによって管理されます。
The length of the Response field is two octets, allowing 65536 codes.
However, in this document, the response codes have been classified
and registered following an HTTP-style code numbering. New response
codes should be classified following the guidelines below:
Code Level Purpose
---------- ---------------
1xx Informational
2xx Success
3xx Redirection
4xx RTP Receiver (RTP_Rx) Error
5xx Burst/Retransmission Source (BRS) Error
The Response code 65535 is reserved for future use.
応答コード65535は、将来の使用のために予約されています。
The registry is initialized with the following entries:
レジストリは次のエントリで初期化されます。
Code Description Reference
----- -------------------------------------------------- ------------
0 A private response code is included in the message [RFC6285]
100 Parameter update for RAMS session [RFC6285]
Ramsセッションの100パラメーターアップデート[RFC6285]
200 RAMS request has been accepted [RFC6285] 201 Unicast burst has been completed [RFC6285]
200ラムズリクエストが受け入れられました[RFC6285] 201ユニキャストバーストが完了しました[RFC6285]
400 Invalid RAMS-R message syntax [RFC6285]
401 Invalid min buffer requirement in RAMS-R message [RFC6285]
402 Invalid max buffer requirement in RAMS-R message [RFC6285]
403 Insufficient max bitrate requirement in RAMS-R
message [RFC6285]
404 Invalid RAMS-T message syntax [RFC6285]
500 An unspecified BRS internal error has occurred [RFC6285]
501 BRS has insufficient bandwidth to start RAMS
session [RFC6285]
502 Burst is terminated due to network congestion [RFC6285]
503 BRS has insufficient CPU cycles to start RAMS
session [RFC6285]
504 RAMS functionality is not available on BRS [RFC6285]
505 RAMS functionality is not available for RTP_Rx [RFC6285]
506 RAMS functionality is not available for
the requested multicast stream [RFC6285]
507 BRS has no valid starting point available for
the requested multicast stream [RFC6285]
508 BRS has no reference information available for
the requested multicast stream [RFC6285]
509 BRS has no RTP stream matching the requested SSRC [RFC6285]
510 RAMS request to acquire the entire session
has been denied [RFC6285]
511 Only the preamble information is sent [RFC6285]
512 RAMS request has been denied due to a policy [RFC6285]
Any registration for an unassigned Response code needs to contain the
following information:
o Contact information of the one doing the registration, including at least name, address, and email.
o 少なくとも名前、住所、電子メールを含む登録を行う人の連絡先情報。
o A detailed description of what the new Response code describes and how it shall be interpreted.
o 新しい応答コードが説明していることと、それがどのように解釈されるかについての詳細な説明。
Dave Oran, Magnus Westerlund, and Colin Perkins have contributed significantly to this specification by providing text and solutions to some of the issues raised during the development of this specification.
Dave Oran、Magnus Westerlund、およびColin Perkinsは、この仕様の開発中に提起されたいくつかの問題にテキストと解決策を提供することにより、この仕様に大きく貢献しています。
The following individuals reviewed earlier versions of this specification and provided helpful comments: Joerg Ott, Roni Even, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, Muriel Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox, Jose Rey, Sean Sheedy, and Keith Drage.
次の個人は、この仕様の以前のバージョンをレビューし、Joerg Ott、Roni Even、Dan Wing、Tony Faustini、Peilin Yang、Jeff Goldberg、Muriel Deschanel、Orit Levin、Guy Hirson、Tom Taylor、Xavier Marjou、Ye-kuiiWang、Zixuan Zou、Ingemar Johansson、Haibin Song、Ning Zong、Jonathan Lennox、Jose Rey、Sean Sheedy、Keith Drage。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3605] Huitema、C。、「セッション説明プロトコル（SDP）のリアルタイムコントロールプロトコル（RTCP）属性」、RFC 3605、2003年10月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[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, July 2006.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張RTPプロファイル"、RFC 4585、2006年7月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588] Rey、J.、Leon、D.、Miyazaki、A.、Varsa、V。、およびR. Hakenberg、「RTP再送信ペイロードフォーマット」、RFC 4588、2006年7月。
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[RFC4604] Holbrook、H.、Cain、B。、およびB. Haberman、「インターネットグループ管理プロトコルバージョン3（IGMPV3）およびマルチキャストリスナーディスカバリーバージョンバージョン2（MLDV2）を使用して、ソース固有のマルチキャスト、RFC 4604、8月2006年。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「サーバー側の状態なしでの輸送層セキュリティ（TLS）セッション再開」、RFC 5077、2008年1月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008.
[RFC5285]シンガー、D。およびH.デシネニ、「RTPヘッダー拡張の一般的なメカニズム」、RFC 5285、2008年7月。
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009.
[RFC5506] Johansson、I。およびM. Westerlund、「減少リアルタイム輸送制御プロトコル（RTCP）のサポート：機会と結果」、RFC 5506、2009年4月。
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.
[RFC5576] Lennox、J.、Ott、J。、およびT. Schierl、「セッション説明プロトコル（SDP）のソース固有のメディア属性」、RFC 5576、2009年6月。
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5760] Ott、J.、Chesterfield、J。、およびE. Schooler、「RTPコントロールプロトコル（RTCP）ユニキャストフィードバックを備えたシングルソースマルチキャストセッションの拡張」、RFC 5760、2010年2月。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761] Perkins、C。およびM. Westerlund、「単一のポートのRTPデータと制御パケットを多重化」、RFC 5761、2010年4月。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764] McGrew、D。およびE. Rescorla、「Datagram Transport Layer Security（DTLS）拡張機能を確立するためのextension」、安全なリアルタイム輸送プロトコル（SRTP）のキーを確立する」、2010年5月、RFC 5764。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888] Camarillo、G。およびH. Schulzrinne、「セッション説明プロトコル（SDP）グループ化フレームワーク」、RFC 5888、2010年6月。
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010.
[RFC6051] Perkins、C。およびT. Schierl、「RTPフローの迅速な同期」、RFC 6051、2010年11月。
[RFC6128] Begen, A., "RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions", RFC 6128, February 2011.
[RFC6128] BEGEN、A。、「RTP制御プロトコル（RTCP）ソース固有のマルチキャスト（SSM）セッションのためのポート」、RFC 6128、2011年2月。
[RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping Between Unicast and Multicast RTP Sessions", RFC 6284, June 2011.
[RFC6284] Begen、A.、Wing、D。、およびT. Van Caenegem、「ユニキャストとマルチキャストRTPセッションの間のポートマッピング」、RFC 6284、2011年6月。
[ECN-FOR-RTP] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", Work in Progress, May 2011.
[ECN-For-RTP] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「UDPを介したRTPの明示的な混雑通知（ECN）」、進行中の作業、2011年5月。
[IC2009] Begen, A., Glazebrook, N., and W. Ver Steeg, "Reducing Channel Change Times in IPTV with Real-Time Transport Protocol (IEEE Internet Computing)", May 2009.
[IC2009] Begen、A.、Glazebrook、N。、およびW. Ver Steeg、「リアルタイムトランスポートプロトコル（IEEEインターネットコンピューティング）を使用してIPTVのチャネルの変更時間を短縮する」、2009年5月。
[MULTICAST-ACQ] Begen, A. and E. Friedrich, "Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", Work in Progress, May 2011.
[Multicast-ACQ] Begen、A。およびE. Friedrich、「RTPコントロールプロトコル（RTCP）拡張レポート（XRS）のマルチキャスト取得レポートブロックタイプ」、2011年5月の進行中。
[RAMS-SCENARIOS] Begen, A., "Considerations and Guidelines for Deploying the Rapid Acquisition of Multicast Sessions (RAMS) Method", Work in Progress, June 2011.
[Rams-Scenarios] Begen、A。、「マルチキャストセッション（RAMS）メソッドの迅速な買収を展開するための考慮事項とガイドライン」、2011年6月、進行中の作業。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F。およびC. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control Protocol (DCCP)", RFC 5762, April 2010.
[RFC5762] Perkins、C。、「RTPおよびThe Datagram輻輳制御プロトコル（DCCP）」、RFC 5762、2010年4月。
[RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)", RFC 6015, October 2010.
[RFC6015] BEGEN、A。、「1-Dインターリーブパリティフォワードエラー補正（FEC）のRTPペイロード形式」、RFC 6015、2010年10月。
[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 6222, April 2011.
[RFC6222] Begen、A.、Perkins、C。、およびD. Wing、「RTPコントロールプロトコル（RTCP）標準名（CNAME）を選択するためのガイドライン」、RFC 6222、2011年4月。
[SRTP-EKT] McGrew, D., Andreasen, F., Wing, D., and K. Fischer, "Encrypted Key Transport for Secure RTP", Work in Progress, March 2011.
[SRTP-EKT] McGrew、D。、Andreasen、F.、Wing、D。、およびK. Fischer、「安全なRTPのための暗号化されたキートランスポート」、2011年3月の作業。
[UPnP-IGD] UPnP Forum, "Universal Plug and Play (UPnP) Internet Gateway Device (IGD)", December 2010.
[UPNP-IGD] UPNPフォーラム、「ユニバーサルプラグアンドプレイ（UPNP）インターネットゲートウェイデバイス（IGD）」、2010年12月。
Authors' Addresses
著者のアドレス
Bill Ver Steeg Cisco 5030 Sugarloaf Parkway Lawrenceville, GA 30044 USA
Bill Ver Steeg Cisco 5030 Sugarloaf Parkway Lawrenceville、GA 30044 USA
EMail: billvs@cisco.com
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco 181 Bay Street Toronto、M5J 2T3カナダ
EMail: abegen@cisco.com
Tom Van Caenegem Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium
Tom Van Caenegem Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium
EMail: Tom.Van_Caenegem@alcatel-lucent.be
Zeev Vax Magnum Semiconductor, Inc. 591 Yosemite Drive Milpitas, CA 95035 USA
Zeev Vax Magnum Semiconductor、Inc。591 Yosemite Drive Milpitas、CA 95035 USA
EMail: zeev.vax@magnumsemi.com