draft-ietf-avtext-rams-scenarios-00.txt   draft-ietf-avtext-rams-scenarios-01.txt 
AVTEXT A. Begen AVTEXT A. Begen
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational June 10, 2011 Intended status: Informational October 11, 2011
Expires: December 12, 2011 Expires: April 13, 2012
Considerations and Guidelines for Deploying the Rapid Acquisition of Considerations for Deploying the Rapid Acquisition of Multicast RTP
Multicast RTP Sessions (RAMS) Method Sessions (RAMS) Method
draft-ietf-avtext-rams-scenarios-00 draft-ietf-avtext-rams-scenarios-01
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 RTP Control Protocol (RTCP) that enables an
RTP receiver to rapidly acquire and start consuming the RTP multicast RTP receiver to rapidly acquire and start consuming the RTP multicast
data. Upon a request from the RTP receiver, an auxiliary unicast RTP data. Upon a request from the RTP receiver, an auxiliary unicast RTP
retransmission session is set up between a retransmission server and retransmission session is set up between a retransmission server and
the RTP receiver, over which the reference information about the new the RTP receiver, over which the reference information about the new
multicast stream the RTP receiver is about to join is transmitted at multicast stream the RTP receiver is about to join is transmitted at
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 12, 2011. This Internet-Draft will expire on April 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 4
4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Scenario #1: Two Multicast Groups . . . . . . . . . . . . 4
4.1. Scenario #1: Two Multicast Groups . . . . . . . . . . . . 4 3.2. Scenario #2: One Multicast Group . . . . . . . . . . . . . 5
4.2. Scenario #2: One Multicast Group . . . . . . . . . . . . . 5 3.3. Scenario #3: SSRC Multiplexing . . . . . . . . . . . . . . 6
4.3. Scenario #3: SSRC Multiplexing . . . . . . . . . . . . . . 6 3.4. Scenario #4: Payload-Type Multiplexing . . . . . . . . . . 7
4.4. Scenario #4: Payload-Type Multiplexing . . . . . . . . . . 7 4. Feedback Target and SSRC Signaling Issues . . . . . . . . . . 7
5. Feedback Target and SSRC Signaling Issues . . . . . . . . . . 7 5. FEC during RAMS and Bandwidth Issues . . . . . . . . . . . . . 7
6. FEC during RAMS and Bandwidth Issues . . . . . . . . . . . . . 7 5.1. Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Scenario #3 . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Scenario #3 . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
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 RTP Control Protocol (RTCP) that enables an
RTP receiver to rapidly acquire and start consuming the RTP multicast RTP receiver to rapidly acquire and start consuming the RTP multicast
data. Through an auxiliary unicast RTP retransmission session data. Through an auxiliary unicast RTP retransmission session
[RFC4588], the RTP receiver receives a reference information about [RFC4588], the RTP receiver receives a reference information about
the new multicast stream it is about to join. This often precedes, the new multicast stream it is about to join. This often precedes,
but may also accompany, the multicast stream itself. The RAMS but may also accompany, the multicast stream itself. The RAMS
solution is documented in detail in solution is documented in detail in [RFC6285].
[I-D.ietf-avt-rapid-acquisition-for-rtp].
The RAMS specification [I-D.ietf-avt-rapid-acquisition-for-rtp] has The RAMS specification [RFC6285] has provisions for concurrently
provisions for concurrently acquiring multiple streams inside a acquiring multiple streams inside a multicast RTP session. However,
multicast RTP session. However, the specification has mostly focused the specification does not discuss scenarios where an RTP receiver
on the simplest case, which is when the RTP receiver acquires only makes use of the RAMS method to rapidly acquire multiple and
one multicast stream at a time, to explain the protocol details. 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.
There are certain deployment models where a multicast RTP session may There are certain deployment models where a multicast RTP session may
have two or more multicast streams associated with it. There are have two or more multicast streams associated with it. There are
also cases, where an RTP receiver may be interested in acquiring one also cases, where an RTP receiver may be interested in acquiring one
or more multicast streams from several multicast RTP sessions. In or more multicast streams from several multicast RTP sessions. In
scenarios where multiple RAMS sessions will be simultaneously run by scenarios where multiple RAMS sessions, each initiated with an
an RTP receiver, they need to be coordinated. In this document, we individual RAMS Request message to a different feedback target, will
present scenarios from real-life deployments and provide guidelines. be simultaneously run by an RTP receiver, they need to be
coordinated. In this document, we present scenarios from real-life
2. Requirements Notation deployments and provide guidelines.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
Editor's note: I am inclined not use any 2119 keyword in this
document and remove this section altogether.
3. 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 somehow associated with each other. These could (1 and 2) that are somehow associated with each other. These could
be audio and video elementary streams for the same TV channel, or be audio and video elementary streams for the same TV channel, or
they could be an MPEG2-TS stream (that has audio and video they could be an MPEG2-TS stream (that has audio and video
multiplexed together) and its Forward Error Correction (FEC) stream. multiplexed together) and its Forward Error Correction (FEC) stream.
It is important to note that a source-specific multicast (SSM) It is important to note that an SSM session is defined by its
session is defined by its (distribution) source address and (distribution) source address and (destination) multicast group and
(destination) multicast group and there can be only one feedback there can be only one feedback target per SSM session [RFC5760]. So,
target per SSM session [RFC5760]. So, if the RTP streams are if the RTP streams are distributed by different sources or over
distributed by different sources or over different multicast groups, different multicast groups, they are considered different SSM
they are considered different SSM sessions. While different SSM sessions. While different SSM sessions can normally share the same
sessions can normally share the same feedback target address and/or feedback target address and/or port, RAMS requires each unique
port, RAMS requires each unique feedback target (i.e., the feedback target (i.e., the combination of address and port) to be
combination of address and port) to be associated with at most one associated with at most one RTP session (See Section 6.2 of
RTP session (See Section 6.2 of [RFC6285]).
[I-D.ietf-avt-rapid-acquisition-for-rtp]).
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 (i.e., 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 (i.e., 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, two different media streams with different clock rates are
suggested to use different SSRCs or to be carried in different RTP suggested to use different SSRCs or to be carried in different RTP
sessions to avoid complications in RTCP reports. Some of the fields sessions to avoid complications in RTCP reports. Some of the fields
in RAMS messages might depend on the clock rate. Thus, in a single in RAMS messages might depend on the clock rate. Thus, in a single
RTP session, RTP streams carrying payloads with different clock rates RTP session, RTP streams carrying payloads with different clock rates
need to have different SSRCs. Since RTP streams in the same RTP need to have different SSRCs. Since RTP streams with different SSRCs
session but with different SSRCs do not share the sequence numbering, do not share the sequence numbering, each stream needs to be acquired
each stream needs to be acquired individually. individually.
In the remaining sections, only the relevant portions of the SDP In the remaining sections, only the relevant portions of the SDP
descriptions [RFC4566] will be provided. For an example of a full descriptions [RFC4566] will be provided. For an example of a full
SDP description, refer to Section 8.3 of SDP description, refer to Section 8.3 of [RFC6285].
[I-D.ietf-avt-rapid-acquisition-for-rtp].
4. Example Scenarios 3. Example Scenarios
4.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.
We run an individual RAMS session for each of these RTP streams that We run an individual RAMS session for each of these RTP streams that
we want to rapidly acquire. These RAMS sessions can be run in we want to rapidly acquire. Each requires a separate RAMS Request
parallel. If they are, the RTP receiver needs to pay attention to message to be sent. These RAMS sessions can be run in parallel. If
using the shared bandwidth appropriately among the two unicast they are, the RTP receiver needs to pay attention to using the shared
bursts. As explained earlier, there has to be a different feedback bandwidth appropriately among the two unicast bursts. As explained
target for these two SSM sessions. earlier, there has to be a different feedback target for these two
SSM sessions.
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
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1 a=rtcp:41000 IN IP4 192.0.2.1
a=ssrc:1 cname:ch1_video@example.com a=ssrc:1 cname:ch1_video@example.com
a=mid:Channel1_Video a=mid:Channel1_Video
m=application 40000 RTP/AVPF 97 m=application 40000 RTP/AVPF 97
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
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].
4.2. Scenario #2: One Multicast Group 3.2. Scenario #2: One Multicast Group
This is the scenario for session multiplexing where RTP streams 1 and Here RTP streams 1 and 2 are transmitted over the same multicast
2 are transmitted over the same multicast group with different group with different destination ports. A practical use case is
destination ports. A practical use case is where the SSM session where the SSM session carries the primary video and audio streams,
carries the primary video and audio streams, each destined to a each destined to a different port.
different port.
Similar to scenario #1, we run individual RAMS sessions for each RTP The RAMS Request message sent by an RTP receiver to the feedback
stream that we want to rapidly acquire (Note that the RAMS request target could indicate the desire to acquire all or a subset or one of
sent by an RTP receiver could indicate the desire to acquire all or a the available RTP streams. Thus, both the primary video and audio
subset or one of the available RTP streams in an SSM session). streams can be acquired rapidly in parallel. Or, the RTP receiver
Compared to the previous scenario, the only difference is that in can acquire only the primary video or audio stream, if desired, by
this case the join times for both streams need to be coordinated as indicating the specific SSRC in the request. Compared to the
they are on the same multicast session. 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.
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
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1 a=rtcp:41000 IN IP4 192.0.2.1
a=ssrc:1 cname:ch1_video@example.com a=ssrc:1 cname:ch1_video@example.com
a=mid:Channel1_Video a=mid:Channel1_Video
m=audio 40001 RTP/AVPF 97 m=audio 40001 RTP/AVPF 97
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1 a=rtcp:41000 IN IP4 192.0.2.1
a=ssrc:2 cname:ch1_audio@example.com a=ssrc:2 cname:ch1_audio@example.com
a=mid:Channel1_Audio a=mid:Channel1_Audio
Note that the destination ports in the above SDP need to be distinct Note that the destination ports in "m" lines need to be distinct per
per [RFC5888]. [RFC5888].
If RTP streams 1 and 2 share the same distribution source, then there 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 is only one SSM session, which means that there can be only one
feedback target (as shown in the SDP description above). This feedback target (as shown in the SDP description above). This
requires RTP streams 1 and 2 to have their own unique SSRC values 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 (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.
4.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, we run individual RAMS sessions and the join Similar to scenario #2, both the primary video and audio streams can
time needs to be coordinated. In this case, there is only one 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. 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.
m=video 40000 RTP/AVPF 96 97 m=video 40000 RTP/AVPF 96 97
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1 a=rtcp:41000 IN IP4 192.0.2.1
a=ssrc:1 cname:ch1_video@example.com a=ssrc:1 cname:ch1_video@example.com
a=ssrc:2 cname:ch1_audio@example.com a=ssrc:2 cname:ch1_audio@example.com
a=mid:Channel1 a=mid:Channel1
4.4. Scenario #4: Payload-Type Multiplexing 3.4. Scenario #4: Payload-Type Multiplexing
This is the scenario for payload-type multiplexing. This is the scenario for payload-type multiplexing.
In this case, instead of two, we have only one RTP stream (and one In this case, instead of two, we have only one RTP stream (and one
RTP session) carrying both payload types (e.g., media payload and its RTP session) carrying both payload types (e.g., media payload and its
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
retransmission and RAMS operations will not be able to be applied RAMS operations will not be able to be applied based on the payload
based on the payload type. For other drawbacks and details, see type. For other drawbacks and details, see Section 5.2 of [RFC3550].
Section 5.2 of [RFC3550].
5. 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, since this is not an easy requirement to satisfy, value. However, since this is not an easy requirement to satisfy,
RAMS specification forbids to have more than one RTP session to be RAMS specification forbids to have more than one RTP session to be
associated with a specific feedback target. associated with a specific feedback target on a specific port.
6. 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 FEC stream that has a bitrate of 10 Mbps and RTP stream 2 denotes the associated FEC stream
bitrate of 1 Mbps. Also assume that the RTP receiver knows that it that has a bitrate of 1 Mbps. Also assume that the RTP receiver
can receive data at a maximum bitrate of 22 Mbps. SDP can specify knows that it can receive data at a maximum bitrate of 22 Mbps. SDP
the bitrate ("b=" line in Kbps) of each media session (per "m" line). can specify the bitrate ("b=" line in Kbps) of each media session
(per "m" line).
6.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. Having FEC in a This is the preferred deployment model for FEC
different multicast group provides flexibility for not only the RTP [I-D.ietf-fecframe-framework]. Having FEC in a different multicast
receivers that are not FEC capable but also the ones that are FEC group provides two flexibility points: RTP receivers that are not
capable but are not willing to receive FEC during the rapid FEC capable can receive the primary video stream without FEC, and RTP
acquisition. 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).
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
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1 a=rtcp:41000 IN IP4 192.0.2.1
a=rtpmap:96 MP2T/90000 a=rtpmap:96 MP2T/90000
b=TIAS:10000 b=TIAS:10000
a=ssrc:1 cname:ch1_video@example.com a=ssrc:1 cname:ch1_video@example.com
a=mid:Channel1_Video a=mid:Channel1_Video
skipping to change at page 8, line 38 skipping to change at page 8, line 40
a=rtcp:42000 IN IP4 192.0.2.1 a=rtcp:42000 IN IP4 192.0.2.1
a=rtpmap:97 1d-interleaved-parityfec/90000 a=rtpmap:97 1d-interleaved-parityfec/90000
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
If the RTP receiver does not want to receive FEC until the If the RTP receiver does not want to receive FEC until the
acquisition of the primary video stream is completed, the total acquisition of the primary video stream is completed, the total
available bandwidth can be used for faster acquisition of the primary available bandwidth can be used for faster acquisition of the primary
video stream. In this case, the RTP receiver can request a Max video stream. In this case, the RTP receiver can request a Max
Receive Bitrate of 22 Mbps in the RAMS Request message. Once RAMS Receive Bitrate of 22 Mbps in the RAMS Request message for the
has been completed, the RTP receiver can join the FEC multicast primary video stream. Once RAMS has been completed, the RTP receiver
session, if desired. can join the FEC multicast session, if desired.
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.
6.2. Scenario #2 5.2. Scenario #2
This is the scenario for session multiplexing where RTP streams 1 and Here RTP streams 1 (primary video) and 2 (FEC) are transmitted over
2 are transmitted over the same multicast group with different the same multicast group with different destination ports. This is
destination ports. not a preferred deployment model.
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
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1 a=rtcp:41000 IN IP4 192.0.2.1
a=rtpmap:96 MP2T/90000 a=rtpmap:96 MP2T/90000
b=TIAS:10000 b=TIAS:10000
a=ssrc:1 cname:ch1_video@example.com a=ssrc:1 cname:ch1_video@example.com
a=mid:Channel1_Video a=mid:Channel1_Video
m=application 40001 RTP/AVPF 97 m=application 40001 RTP/AVPF 97
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1 a=rtcp:41000 IN IP4 192.0.2.1
a=rtpmap:97 1d-interleaved-parityfec/90000 a=rtpmap:97 1d-interleaved-parityfec/90000
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
Similar to scenario #1, the RTP receiver can first ask for RAMS for The RAMS Request message sent by an RTP receiver to the feedback
the primary video stream at the full receive bitrate. But, upon the 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
(Acquiring only the FEC stream without the primary video stream is
not practical). 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 multicast join, the available bandwidth for the burst drops to 11
Mbps instead of 12 Mbps. Regardless of whether FEC is desired or not 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 by the RTP receiver, its bitrate needs to be taken into account once
the RTP receiver joins the SSM session. the RTP receiver joins the SSM session.
If the RTP receiver wants to rapidly acquire both primary and FEC 5.3. Scenario #3
streams, the same conditions explained for scenario #1 apply. The
only difference from scenario #1 is that here the join time is the
same for both the primary video and FEC streams.
6.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.
m=video 40000 RTP/AVPF 96 97 m=video 40000 RTP/AVPF 96 97
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1 a=rtcp:41000 IN IP4 192.0.2.1
a=rtpmap:96 MP2T/90000 a=rtpmap:96 MP2T/90000
a=rtpmap:97 1d-interleaved-parityfec/90000 a=rtpmap:97 1d-interleaved-parityfec/90000
a=fmtp:97 L=10; D=10; repair-window=200000 a=fmtp:97 L=10; D=10; repair-window=200000
a=ssrc:1 cname:ch1_video@example.com a=ssrc:1 cname:ch1_video@example.com
a=ssrc:2 cname:ch1_fec@example.com a=ssrc:2 cname:ch1_fec@example.com
a=mid:Channel1
b=TIAS:11000 b=TIAS:11000
a=mid:Channel1 a=mid:Channel1
This is similar to scenario #2. However, since we cannot explicitly Similar to scenario #2, both the primary video and audio streams can
specify the bitrates for the primary and FEC streams, the RTP be acquired rapidly in parallel. Or, the RTP receiver can acquire
receiver can request to rapidly acquire both streams in parallel. In only the primary video stream, if desired, by indicating its specific
this case, two separate RAMS Request messages have to be sent by the SSRC in the request.
RTP receiver to the feedback target.
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.
7. Security Considerations 6. Security Considerations
There are no security considerations in this document. There are no security considerations in this document.
8. IANA Considerations 7. IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
9. Acknowledgments 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.
10. References 9. References
10.1. Normative References 9.1. Normative References
[I-D.ietf-avt-rapid-acquisition-for-rtp] [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- "Unicast-Based Rapid Acquisition of Multicast RTP
Based Rapid Acquisition of Multicast RTP Sessions", Sessions", RFC 6285, June 2011.
draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in
progress), November 2010.
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010. Sessions with Unicast Feedback", RFC 5760, February 2010.
10.2. Informative References 9.2. Informative References
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in
the Session Description Protocol", RFC 5956, the Session Description Protocol", RFC 5956,
September 2010. September 2010.
[I-D.ietf-fecframe-framework]
Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework",
draft-ietf-fecframe-framework-15 (work in progress),
June 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. 46 change blocks. 
140 lines changed or deleted 139 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/