draft-ietf-avtext-rams-scenarios-05.txt   rfc6659.txt 
AVTEXT A. Begen Internet Engineering Task Force (IETF) A. Begen
Internet-Draft Cisco Request for Comments: 6659 Cisco
Intended status: Informational May 10, 2012 Category: Informational July 2012
Expires: November 11, 2012 ISSN: 2070-1721
Considerations for Deploying the Rapid Acquisition of Multicast RTP Considerations for Deploying the Rapid Acquisition of
Sessions (RAMS) Method Multicast RTP Sessions (RAMS) Method
draft-ietf-avtext-rams-scenarios-05
Abstract Abstract
The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a
method based on RTP and RTP Control Protocol (RTCP) that enables an method based on RTP and the RTP Control Protocol (RTCP) that enables
RTP receiver to rapidly acquire and start consuming the RTP multicast an RTP receiver to rapidly acquire and start consuming the RTP
data. Upon a request from the RTP receiver, an auxiliary unicast RTP multicast data. Upon a request from the RTP receiver, an auxiliary
retransmission session is set up between a retransmission server and unicast RTP retransmission session is set up between a retransmission
the RTP receiver, over which the reference information about the new server and the RTP receiver, over which the reference information
multicast stream the RTP receiver is about to join is transmitted at about the new multicast stream the RTP receiver is about to join is
an accelerated rate. This often precedes, but may also accompany, transmitted at an accelerated rate. This often precedes, but may
the multicast stream itself. When there is only one multicast stream also accompany, the multicast stream itself. When there is only one
to be acquired, the RAMS solution works in a straightforward manner. multicast stream to be acquired, the RAMS solution works in a
However, when there are two or more multicast streams to be acquired straightforward manner. However, when there are two or more
from the same or different multicast RTP sessions, care should be multicast streams to be acquired from the same or different multicast
taken to configure each RAMS session appropriately. This document RTP sessions, care should be taken to configure each RAMS session
provides example scenarios and discusses how the RAMS solution could appropriately. This document provides example scenarios and
be used in such scenarios. discusses how the RAMS solution could be used in such scenarios.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on November 11, 2012. 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.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background ......................................................3
3. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 3. Example Scenarios ...............................................4
3.1. Scenario #1: Two Multicast Groups . . . . . . . . . . . . 4 3.1. Scenario #1: Two Multicast Groups ..........................4
3.2. Scenario #2: One Multicast Group . . . . . . . . . . . . . 5 3.2. Scenario #2: One Multicast Group ...........................5
3.3. Scenario #3: SSRC Multiplexing . . . . . . . . . . . . . . 6 3.3. Scenario #3: SSRC Multiplexing .............................6
3.4. Scenario #4: Payload-Type Multiplexing . . . . . . . . . . 7 3.4. Scenario #4: Payload-Type Multiplexing .....................6
4. Feedback Target and SSRC Signaling Issues . . . . . . . . . . 7 4. Feedback Target and SSRC Signaling Issues .......................7
5. FEC during RAMS and Bandwidth Issues . . . . . . . . . . . . . 7 5. FEC during RAMS and Bandwidth Issues ............................7
5.1. Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Scenario #1 ................................................7
5.2. Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Scenario #2 ................................................9
5.3. Scenario #3 . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Scenario #3 ...............................................10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations ........................................10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments ................................................10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. References .....................................................11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References ......................................11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References ....................................11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a
method based on RTP and RTP Control Protocol (RTCP) that enables an method based on RTP and the RTP Control Protocol (RTCP) that enables
RTP receiver to rapidly acquire and start consuming the RTP multicast an RTP receiver to rapidly acquire and start consuming the RTP
data. Through an auxiliary unicast RTP retransmission session multicast data. Through an auxiliary unicast RTP retransmission
[RFC4588], the RTP receiver receives a reference information about session [RFC4588], the RTP receiver receives reference information
the new multicast stream it is about to join. This often precedes, about the new multicast stream it is about to join. This often
but may also accompany, the multicast stream itself. The RAMS precedes, but may also accompany, the multicast stream itself. The
solution is documented in detail in [RFC6285]. RAMS solution is documented in detail in [RFC6285].
The RAMS specification [RFC6285] has provisions for concurrently The RAMS specification [RFC6285] has provisions for concurrently
acquiring multiple streams inside a multicast RTP session. However, acquiring multiple streams inside a multicast RTP session. However,
the RAMS specification does not discuss scenarios where an RTP the RAMS specification does not discuss scenarios where an RTP
receiver makes use of the RAMS method to rapidly acquire multiple and receiver makes use of the RAMS method to rapidly acquire multiple and
associated multicast streams in parallel, or where different RTP associated multicast streams in parallel, or where different RTP
sessions are part of the same source-specific multicast (SSM) sessions are part of the same Source-Specific Multicast (SSM)
session. The example presented in Section 8.3 of [RFC6285] addresses session. The example presented in Section 8.3 of [RFC6285] addresses
only the simple case of an RTP receiver rapidly acquiring only one only the simple case of an RTP receiver rapidly acquiring only one
multicast stream to explain the protocol details. multicast stream to explain the protocol details.
There are certain deployment models where a multicast RTP session There are certain deployment models where a multicast RTP session
might have two or more multicast streams associated with it. There might have two or more multicast streams associated with it. There
are also cases, where an RTP receiver might be interested in are also cases where an RTP receiver might be interested in acquiring
acquiring one or more multicast streams from several multicast RTP one or more multicast streams from several multicast RTP sessions.
sessions. Close coordination is required for multiple RAMS sessions Close coordination is required for multiple RAMS sessions
simultaneously started by an RTP server, where each session is simultaneously started by an RTP server, where each session is
initiated with an individual RAMS Request message to a different initiated with an individual RAMS Request message to a different
feedback target. In this document, we present scenarios from real- feedback target. In this document, we present scenarios from real-
life deployments and discuss how the RAMS solution could be used in life deployments and discuss how the RAMS solution could be used in
such scenarios. such scenarios.
2. Background 2. Background
In the following discussion, we assume that there are two RTP streams 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 (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, could be audio and video elementary streams for the same TV channel,
or they could be an MPEG2-TS stream (that has audio and video or they could be an MPEG2 Transport Stream (that has audio and video
multiplexed together) and its Forward Error Correction (FEC) stream. multiplexed together) and its Forward Error Correction (FEC) stream.
An SSM session is defined by its (distribution) source address and An SSM session is defined by its (distribution) source address and
(destination) multicast group and there can be only one feedback (destination) multicast group, and there can be only one feedback
target per SSM session [RFC5760]. So, if the RTP streams are target per SSM session [RFC5760]. So, if the RTP streams are
distributed by different sources or over different multicast groups, distributed by different sources or over different multicast groups,
they are considered different SSM sessions. While different SSM they are considered different SSM sessions. While different SSM
sessions can normally share the same feedback target address and/or sessions can normally share the same feedback target address and/or
port, RAMS requires each unique feedback target (i.e., the port, RAMS requires each unique feedback target (i.e., the
combination of address and port) to be associated with at most one combination of address and port) to be associated with at most one
RTP session (See Section 6.2 of [RFC6285]). RTP session (See Section 6.2 of [RFC6285]).
Two or more multicast RTP streams can be transmitted in the same RTP 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 session (e.g., in a single UDP flow). This is called Synchronization
Source (SSRC) multiplexing. In this case, (de)multiplexing is done Source (SSRC) multiplexing. In this case, (de)multiplexing is done
at the SSRC level. Alternatively, the multicast RTP streams can be at the SSRC level. Alternatively, the multicast RTP streams can be
transmitted in different RTP sessions (e.g., in different UDP flows), transmitted in different RTP sessions (e.g., in different UDP flows),
which is called session multiplexing. In practice, there are which is called session multiplexing. In practice, there are
different deployment models for each multiplexing scheme. different deployment models for each multiplexing scheme.
Generally, two different media streams with different clock rates are Generally, to avoid complications in RTCP reports, it is suggested
suggested to use different SSRCs or to be carried in different RTP that two different media streams with different clock rates use
sessions to avoid complications in RTCP reports. Some of the fields different SSRCs or be carried in different RTP sessions. Some of the
in RAMS messages might depend on the clock rate. Thus, in a single fields in RAMS messages might depend on the clock rate. Thus, in a
RTP session, RTP streams carrying payloads with different clock rates single RTP session, RTP streams carrying payloads with different
need to have different SSRCs. Since RTP streams with different SSRCs clock rates need to have different SSRCs. Since RTP streams with
do not share the sequence numbering, each stream needs to be acquired different SSRCs do not share the sequence numbering, each stream
individually. needs to be acquired individually.
In the remaining sections, only the relevant portions of the SDP In the remaining sections, only the relevant portions of the Session
descriptions [RFC4566] will be provided. For an example of a full Description Protocol (SDP) descriptions [RFC4566] will be provided.
SDP description, refer to Section 8.3 of [RFC6285]. For an example of a full SDP description, refer to Section 8.3 of
[RFC6285].
3. Example Scenarios 3. Example Scenarios
3.1. Scenario #1: Two Multicast Groups 3.1. Scenario #1: Two Multicast Groups
This is the scenario for session multiplexing where RTP streams 1 and This is the scenario for session multiplexing where RTP streams 1 and
2 are transmitted over different multicast groups. A practical use 2 are transmitted over different multicast groups. A practical use
case is where the first and second SSM sessions carry the primary case is where the first and second SSM sessions carry the primary
video stream and its associated FEC stream, respectively. video stream and its associated FEC stream, respectively.
An individual RAMS sesson is run for each of the RTP streams that An individual RAMS session is run for each of the RTP streams that
requires rapid acquisition. Each requires a separate RAMS Request require rapid acquisition. Each requires a separate RAMS Request
message to be sent. These RAMS sessions can be run in parallel. If 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 they are, the RTP receiver needs to pay attention to using the shared
bandwidth appropriately among the two unicast bursts. As explained bandwidth appropriately among the two unicast bursts. As explained
earlier, there has to be a different feedback target for these two earlier, there has to be a different feedback target for these two
SSM sessions. SSM sessions.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios s=RAMS Scenarios
t=0 0 t=0 0
skipping to change at page 5, line 29 skipping to change at page 5, line 11
a=rtcp:42000 IN IP4 192.0.2.1 a=rtcp:42000 IN IP4 192.0.2.1
a=ssrc:2 cname:ch1_fec@example.com a=ssrc:2 cname:ch1_fec@example.com
a=mid:Channel1_FEC a=mid:Channel1_FEC
Note that the multicast destination ports in the above SDP do not Note that the multicast destination ports in the above SDP do not
matter, and they could be the same or different. The "FEC-FR" matter, and they could be the same or different. The "FEC-FR"
grouping semantics are defined in [RFC5956]. grouping semantics are defined in [RFC5956].
3.2. Scenario #2: One Multicast Group 3.2. Scenario #2: One Multicast Group
Here RTP streams 1 and 2 are transmitted over the same multicast Here, RTP streams 1 and 2 are transmitted over the same multicast
group with different destination ports. A practical use case is group with different destination ports. A practical use case is
where the SSM session carries the primary video and audio streams, where the SSM session carries the primary video and audio streams,
each destined to a different port. each destined to a different port.
The RAMS Request message sent by an RTP receiver to the feedback 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 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 the available RTP streams. Thus, both the primary video and audio
streams can be acquired rapidly in parallel. Or, the RTP receiver streams can be acquired rapidly in parallel. Or, the RTP receiver
can acquire only the primary video or audio stream, if desired, by can acquire only the primary video or audio stream, if desired, by
indicating the specific SSRC in the request. Compared to the indicating the specific SSRC in the request. Compared to the
skipping to change at page 6, line 39 skipping to change at page 6, line 12
(also as shown in the SDP description above). If RTP streams 1 and 2 (also as shown in the SDP description above). If RTP streams 1 and 2
do not share the same distribution source, meaning that their do not share the same distribution source, meaning that their
respective SSM sessions can use different feedback target transport respective SSM sessions can use different feedback target transport
addresses, then their SSRC values do not have to be different from addresses, then their SSRC values do not have to be different from
each other. each other.
3.3. Scenario #3: SSRC Multiplexing 3.3. Scenario #3: SSRC Multiplexing
This is the scenario for SSRC multiplexing where both RTP streams are This is the scenario for SSRC multiplexing where both RTP streams are
transmitted over the same multicast group to the same destination transmitted over the same multicast group to the same destination
port. This is a less practical scenario but it could be used where port. This is a less practical scenario, but it could be used where
the SSM session carries both the primary video and audio stream, the SSM session carries both the primary video and audio stream,
destined to the same port. destined to the same port.
Similar to scenario #2, both the primary video and audio streams can Similar to scenario #2, both the primary video and audio streams can
be acquired rapidly in parallel. Or, the RTP receiver can acquire be acquired rapidly in parallel. Or, the RTP receiver can acquire
only the primary video or audio stream, if desired, by indicating the only the primary video or audio stream, if desired, by indicating the
specific SSRC in the request. In this case, there is only one specific SSRC in the request. In this case, there is only one
distribution source and the destination multicast address is shared. distribution source and the destination multicast address is shared.
Thus, there is always one SSM session and one feedback target. Thus, there is always one SSM session and one feedback target.
skipping to change at page 7, line 33 skipping to change at page 7, line 9
FEC data). While this scheme is permissible per [RFC3550], it has FEC data). While this scheme is permissible per [RFC3550], it has
several drawbacks. For example, RTP packets carrying different several drawbacks. For example, RTP packets carrying different
payload formats will share the same sequence numbering space, and the payload formats will share the same sequence numbering space, and the
RAMS operations will not be able to be applied based on the payload 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]. type. For other drawbacks and details, see Section 5.2 of [RFC3550].
4. Feedback Target and SSRC Signaling Issues 4. Feedback Target and SSRC Signaling Issues
The RAMS protocol uses the common packet format from [RFC4585], which 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 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 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 from the RTP packets once the transmission starts. In RAMS, the
latter cannot be used. latter cannot be used.
Signaling the media sender SSRC value helps the feedback target Signaling the media sender SSRC value helps the feedback target
correctly identify the RTP stream to be acquired. If a feedback correctly identify the RTP stream to be acquired. If a feedback
target is serving multiple SSM sessions on a particular port, all the 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 RTP streams in these SSM sessions are supposed to have a unique SSRC
value. However, this is not an easy requirement to satisfy. Thus, value. However, this is not an easy requirement to satisfy. Thus,
RAMS specification forbids to have more than one RTP session to be the RAMS specification forbids having more than one RTP session
associated with a specific feedback target on a specific port. associated with a specific feedback target on a specific port.
5. FEC during RAMS and Bandwidth Issues 5. FEC during RAMS and Bandwidth Issues
Suppose that RTP stream 1 denotes the primary video stream that has a 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 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 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 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 can specify the bitrate ("b=" line in kbps) of each media session
(per "m" line). (per "m" line).
Note that RAMS can potentially congest the network temporarily. Note that RAMS can potentially congest the network temporarily.
Refer to [RFC6285] for detailed discussion. Refer to [RFC6285] for a detailed discussion.
5.1. Scenario #1 5.1. Scenario #1
This is the scenario for session multiplexing where RTP streams 1 and This is the scenario for session multiplexing where RTP streams 1 and
2 are transmitted over different multicast groups. 2 are transmitted over different multicast groups.
This is the preferred deployment model for FEC [RFC6363]. Having FEC This is the preferred deployment model for FEC [RFC6363]. Having FEC
in a different multicast group provides two flexibility points: RTP in a different multicast group provides two flexibility points: RTP
receivers that are not FEC capable can receive the primary video receivers that are not FEC capable can receive the primary video
stream without FEC, and RTP receivers that are FEC capable can decide stream without FEC, and RTP receivers that are FEC capable can decide
to not receive FEC during the rapid acquisition (but still start to not receive FEC during the rapid acquisition (but still start
receiving the FEC stream after the acquisition of the primary video receiving the FEC stream after the acquisition of the primary video
stream has been completed). stream has been completed).
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios s=RAMS Scenarios
t=0 0 t=0 0
skipping to change at page 9, line 15 skipping to change at page 8, line 44
If the RTP receiver wants to rapidly acquire both primary and 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 streams, it needs to allocate the total bandwidth among the two RAMS
sessions and indicate individual Max Receive Bitrate values in each sessions and indicate individual Max Receive Bitrate values in each
respective RAMS Request message. Since less bandwidth will be used respective RAMS Request message. Since less bandwidth will be used
to acquire the primary video stream, the acquisition of the primary to acquire the primary video stream, the acquisition of the primary
video session will take a longer time on the average. video session will take a longer time on the average.
While the RTP receiver can update the Max Receive Bitrate values While the RTP receiver can update the Max Receive Bitrate values
during the course of the RAMS session, this approach is more error- during the course of the RAMS session, this approach is more error-
prone due to the possibility of losing the update messages. prone, due to the possibility of losing the update messages.
5.2. Scenario #2 5.2. Scenario #2
Here RTP streams 1 (primary video) and 2 (FEC) are transmitted over Here, RTP streams 1 (primary video) and 2 (FEC) are transmitted over
the same multicast group with different destination ports. This is the same multicast group with different destination ports. This is
not a preferred deployment model. not a preferred deployment model.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios s=RAMS Scenarios
t=0 0 t=0 0
a=group:FEC-FR Channel1_Video Channel1_FEC a=group:FEC-FR Channel1_Video Channel1_FEC
m=video 40000 RTP/AVPF 96 m=video 40000 RTP/AVPF 96
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
skipping to change at page 10, line 4 skipping to change at page 9, line 39
b=TIAS:1000 b=TIAS:1000
a=ssrc:2 cname:ch1_fec@example.com a=ssrc:2 cname:ch1_fec@example.com
a=mid:Channel1_FEC a=mid:Channel1_FEC
The RAMS Request message sent by an RTP receiver to the feedback 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 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 the available RTP streams. Thus, both the primary video and FEC
streams can be acquired rapidly in parallel sharing the same streams can be acquired rapidly in parallel sharing the same
available bandwidth. Or, the RTP receiver can acquire only the available bandwidth. Or, the RTP receiver can acquire only the
primary video stream by indicating its specific SSRC in the request. primary video stream by indicating its specific SSRC in the request.
In this case, the RTP receiver can first acquire the primary video In this case, the RTP receiver can first acquire the primary video
stream at the full receive bitrate. But, upon the multicast join, stream at the full receive bitrate. But, upon the multicast join,
the available bandwidth for the burst drops to 11 Mbps instead of 12 the available bandwidth for the burst drops to 11 Mbps instead of
Mbps. Regardless of whether FEC is desired or not by the RTP 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, its bitrate needs to be taken into account once the RTP
receiver joins the SSM session. receiver joins the SSM session.
5.3. Scenario #3 5.3. Scenario #3
This is the scenario for SSRC multiplexing where both RTP streams are This is the scenario for SSRC multiplexing where both RTP streams are
transmitted over the same multicast group to the same destination transmitted over the same multicast group to the same destination
port. port.
v=0 v=0
skipping to change at page 10, line 46 skipping to change at page 10, line 39
only the primary video stream, if desired, by indicating its specific only the primary video stream, if desired, by indicating its specific
SSRC in the request. SSRC in the request.
Note that based on the "a=fmtp" line for the FEC stream, it could be 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 possible to infer the bitrate of this FEC stream and set the Max
Receive Bitrate value accordingly. Receive Bitrate value accordingly.
6. Security Considerations 6. Security Considerations
Because this document describes deployment scenarios for RAMS, all Because this document describes deployment scenarios for RAMS, all
security considerations are specified in the RAMS specifiction security considerations are specified in the RAMS specification
[RFC6285]. [RFC6285].
7. IANA Considerations 7. Acknowledgments
There are no IANA considerations in this document.
Note to RFC Editor: You can remove this section (7) upon
publication.
8. Acknowledgments
I would like to thank various individuals in the AVTEXT and MMUSIC I would like to thank various individuals in the AVTEXT and MMUSIC
WGs, and my friends at Cisco for their comments and feedback. WGs, and my friends at Cisco for their comments and feedback.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,
"Unicast-Based Rapid Acquisition of Multicast RTP "Unicast-Based Rapid Acquisition of Multicast RTP
Sessions", RFC 6285, June 2011. Sessions", RFC 6285, June 2011.
9.2. Informative References 8.2. Informative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
skipping to change at page 12, line 18 skipping to change at page 12, line 13
Correction (FEC) Framework", RFC 6363, October 2011. Correction (FEC) Framework", RFC 6363, October 2011.
Author's Address Author's Address
Ali Begen Ali Begen
Cisco Cisco
181 Bay Street 181 Bay Street
Toronto, ON M5J 2T3 Toronto, ON M5J 2T3
Canada Canada
Email: abegen@cisco.com EMail: abegen@cisco.com
 End of changes. 33 change blocks. 
103 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/