draft-ietf-avtext-rams-scenarios-01.txt   draft-ietf-avtext-rams-scenarios-02.txt 
AVTEXT A. Begen AVTEXT A. Begen
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational October 11, 2011 Intended status: Informational January 17, 2012
Expires: April 13, 2012 Expires: July 20, 2012
Considerations for Deploying the Rapid Acquisition of Multicast RTP Considerations for Deploying the Rapid Acquisition of Multicast RTP
Sessions (RAMS) Method Sessions (RAMS) Method
draft-ietf-avtext-rams-scenarios-01 draft-ietf-avtext-rams-scenarios-02
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 April 13, 2012. This Internet-Draft will expire on July 20, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 7, line 37 skipping to change at page 7, line 37
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, this is not an easy requirement to satisfy. Thus,
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 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).
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 This is the preferred deployment model for FEC [RFC6363]. Having FEC
[I-D.ietf-fecframe-framework]. Having FEC in a different multicast in a different multicast group provides two flexibility points: RTP
group provides two flexibility points: RTP receivers that are not receivers that are not FEC capable can receive the primary video
FEC capable can receive the primary video stream without FEC, and RTP stream without FEC, and RTP receivers that are FEC capable can decide
receivers that are FEC capable can decide to not receive FEC during to not receive FEC during the rapid acquisition (but still start
the rapid acquisition (but still start receiving the FEC stream after receiving the FEC stream after the acquisition of the primary video
the acquisition of the primary video stream has been completed). 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 9, line 36 skipping to change at page 9, line 36
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
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.
(Acquiring only the FEC stream without the primary video stream is In this case, the RTP receiver can first acquire the primary video
not practical). In this case, the RTP receiver can first acquire the stream at the full receive bitrate. But, upon the multicast join,
primary video stream at the full receive bitrate. But, upon the the available bandwidth for the burst drops to 11 Mbps instead of 12
multicast join, the available bandwidth for the burst drops to 11 Mbps. Regardless of whether FEC is desired or not by the RTP
Mbps instead of 12 Mbps. Regardless of whether FEC is desired or not receiver, its bitrate needs to be taken into account once the RTP
by the RTP receiver, its bitrate needs to be taken into account once receiver joins the SSM session.
the RTP 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.
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
skipping to change at page 11, line 31 skipping to change at page 11, line 31
9.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] [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.
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. 8 change blocks. 
26 lines changed or deleted 22 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/