[要約] 要約： RFC 6659は、Rapid Acquisition of Multicast RTP Sessions (RAMS) メソッドの展開に関する考慮事項を提供しています。目的： このRFCの目的は、RAMSメソッドの効果的な展開に向けたガイダンスを提供することです。
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 6659 Cisco
Category: Informational July 2012
ISSN: 2070-1721
Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method
マルチキャストRTPセッション（RAMS）メソッドの迅速な取得を展開するための考慮事項
Abstract
概要
The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and the RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate. This often precedes, but may also accompany, the multicast stream itself. When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner. However, when there are two or more multicast streams to be acquired from the same or different multicast RTP sessions, care should be taken to configure each RAMS session appropriately. This document provides example scenarios and discusses how the RAMS solution could be used in such scenarios.
マルチキャストRTPセッションの高速取得（RAMS）ソリューションは、RTPおよびRTP制御プロトコル（RTCP）に基づく方法であり、RTP受信者がRTPマルチキャストデータをすばやく取得して消費を開始できるようにします。 RTPレシーバーからの要求に応じて、再送信サーバーとRTPレシーバーの間に補助ユニキャストRTP再送信セッションが設定され、RTPレシーバーが参加しようとしている新しいマルチキャストストリームに関する参照情報が加速レートで送信されます。これは多くの場合、マルチキャストストリーム自体に先行しますが、付随することもあります。取得するマルチキャストストリームが1つしかない場合、RAMSソリューションは簡単に機能します。ただし、同じまたは異なるマルチキャストRTPセッションから取得するマルチキャストストリームが2つ以上ある場合は、各RAMSセッションを適切に構成するように注意する必要があります。このドキュメントでは、シナリオ例を提供し、RAMSソリューションをそのようなシナリオでどのように使用できるかについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6659.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6659で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Background ......................................................3
3. Example Scenarios ...............................................4
3.1. Scenario #1: Two Multicast Groups ..........................4
3.2. Scenario #2: One Multicast Group ...........................5
3.3. Scenario #3: SSRC Multiplexing .............................6
3.4. Scenario #4: Payload-Type Multiplexing .....................6
4. Feedback Target and SSRC Signaling Issues .......................7
5. FEC during RAMS and Bandwidth Issues ............................7
5.1. Scenario #1 ................................................7
5.2. Scenario #2 ................................................9
5.3. Scenario #3 ...............................................10
6. Security Considerations ........................................10
7. Acknowledgments ................................................10
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................11
The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and the RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Through an auxiliary unicast RTP retransmission session [RFC4588], the RTP receiver receives reference information about the new multicast stream it is about to join. This often precedes, but may also accompany, the multicast stream itself. The RAMS solution is documented in detail in [RFC6285].
マルチキャストRTPセッションの高速取得（RAMS）ソリューションは、RTPおよびRTP制御プロトコル（RTCP）に基づく方法であり、RTP受信者がRTPマルチキャストデータをすばやく取得して消費を開始できるようにします。補助ユニキャストRTP再送信セッション[RFC4588]を介して、RTP受信機は、参加しようとしている新しいマルチキャストストリームに関する参照情報を受信します。これは多くの場合、マルチキャストストリーム自体に先行しますが、付随することもあります。 RAMSソリューションは[RFC6285]で詳細に文書化されています。
The RAMS specification [RFC6285] has provisions for concurrently acquiring multiple streams inside a multicast RTP session. However, the RAMS specification does not discuss scenarios where an RTP receiver makes use of the RAMS method to rapidly acquire multiple and associated multicast streams in parallel, or where different RTP sessions are part of the same Source-Specific Multicast (SSM) session. The example presented in Section 8.3 of [RFC6285] addresses only the simple case of an RTP receiver rapidly acquiring only one multicast stream to explain the protocol details.
RAMS仕様[RFC6285]には、マルチキャストRTPセッション内で複数のストリームを同時に取得するための規定があります。ただし、RAMS仕様では、RTPレシーバーがRAMSメソッドを使用して複数の関連するマルチキャストストリームを並行して迅速に取得するシナリオや、異なるRTPセッションが同じ送信元固有のマルチキャスト（SSM）セッションの一部であるシナリオについては説明していません。 [RFC6285]のセクション8.3に示されている例は、RTP受信機が1つのマルチキャストストリームのみを迅速に取得してプロトコルの詳細を説明するという単純なケースのみを扱っています。
There are certain deployment models where a multicast RTP session might have two or more multicast streams associated with it. There are also cases where an RTP receiver might be interested in acquiring one or more multicast streams from several multicast RTP sessions. Close coordination is required for multiple RAMS sessions simultaneously started by an RTP server, where each session is initiated with an individual RAMS Request message to a different feedback target. In this document, we present scenarios from real-life deployments and discuss how the RAMS solution could be used in such scenarios.
マルチキャストRTPセッションに2つ以上のマルチキャストストリームが関連付けられている場合がある特定の配置モデルがあります。また、RTPレシーバーが複数のマルチキャストRTPセッションから1つ以上のマルチキャストストリームを取得することに関心を持つ場合もあります。 RTPサーバーによって同時に開始された複数のRAMSセッションには緊密な調整が必要です。各セッションは、異なるフィードバックターゲットへの個別のRAMS要求メッセージで開始されます。このドキュメントでは、実際の展開のシナリオを紹介し、RAMSソリューションをそのようなシナリオでどのように使用できるかについて説明します。
In the following discussion, we assume that there are two RTP streams (1 and 2) that are in some manner associated with each other. These could be audio and video elementary streams for the same TV channel, or they could be an MPEG2 Transport Stream (that has audio and video multiplexed together) and its Forward Error Correction (FEC) stream.
以下の説明では、2つのRTPストリーム（1と2）が互いに何らかの方法で関連付けられていると想定しています。これらは、同じTVチャネルのオーディオとビデオのエレメンタリーストリーム、またはMPEG2トランスポートストリーム（オーディオとビデオが多重化されている）とその前方誤り訂正（FEC）ストリームの可能性があります。
An SSM session is defined by its (distribution) source address and (destination) multicast group, and there can be only one feedback target per SSM session [RFC5760]. So, if the RTP streams are distributed by different sources or over different multicast groups, they are considered different SSM sessions. While different SSM sessions can normally share the same feedback target address and/or port, RAMS requires each unique feedback target (i.e., the combination of address and port) to be associated with at most one RTP session (See Section 6.2 of [RFC6285]).
SSMセッションは、その（配信）送信元アドレスと（宛先）マルチキャストグループによって定義され、SSMセッションごとに1つのフィードバックターゲットしか存在できません[RFC5760]。したがって、RTPストリームが異なるソースまたは異なるマルチキャストグループに配信される場合、それらは異なるSSMセッションと見なされます。通常、異なるSSMセッションは同じフィードバックターゲットアドレスまたはポート、あるいはその両方を共有できますが、RAMSでは、一意の各フィードバックターゲット（アドレスとポートの組み合わせ）を最大1つのRTPセッションに関連付ける必要があります（[RFC6285]のセクション6.2を参照）。 ）。
Two or more multicast RTP streams can be transmitted in the same RTP session (e.g., in a single UDP flow). This is called Synchronization Source (SSRC) multiplexing. In this case, (de)multiplexing is done at the SSRC level. Alternatively, the multicast RTP streams can be transmitted in different RTP sessions (e.g., in different UDP flows), which is called session multiplexing. In practice, there are different deployment models for each multiplexing scheme.
同じRTPセッションで（たとえば、単一のUDPフローで）2つ以上のマルチキャストRTPストリームを送信できます。これは同期ソース（SSRC）多重化と呼ばれます。この場合、（逆）多重化はSSRCレベルで行われます。あるいは、マルチキャストRTPストリームは、異なるRTPセッションで（たとえば、異なるUDPフローで）送信できます。これは、セッションの多重化と呼ばれます。実際には、多重化スキームごとに異なる配置モデルがあります。
Generally, to avoid complications in RTCP reports, it is suggested that two different media streams with different clock rates use different SSRCs or be carried in different RTP sessions. Some of the fields in RAMS messages might depend on the clock rate. Thus, in a single RTP session, RTP streams carrying payloads with different clock rates need to have different SSRCs. Since RTP streams with different SSRCs do not share the sequence numbering, each stream needs to be acquired individually.
一般に、RTCPレポートの複雑さを回避するために、異なるクロックレートの2つの異なるメディアストリームは異なるSSRCを使用するか、異なるRTPセッションで伝送することをお勧めします。 RAMSメッセージの一部のフィールドは、クロックレートに依存する場合があります。したがって、単一のRTPセッションでは、異なるクロックレートのペイロードを運ぶRTPストリームは、異なるSSRCを持つ必要があります。 SSRCが異なるRTPストリームはシーケンス番号を共有しないため、各ストリームを個別に取得する必要があります。
In the remaining sections, only the relevant portions of the Session Description Protocol (SDP) descriptions [RFC4566] will be provided. For an example of a full SDP description, refer to Section 8.3 of [RFC6285].
残りのセクションでは、セッション記述プロトコル（SDP）記述[RFC4566]の関連部分のみが提供されます。 SDPの完全な説明の例については、[RFC6285]のセクション8.3を参照してください。
This is the scenario for session multiplexing where RTP streams 1 and 2 are transmitted over different multicast groups. A practical use case is where the first and second SSM sessions carry the primary video stream and its associated FEC stream, respectively.
これは、RTPストリーム1および2が異なるマルチキャストグループを介して送信されるセッション多重化のシナリオです。実際の使用例は、最初と2番目のSSMセッションが、それぞれプライマリビデオストリームとそれに関連するFECストリームを運ぶ場合です。
An individual RAMS session is run for each of the RTP streams that require rapid acquisition. Each requires a separate RAMS Request message to be sent. These RAMS sessions can be run in parallel. If they are, the RTP receiver needs to pay attention to using the shared bandwidth appropriately among the two unicast bursts. As explained earlier, there has to be a different feedback target for these two SSM sessions.
迅速な取得が必要な各RTPストリームに対して、個別のRAMSセッションが実行されます。それぞれに個別のRAMS要求メッセージを送信する必要があります。これらのRAMSセッションは並行して実行できます。そうである場合、RTPレシーバーは2つのユニキャストバースト間で共有帯域幅を適切に使用することに注意を払う必要があります。前に説明したように、これら2つのSSMセッションには異なるフィードバックターゲットが必要です。
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
a=group:FEC-FR Channel1_Video Channel1_FEC
m=video 40000 RTP/AVPF 96
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=ssrc:1 cname:ch1_video@example.com
a=mid:Channel1_Video
m=application 40000 RTP/AVPF 97
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtcp:42000 IN IP4 192.0.2.1
a=ssrc:2 cname:ch1_fec@example.com
a=mid:Channel1_FEC
Note that the multicast destination ports in the above SDP do not matter, and they could be the same or different. The "FEC-FR" grouping semantics are defined in [RFC5956].
上記のSDPのマルチキャスト宛先ポートは重要ではなく、同じでも異なっていてもかまいません。 「FEC-FR」グループ化セマンティクスは、[RFC5956]で定義されています。
Here, RTP streams 1 and 2 are transmitted over the same multicast group with different destination ports. A practical use case is where the SSM session carries the primary video and audio streams, each destined to a different port.
ここで、RTPストリーム1および2は、異なる宛先ポートを持つ同じマルチキャストグループを介して送信されます。実際の使用例は、SSMセッションが、それぞれ異なるポート宛のプライマリビデオストリームとオーディオストリームを伝送する場合です。
The RAMS Request message sent by an RTP receiver to the feedback target could indicate the desire to acquire all or a subset or one of the available RTP streams. Thus, both the primary video and audio streams can be acquired rapidly in parallel. Or, the RTP receiver can acquire only the primary video or audio stream, if desired, by indicating the specific SSRC in the request. Compared to the previous scenario, the only difference is that in this case the join times for both streams need to be coordinated as they are delivered in the same multicast session.
RTPレシーバーからフィードバックターゲットに送信されたRAMS要求メッセージは、使用可能なRTPストリームのすべてまたはサブセットまたは1つを取得したいという要望を示します。したがって、プライマリビデオストリームとオーディオストリームの両方を同時に並行して取得できます。または、RTPレシーバーは、必要に応じて、要求で特定のSSRCを示すことにより、プライマリビデオまたはオーディオストリームのみを取得できます。前のシナリオと比較した場合の唯一の違いは、この場合、同じマルチキャストセッションで配信されるため、両方のストリームの結合時間を調整する必要があることです。
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
m=video 40000 RTP/AVPF 96
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=ssrc:1 cname:ch1_video@example.com
a=mid:Channel1_Video
m=audio 40001 RTP/AVPF 97
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=ssrc:2 cname:ch1_audio@example.com
a=mid:Channel1_Audio
Note that the destination ports in "m" lines need to be distinct per [RFC5888].
[m]行の宛先ポートは[RFC5888]ごとに異なる必要があることに注意してください。
If RTP streams 1 and 2 share the same distribution source, then there is only one SSM session, which means that there can be only one feedback target (as shown in the SDP description above). This requires RTP streams 1 and 2 to have their own unique SSRC values (also as shown in the SDP description above). If RTP streams 1 and 2 do not share the same distribution source, meaning that their respective SSM sessions can use different feedback target transport addresses, then their SSRC values do not have to be different from each other.
RTPストリーム1と2が同じ配布ソースを共有する場合、SSMセッションは1つしかありません。つまり、フィードバックターゲットは1つだけです（上記のSDPの説明に示されているように）。これには、RTPストリーム1および2に独自の一意のSSRC値が必要です（上記のSDPの説明にも示されています）。 RTPストリーム1と2が同じ配布ソースを共有しない場合、つまり、それぞれのSSMセッションが異なるフィードバックターゲットトランスポートアドレスを使用できる場合、それらのSSRC値は互いに異なる必要はありません。
This is the scenario for SSRC multiplexing where both RTP streams are transmitted over the same multicast group to the same destination port. This is a less practical scenario, but it could be used where the SSM session carries both the primary video and audio stream, destined to the same port.
これは、両方のRTPストリームが同じマルチキャストグループを介して同じ宛先ポートに送信されるSSRC多重化のシナリオです。これはあまり実用的ではないシナリオですが、SSMセッションがプライマリビデオとオーディオストリームの両方を同じポートに送信する場合に使用できます。
Similar to scenario #2, both the primary video and audio streams can be acquired rapidly in parallel. Or, the RTP receiver can acquire only the primary video or audio stream, if desired, by indicating the specific SSRC in the request. In this case, there is only one distribution source and the destination multicast address is shared. Thus, there is always one SSM session and one feedback target.
シナリオ＃2と同様に、プライマリビデオストリームとオーディオストリームの両方を並行して迅速に取得できます。または、RTPレシーバーは、必要に応じて、要求で特定のSSRCを示すことにより、プライマリビデオまたはオーディオストリームのみを取得できます。この場合、配布元は1つだけで、宛先マルチキャストアドレスは共有されます。したがって、常に1つのSSMセッションと1つのフィードバックターゲットがあります。
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
m=video 40000 RTP/AVPF 96 97
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=ssrc:1 cname:ch1_video@example.com
a=ssrc:2 cname:ch1_audio@example.com
a=mid:Channel1
This is the scenario for payload-type multiplexing.
これは、ペイロードタイプの多重化のシナリオです。
In this case, instead of two, there is only one RTP stream (and one RTP session) carrying both payload types (e.g., media payload and its FEC data). While this scheme is permissible per [RFC3550], it has several drawbacks. For example, RTP packets carrying different payload formats will share the same sequence numbering space, and the RAMS operations will not be able to be applied based on the payload type. For other drawbacks and details, see Section 5.2 of [RFC3550].
この場合、2つではなく1つのRTPストリーム（および1つのRTPセッション）で、両方のペイロードタイプ（メディアペイロードとそのFECデータなど）を伝送します。このスキームは[RFC3550]で許可されていますが、いくつかの欠点があります。たとえば、異なるペイロード形式を伝送するRTPパケットは同じシーケンス番号付けスペースを共有し、RAMS操作はペイロードタイプに基づいて適用できません。その他の欠点と詳細については、[RFC3550]のセクション5.2をご覧ください。
The RAMS protocol uses the common packet format from [RFC4585], which has a field to signal the media sender SSRC. The SSRCs for the RTP streams can be signaled out-of-band in the SDP or could be learned from the RTP packets once the transmission starts. In RAMS, the latter cannot be used.
RAMSプロトコルは、[RFC4585]の一般的なパケット形式を使用します。これには、メディア送信側SSRCに信号を送るためのフィールドがあります。 RTPストリームのSSRCは、SDPで帯域外に通知することも、送信が開始されるとRTPパケットから学習することもできます。 RAMSでは、後者は使用できません。
Signaling the media sender SSRC value helps the feedback target correctly identify the RTP stream to be acquired. If a feedback target is serving multiple SSM sessions on a particular port, all the RTP streams in these SSM sessions are supposed to have a unique SSRC value. However, this is not an easy requirement to satisfy. Thus, the RAMS specification forbids having more than one RTP session associated with a specific feedback target on a specific port.
メディアセンダーのSSRC値を通知すると、フィードバックターゲットが、取得するRTPストリームを正しく特定するのに役立ちます。フィードバックターゲットが特定のポートで複数のSSMセッションを処理している場合、これらのSSMセッションのすべてのRTPストリームは一意のSSRC値を持っているはずです。ただし、これは簡単に満たすことができる要件ではありません。したがって、RAMS仕様では、特定のポート上の特定のフィードバックターゲットに関連付けられた複数のRTPセッションを禁止しています。
Suppose that RTP stream 1 denotes the primary video stream that has a bitrate of 10 Mbps and RTP stream 2 denotes the associated FEC stream that has a bitrate of 1 Mbps. Also assume that the RTP receiver knows that it can receive data at a maximum bitrate of 22 Mbps. SDP can specify the bitrate ("b=" line in kbps) of each media session (per "m" line).
RTPストリーム1がビットレートが10 Mbpsのプライマリビデオストリームを示し、RTPストリーム2がビットレートが1 Mbpsの関連するFECストリームを示しているとします。また、RTPレシーバーが最大22 Mbpsのビットレートでデータを受信できることを知っていると仮定します。 SDPは、各メディアセッションのビットレート（kbpsの「b =」行）を指定できます（「m」行ごと）。
Note that RAMS can potentially congest the network temporarily. Refer to [RFC6285] for a detailed discussion.
RAMSはネットワークを一時的に混雑させる可能性があることに注意してください。詳細な議論については[RFC6285]を参照してください。
This is the scenario for session multiplexing where RTP streams 1 and 2 are transmitted over different multicast groups.
これは、RTPストリーム1および2が異なるマルチキャストグループを介して送信されるセッション多重化のシナリオです。
This is the preferred deployment model for FEC [RFC6363]. Having FEC in a different multicast group provides two flexibility points: RTP receivers that are not FEC capable can receive the primary video stream without FEC, and RTP receivers that are FEC capable can decide to not receive FEC during the rapid acquisition (but still start receiving the FEC stream after the acquisition of the primary video stream has been completed).
これはFEC [RFC6363]の推奨される展開モデルです。異なるマルチキャストグループにFECがあると、2つの柔軟性の点が提供されます。FECに対応していないRTPレシーバーはFECなしでプライマリビデオストリームを受信できます。プライマリビデオストリームの取得が完了した後のFECストリーム）。
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
a=group:FEC-FR Channel1_Video Channel1_FEC
m=video 40000 RTP/AVPF 96
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=rtpmap:96 MP2T/90000
b=TIAS:10000
a=ssrc:1 cname:ch1_video@example.com
a=mid:Channel1_Video
m=application 40000 RTP/AVPF 97
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtcp:42000 IN IP4 192.0.2.1
a=rtpmap:97 1d-interleaved-parityfec/90000
b=TIAS:1000
a=ssrc:2 cname:ch1_fec@example.com
a=mid:Channel1_FEC
If the RTP receiver does not want to receive FEC until the acquisition of the primary video stream is completed, the total available bandwidth can be used for faster acquisition of the primary video stream. In this case, the RTP receiver can request a Max Receive Bitrate of 22 Mbps in the RAMS Request message for the primary video stream. Once RAMS has been completed, the RTP receiver can join the FEC multicast session, if desired.
RTPレシーバーがプライマリビデオストリームの取得が完了するまでFECの受信を望まない場合、使用可能な帯域幅の合計を使用して、プライマリビデオストリームの取得を高速化できます。この場合、RTPレシーバーは、プライマリビデオストリームのRAMS要求メッセージで22 Mbpsの最大受信ビットレートを要求できます。 RAMSが完了すると、RTPレシーバーは必要に応じてFECマルチキャストセッションに参加できます。
If the RTP receiver wants to rapidly acquire both primary and FEC streams, it needs to allocate the total bandwidth among the two RAMS sessions and indicate individual Max Receive Bitrate values in each respective RAMS Request message. Since less bandwidth will be used to acquire the primary video stream, the acquisition of the primary video session will take a longer time on the average.
RTPレシーバーがプライマリストリームとFECストリームの両方を迅速に取得する必要がある場合は、2つのRAMSセッション間で合計帯域幅を割り当て、それぞれのRAMS要求メッセージで個々の最大受信ビットレート値を示す必要があります。プライマリビデオストリームの取得に使用される帯域幅が少なくなるため、プライマリビデオセッションの取得には、平均で長い時間がかかります。
While the RTP receiver can update the Max Receive Bitrate values during the course of the RAMS session, this approach is more error-prone, due to the possibility of losing the update messages.
RTPレシーバーはRAMSセッションの過程で最大受信ビットレート値を更新できますが、更新メッセージが失われる可能性があるため、このアプローチはエラーが発生しやすくなります。
Here, RTP streams 1 (primary video) and 2 (FEC) are transmitted over the same multicast group with different destination ports. This is not a preferred deployment model.
ここでは、RTPストリーム1（プライマリビデオ）と2（FEC）は、異なる宛先ポートを持つ同じマルチキャストグループを介して送信されます。これは推奨される配置モデルではありません。
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
a=group:FEC-FR Channel1_Video Channel1_FEC
m=video 40000 RTP/AVPF 96
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=rtpmap:96 MP2T/90000
b=TIAS:10000
a=ssrc:1 cname:ch1_video@example.com
a=mid:Channel1_Video
m=application 40001 RTP/AVPF 97
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=rtpmap:97 1d-interleaved-parityfec/90000
b=TIAS:1000
a=ssrc:2 cname:ch1_fec@example.com
a=mid:Channel1_FEC
The RAMS Request message sent by an RTP receiver to the feedback target could indicate the desire to acquire all or a subset or one of the available RTP streams. Thus, both the primary video and FEC streams can be acquired rapidly in parallel sharing the same available bandwidth. Or, the RTP receiver can acquire only the primary video stream by indicating its specific SSRC in the request. In this case, the RTP receiver can first acquire the primary video stream at the full receive bitrate. But, upon the multicast join, the available bandwidth for the burst drops to 11 Mbps instead of 12 Mbps. Regardless of whether FEC is desired or not by the RTP receiver, its bitrate needs to be taken into account once the RTP receiver joins the SSM session.
RTPレシーバーからフィードバックターゲットに送信されたRAMS要求メッセージは、使用可能なRTPストリームのすべてまたはサブセットまたは1つを取得したいという要望を示します。したがって、プライマリビデオストリームとFECストリームの両方を同時に取得して、同じ利用可能な帯域幅を共有できます。または、RTPレシーバーは、リクエストで特定のSSRCを示すことにより、プライマリビデオストリームのみを取得できます。この場合、RTPレシーバーは、最初にフル受信ビットレートでプライマリビデオストリームを取得できます。ただし、マルチキャストに参加すると、バーストの使用可能な帯域幅は12 Mbpsではなく11 Mbpsに低下します。 RTPレシーバーがFECを必要とするかどうかに関係なく、RTPレシーバーがSSMセッションに参加すると、ビットレートを考慮する必要があります。
This is the scenario for SSRC multiplexing where both RTP streams are transmitted over the same multicast group to the same destination port.
これは、両方のRTPストリームが同じマルチキャストグループを介して同じ宛先ポートに送信されるSSRC多重化のシナリオです。
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
m=video 40000 RTP/AVPF 96 97
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=rtpmap:96 MP2T/90000
a=rtpmap:97 1d-interleaved-parityfec/90000
a=fmtp:97 L=10; D=10; repair-window=200000
a=ssrc:1 cname:ch1_video@example.com
a=ssrc:2 cname:ch1_fec@example.com
b=TIAS:11000
a=mid:Channel1
Similar to scenario #2, both the primary video and audio streams can be acquired rapidly in parallel. Or, the RTP receiver can acquire only the primary video stream, if desired, by indicating its specific SSRC in the request.
シナリオ＃2と同様に、プライマリビデオストリームとオーディオストリームの両方を並行して迅速に取得できます。または、RTPレシーバーは、必要に応じて、その特定のSSRCを要求で示すことにより、プライマリビデオストリームのみを取得できます。
Note that based on the "a=fmtp" line for the FEC stream, it could be possible to infer the bitrate of this FEC stream and set the Max Receive Bitrate value accordingly.
FECストリームの「a = fmtp」行に基づいて、このFECストリームのビットレートを推測し、それに応じて最大受信ビットレート値を設定できることに注意してください。
Because this document describes deployment scenarios for RAMS, all security considerations are specified in the RAMS specification [RFC6285].
このドキュメントではRAMSの展開シナリオについて説明しているため、セキュリティに関するすべての考慮事項はRAMS仕様[RFC6285]で指定されています。
I would like to thank various individuals in the AVTEXT and MMUSIC WGs, and my friends at Cisco for their comments and feedback.
AVTEXT WGとMMUSIC WGのさまざまな個人、およびシスコの友人からのコメントとフィードバックに感謝します。
[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, June 2011.
[RFC6285] Ver Steeg、B.、Begen、A.、Van Caenegem、T。、およびZ. Vax、「Unicast-Based Rapid Acquisition of Multicast RTP Sessions」、RFC 6285、2011年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、2006年7月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588] Rey、J.、Leon、D.、Miyazaki、A.、Varsa、V。、およびR. Hakenberg、「RTP Retransmission Payload Format」、RFC 4588、2006年7月。
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5760] Ott、J.、Chesterfield、J。、およびE. Schooler、「ユニキャストフィードバック付きの単一ソースマルチキャストセッション用のRTP制御プロトコル（RTCP）拡張」、RFC 5760、2010年2月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888] Camarillo、G。およびH. Schulzrinne、「Session Description Protocol（SDP）Grouping Framework」、RFC 5888、2010年6月。
[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, September 2010.
[RFC5956] Begen、A。、「Session Description ProtocolのForward Error Correction Grouping Semantics」、RFC 5956、2010年9月。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.
[RFC6363] Watson、M.、Begen、A。、およびV. Roca、「Forward Error Correction（FEC）Framework」、RFC 6363、2011年10月。
Author's Address
著者のアドレス
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco 181 Bay Streetトロント、ON M5J 2T3カナダ
EMail: abegen@cisco.com