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
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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）Joinメッセージを発行する、同じマルチキャストセッションへの参加を希望する場合、それはセッションのためのフィードバック目標にリクエストを送信し、リファレンス情報を要求します。再送サーバは、新しいユニキャスト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セッションのユニキャストベースの迅速な取得と、このメソッドを参照してください。この方法の主な使用ケースは、圧縮されたビデオストリームをランダムこれらのセッションに参加する異なるSSMセッションと視聴者にマルチキャストされるIPTVネットワークにおけるチャネル変更時間を低減することです。
-----------------------
+--->| 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受信機の両方が同じエッジネットワーク内にある限り、この仮定は一般的に成り立ちません。したがって、このソリューションは、インターネットの任意のベストエフォート型の経路を横切って使用すべきではありません。さらに、この解決策は、既に非輻輳応答マルチキャストトラフィックを運んでいるネットワークで使用され、（ユニキャスト）を確保するために再送サーバにメカニズムを絞る持たなければならないトラフィックがマルチキャスト負荷に既知の一定上限乗数であるバースト。
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セッションが再送信サーバーによって確立され、再送サーバによって送信されます。このユニキャストRTPセッションが関連付けられているプライマリマルチキャストRTPセッションから分離されています。 （I）その関連するユニキャストフィードバックおよび（ii）ユニキャストRTPセッションにプライマリマルチキャストRTPセッション：結果として、迅速な取得プロトコルの単一のインスタンス内の2つの異なる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節では、迅速な取得のためのプロトコルの設計上の考慮事項の概要を説明します。我々は、それぞれの実施例およびNATに関連する問題、の問題シグナリングセッション記述プロトコル（SDP）を議論セクション6および7部8,9の急速な取得方法のプロトコルの詳細を提供します。最後に、セクション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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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ストリーム（S）。
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]とIPv4のマルチキャストリスナ探索プロトコル（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セッション：一つ以上のユニキャストバースト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.
（ユニキャスト）バースト（ストリーム）：急速プライマリマルチキャストストリームに関連付けられた参照情報を取得するRTP受信機を有効RTP再送パケットのユニキャストストリーム。各バーストストリームは、プライマリマルチキャストRTPセッション内で一意であるその同期ソース（SSRC）識別子によって識別されます。 [RFC4588]でのセッション多重化ガイドラインに従って、各ユニキャストバーストストリームは、プライマリマルチキャストRTPストリームとして同じSSRC及び正規名（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つのマルチキャストセッションから切り替えるときに取得遅延に寄与する三個の大要素があります。これらは：
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）よりも通常より少ない待ち時間を、参加しています。受信機は新しいセッションに参加する前に、別のマルチキャストセッションに参加していた場合は、セッションを残してその上流のルータにLeaveメッセージを送信する必要があります。共通のマルチキャストルーティングプロトコルでは、離脱時間は、通常、参加倍よりも小さいです。しかし、それはそれを残すことも可能であるとJoinメッセージをマルチキャストスイッチング遅延が必然的に増加する場合には、失われてしまうかもしれません。
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.
リファレンス情報の待ち時間は、それが参照情報を取得するために受信機にかかる時間です。これは、受信機は参照情報は参照情報を連続的に送信されたか否か、セッションで受信機に送信される次回にセッションに参加し、実際の時間の近接性、及び参照情報のサイズに大きく依存します。いくつかのマルチキャストフローについては、参考情報の待ち時間がnilか、無視することができるであろう、その場合には、データ、中にほとんど、あるいは全く相互依存性があります。他のマルチキャストフローのために、相互依存度が高いです。関心の一例は、圧縮されたオーディオ/ビデオを運ぶマルチキャストフローです。これらのフローについては、参考情報の待ち時間が非常に大きくなると、全体的な遅延に大きく貢献することができます。
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]）と再送信。これらの損失の修理方法は、適切に機能するために、受信側でバッファリングが必要です。多くのアプリケーションでは、アプリケーションにそれらを供給する前に、着信データパケットをジッタに解除することもしばしば必要です。デジッタプロセスは、バッファリング遅延を増加させます。これらのネットワーク関連のバッファリング遅延に加えて、個々のアプリケーションが必要とする特定のバッファリングの必要性もあります。例えば、標準的なビデオデコーダは、典型的には、符号化された映像データは、従来のビデオビットストリームをデコードするために開始するプリデコーディングバッファにおいて利用可能であるとの、時には数秒まで、一定量を必要とします。
5. Protocol Design Considerations and Their Effect on Resource Management for Rapid Acquisition
5.プロトコルの設計上の考慮事項とRapid取得のためのリソース管理上における効果
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））、およびのホームネットワーク内に存在しています加入。これらのリンクの一部は、その加入者のトラフィックに輻輳の影響を制限する、唯一の単一の加入者にサービスを提供かもしれませんが、他の人は、多くの加入者のマルチキャストセッションを搬送するリンクを共有することができます。また、これらのリンクの状態が経時的に変化することに注意してください。受信機は、このネットワークの一部の知識を持っているか、またはネットワーク全体の部分的な知識を持っているかもしれません。このネットワーク状態情報を取得するためにデバイスによって使用される方法は、この文書の範囲外です。受信機は、それが扱うことができると考えている帯域幅を持つサーバーを通知することができるはずです。また、サーバは、それは知っているパフォーマンスエンベロープ内に滞在するために、流れをレート制限できるようにする必要があります。サーバーと受信機の両方が要求さや料金を納入の変化の他に通知できるようにする必要があります。しかし、プロトコルは、パケット損失の存在下で、堅牢でなければならないので、このシグナリングは、適切なデフォルト動作を含める必要があります。
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.
第二の課題は、ユニキャストバーストのフロー持続時間が短いながら、いくつかの用途（例えば、高ビットレートビデオ）ユニキャストバーストビットレートのために高いことです。ユニキャストバーストの目的は、RTP受信機が迅速にマルチキャストに参加し、それによってバーストによって消費される全体的なリソースを制限できるようにするためです。このような高ビットレート、短時間のフローは従来のアドミッション制御技術に適していません。例えば、エンド・ツー・エンドのフロー単位は、リソース予約プロトコル（RSVP）などのアドミッション制御技術が急速取得のための良好なフィットであるには余りにも多くの遅延および制御チャネルのオーバーヘッドが合図をしました。同様に、遅延の多くのラウンドトリップ時間（RTTの）を導入することにより、最初の場所で迅速な取得を試みるの目的を台無しにしてしまうの混雑を誘発避けるために、3ウェイハンドシェイクとスロースタートとTCP（またはTCPのような）アプローチを使用して。
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（単にマルチキャストセッションに参加するとの比較）。結合した合理的なサイズは、Bは、プライマリマルチキャストストリームの公称帯域幅であり、Eは、過剰帯域幅の係数B、* Eです。ユニキャストバーストの全持続時間は、合理的なバウンドを有していなければなりません。長いユニキャストバーストがシステム全体のマルチユニキャストの帯域幅プロファイルに委譲します。
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.
上記に加えて、考慮すべきいくつかの他のプロトコルの設計上の問題があります。まず、RTT制御ループにおける「スロップ」の少なくとも一つがあります。急速獲得バーストを開始するには、これは、ユニキャストバーストを要求しているクライアントとバーストの説明及び/又は受信機に到着する最初のユニキャストバーストパケット間の時間として現れます。ユニキャストバーストを管理し、終了するため、制御ループのための2つの可能なアプローチがあります。まず、受信機は、受信されたように、ユニキャストバーストに適応観察に基づいて収束し、明示的に（ちょうどないユニキャストバーストを出発物質として、1 RTTの最小値をとる）第2の制御ループの交換とユニキャストバーストを終了することができます。あるいは、ユニキャストバーストを生成するサーバは、最初の要求での情報に基づいて、バーストパラメータを事前に計算し、受信機にバースト期間を伝えることができます。
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]はSSMセッションでユニキャストフィードバックを使用するRTP制御プロトコル（RTCP）の拡張を指定します。これは、SSMのコンテキストで、RTPデータを配信し、すべてのRTP受信機にRTCP情報を再配布、配布ソース、の概念を導入アーキテクチャを定義しています。この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)
または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メッセージを用いてパケット損失を示すか、迅速によりプライマリマルチキャストRTPセッションを取得するRTP_Rxの要望を示す、そのRTCPフィードバックメッセージを送信するエンティティでありますこの文書で定義されたRTCPフィードバックメッセージ。バースト/再送信ソース（BRS）は、これらのメッセージに、迅速な取得プロセスの場合、RTP_RxとのさらなるRTCP相互作用に応答する責任がありますが、それはこの文書の残りの部分で想定されるこれら二つの論理エンティティ（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に送信され、ユニキャストバースト/再送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.
（フィードバック（AVPF）とRTP /オーディオビジュアルプロファイル）RTCPベースのフィードバックのための拡張RTPプロファイルで、プライマリマルチキャストRTPセッションでFTに送信されたこれらのメッセージの両方のスケジューリングに適用される特定のルールが存在します。これらは、[RFC4585]の3.5節で詳述されています。ルールの一つは、そのような私たちはこの仕様で検討しているSSMセッションなどのマルチパーティセッションでRTP_Rxがセッションに参加した後、1秒の最小のためのRTCPフィードバックメッセージを送信できないと述べている（すなわち、Tminを= 1.0秒） 。このルールは、典型的なマルチパーティセッションでフラッシュ群衆に関連する問題を回避するという目標を持っているが、それは急速な買収の目的に反し。 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は、そのRTPとRTCPがユニキャスト用のポートがRTPセッションをバースト受信を選択する必要があります。このユニキャスト・セッションが確立されているので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.
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識別子を含み、関心の主要マルチキャストストリーム（S）（メディアソースの別名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.
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はRTP_Rxによって要求されたバースト（複数可）の状態を伝えるためにRTP_RxにRAMS情報（RAMS-I）メッセージ（複数可）を送信します。
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).
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が二つ以上の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（S）のサブセットの要求を受け入れることができます。 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によって提供SSRCsのいずれかに設定されています。この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によってサービスすることができない各プライマリマルチキャストストリームのため（セクション11.6で定義されるように）適切な5xxのレベルの応答コードと別個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が同じ要求の送信を再試行したい場合は、不十分なBRSやネットワークリソースとして一時的な問題を示す応答を拒否受信すると、RTP_Rxは一時的な問題が離れて行くことができるように、[RFC4585]のRTCPタイマーのルールに従わなければなりません。しかし、拒否応答は、非一時的な問題（例えば、応答コード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メッセージを送信しなければならないことにより、要求された各プライマリマルチキャストストリームに対して（セクション11.6に記載されているように成功したことを示すプライベート応答または応答コード200を示すゼロのいずれか） 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_Rxが欠落している最初のパケット（複数可）を検出することを可能にするために、それぞれのRTPストリーム内で送信される最初のパケットのRTPシーケンス番号を運びます。 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メッセージが表示されます仮定してはいけません。冗長性のために、[RFC4585]で定義されたRTCPタイマーのルールを次のようにBRSは限り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.ユニキャストバースト：要求が受け入れられたのプライマリマルチキャストストリーム（S）の場合、BRSは、ユニキャストで送信された一つ以上のRTP再送信パケットはRTPセッションバースト含むユニキャストバースト（複数可）を送信開始します。いくつかの用途において、BRSは、プライムメディアデコーダ（単数または複数）に要求されたバーストに加えてRTP_Rxにプリアンブル情報データを送信することができます。しかし、BRSは、特定の形式のプリアンブル情報を送信するために、RTP_Rxから明示的なシグナリングが必要とされています。セクション7.1で定義されるようRTP_Rxがパブリックまたはプライベート拡張を介してRAMS-Rのメッセージにそのフォーマットをサポートして合図していない限り、換言すれば、BRSは、特定の形式のプリアンブル情報を送ってはいけません。
The format of this preamble data is RTP-payload specific and not
specified here.
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つまたは複数のフィールドに異なる値を持つ（プライマリマルチキャストRTPセッションにおけるユニキャストフィードバックとして）更新RAMS-Rのメッセージを送信することができます。 BRSは、バーストが既にために計画されているか、この特定のメディア送信元SSRCこの特定RTP_Rxに伝達されるかどうかを検出できなければなりません。既存のバーストのために計画されたまたは送信されているが存在する場合、新たに到着RAMS-Rが更新要求です。それ以外の場合は、新しい要求です。 RTP_Rxが不適切にフォーマットRAMS-Rのメッセージを送信またはRAMS-Rメッセージに無効な値を使用していることも可能です。 4XXレベルの応答コードを使用して（セクション11.6で定義されるように）のみ[RFC4585]のタイミング規則に従った後BRSで通知した場合、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.
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は、それが行われた変更を示すために、ユニキャストバースト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以前RAMS-Iメッセージに1つ以上のフィールドの値を更新するために、例えば、ユニキャストバーストRTPセッションで複数のRAMS-Iメッセージを送信することができます。更新RAMS-IメッセージがまたはRAMS-Rメッセージに直接応答できない場合があります。 BRSはまた、BRSはすでにバーストの開始時に、例えば、初期RAMS-Iメッセージを送ったときSSMセッションに参加するために、リアルタイムでRTP_Rxを知らせるために更新RAMS-Iメッセージを送ることができます。 RTP_Rxは、最初のRAMS-Iメッセージで伝えることができるか、後でRAMS-Iメッセージに改訂/送信することができます参加時間を、学ぶためにBRSに依存します。 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がJoinメッセージを送信する必要があるときBRSを明示的に知らせることができます。それは、より正確な情報を持っていない限り、RTP_Rxは、最新のRAMS-Iメッセージからこの情報を使用すべきです。要求が受け入れられた場合、この情報は、少なくとも一つの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.
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は（RAMS-T）ユニキャストでRTCPフィードバックとして送信されたメッセージは、RTPセッションバーストRAMS終端を使用します。 RTCP BYEメッセージをユニキャストで送信されていない限り、別個RAMS-Tメッセージは、BRSによってサービス各プライマリマルチキャストストリームに対して送信されBRSによって拒否されたバースト要求の場合、ステップ10で説明したようにRTPセッションバースト、あります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.
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メッセージを送らなければなりません。それはその元のシーケンス番号（OSN）フィールドRTP再送信ペイロードヘッダにおいてこの番号から1を引いたものと一致するユニキャストバーストパケットを送信した後、次いで、BRSは、それぞれのバーストを終了しなければなりません。 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によってサービスされる各一次マルチキャスト・ストリームのための少なくとも一つのRAMS-Tメッセージを送らなければなりません。 RAMS-Tメッセージ（単数または複数）は、ユニキャストバーストRTPセッションにおいてBRSに送信されなければなりません。メッセージの損失の可能性に対して、[RFC4585]で定義されたRTCPタイマールールを次のようにRTP_Rxは限り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.
前記RTCP BYEで終了：RTP_Rxは、1つ以上のバーストストリームを受信しているときRTP_Rxがもはや一次マルチキャストストリームのいずれかを取得することに興味なると、RTP_Rxは、ユニキャストのためにRTCP BYEメッセージを発行しないものとRTPセッションと別のバースト主マルチキャストRTPセッションのためにRTCP BYEメッセージ。これらの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.
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.
ユニキャストのために発行されたRTCP BYEメッセージは、RTPセッションは、そのセッションを終了し、そのセッション内の任意の更なるパケットを送信停止バーストので、唯一のそれぞれのバーストを終了することになる明示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の迅速な取得経験についての詳細な情報を収集するためには、[マルチキャスト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セッションで送信され、頻繁ヘッダの拡張もRTPの迅速な同期がRAMSをサポートするか、それが直接RAMSを実行せずに、マルチキャストセッションに参加していない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間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）（セクション7.2を参照）は、最大RAMSバッファとして、RAMS-Rのメッセージを介して得られた情報は、要件を満たし、/又はMaxはビットレートを受信します。
(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レシーバレポートを介して取得した情報を、。これらのレシーバレポートは、パケット損失を示しているときに、これはRTP_RxへのRSからのパスに特定の輻輳状態を示すことができます。
(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.
バーストのためにセッションビットレートの適応を可能にする主要マルチキャストRTPセッションでRTP_Rxによって提供されるRTCPのNACKを介して得られる（C）情報、。このようなRTCPのNACKは、バーストにおけるパケットロス検出に応答してRTP_Rxによって送信されます。 NACKはRTP_RxへのRSからのパス上の特定の輻輳状態を示すことができます。
(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.
BRSによってサポートされている場合（e）の情報は、セッション中ビットレートの適応を可能にする、更新されたRAMS-Rのメッセージを介して得られます。
(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又はパケットロスがRTP_RxにRSの経路に沿った混雑の結果として生じないであろうため上限破裂ビットレートを示すRTP_Rxsのセットのための事前構成設定。例えば、エンドツーエンドパスに沿ったボトルネック帯域が知られており、ここで、RSと、このリンク間のネットワークがプロビジョニングされ、バーストストリームを搬送するような寸法管理IPTVネットワークにおいて、バーストビットレートは、プロビジョニングさ超えません値。これらの設定は、動的にアプリケーションを意識した知識を使用して適合させることができます。
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.
（g）に記載されているような環境でRAMを使用する場合、O、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.
BRSは、ユニキャストバーストのための信頼できるビットレート値を決定できない場合BRSはない公称ビットレート以上の適切な初期ビットレートを選択し、輻輳がない限り、徐々にそれを増加させるため、O、それが望ましい（（g）を介して（A）を使用して）検出されました。
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は、連続的に（F）を介して（B）で説明したメカニズムのうちの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増加とは、バーストのためのビットレートを減少することにより、速度がDCCPに定義されている輻輳制御アルゴリズムによって、（F）の場合には、UDP上のRTPのTCP向けビットレート適応アルゴリズムにより決定もしくはすることができる[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.
輻輳が永続的で、BRSはRTP_Rxバッファは下回らたりバーストがあまりにも多くのリソースを消費しますポイントにバーストビットレートを下げる必要がある場合、O、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を知らせるためBRSはRTP_Rxメッセージを参加SFGMPを送信することを想定したとき、BRSはRTP_RxはSSMセッションでマルチキャストパケットの受信を開始する時期の目安を有することができます。 BRSは、バーストパケットを送信し続けるが、考慮に入れ、全体SSMセッションのビットレートを取ることによって、適切な瞬間に応じてビットレートを低減することができます。バーストが追いつく前に、BRSは、バーストパケットを送信停止する場合、この不完全切り替えRTP_Rxによって起因する隙間は、後にRSからの欠落パケットの再送を要求することによって修復することができます。再送信は、彼らが主マルチキャストRTPセッションで担保の損失が発生していないことを確認するBRSによって形成することができ、ユニキャストは、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メッセージでもユニキャストバーストどちらを取得します。 [RFC4585]で定義されたRTCPタイマーのルールに基づいてそうする資格があるとき、この場合、RTP_Rxは、要求を再送信することができます。または、妥当な時間の後、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が断念された故障の場合に、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のメッセージが宛先に届かない場合は、BRSはRTP_Rxは、もはやそれらを必要としていても、バーストパケットを送信しない続けることができます。 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はRTP_Rxが送信するRTCPメッセージとレポートを経由してRTP_Rxの生存性をチェックする必要があります。デフォルトのルールは、同様にRAMSに適用されます[RFC3550]で説明しました。
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.
特定のシナリオとRAMSメッセージの適時性/重要性に応じて、縮小RTCPパケット[RFC5506]でそれを送信することが望ましいです。ただし、のサポートがない限り、[RFC5506]にシグナリングされている、化合物RTCPパケットは、[RFC3550]のルールに従うことによって使用されなければなりません。
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]で指定されたルールは、以下に定義されたメッセージ内のすべての整数フィールドはネットワークバイトオーダーで運ばれた後、それは、最初に、また、ビッグエンディアンとして知られている最上位バイト（オクテット）です。特に断りのない限り、数値定数は、小数点（基数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長さ：それらの間の型と長さフィールドと、8ビットのReservedフィールドを除くTLV要素の長さを（オクテットで）示す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.
プライベート拡張のために使用されなければならない構造がhttp://www.iana.orgに記載されているように、企業の数であり、ここで、図6に示されています。これは、プライベート拡張の一意性を確保し、任意の衝突を避けることができます。
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セッションまたは同じ一次マルチキャストRTPセッションに属する1つの以上の一次マルチキャストストリームの迅速な取得を要求するRTP_RxによってプライマリマルチキャストRTPセッションでユニキャストフィードバックとして送信されます。メディア送信元SSRCは知られていないので、RAMS-Rメッセージに、RTP_Rxは、それ自身の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フィールドは一つだけ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）：必須TLV要素RTP_Rxによって要求されたメディアの送信者SSRC（複数可）を示しています。 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.
Lengthフィールドは、（すなわち、いかなるメディア送信元SSRCがリストされていない）がゼロに設定されている場合、それはRTP_Rxが急速に全体プライマリマルチキャストRTPセッションを取得するように要求していることを意味します。そうでなければ、RTP_RxこのTLV要素における個々のメディア送信元SSRCsを示し、nはSSRCエントリの数である4×NにTLV要素の長さフィールドを設定します。
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.
RTP_Rxデータがアプリケーションによって消費されることを可能にする前にバッファを持っていることを望むデータの最小ミリ秒を表すオプションTLV要素：OミンRAMSバッファ（32ビット）の要件を満たします。
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.
RTP_Rxはバッファオーバーフローによるデータを失うことなく、バッファリングできるデータの最大ミリ秒を表すオプションTLV要素：O最大RAMSバッファ（32ビット）の要件を満たします。
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.
RTP_Rxがユニキャストバースト（単数または複数）の凝集とによって提供される任意のペイロード固有の情報を処理可能な（bps単位）の最大ビットレートを表すオプションTLV要素：Oマックスビットレート（64ビット）を受信しますBRS。限界値は、受信機に知られているローカル・レシーバの制限ならびにネットワークの制限を含むことができます。
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
Oプリアンブルのみ（0ビット）可：オプションTLV要素RTP_RxのみBRSがユニキャストバーストストリーム（単数または複数）を送信できない場合に所望の一次マルチキャストストリーム（S）のためのプリアンブル情報を受信する意思があることを示しています。 （このような場合には、BRSは、要求を受け入れないが、セクション11.6で定義されるようにRAMS-Iメッセージで応答コード511を送信する。）なお、
the RTP_Rx signals the particular preamble format(s) it supports through a public or a private extension in the same RAMS-R message.
RTP_Rxは、パブリックまたは同じ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要素は、値フィールドを有していないので、Lengthフィールドはゼロに設定しなければなりません。
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サポートされている企業の数（S）：オプションのTLV要素RTP_Rx実装がサポートしている企業の数（複数可）を示しています。 http://www.iana.orgに記載されたプライベート拡張と同様に、ここでは企業数があります。このTLV要素、存在する場合は、プライベート拡張RTP_Rxが潜在的にサポートできるかについてのBRSにヒントを提供します。 RTP_Rxは、必ずしも特定の企業数の下にあるすべてのプライベート拡張をサポートしていないことに注意してください。 BRSが明示的にプライベートた拡張RTP_Rxサポート（このまたは一部の帯域外の手段を通じて）を知っている場合を除き、BRSは、RAMS-Iメッセージにプライベート拡張を使用しないでください。 BRSはむしろ唯一のベンダー中立の拡張機能を使用すべきです。このTLV要素の長さフィールドは、nは企業数のエントリの数である4×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によりRTPセッションバーストユニキャストで送信されます。これらRAMS-Iメッセージの各々において、メディア送信元SSRCおよびパケット送信元SSRCフィールドは、両方のそれぞれの一次マルチキャストストリームのSSRCに等しいBRSのSSRCに設定されています。
The FCI field MUST contain only one RAMS Information message. The FCI field has the structure depicted in Figure 8.
FCIフィールドは一つだけ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の値がゼロに設定されます。迅速な取得の間、同じRAMS-Iメッセージは、MSNの値をインクリメントすることなく、冗長性のために繰り返されてもよいです。更新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は、BRSにすぐにRAMS-Tメッセージを送らなければなりません。
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メディア送信者SSRC（32ビット）：ユニキャストバーストストリームのメディア送信元SSRCを指定するオプションTLV要素。 RAMS-Rのメッセージを受信FT_Apは、単一の一次マルチキャストストリームに関連付けられているが、要求されたメディアの送信元SSRCこのFT_Apに関連付けられたRTPストリームのSSRCと一致しない場合、BRSは、初期RAMS-IでこのTLV要素を含みますRTP_Rxがメディア送信者SSRCが変更されたことを知らせるメッセージが表示されます。 2 SSRCsが一致した場合、この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.
先頭パケットのRTP O 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.
（バーストパケットまたはペイロード固有のパケットであってもよい）、ユニキャストRTPストリームの最初のRTPパケットの到着間隔（ミリ秒）のデルタ時間を指定TLV要素と：O最も早いマルチキャストは時間（32ビット）に参加しますRTP_RxがSFGMPがマルチキャストセッションに参加するJoinメッセージを送るかもしれ早い時刻。この要素に示されているゼロの値がRTP_RxがSFGMPはすぐにJoinメッセージを送信してもよいことを意味します。 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要求が受け入れられた場合RTP_Rxは、マルチキャストセッションに参加する際に知っているように、BRSは、少なくとも一度は、この要素を送ります。応答フィールドに示されているように、バースト要求が拒否された場合、この要素はゼロ値を示さなければなりません。その場合には、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に基づいてメッセージを参加送ります早いの時間に参加します。
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ビット）：バースト（ミリ秒）続く時間を示しオプションTLV要素、すなわち、BRSはで送信するように計画している最初と最後のバーストパケットの予想伝送時間の差それぞれのユニキャスト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-T又はRTP_RxからBYEメッセージを取得しない場合でも、それらの後発事象によって確立された持続時間で示す期間内の流れを停止しなければなりません。バースト要求が受け入れられたとき、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最大送信ビットレート（64ビット）：このRAMS-Iメッセージに関連付けられたRTPストリームのためにBRSによって使用される（bps単位）の最大ビットレートを表すオプション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.
100 O：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.
201 O：ユニキャストバーストが完了したと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ベースのエラー状態を収集するためにマルチキャスト取得レポート・ブロック[マルチキャストACQ]のステータスコードとして使用されます。
o 400: This is used when the RAMS-R message is improperly formatted.
400○：RAMS-Rのメッセージが正しくフォーマットされている場合に使用されます。
o 401: This is used when the minimum RAMS buffer fill requirement value indicated in the RAMS-R message is invalid.
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.
402○：RAMS-Rのメッセージに示された最大RAMSバッファ充填要求値が無効である場合に使用されます。
o 403: This is used when the maximum receive bitrate value indicated in the RAMS-R message is insufficient.
403○：最大値が不十分であるRAMS-Rのメッセージに示されたビットレート値を受信したときにこれが使用されます。
o 404: This is used when the RAMS-T message is improperly formatted.
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ベースのエラー状態を収集するためにマルチキャスト取得レポート・ブロック[マルチキャストACQ]のステータスコードとして使用されます。
o 500: This is used when the BRS has experienced an internal error and cannot accept the RAMS request.
500○：これはBRSで内部エラーが発生しましたときに使用され、RAMS要求を受け入れることはできません。
o 501: This is used when the BRS does not have enough bandwidth to send the unicast burst stream.
501 O：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.
503 O：BRSは、ユニキャストバーストストリームを送信するために十分なCPUリソースを持っていない場合に使用されます。
o 504: This is used when the BRS does not support sending a unicast burst stream.
504 O：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.
506 O：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.
507○：BRSはRTP_Rxの要件を満たすユニキャストバースト・ストリームのための有効な出発点を見つけることができない場合に使用されます。
o 508: This is used when the BRS cannot find the essential reference information for the requested multicast stream.
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.
510○：これは、BRSは、要求されたセッション全体にサービスを提供できない場合に使用されます。
o 511: This is used when the BRS sends only the preamble information but not the whole unicast burst stream.
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.
512○：RAMS要求が拒否されたとき、これは、要求されたマルチキャストストリーム、RTP_Rx、またはこの特定のBRSのポリシーに使用されています。
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.
RAMS終端バーストを停止するときを決定する際にBRSを支援するために使用されます。別RAMS-Tメッセージをユニキャストで送信されるBRSによってサービスされている各プライマリマルチキャストストリームに対してRTP_RxによりRTPセッションバースト。これらの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は、バーストのすべてを終了したい場合は、単一の複合RTCPパケットにそれぞれのRAMS-Tメッセージの全てを送信する必要があります。
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フィールドは一つだけ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].)
（[RFC4585]で定義されるように、以下のABNF [RFC5234]は、RTCP-FB-NACK-PARAMが使用されています。）
rtcp-fb-nack-param =/ SP "rai"
Rtisipi-phambu-NAG-購入= /レスポンス "石"
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「ライは」迅速な取得指示の略で、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属性（「ラム・アップデート」）を定義します。この属性は、宣言的に使用され、何のオファー/アンサーモデルの挙動が指定されていません。 BRSが更新要求メッセージをサポートしており、この属性がSDP記述に含まれている場合、RTP_Rxが更新要求を送信することができます。 BRSは、または更新RAMS-Rのメッセージ内のすべてのフィールドの値の変化を受け入れることができない場合があります。 「ラム・アップデート」属性が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]
SDPグルーピングフレームワークOおよび識別（FID）意味論[RFC5888]を流れ
o The RTP/AVPF profile [RFC4585]
RTP / AVPFプロファイルO [RFC4585]
o The RTP retransmission payload format [RFC4588]
RTP再送信ペイロードフォーマットO [RFC4588]
o The RTCP extensions for SSM sessions with unicast feedback [RFC5760]
ユニキャストフィードバック[RFC5760]とSSMセッションのRTCP拡張O
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]
'ポートマッピング-REQ' 属性O [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.
「SSRC」属性は、メディア記述に使用する場合、ソース特有のメディア属性[RFC5576]のサポートも必要になることができます。
This section provides a declarative SDP [RFC4566] example (for the RTP_Rx side) for enabling rapid acquisition of multicast RTP sessions.
このセクションでは、マルチキャストRTPセッションの迅速な取得を可能にする（RTP_Rx側用）宣言SDP [RFC4566]の例を提供します。
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：シングルチャネルRAMSシナリオの例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の記述では、プライマリマルチキャスト（ソース）ストリーム及びユニキャスト再送ストリームを有しています。ソースストリームが（198.51.100.1の送信元IPアドレスを持つ）配信元から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で（192.0.2.1のアドレスを持つ）RS上に存在するフィードバック目標（FT_Ap）が「A = RTCP」行[RFC3605]で宣言されています。ライン：従来の再送信のためのサポートは、「98 NACK A = RTCP-FB」を介して示されています。 RTPレシーバー（複数可）フィードバック目標と要求再送信にソースストリームの欠落パケットを報告することができます。再送が一方向のみに送信されるので、上記SDPは、再送ストリームのメディアについては、「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-時間」、従来の再送信と迅速な取得の両方に適用されます。迅速な取得が有効になっている場合ただし、[RFC4588]で指定されたパラメータ「RTX-時間」のための標準的な定義が続いていません。その代わり、迅速な取得支援が有効になっている場合、「RTX-時間」BRSはありません示された時間から、パケットがBRSで受信した時刻から測定した再送（のためにそのキャッシュに利用できるRTPパケットを保持する時間をミリ秒単位で指定しますパケットのタイムスタンプで）。
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が唯一のRTPストリームに関連付けられている場合、RTP_Rxは、アウトオブバンド方式を経由してそのストリームのSSRCを学習する必要はありません。 BRSは、迅速な取得要求を受け入れた場合、それが正しいSSRC識別子にRAMS-Iメッセージを送信します。 FT_Apは、マルチストリームのRTPセッションに関連付けられており、RTP_Rxは、セッション全体のための迅速な取得を要求する意思がある場合は、RTP_Rxは再びアウトオブバンド方式経由SSRCsを学習する必要はありません。 RTP_Rxがプライマリマルチキャストストリームの特定のサブセットを要求しようとする場合しかし、それは彼らのSSRC識別子を学び、RAMS-Rのメッセージでそれらをリストする必要があります。このRTP_Rxまだプライマリマルチキャストストリーム（S）のための任意の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].
SSRC衝突が発生したときにSDPファイル内のプライマリマルチキャストストリームの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セッションに追いつくために望んでいることを認識するようになります。必要条件が満たされている場合（セクション7に概説されるように[RFC4585]）と利用可能なリソースは、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は[RAMS-シナリオ]に提示されていると同時に、複数のプライマリマルチキャスト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つ以上のネットワークアドレスポート翻訳者（以下、単にNATと呼ばれるNAPTは、）RTP_RxとRSの間に存在することができます。 NATは、UDPトラフィックの動作特性の多様性を持っている[RFC4787]。 NATはRTP_Rxに到着するBRSからのトラフィックを許可するためには、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。 UDP（またはDCCP）（NATの「外」にある）BRSに（NATの「内部」にある）RTP_Rxから送信されるトラフィックを参照してください。このトラフィックは、その後の応答トラフィックと同じトランスポートアドレスを持っている、または
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は、NATが生き結合、少なくとも30秒ごとに[RFC4787]を維持するためにUDPトラフィックを送らなければなりません。 （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セッションにおけるユニキャストフィードバックとしてFTに要求（RAMS-R）メッセージを送信し、要求がFTによって受信されると、新しいユニキャストは、RTPセッションがBRSとRTP_Rxとの間に確立されるバースト。
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セッション（一方マルチキャスト一のユニキャスト）であり、それらの一方が他方に送信されたフィードバック・メッセージをもとに確立されているので、これは明示的なポートマッピング方法を必要とします。
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を使用するアプリケーションは、RTP受信機がそれらの所望のポートを使用し、NATデバイスの背後にRAMSをサポートすることを可能にするRSとRTP_Rx側の両方の[RFC6284]に提示された方法をサポートしなければなりません。ポートマッピングメッセージ交換はRTP_Rxが急速に先立ち関連するSSMのセッションに参加するには、特定のマルチキャストRTPセッションを取得するためのRAMSプロトコルの使用をしようとする時はいつでも場所を取る必要があります。
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.
RAMSを使用しているアプリケーションは、[RFC5760]に記載されたユニキャストフィードバック機構、[RFC4588]で定義されたペイロード・フォーマット、および[RFC6284]で指定されたポートマッピング溶液を多用します。したがって、これらのアプリケーションは、それらの文書で説明した一般的なセキュリティの考慮の対象となっています。特に、[RFC5760]で議論脅威とリスクを慎重に検討する必要があります。このセクションでは、RAMSの観点から、これらの仕様で説明するガイドラインと提案の概要を与えます。我々はまた、明示的に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.
一つ以上の再送をトリガする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受信機が間違った決定を下すことがあります。その結果、RAMS操作が失敗する可能性があります。
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メッセージに示された値が妥当である場合に考慮しなければなりません。再送サーバー上のDoS攻撃を延長しようとする試みである可能性が高いので、例えば、要件要素を埋める分RAMSバッファーで何秒の大きな値を要求し、要求が、特殊なユースケースがない限りおそらく、存在するはずが拒否され、RTP受信機、及び/又はネットワーク。マックスは、ビットレートを受信、ネットワークによってサポートされませんビットレートで破裂による大規模な渋滞を引き起こす再送サーバーを取得しようとする非常に大きな値に設定することができます。最古のマルチキャストの値は、時間に参加して、RAMS-Iメッセージで再送サーバによって示されたバースト期間が合理的である場合RTP_Rxも検討すべきです。バーストパケットが到着停止し、参加時間が未来にかなり遠く、まだであれば、例えば、これは、RAMS-Iメッセージが攻撃者によって操作されたman-in-the-middle攻撃の兆候かもしれません。
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の一連のメッセージは、一時的に再送サーバが過負荷にすることができます。そのリソースが再び利用可能になるまで、このような状況では、再送信サーバは、例えば、入ってくるRAMS要求を拒否することができます。一つは、この脅威が着信RAMS要求にあたり、エンドポイントポリシングメカニズムを適用することで改善することを意味します。合理的なポリシングメカニズムは、アプリケーション固有の要件を考慮し、偽陰性を最小限に抑える必要があります。
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は、リプレイ攻撃は少ないが、不可能ではないになり、シーケンス番号を持っています。捕捉注入、又はRAMSメッセージを容易上記の攻撃を達成することができる修飾することが可能であるman-in-the-middle攻撃。このように、暗号化整合性と認証は、唯一の信頼できる保護です。 man-in-the-middleからRTCPメッセージを保護し、攻撃を再生するに、RTP受信機及び再送サーバは、RTCPチャネル上でデータグラムトランスポート層セキュリティ（DTLS）-SRTP握手[RFC5764]を実行する必要があります。 RTP受信機及び再送サーバの間には整合性が保護シグナリングチャネルが存在しないので、再送サーバーは、正当なRTP受信機が所有している証明書のリストを維持しなければなりません、またはその証明書は信頼できる認証局によって署名されなければなりません。 DTLS-SRTPのセキュリティが確立されると、特定のRTP受信機から受信した非SRTCPで保護されたメッセージを再送信サーバーによって無視されます。同一の再送サーバ上の異なるフィードバックターゲットとの通信時にDTLS-SRTPオーバーヘッドの影響を低減するために、それが推奨されるRTP受信機とサーバ側の状態[RFC5077]せずに再送サーバの両方をサポートTLSセッション再開。同一のデータの再送信を求める多くのRTP受信機を処理するために、スケールのSRTPを支援するために、実装者は、[SRTP-EKT]受信者に送信された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
アリは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.
マルチキャスト取得方法レジストリの「RAMS」（値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
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]
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]
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少なくとも名前、住所、電子メールなどの登録をしている1の情報を、お問い合わせください。
o A detailed description of what the new SFMT represents and how it shall be interpreted.
新しいSFMTが何を表すかの詳細な説明Oとそれがどのように解釈されなければなりません。
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少なくとも名前、住所、電子メールなどの登録をしている1の情報を、お問い合わせください。
o A detailed description of what the new TLV element represents and how it shall be interpreted.
新しいTLV要素が何を表すかの詳細な説明Oとそれがどのように解釈されなければなりません。
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:
レスポンスフィールドの長さは65536のコードをできるように、2つのオクテットです。しかし、この文書では、応答コードはHTTPスタイルのコード番号以下に分類して登録されています。新しい応答コードは、以下のガイドラインに従って分類されるべきです。
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 RAMS要求が受け入れられている[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]
400無効RAMS-Rのメッセージ構文[RFC6285] RAMS-Rのメッセージ401が無効分のバッファ要件[RFC6285] RAMS-Rのメッセージ402無効な最大バッファ要件[RFC6285] RAMS-Rのメッセージ403不十分な最大ビットレート要件[RFC6285] 404無効RAMS-Tメッセージ構文[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]
500不特定BRS内部エラーが発生しました[RFC6285] 501 BRS 502バーストは、ネットワークの混雑[RFC6285] 503 BRSはRAMSセッション[RFC6285] 504 RAMS機能を開始するのに十分なCPUサイクルを有するに終了するRAMSセッション[RFC6285]を開始するのに十分な帯域幅を有しています[RFC6285] 508 507 BRSは、要求されたマルチキャストストリームのために利用できる有効な出発点を有していない[RFC6285]は機能が要求されたマルチキャストストリームのために利用できない[RFC6285] 505 RAMS機能はRTP_Rxのために利用可能でないBRSで506 RAMSは使用できません[RFC6285] BRSは、要求されたマルチキャストストリームのために利用可能な参照情報を有していない[RFC6285] 509 BRSは、拒否された要求されたSSRC [RFC6285] 510 RAMSセッション全体を取得するための要求に一致するRTPストリームを持っていない[RFC6285] 511のみプリアンブル情報が送信される[RFC6285 ] 512 RAMS要求がポリシーが原因で拒否された[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少なくとも名前、住所、電子メールなどの登録をしている1の情報を、お問い合わせください。
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.
デイブ・オラン、マグヌスウェスター、およびコリンパーキンスは、この仕様の開発中に提起された問題の一部にテキストやソリューションを提供することにより、この仕様に大きく貢献してきました。
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.
以下の個人はこの仕様の以前のバージョンを見直し、有益なコメント提供：イェルク・オット、ロニでも、ダン・ウィング、トニーFaustini、Peilinヤン、ジェフ・ゴールドバーグ、ミュリエル・デシャネル、のoriTレヴィン、ガイHirson、トム・テイラー、ザビエルMarjou、イェ・クイを王、Zixuanゾウ、インゲマル・ヨハンソン、海浜ソング、寧宗、ジョナサン・レノックス、ホセ・レイ、ショーン・シーディ、そしてキース糖剤。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、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]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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.、フレデリック、R.、およびV.ヤコブソン、 "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.、 "リアルタイム制御プロトコル（RTCP）セッション記述プロトコル（SDP）内の属性"、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.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
"IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）" [RFC3810]ヴィーダ、R.とL.コスタ、RFC 3810、2004年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[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]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ「ベースのフィードバック（RTP / AVPF）リアルタイムトランスポート制御プロトコル（RTCP）の拡張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]レイ、J.、レオン、D.、宮崎、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]ホルブルック、H.、カイン、B.、およびB.ハーバーマン、 "ソース固有マルチキャストのためにインターネットグループ管理プロトコルバージョン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.、周、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]クロッカー、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. Desineni、 "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]ヨハンソン、I.およびM.ウェスター、「縮小リアルタイムトランスポート制御プロトコル（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]レノックス、J.、オット、J.、およびT. Schierl、RFC 5576、2009年6月 "ソース固有のメディアセッション記述プロトコル（SDP）の属性"。
[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]オット、J.、チェスターフィールド、J.、およびE.学生、 "ユニキャストフィードバックを有する単一ソースマルチキャストセッションのために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]パーキンス、C.とM.ウェスター、 "シングルポートの多重化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]マグリュー、D.およびE.レスコラ、「データグラムトランスポート層セキュリティ（DTLS）セキュアリアルタイム転送プロトコル（SRTP）のための鍵を確立するための拡張」、RFC 5764、2010年5月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888]キャマリロ、G.およびH. Schulzrinneと、 "セッション記述プロトコル（SDP）グループ化フレームワーク"、RFC 5888、2010年6月。
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010.
[RFC6051]パーキンス、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制御プロトコルソース固有マルチキャスト（SSM）セッション用（RTCP）ポート"、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.、ウイング、D.、およびT.ヴァン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]ウェスター、M.、ヨハンソン、I.、パーキンス、C.、オハンロン、P.、およびK.カールバーグ、 "明示的輻輳通知（ECN）RTPのためのUDP上"、進行中で働い、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.、グレーズブルック、N.、およびW.版シュテーク、2009年5月 "リアルタイムトランスポートプロトコル（IEEEインターネットコンピューティング）とIPTVにチャンネル変更時間を短縮"。
[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.
[マルチキャストACQ] Begen、A.とE.フリードリヒ、進歩、2011年5月における作業 "マルチキャスト取得レポートブロックタイプRTP制御プロトコル（RTCP）拡張レポート（XRS）のために"。
[RAMS-SCENARIOS] Begen, A., "Considerations and Guidelines for Deploying the Rapid Acquisition of Multicast Sessions (RAMS) Method", Work in Progress, June 2011.
[RAMS-シナリオ] Begen、A.、「考慮事項とマルチキャストセッション（RAMS）メソッドの迅速な取得を展開するためのガイドライン」、進歩、2011年6月ワーク。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、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.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、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]パーキンス、C.、 "RTPデータグラム輻輳制御プロトコル（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]、RFC 6015、2010年10月Begen、A.、 "1-Dインターリーブパリティ前方誤り訂正（FEC）のためのRTPペイロードフォーマット"。
[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 6222, April 2011.
[RFC6222]、RFC 6222、2011年4月Begen、A.、パーキンス、C.、およびD.翼、 "RTP制御プロトコル（RTCP）正規名（のCNAME）を選択するためのガイドライン"。
[SRTP-EKT] McGrew, D., Andreasen, F., Wing, D., and K. Fischer, "Encrypted Key Transport for Secure RTP", Work in Progress, March 2011.
[SRTP-EKT]マグリュー、D.、アンドレア、F.、ウイング、D.、およびK.フィッシャー、 "セキュア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
ビル版シュテークのCisco 5030シュガーローフパークウェイローレンスビル、GA 30044 USA
EMail: billvs@cisco.com
メールアドレス：billvs@cisco.com
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
M5J 2T3カナダONアリBegenのCisco 181ベイストリートトロント、
EMail: abegen@cisco.com
メールアドレス：abegen@cisco.com
Tom Van Caenegem Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium
トム・ヴァンCaenegemアルカテル・ルーセントCopernicuslaan 50アントワープベルギー
EMail: Tom.Van_Caenegem@alcatel-lucent.be
メールアドレス：Tom.Van_Caenegem@alcatel-lucent.be
Zeev Vax Magnum Semiconductor, Inc. 591 Yosemite Drive Milpitas, CA 95035 USA
あるZeev Vaxのマグナムセミコンダクター社591ヨセミテドライブミルピタス、CA 95035 USA
EMail: zeev.vax@magnumsemi.com
メールアドレス：zeev.vax@magnumsemi.com