Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 6659 Cisco
Category: Informational July 2012
ISSN: 2070-1721
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接收器将要加入的新多播流的参考信息。这通常先于多播流本身，但也可能伴随多播流本身。当只需要获取一个多播流时，RAMS解决方案以简单的方式工作。但是，当从相同或不同的多播RTP会话获取两个或多个多播流时，应注意适当配置每个RAMS会话。本文档提供了示例场景，并讨论了如何在此类场景中使用RAMS解决方案。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2012 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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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接收器接收关于其即将加入的新多播流的参考信息。这通常先于多播流本身，但也可能伴随多播流本身。[RFC6285]中详细记录了RAMS解决方案。
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接收器仅快速获取一个多播流的简单情况，以解释协议细节。
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会话可能有两个或多个与之关联的多播流。还存在RTP接收器可能有兴趣从多个多播RTP会话获取一个或多个多播流的情况。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.
在下面的讨论中，我们假设有两个RTP流（1和2）以某种方式彼此关联。这些可以是同一电视频道的音频和视频基本流，也可以是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会话只能有一个反馈目标[RFC5760]。因此，如果RTP流由不同的源或在不同的多播组上分布，则它们被视为不同的SSM会话。虽然不同的SSM会话通常可以共享相同的反馈目标地址和/或端口，但RAMS要求每个唯一的反馈目标（即地址和端口的组合）最多与一个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流中）中传输两个或多个多播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报告中的复杂性，建议使用不同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通过不同的多播组传输。实际用例是第一和第二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接收机需要注意在两个单播突发之间适当地使用共享带宽。如前所述，这两个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
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中的多播目标端口并不重要，它们可以相同也可以不同。[RFC5956]中定义了“FEC-FR”分组语义。
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流的愿望。因此，可以并行地快速获取主要视频和音频流。或者，如果需要，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
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
如果RTP流1和2共享相同的分发源，则只有一个SSM会话，这意味着只能有一个反馈目标（如上面的SDP描述所示）。这要求RTP流1和2具有自己独特的SSRC值（也如上面的SDP描述所示）。如果RTP流1和2不共享相同的分发源，这意味着它们的
respective SSM sessions can use different feedback target transport addresses, then their SSRC values do not have to be different from each other.
各自的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.
这是SSRC多路复用的场景，其中两个RTP流通过相同的多播组传输到相同的目标端口。这是一个不太实际的场景，但它可以用于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来仅获取主视频或音频流。在这种情况下，只有一个分发源，目标多播地址是共享的。因此，始终存在一个SSM会话和一个反馈目标。
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
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].
在这种情况下，只有一个RTP流（和一个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表示比特率为10mbps的主视频流，RTP流2表示比特率为1mbps的相关FEC流。还假设RTP接收机知道它可以以22mbps的最大比特率接收数据。SDP可以指定每个媒体会话（每“m”行）的比特率（“以kbps为单位的行”）。
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提供了两个灵活性点：不具有FEC能力的RTP接收机可以在没有FEC的情况下接收主视频流，并且具有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
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流，它需要在两个RAM会话之间分配总带宽，并在每个相应的RAM请求消息中指示单个最大接收比特率值。由于将使用较少的带宽来获取主视频流，因此主视频会话的获取平均将花费更长的时间。
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
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流的愿望。因此，主视频和FEC流都可以共享相同的可用带宽而并行地快速获取。或者，RTP接收机可以通过在请求中指示其特定的SSRC来仅获取主视频流。在这种情况下，RTP接收机可以首先以全接收比特率获取主视频流。但是，在多播加入时，突发的可用带宽从12Mbps下降到11Mbps。无论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.
这是SSRC多路复用的场景，其中两个RTP流通过相同的多播组传输到相同的目标端口。
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
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和MMUSIC WGs中的各种个人，以及我在Cisco的朋友们的评论和反馈。
[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，“基于单播的多播RTP会话的快速获取”，RFC 62852011年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：实时应用的传输协议”，STD 64，RFC 35502003年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：会话描述协议”，RFC4566，2006年7月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，2006年7月。
[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 57602010年2月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888]Camarillo，G.和H.Schulzrinne，“会话描述协议（SDP）分组框架”，RFC 5888，2010年6月。
[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, September 2010.
[RFC5956]Begen，A.“会话描述协议中的前向纠错分组语义”，RFC 59562010年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，“前向纠错（FEC）框架”，RFC6363，2011年10月。
Author's Address
作者地址
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco位于加拿大多伦多湾街181号M5J 2T3
EMail: abegen@cisco.com
EMail: abegen@cisco.com