draft-ietf-avt-rapid-acquisition-for-rtp-04.txt   draft-ietf-avt-rapid-acquisition-for-rtp-05.txt 
AVT B. VerSteeg AVT B. VerSteeg
Internet-Draft A. Begen Internet-Draft A. Begen
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco
Expires: April 11, 2010 T. VanCaenegem Expires: May 20, 2010 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
October 8, 2009 November 16, 2009
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-04 draft-ietf-avt-rapid-acquisition-for-rtp-05
Abstract
When an RTP receiver joins a primary multicast session, it may need
to acquire and parse certain Reference Information before it can
process any data sent in the multicast session. Depending on the
join time, length of the Reference Information repetition interval,
size of the Reference Information as well as the application and
transport properties, the time lag before an RTP receiver can
usefully consume the multicast data, which we refer to as the
Acquisition Delay, varies and may be large. This is an undesirable
phenomenon for receivers that frequently switch among different
multicast sessions, such as video broadcasts.
In this document, we describe a method using the existing RTP and
RTCP protocol machinery that reduces the acquisition delay. In this
method, an auxiliary unicast RTP session carrying the Reference
Information to the receiver precedes/accompanies the primary
multicast stream. This unicast RTP flow may be transmitted at a
faster than natural rate to further accelerate the acquisition. The
motivating use case for this capability is multicast applications
that carry real-time compressed audio and video. However, the
proposed method can also be used in other types of multicast
applications where the acquisition delay is long enough to be a
problem.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 11, 2010. This Internet-Draft will expire on May 20, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
When an RTP receiver joins a primary multicast session, it may need described in the BSD License.
to acquire and parse certain Reference Information before it can
process any data sent in the multicast session. Depending on the
join time, length of the Reference Information repetition interval,
size of the Reference Information as well as the application and
transport properties, the time lag before an RTP receiver can
usefully consume the multicast data, which we refer to as the
Acquisition Delay, varies and may be large. This is an undesirable
phenomenon for receivers that frequently switch among different
multicast sessions, such as video broadcasts.
In this document, we describe a method using the existing RTP and This document may contain material from IETF Documents or IETF
RTCP protocol machinery that reduces the acquisition delay. In this Contributions published or made publicly available before November
method, an auxiliary unicast RTP session carrying the Reference 10, 2008. The person(s) controlling the copyright in some of this
Information to the receiver precedes/accompanies the primary material may not have granted the IETF Trust the right to allow
multicast stream. This unicast RTP flow may be transmitted at a modifications of such material outside the IETF Standards Process.
faster than natural rate to further accelerate the acquisition. The Without obtaining an adequate license from the person(s) controlling
motivating use case for this capability is multicast applications the copyright in such materials, this document may not be modified
that carry real-time compressed audio and video. However, the outside the IETF Standards Process, and derivative works of it may
proposed method can also be used in other types of multicast not be created outside the IETF Standards Process, except to format
applications where the acquisition delay is long enough to be a it for publication as an RFC or to translate it into languages other
problem. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Elements of Delay in Multicast Applications . . . . . . . . . 8 4. Elements of Delay in Multicast Applications . . . . . . . . . 8
5. Protocol Design Considerations and Their Effect on 5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Acquisition . . . . . . . . . . 10 Resource Management for Rapid Acquisition . . . . . . . . . . 10
6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 12 6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 12
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 21 6.3. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 21
6.4. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 23 6.4. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 23
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 24 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 24
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 25 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 25
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 25 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 26
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 26 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 26
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 28 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 28
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 30 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 30
8. SDP Definitions and Examples . . . . . . . . . . . . . . . . . 31 8. SDP Definitions and Examples . . . . . . . . . . . . . . . . . 31
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 31
8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 31
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 34 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 35
10. Known Implementations . . . . . . . . . . . . . . . . . . . . 35 10. Known Implementations . . . . . . . . . . . . . . . . . . . . 35
10.1. Open Source RTP Receiver Implementation by Cisco . . . . . 35 10.1. Open Source RTP Receiver Implementation by Cisco . . . . . 35
10.2. IPTV Commercial Implementation by Microsoft . . . . . . . 36 10.2. IPTV Commercial Implementation by Microsoft . . . . . . . 36
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36
12. Security Considerations . . . . . . . . . . . . . . . . . . . 36 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 12.1. Registration of SDP Attributes . . . . . . . . . . . . . . 38
13.1. Registration of SDP Attributes . . . . . . . . . . . . . . 38 12.2. Registration of SDP Attribute Values . . . . . . . . . . . 38
13.2. Registration of SDP Attribute Values . . . . . . . . . . . 38 12.3. Registration of FMT Values . . . . . . . . . . . . . . . . 38
13.3. Registration of FMT Values . . . . . . . . . . . . . . . . 39 12.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 39
13.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 39 12.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 39
13.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 40 12.6. RAMS Response Code Space Registry . . . . . . . . . . . . 40
13.6. RAMS Response Code Space Registry . . . . . . . . . . . . 40 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 42
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 42 14.1. draft-ietf-avt-rapid-acquisition-for-rtp-05 . . . . . . . 42
15.1. draft-ietf-avt-rapid-acquisition-for-rtp-04 . . . . . . . 42 14.2. draft-ietf-avt-rapid-acquisition-for-rtp-04 . . . . . . . 42
15.2. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 42 14.3. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 42
15.3. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 42 14.4. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 42
15.4. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 43 14.5. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 43
15.5. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 43 14.6. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 43
15.6. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 43 14.7. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 43
15.7. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 43 14.8. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 43
15.8. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 44 14.9. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 44
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
16.1. Normative References . . . . . . . . . . . . . . . . . . . 44 15.1. Normative References . . . . . . . . . . . . . . . . . . . 44
16.2. Informative References . . . . . . . . . . . . . . . . . . 46 15.2. Informative References . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
Most multicast flows carry a stream of inter-related data. Certain Most multicast flows carry a stream of inter-related data. Certain
information must first be acquired by the receivers to start information must first be acquired by the receivers to start
processing any data sent in the multicast session. This document processing any data sent in the multicast session. This document
refers to this information as Reference Information. The Reference refers to this information as Reference Information. The Reference
Information is conventionally sent periodically in the multicast Information is conventionally sent periodically in the multicast
session and usually consists of items such as a description of the session and usually consists of items such as a description of the
skipping to change at page 13, line 34 skipping to change at page 13, line 34
6.2. Message Flows 6.2. Message Flows
Figure 2 shows the main entities involved in rapid acquisition: Figure 2 shows the main entities involved in rapid acquisition:
o Multicast Source o Multicast Source
o Feedback Target (FT) o Feedback Target (FT)
o Burst/Retransmission Source o Burst/Retransmission Source
o RTP Receiver (RR) o RTP Receiver (RTP_Rx)
+----------------------------------------------+ +----------------------------------------------+
| Retransmission Server | | Retransmission Server |
| (RS) | | (RS) |
| +----------+ +---------------------------+ | | +----------+ +---------------------------+ |
| | Feedback | | Burst/Retransmission | | | | Feedback | | Burst/Retransmission | |
| | Target | | Source | | | | Target | | Source | |
| +----------+ +---------------------------+ | | +----------+ +---------------------------+ |
+----------------------------------------------+ +----------------------------------------------+
^ ^ : ^ ^ :
| ' : | ' :
| ' : | ' :
| ' v | ' v
+-----------+ +----------+ +----------+ +-----------+ +----------+ +----------+
| | | |'''''''''''>| | | | | |'''''''''''>| |
| Multicast |------->| Router |...........>| RTP | | Multicast |------->| Router |...........>| RTP |
| Source | | |<~~~~~~~~~~~| Receiver | | Source | | |<~~~~~~~~~~~| Receiver |
| | | |----------->| (RR) | | | | |----------->| (RTP_Rx) |
+-----------+ +----------+ +----------+ +-----------+ +----------+ +----------+
'''> Unicast RTCP Messages '''> Unicast RTCP Messages
~~~> SFGMP Messages ~~~> SFGMP Messages
...> Unicast RTP Flow ...> Unicast RTP Flow
---> Multicast RTP Flow ---> Multicast RTP Flow
Figure 2: Flow diagram for unicast-based rapid acquisition Figure 2: Flow diagram for unicast-based rapid acquisition
The feedback target (FT) is the entity as defined in The feedback target (FT) is the entity as defined in
[I-D.ietf-avt-rtcpssm], to which RR sends its RTCP feedback messages [I-D.ietf-avt-rtcpssm], to which RTP_Rx sends its RTCP feedback
indicating packet loss in the primary multicast stream by means of an messages indicating packet loss in the primary multicast stream by
RTCP NACK message or indicating RR's desire to rapidly acquire the means of an RTCP NACK message or indicating RTP_Rx's desire to
primary multicast stream by means of an RTCP feedback message defined rapidly acquire the primary multicast stream by means of an RTCP
in this document. While the Burst/Retransmission Source is feedback message defined in this document. While the Burst/
responsible for responding to these messages and for further RTCP Retransmission Source is responsible for responding to these messages
interaction with RR in the case of a rapid acquisition process, it is and for further RTCP interaction with RTP_Rx in the case of a rapid
assumed in the remainder of the document that these two logical acquisition process, it is assumed in the remainder of the document
entities (FT and Burst/Retransmission Source) are combined in a that these two logical entities (FT and Burst/Retransmission Source)
single physical entity and they share state. In the remainder of the are combined in a single physical entity and they share state. In
text, the term Retransmission Server will be used whenever the remainder of the text, the term Retransmission Server will be
appropriate, to refer to the combined functionality of the FT and used whenever appropriate, to refer to the combined functionality of
Burst/Retransmission Source. the FT and Burst/Retransmission Source.
However, it must be noted that only FT is involved in the primary However, it must be noted that only FT is involved in the primary
multicast session, whereas the Burst/Retransmission Source transmits multicast session, whereas the Burst/Retransmission Source transmits
the unicast burst and retransmission packets both formatted as RTP the unicast burst and retransmission packets both formatted as RTP
retransmission packets [RFC4588] in a single separate unicast RTP retransmission packets [RFC4588] in a single separate unicast RTP
retransmission session to each RR. In the retransmission session, as retransmission session to each RTP_Rx. In the retransmission
in any other RTP session, RS and RR regularly send the periodic session, as in any other RTP session, RS and RTP_Rx regularly send
sender and receiver reports, respectively. the periodic sender and receiver reports, respectively.
Note also that the same method (with the identical message flows) Note also that the same method (with the identical message flows)
would also apply in a scenario where rapid acquisition is performed would also apply in a scenario where rapid acquisition is performed
by a feedback target co-located with the media source. by a feedback target co-located with the media source.
The unicast burst is triggered by an RTCP feedback message that is The unicast burst is triggered by an RTCP feedback message that is
defined in this document, whereas an RTP retransmission is triggered defined in this document, whereas an RTP retransmission is triggered
by an RTCP NACK message defined in [RFC4585]. Based on its design, by an RTCP NACK message defined in [RFC4585]. Based on its design,
in an RAMS implementation, there may be a gap between the end of the in an RAMS implementation, there may be a gap between the end of the
burst and the reception of the primary multicast stream because of burst and the reception of the primary multicast stream because of
the imperfections in the switch-over. If needed, RR may make use of the imperfections in the switch-over. If needed, RTP_Rx may make use
the RTCP NACK message to request a retransmission for the missing of the RTCP NACK message to request a retransmission for the missing
packets in the gap. packets in the gap.
Figure 3 depicts an example of messaging flow for rapid acquisition. Figure 3 depicts an example of messaging flow for rapid acquisition.
The RTCP feedback messages are explained below. Note that the The RTCP feedback messages are explained below. Note that the
messages indicated in parentheses may or may not be present during messages indicated in parentheses may or may not be present during
rapid acquisition. rapid acquisition.
+-----------+ +----------------+ +----------+ +------------+ +-----------+ +----------------+ +----------+ +------------+
| Multicast | | Retransmission | | | | RTP | | Multicast | | Retransmission | | | | RTP |
| Source | | Server | | Router | | Receiver | | Source | | Server | | Router | | Receiver |
| | | (RS) | | | | (RR) | | | | (RS) | | | | (RTP_Rx) |
+-----------+ +----------------+ +----------+ +------------+ +-----------+ +----------------+ +----------+ +------------+
| | | | | | | |
|-- RTP Multicast ------------------->| | |-- RTP Multicast ------------------->| |
| | | | | | | |
|-- RTP Multicast ->| | | |-- RTP Multicast ->| | |
| | | | | | | |
| |<'''''''''''''''''' RTCP RAMS-R ''| | |<'''''''''''''''''' RTCP RAMS-R ''|
| | | | | | | |
| | | | | | | |
| |'' (RTCP RAMS-I) ''''''''''''''''>| | |'' (RTCP RAMS-I) ''''''''''''''''>|
skipping to change at page 17, line 6 skipping to change at page 17, line 6
| |<''''''''''''''''''' (RTCP BYE) ''| | |<''''''''''''''''''' (RTCP BYE) ''|
| | | | | | | |
| | | | | | | |
'''> Unicast RTCP Messages '''> Unicast RTCP Messages
~~~> SFGMP Messages ~~~> SFGMP Messages
...> Unicast RTP Flow ...> Unicast RTP Flow
---> Multicast RTP Flow ---> Multicast RTP Flow
Figure 3: Message flows for unicast-based rapid acquisition Figure 3: Message flows for unicast-based rapid acquisition
This document defines the expected behaviors of RS and RR. It is This document defines the expected behaviors of RS and RTP_Rx. It is
instructive to have independently operating implementations on RS and instructive to have independently operating implementations on RS and
RR that request the burst, describe the burst, start the burst, join RTP_Rx that request the burst, describe the burst, start the burst,
the multicast session and stop the burst. These implementations send join the multicast session and stop the burst. These implementations
messages to each other, but there MUST be provisions for the cases send messages to each other, but there MUST be provisions for the
where the control messages get lost, or re-ordered, or are not being cases where the control messages get lost, or re-ordered, or are not
delivered to their destinations. being delivered to their destinations.
The following steps describe rapid acquisition in detail: The following steps describe rapid acquisition in detail:
1. Request: RR sends a rapid acquisition request for the new 1. Request: RTP_Rx sends a rapid acquisition request for the new
multicast RTP session to the feedback target address of that multicast RTP session to the feedback target address of that
session. The request contains the SSRC of RR and the SSRC of the session. The request contains the SSRC of RTP_Rx and the SSRC of
media source. This RTCP feedback message is defined as the RAMS- the media source. This RTCP feedback message is defined as the
Request (RAMS-R) message and MAY contain parameters, which may RAMS-Request (RAMS-R) message and MAY contain parameters, which
constrain the burst, such as the bandwidth limit. Other may constrain the burst, such as the bandwidth limit. Other
parameters may be related to the amount of buffering capacity parameters may be related to the amount of buffering capacity
available at RR, which may be used by RS to prepare a burst that available at RTP_Rx, which may be used by RS to prepare a burst
conforms with RR's requirements. that conforms with RTP_Rx's requirements.
Before joining the primary multicast session, a new joining RR Before joining the primary multicast session, a new joining
learns the addresses associated with the new multicast session RTP_Rx learns the addresses associated with the new multicast
(addresses for the multicast source, group and retransmission session (addresses for the multicast source, group and
server) by out-of-band means. Also note that since no RTP retransmission server) by out-of-band means. Also note that
packets have been received yet for this session, the SSRC must be since no RTP packets have been received yet for this session, the
obtained out-of-band. See Section 8 for details. SSRC must be obtained out-of-band. See Section 8 for details.
2. Response: RS receives the RAMS-R message and decides whether to 2. Response: RS receives the RAMS-R message and decides whether to
accept it or not. RS MUST send an (at least one) RAMS- accept it or not. RS MUST send an (at least one) RAMS-
Information (RAMS-I) message to RR. The first RAMS-I message MAY Information (RAMS-I) message to RTP_Rx. The first RAMS-I message
precede the unicast burst or it MAY be sent during the burst. MAY precede the unicast burst or it MAY be sent during the burst.
Additional RAMS-I messages MAY be sent during the burst and these Additional RAMS-I messages MAY be sent during the burst and these
RAMS-I messages may or may not be a direct response to an RAMS-R RAMS-I messages may or may not be a direct response to an RAMS-R
message. The RAMS-I message is sent by the Burst/Retransmission message. The RAMS-I message is sent by the Burst/Retransmission
Source logical entity that is part of RS. Source logical entity that is part of RS.
Note that RS learns the IP address information for RR from the Note that RS learns the IP address information for RTP_Rx from
RAMS-R message it received. (This description glosses over the the RAMS-R message it received. (This description glosses over
NAT details. Refer to Section 9 for a discussion of NAT-related the NAT details. Refer to Section 9 for a discussion of NAT-
issues.) related issues.)
If RS cannot provide a rapid acquisition service, RS rejects the If RS cannot provide a rapid acquisition service, RS rejects the
request and informs RR immediately via an RAMS-I message. If RR request and informs RTP_Rx immediately via an RAMS-I message. If
receives a message indicating that its rapid acquisition request RTP_Rx receives a message indicating that its rapid acquisition
has been denied, it abandons the rapid acquisition attempt and request has been denied, it abandons the rapid acquisition
MAY immediately join the multicast session by sending an SFGMP attempt and MAY immediately join the multicast session by sending
Join message towards its upstream multicast router for the new an SFGMP Join message towards its upstream multicast router for
primary multicast session. the new primary multicast session.
If RS accepts the request, it sends an RAMS-I message to RR If RS accepts the request, it sends an RAMS-I message to RTP_Rx
(before commencing the unicast burst or during the unicast burst) (before commencing the unicast burst or during the unicast burst)
that comprises fields that can be used to describe the unicast that comprises fields that can be used to describe the unicast
burst (e.g., the maximum bitrate and the duration of the unicast burst (e.g., the maximum bitrate and the duration of the unicast
burst). A particularly important field in the RAMS-I message burst). A particularly important field in the RAMS-I message
carries the RTP sequence number of the first packet transmitted carries the RTP sequence number of the first packet transmitted
in the retransmission session to allow RR to detect any missing in the retransmission session to allow RTP_Rx to detect any
initial packet(s). Note that the first RTP packet transmitted in missing initial packet(s). Note that the first RTP packet
the retransmission session is not necessarily a burst packet. It transmitted in the retransmission session is not necessarily a
could be a payload-specific RTP packet (See burst packet. It could be a payload-specific RTP packet (See
[I-D.begen-avt-rtp-mpeg2ts-preamble] for an example). When RS [I-D.begen-avt-rtp-mpeg2ts-preamble] for an example). When RS
accepts the request, this field MUST be populated in the RAMS-I accepts the request, this field MUST be populated in the RAMS-I
message and it is RECOMMENDED that the RAMS-I message is sent message and it is RECOMMENDED that the RAMS-I message is sent
early enough in the session to be useful. If RS rejects the early enough in the session to be useful. If RS rejects the
request, this field SHALL NOT exist in the RAMS-I message. request, this field SHALL NOT exist in the RAMS-I message.
It is RECOMMENDED to include a sender report with the RAMS-I It is RECOMMENDED to include a sender report with the RAMS-I
message in the same compound RTCP packet. This allows rapid message in the same compound RTCP packet. This allows rapid
synchronization among multiple RTP flows synchronization among multiple RTP flows
[I-D.ietf-avt-rapid-rtp-sync]. [I-D.ietf-avt-rapid-rtp-sync].
The unicast burst duration MAY be calculated by RS, and its value The unicast burst duration MAY be calculated by RS, and its value
MAY be updated by messages received from RR. If RS accepts the MAY be updated by messages received from RTP_Rx. If RS accepts
request, the join time information (for the new multicast the request, the join time information (for the new multicast
session) MUST be populated in at least one of the RAMS-I session) MUST be populated in at least one of the RAMS-I
messages. If RS rejects the request, including the join time messages. If RS rejects the request, including the join time
information in a RAMS-I message is OPTIONAL. information in a RAMS-I message is OPTIONAL.
RS MAY send the RAMS-I message after a significant delay, so RR RS MAY send the RAMS-I message after a significant delay, so
SHOULD NOT make protocol dependencies on quickly receiving an RTP_Rx SHOULD NOT make protocol dependencies on quickly receiving
RAMS-I message. an RAMS-I message.
3. Unicast Burst: If the request is accepted, RS starts sending the 3. Unicast Burst: If the request is accepted, RS starts sending the
unicast burst that comprises one or more RTP retransmission unicast burst that comprises one or more RTP retransmission
packets (The burst packet(s) are sent by the Burst/Retransmission packets (The burst packet(s) are sent by the Burst/Retransmission
Source logical entity). In addition, there MAY be optional Source logical entity). In addition, there MAY be optional
payload-specific information that RS chooses to send to RR. Such payload-specific information that RS chooses to send to RTP_Rx.
an example is discussed in [I-D.begen-avt-rtp-mpeg2ts-preamble] Such an example is discussed in
for transmitting the payload-specific information for MPEG2 [I-D.begen-avt-rtp-mpeg2ts-preamble] for transmitting the
Transport Streams. payload-specific information for MPEG2 Transport Streams.
4. Updated Request: RR MAY send a new RAMS-R message (to the FT 4. Updated Request: RTP_Rx MAY send a new RAMS-R message (to the FT
entity of RS) with a different value for one or more fields of an entity of RS) with a different value for one or more fields of an
earlier RAMS-R message. Upon receiving an updated request, RS earlier RAMS-R message. Upon receiving an updated request, RS
MAY use the updated values for sending/shaping the burst, or MAY use the updated values for sending/shaping the burst, or
refine the values and use the refined values for sending/shaping refine the values and use the refined values for sending/shaping
the burst. the burst.
RS MAY send a new RAMS-I message to indicate the changes it made. RS MAY send a new RAMS-I message to indicate the changes it made.
However, note that RS does not have to send a new RAMS-I, or the However, note that RS does not have to send a new RAMS-I, or the
new RAMS-I message may get lost. It is also possible that the new RAMS-I message may get lost. It is also possible that the
updated RAMS-R message could have been lost. Thus, RR SHOULD NOT updated RAMS-R message could have been lost. Thus, RTP_Rx SHOULD
make protocol dependencies on quickly (or ever) receiving a new NOT make protocol dependencies on quickly (or ever) receiving a
RAMS-I message, or assume that RS will honor the requested new RAMS-I message, or assume that RS will honor the requested
changes. changes.
RR may be in an environment where the available resources are RTP_Rx may be in an environment where the available resources are
time-varying, which may or may not deserve sending a new updated time-varying, which may or may not deserve sending a new updated
request. Determining the circumstances where RR should or should request. Determining the circumstances where RTP_Rx should or
not send an updated request and the methods that RR can use to should not send an updated request and the methods that RTP_Rx
detect and evaluate the time-varying available resources are not can use to detect and evaluate the time-varying available
specified in this document. resources are not specified in this document.
5. Updated Response: RS may send more than one RAMS-I messages, 5. Updated Response: RS may send more than one RAMS-I messages,
e.g., to update the value of one or more fields in an earlier e.g., to update the value of one or more fields in an earlier
RAMS-I message and/or to signal RR in real time to join the RAMS-I message and/or to signal RTP_Rx in real time to join the
primary multicast session. RR usually depends on RS to learn the primary multicast session. RTP_Rx usually depends on RS to learn
join time, which can be conveyed by the first RAMS-I message, or the join time, which can be conveyed by the first RAMS-I message,
can be sent/revised in a later RAMS-I message. If RS is not or can be sent/revised in a later RAMS-I message. If RS is not
capable of determining the join time in the first RAMS-I message, capable of determining the join time in the first RAMS-I message,
it MUST send another RAMS-I message (with the join time it MUST send another RAMS-I message (with the join time
information) later. information) later.
6. Multicast Join Signaling: In principal, RR can join the primary 6. Multicast Join Signaling: In principal, RTP_Rx can join the
multicast session any time during or after the end of the unicast primary multicast session any time during or after the end of the
burst via an SFGMP Join message. However, there may be missing unicast burst via an SFGMP Join message. However, there may be
packets if RR joins the primary multicast session too early or missing packets if RTP_Rx joins the primary multicast session too
too late. For example, if RR starts receiving the primary early or too late. For example, if RTP_Rx starts receiving the
multicast stream while it is still receiving the unicast burst at primary multicast stream while it is still receiving the unicast
a high excess bitrate, this may result in an increased risk of burst at a high excess bitrate, this may result in an increased
packet loss. Or, if RR joins the primary multicast session some risk of packet loss. Or, if RTP_Rx joins the primary multicast
time after the unicast burst is finished, there may be a gap session some time after the unicast burst is finished, there may
between the burst and multicast data (a number of RTP packets may be a gap between the burst and multicast data (a number of RTP
be missing). In both cases, RR MAY issue retransmissions packets may be missing). In both cases, RTP_Rx MAY issue
requests (via RTCP NACK messages) [RFC4585] to fill the gap. retransmissions requests (via RTCP NACK messages) [RFC4585] to
fill the gap.
Yet, there are cases where the remaining available bandwidth may Yet, there are cases where the remaining available bandwidth may
limit the number of retransmissions that can be provided within a limit the number of retransmissions that can be provided within a
certain time period, causing the retransmission data to arrive certain time period, causing the retransmission data to arrive
too late at RR (from an application-layer point of view). To too late at RTP_Rx (from an application-layer point of view). To
cope with such cases, the RAMS-I message allows RS to signal cope with such cases, the RAMS-I message allows RS to signal
explicitly when RR should send the SFGMP Join message. explicitly when RTP_Rx should send the SFGMP Join message.
Alternatively, RS may pre-compute the burst duration and the time Alternatively, RS may pre-compute the burst duration and the time
RR should send the SFGMP Join message. This information may be RTP_Rx should send the SFGMP Join message. This information may
conveyed in the RAMS-I message and can be updated in a subsequent be conveyed in the RAMS-I message and can be updated in a
RAMS-I message. While RR MAY use a locally calculated join time, subsequent RAMS-I message. While RTP_Rx MAY use a locally
it SHOULD use the information from the most recent RAMS-I calculated join time, it SHOULD use the information from the most
message. recent RAMS-I message.
7. Multicast Receive: After the join, RR starts receiving the 7. Multicast Receive: After the join, RTP_Rx starts receiving the
primary multicast stream. primary multicast stream.
8. Terminate: RS may know when it needs to stop the unicast burst 8. Terminate: RS may know when it needs to stop the unicast burst
based on the burst parameters, or RR MAY explicitly let RS know based on the burst parameters, or RTP_Rx MAY explicitly let RS
the sequence number of the first RTP packet it received from the know the sequence number of the first RTP packet it received from
multicast session, or RR MAY request RS to terminate the burst the multicast session, or RTP_Rx MAY request RS to terminate the
immediately. burst immediately.
Regardless of whether or not RS knows when it needs to stop the Regardless of whether or not RS knows when it needs to stop the
burst, RR SHALL use the RAMS-Termination (RAMS-T) message at an burst, RTP_Rx SHALL use the RAMS-Termination (RAMS-T) message at
appropriate time. RR can choose to send the RAMS-T message an appropriate time. RTP_Rx can choose to send the RAMS-T
before or after it starts receiving the multicast data. In the message before or after it starts receiving the multicast data.
latter case, RR SHALL include the sequence number of the first In the latter case, RTP_Rx SHALL include the sequence number of
RTP packet received in the primary multicast session in the the first RTP packet received in the primary multicast session in
RAMS-T message, and RS SHOULD terminate the burst after it sends the RAMS-T message, and RS SHOULD terminate the burst after it
the unicast burst packet whose Original Sequence Number (OSN) sends the unicast burst packet whose Original Sequence Number
field in the RTP retransmission payload header matches this (OSN) field in the RTP retransmission payload header matches this
number minus one. number minus one.
If RR wants to stop the burst prior to receiving the multicast If RTP_Rx wants to stop the burst prior to receiving the
data, it sends an RAMS-T message without an RTP sequence number. multicast data, it sends an RAMS-T message without an RTP
sequence number.
RR MUST send at least one RAMS-T message (if an RTCP BYE message RTP_Rx MUST send at least one RAMS-T message (if an RTCP BYE
has not been issued yet as described in Step 9), and the RAMS-T message has not been issued yet as described in Step 9), and the
message MUST be addressed to the RTCP port of the retransmission RAMS-T message MUST be addressed to the RTCP port of the
session. Against the possibility of a message loss, RR MAY retransmission session. Against the possibility of a message
repeat the RAMS-T message multiple times as long as it follows loss, RTP_Rx MAY repeat the RAMS-T message multiple times as long
the RTCP timer rules defined in [RFC4585]. as it follows the RTCP timer rules defined in [RFC4585].
9. Terminate with RTCP BYE: When RR is receiving the burst, if RR 9. Terminate with RTCP BYE: When RTP_Rx is receiving the burst, if
becomes no longer interested in the primary multicast stream, RR RTP_Rx becomes no longer interested in the primary multicast
SHALL issue an RTCP BYE message for the RTP retransmission stream, RTP_Rx SHALL issue an RTCP BYE message for the RTP
session and another RTCP BYE message for the primary multicast retransmission session and another RTCP BYE message for the
session. primary multicast session.
Upon receiving an RTCP BYE message, RS MUST terminate the rapid Upon receiving an RTCP BYE message, RS MUST terminate the rapid
acquisition operation, and cease transmitting any further regular acquisition operation, and cease transmitting any further regular
retransmission packets as well as retransmission packets retransmission packets as well as retransmission packets
associated with the unicast burst. If support for [RFC5506] has associated with the unicast burst. If support for [RFC5506] has
been signaled, the RTCP BYE message MAY be sent in a reduced-size been signaled, the RTCP BYE message MAY be sent in a reduced-size
RTCP packet. Otherwise, Section 6.1 of [RFC3550] mandates the RTCP packet. Otherwise, Section 6.1 of [RFC3550] mandates the
RTCP BYE message always to be sent with a sender or receiver RTCP BYE message always to be sent with a sender or receiver
report in a compound RTCP packet (If no data has been received, report in a compound RTCP packet (If no data has been received,
an empty receiver report MUST be included). With the information an empty receiver report MUST be included). With the information
contained in the receiver report, RS can also figure out how many contained in the receiver report, RS can also figure out how many
duplicate RTP packets have been delivered to RR (Note that this duplicate RTP packets have been delivered to RTP_Rx (Note that
will be an upper-bound estimate as one or more packets might have this will be an upper-bound estimate as one or more packets might
been lost during the burst transmission). The impact of have been lost during the burst transmission). The impact of
duplicate packets and measures that can be taken to minimize the duplicate packets and measures that can be taken to minimize the
impact of receiving duplicate packets will be addressed in impact of receiving duplicate packets will be addressed in
Section 6.3. Section 6.3.
Note that an RTCP BYE message issued for the RTP retransmission Note that an RTCP BYE message issued for the RTP retransmission
session terminates the whole session and ceases transmitting any session terminates the whole session and ceases transmitting any
further packets in that RTP session. Thus, in this case there is further packets in that RTP session. Thus, in this case there is
no need for sending an (explicit) RAMS-T message, which would no need for sending an (explicit) RAMS-T message, which would
only terminate the burst. only terminate the burst.
Note that for the purpose of gathering detailed information about Note that for the purpose of gathering detailed information about
RR's rapid acquisition experience, [I-D.begen-avt-rapid-sync-rtcp-xr] RTP_Rx's rapid acquisition experience,
defines an RTCP Extended Report (XR) Block. This report is designed [I-D.begen-avt-rapid-sync-rtcp-xr] defines an RTCP Extended Report
to be payload-independent, thus, it can be used by any multicast (XR) Block. This report is designed to be payload-independent, thus,
application that supports rapid acquisition. Support for this XR it can be used by any multicast application that supports rapid
report is, however, optional. acquisition. Support for this XR report is, however, optional.
6.3. Shaping the Unicast Burst 6.3. Shaping the Unicast Burst
This section provides informative guidelines about how RS can shape This section provides informative guidelines about how RS can shape
the transmission of the unicast burst. the transmission of the unicast burst.
A higher bitrate for the unicast burst naturally conveys the A higher bitrate for the unicast burst naturally conveys the
Reference Information and media content to RR faster. This way, RR Reference Information and media content to RTP_Rx faster. This way,
can start consuming the data sooner, which results in a faster RTP_Rx can start consuming the data sooner, which results in a faster
acquisition. acquisition.
A higher rate also represents a better utilization of RS resources. A higher rate also represents a better utilization of RS resources.
As the burst may continue until it catches up with the primary As the burst may continue until it catches up with the primary
multicast stream, the higher the bursting rate, the less data RS multicast stream, the higher the bursting rate, the less data RS
needs to transmit. However, a higher rate for the burst also needs to transmit. However, a higher rate for the burst also
increases the chances for congestion-caused packet loss. Thus, as increases the chances for congestion-caused packet loss. Thus, as
discussed in Section 5, there must be an upper bound on the extra discussed in Section 5, there must be an upper bound on the extra
bandwidth used by the burst. bandwidth used by the burst.
When RS transmits the burst, it SHOULD take into account all When RS transmits the burst, it SHOULD take into account all
available information to prevent any packet loss that may take place available information to prevent any packet loss that may take place
during the bursting as a result of buffer overflow on the path during the bursting as a result of buffer overflow on the path
between RS and RR and at RR itself. The bursting rate may be between RS and RTP_Rx and at RTP_Rx itself. The bursting rate may be
determined by taking into account the following data, when available: determined by taking into account the following data, when available:
a. Information obtained via the RAMS-R message, such as Max RAMS a. Information obtained via the RAMS-R message, such as Max RAMS
Buffer Fill Requirement and/or Max Receive Bitrate (See Buffer Fill Requirement and/or Max Receive Bitrate (See
Section 7.2). Section 7.2).
b. Information obtained via RTCP receiver reports provided by RR in b. Information obtained via RTCP receiver reports provided by RTP_Rx
the retransmission session, allowing in-session rate adaptations in the retransmission session, allowing in-session rate
for the burst. When these receiver reports indicate packet loss, adaptations for the burst. When these receiver reports indicate
this may indicate a certain congestion state in the path from RS packet loss, this may indicate a certain congestion state in the
to RR. Heuristics or algorithms that deduce such congestion path from RS to RTP_Rx. Heuristics or algorithms that deduce
such congestion state and how subsequently the RS should act, are
outside the scope of this document.
c. Information obtained via RTCP NACKs provided by RTP_Rx in the
primary multicast session, allowing in-session rate adaptations
for the burst. Such RTCP NACKs are transmitted by RTP_Rx in
response to packet loss detection by RTP_Rx in the burst. NACKs
may indicate a certain congestion state on the path from RS to
RTP_Rx. Heuristics or algorithms that deduce such congestion
state and how subsequently the RS should act, are outside the state and how subsequently the RS should act, are outside the
scope of this document. scope of this document.
c. Information obtained via RTCP NACKs provided by RR in the primary d. There may be other feedback received from RTP_Rx, e.g., in the
multicast session, allowing in-session rate adaptations for the form of ECN-CE RTCP feedback messages
burst. Such RTCP NACKs are transmitted by RR in response to [I-D.westerlund-avt-ecn-for-rtp] that may influence in-session
packet loss detection by RR in the burst. NACKs may indicate a rate adaptations.
certain congestion state on the path from RS to RR. Heuristics
or algorithms that deduce such congestion state and how
subsequently the RS should act, are outside the scope of this
document.
d. There may be other feedback received from RR, e.g., in the form
of ECN-CE RTCP feedback messages [I-D.westerlund-avt-ecn-for-rtp]
that may influence in-session rate adaptations.
e. Information obtained via updated RAMS-R messages, allowing in- e. Information obtained via updated RAMS-R messages, allowing in-
session rate adaptations, if supported by RS. session rate adaptations, if supported by RS.
f. Pre-configured settings for each RR or a set of RRs that indicate f. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that
the upper-bound bursting rates for which no packet loss will indicate the upper-bound bursting rates for which no packet loss
occur as a result of congestion along the path of RS to RR. For will occur as a result of congestion along the path of RS to
example, in managed IPTV networks, where the bottleneck bandwidth RTP_Rx. For example, in managed IPTV networks, where the
along the end-to-end path is known (which is generally the access bottleneck bandwidth along the end-to-end path is known (which is
network link) and where the network between RS and this link is generally the access network link) and where the network between
provisioned and dimensioned to carry the burst streams, the RS and this link is provisioned and dimensioned to carry the
bursting rate does not exceed the provisioned value. These burst streams, the bursting rate does not exceed the provisioned
settings may also be dynamically adapted using application-aware value. These settings may also be dynamically adapted using
knowledge. application-aware knowledge.
The initial bursting rate of the unicast burst to RR is determined by The initial bursting rate of the unicast burst to RTP_Rx is
parameters directly obtained from RR (a) or by pre-configured determined by parameters directly obtained from RTP_Rx (a) or by pre-
settings (f). If such information is not available, RS may choose an configured settings (f). If such information is not available, RS
appropriate initial bursting rate, and could increase or decrease the may choose an appropriate initial bursting rate, and could increase
rate based on the feedback information (b, c, d or e). However, this or decrease the rate based on the feedback information (b, c, d or
may not be an easy task as by the time packet loss is reported back e). However, this may not be an easy task as by the time packet loss
to RS triggering a rate reduction, packet loss may have occurred. is reported back to RS triggering a rate reduction, packet loss may
have occurred.
A specific situation occurs near the end of the unicast burst, when A specific situation occurs near the end of the unicast burst, when
RS has almost no more additional data to sustain the relatively RS has almost no more additional data to sustain the relatively
higher bursting rate, thus, the upper-bound bursting rate higher bursting rate, thus, the upper-bound bursting rate
automatically gets limited by the nominal rate of the primary automatically gets limited by the nominal rate of the primary
multicast stream. During this time frame, RR will join the primary multicast stream. During this time frame, RTP_Rx will join the
multicast session because it was instructed to do so via an RAMS-I primary multicast session because it was instructed to do so via an
message or based on some heuristics. This means that both the burst RAMS-I message or based on some heuristics. This means that both the
packets and the primary multicast stream packets will be burst packets and the primary multicast stream packets will be
simultaneously received by RR for a period of time. simultaneously received by RTP_Rx for a period of time.
In this case, when the unicast burst is close to catch up with the In this case, when the unicast burst is close to catch up with the
primary multicast stream, RS may, for example, keep on sending burst primary multicast stream, RS may, for example, keep on sending burst
packets but should reduce the rate accordingly by taking the nominal packets but should reduce the rate accordingly by taking the nominal
rate of the primary multicast stream into account. Alternatively, RS rate of the primary multicast stream into account. Alternatively, RS
may immediately cease transmitting the burst packets, when being may immediately cease transmitting the burst packets, when being
close to catch-up. Any gap resulting from an imperfect switch by RR close to catch-up. Any gap resulting from an imperfect switch by
in receiving first the burst packets and then only primary multicast RTP_Rx in receiving first the burst packets and then only primary
stream packets, can be later repaired by requesting retransmissions multicast stream packets, can be later repaired by requesting
of the missing packets from RS. The retransmissions may also be retransmissions of the missing packets from RS. The retransmissions
shaped by RS to make sure that they do not cause collateral loss in may also be shaped by RS to make sure that they do not cause
the primary multicast and retransmission sessions. collateral loss in the primary multicast and retransmission sessions.
6.4. Failure Cases 6.4. Failure Cases
All RAMS messages MAY be sent several times against the possibility All RAMS messages MAY be sent several times against the possibility
of message loss as long as RS/RR follows the RTCP timer rules defined of message loss as long as RS/RTP_Rx follows the RTCP timer rules
in [RFC4585]. In the following, we examine the implications of defined in [RFC4585]. In the following, we examine the implications
losing the RAMS-R, RAMS-I or RAMS-T messages. of losing the RAMS-R, RAMS-I or RAMS-T messages.
When RR sends an RAMS-R message to initiate a rapid acquisition but When RTP_Rx sends an RAMS-R message to initiate a rapid acquisition
the message gets lost and RS does not receive it, RR will not get an but the message gets lost and RS does not receive it, RTP_Rx will not
RAMS-I message, nor a unicast burst. In this case, RR MAY resend the get an RAMS-I message, nor a unicast burst. In this case, RTP_Rx MAY
request when it is eligible to do so. Or, after a reasonable amount resend the request when it is eligible to do so. Or, after a
of time, RR MAY time out (based on the previous observed response reasonable amount of time, RTP_Rx MAY time out (based on the previous
times) and immediately join the primary multicast session. In this observed response times) and immediately join the primary multicast
case, RR MUST still send an RAMS-T message. session. In this case, RTP_Rx MUST still send an RAMS-T message.
In the case RR starts receiving a unicast burst but it does not In the case RTP_Rx starts receiving a unicast burst but it does not
receive a corresponding RAMS-I message within a reasonable amount of receive a corresponding RAMS-I message within a reasonable amount of
time, RR MAY either discard the burst data and stop the burst by time, RTP_Rx MAY either discard the burst data and stop the burst by
sending an RAMS-T message to RS, or decide not to interrupt the sending an RAMS-T message to RS, or decide not to interrupt the
unicast burst and be prepared to join the primary multicast session unicast burst and be prepared to join the primary multicast session
at an appropriate time it determines or indicated in a subsequent at an appropriate time it determines or indicated in a subsequent
RAMS-I message (if available). In either case, RR SHALL send an RAMS-I message (if available). In either case, RTP_Rx SHALL send an
RAMS-T message to RS at an appropriate time. RAMS-T message to RS at an appropriate time.
In the case the RAMS-T message sent by RR does not reach its In the case the RAMS-T message sent by RTP_Rx does not reach its
destination, RS may continue sending the unicast burst even though RR destination, RS may continue sending the unicast burst even though
no longer needs it. In some cases, RS has not pre-computed the burst RTP_Rx no longer needs it. In some cases, RS has not pre-computed
duration and does not know when to stop the burst. To cover that the burst duration and does not know when to stop the burst. To
case, RR MAY repeat the RAMS-T message multiple times as long as it cover that case, RTP_Rx MAY repeat the RAMS-T message multiple times
follows the RTCP timer rules defined in [RFC4585]. RS MUST be as long as it follows the RTCP timer rules defined in [RFC4585]. RS
provisioned to deterministically terminate the burst at some point, MUST be provisioned to deterministically terminate the burst at some
even if it never receives an RAMS-T message for an ongoing burst. point, even if it never receives an RAMS-T message for an ongoing
burst.
If RR becomes no longer interested in receiving the primary multicast If RTP_Rx becomes no longer interested in receiving the primary
stream and the associated unicast burst, RR SHALL issue an RTCP BYE multicast stream and the associated unicast burst, RTP_Rx SHALL issue
message to RS to terminate the RTP retransmission session. Only an RTCP BYE message to RS to terminate the RTP retransmission
after that, RR MAY send a new rapid acquisition request for another session. Only after that, RTP_Rx MAY send a new rapid acquisition
primary multicast session. request for another primary multicast session.
7. Encoding of the Signaling Protocol in RTCP 7. Encoding of the Signaling Protocol in RTCP
This section defines the formats of the RTCP transport-layer feedback This section defines the formats of the RTCP transport-layer feedback
messages that are exchanged between the Retransmission Server (RS) messages that are exchanged between the Retransmission Server (RS)
and RTP Receiver (RR) during rapid acquisition. These messages are and RTP Receiver (RTP_Rx) during rapid acquisition. These messages
referred to as the RAMS Messages. They are payload-independent and are referred to as the RAMS Messages. They are payload-independent
MUST be used by all RTP-based multicast applications that support and MUST be used by all RTP-based multicast applications that support
rapid acquisition regardless of the payload they carry. rapid acquisition regardless of the payload they carry.
Payload-specific feedback messages are not defined in this document, Payload-specific feedback messages are not defined in this document,
but an extension mechanism is provided where further optional but an extension mechanism is provided where further optional
payload-independent and payload-specific information can be included payload-independent and payload-specific information can be included
in the exchange. in the exchange.
The common packet format for the RTCP feedback messages is defined in The common packet format for the RTCP feedback messages is defined in
Section 6.1 of [RFC4585]. Each feedback message has a fixed-length Section 6.1 of [RFC4585]. Each feedback message has a fixed-length
field for version, padding, feedback message type (FMT), payload type field for version, padding, feedback message type (FMT), payload type
skipping to change at page 25, line 38 skipping to change at page 25, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. / | Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Structure of a TLV element Figure 4: Structure of a TLV element
7.1.1. Vendor-Neutral Extensions 7.1.1. Vendor-Neutral Extensions
If the goal in defining new TLV elements is to extend the If the goal in defining new TLV elements is to extend the
functionality in a vendor-neutral manner, they MUST be registered functionality in a vendor-neutral manner, they MUST be registered
with IANA through the guidelines provided in Section 13.5. with IANA through the guidelines provided in Section 12.5.
The current document defines several vendor-neutral extensions in the The current document defines several vendor-neutral extensions in the
following sections. following sections.
7.1.2. Private Extensions 7.1.2. Private Extensions
It is desirable to allow vendors to use private extensions in TLV It is desirable to allow vendors to use private extensions in TLV
format. For interoperability, such extensions MUST NOT collide with format. For interoperability, such extensions MUST NOT collide with
each other. each other.
A certain range of TLV Types is reserved for private extensions A certain range of TLV Types is reserved for private extensions
(Refer to Section 13.5). IANA management for these extensions is (Refer to Section 12.5). IANA management for these extensions is
unnecessary and they are the responsibility of individual vendors. unnecessary and they are the responsibility of individual vendors.
The structure that MUST be used for the private extensions is The structure that MUST be used for the private extensions is
depicted in Figure 5. Here, the enterprise numbers are used from depicted in Figure 5. Here, the enterprise numbers are used from
http://www.iana.org/assignments/enterprise-numbers. This will ensure http://www.iana.org/assignments/enterprise-numbers. This will ensure
the uniqueness of the private extensions and avoid any collision. the uniqueness of the private extensions and avoid any collision.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 29 skipping to change at page 26, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Structure of a private extension Figure 5: Structure of a private extension
7.2. RAMS Request 7.2. RAMS Request
The RAMS Request message is identified by SFMT=1. The RAMS Request message is identified by SFMT=1.
The FCI field MUST contain only one RAMS Request. The FCI field MUST contain only one RAMS Request.
The RAMS Request is used by RR to request rapid acquisition for a new The RAMS Request is used by RTP_Rx to request rapid acquisition for a
multicast RTP session. new multicast RTP session.
The FCI field has the structure depicted in Figure 6. The FCI field has the structure depicted in Figure 6.
Editor's note: We have not finalized whether RAMS-R messages need a
sequence number or not.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=1 | Optional TLV-encoded Fields | | SFMT=1 | Optional TLV-encoded Fields |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
: Optional TLV-encoded Fields (and Padding, if needed) : : Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FCI field syntax for the RAMS Request message Figure 6: FCI field syntax for the RAMS Request message
o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element
that denotes the minimum milliseconds of data that RR desires to that denotes the minimum milliseconds of data that RTP_Rx desires
have in its buffer before allowing the data to be consumed by the to have in its buffer before allowing the data to be consumed by
application. the application.
RR may have knowledge of its buffering requirements. These RTP_Rx may have knowledge of its buffering requirements. These
requirements may be application and/or device specific. For requirements may be application and/or device specific. For
instance, RR may need to have a certain amount of data in its instance, RTP_Rx may need to have a certain amount of data in its
application buffer to handle transmission jitter and/or to be able application buffer to handle transmission jitter and/or to be able
to support error-control methods. If RS is told the minimum to support error-control methods. If RS is told the minimum
buffering requirement of the receiver, it may tailor the burst buffering requirement of the receiver, it may tailor the burst
more precisely, e.g., by choosing an appropriate starting point. more precisely, e.g., by choosing an appropriate starting point.
The methods used by RR to determine this value are application The methods used by RTP_Rx to determine this value are application
specific, and thus, out of the scope of this document. specific, and thus, out of the scope of this document.
If specified, the amount of backfill that will be provided by the If specified, the amount of backfill that will be provided by the
unicast burst SHOULD NOT be smaller than the specified value since unicast burst SHOULD NOT be smaller than the specified value since
it will not be able to build up the desired level of buffer at RR it will not be able to build up the desired level of buffer at
and may cause buffer underruns. RTP_Rx and may cause buffer underruns.
Type: 1 Type: 1
o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element
that denotes the maximum milliseconds of data that RR can buffer that denotes the maximum milliseconds of data that RTP_Rx can
without losing the burst data due to buffer overflow. buffer without losing the burst data due to buffer overflow.
RR may have knowledge of its buffering requirements. These RTP_Rx may have knowledge of its buffering requirements. These
requirements may be application or device specific. For instance, requirements may be application or device specific. For instance,
one particular RR may have more physical memory than another RR, one particular RTP_Rx may have more physical memory than another
and thus, can buffer more data. If RS knows the buffering ability RTP_Rx, and thus, can buffer more data. If RS knows the buffering
of the receiver, it may tailor the burst more precisely. The ability of the receiver, it may tailor the burst more precisely.
methods used by the receiver to determine this value are The methods used by the receiver to determine this value are
application specific, and thus, out of scope. application specific, and thus, out of scope.
If specified, the amount of backfill that will be provided by the If specified, the amount of backfill that will be provided by the
unicast burst SHOULD NOT be larger than this value since it may unicast burst SHOULD NOT be larger than this value since it may
cause buffer overflows at RR. cause buffer overflows at RTP_Rx.
Type: 2 Type: 2
o Max Receive Bitrate (32 bits): Optional TLV element that denotes o Max Receive Bitrate (32 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that the RTP receiver can the maximum bitrate (in bits per second) that the RTP receiver can
process the unicast burst. This rate should include whatever process the unicast burst. This rate should include whatever
knowledge the receiver has that would provide an upper bound on knowledge the receiver has that would provide an upper bound on
the unicast burst bitrate. The limits may include local receiver the unicast burst bitrate. The limits may include local receiver
limits as well as network limits that are known to the receiver. limits as well as network limits that are known to the receiver.
skipping to change at page 28, line 16 skipping to change at page 28, line 21
payload type. payload type.
7.3. RAMS Information 7.3. RAMS Information
The RAMS Information message is identified by SFMT=2. The RAMS Information message is identified by SFMT=2.
The FCI field MUST contain only one RAMS Information. The FCI field MUST contain only one RAMS Information.
The RAMS Information is used to describe the unicast burst that will The RAMS Information is used to describe the unicast burst that will
be sent for rapid acquisition. It also includes other useful be sent for rapid acquisition. It also includes other useful
information for RR as described below. Optional payload-specific information for RTP_Rx as described below. Optional payload-specific
information MAY follow RAMS Information. information MAY follow RAMS Information.
The FCI field has the structure depicted in Figure 7. The FCI field has the structure depicted in Figure 7.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=2 | MSN | Response | | SFMT=2 | MSN | Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) : : Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: FCI field syntax for the RAMS Information message Figure 7: FCI field syntax for the RAMS Information message
o Message Sequence Number (8 bits) : Mandatory field that denotes o Message Sequence Number (8 bits) : Mandatory field that denotes
the sequence number of this RAMS-I message. During rapid the sequence number of this RAMS-I message. During rapid
acquisition, multiple RAMS-I messages MAY be sent and/or the same acquisition, multiple RAMS-I messages MAY be sent and/or the same
RAMS-I message MAY be repeated. The first RAMS-I message SHALL RAMS-I message MAY be repeated. The first RAMS-I message SHALL
have an MSN value of 0. This value SHALL NOT be changed if the have an MSN value of 0. This value SHALL NOT be changed if the
same RAMS-I message is sent to the same RR multiple times for same RAMS-I message is sent to the same RTP_Rx multiple times for
redundancy purposes. If a new information is conveyed in a new redundancy purposes. If a new information is conveyed in a new
RAMS-I message, the MSN value SHALL be incremented by one. RAMS-I message, the MSN value SHALL be incremented by one.
o Response (16 bits): Mandatory field that denotes the RS response o Response (16 bits): Mandatory field that denotes the RS response
code for this RAMS-I message. This document defines several code for this RAMS-I message. This document defines several
initial response codes and registers them with IANA. If a new initial response codes and registers them with IANA. If a new
vendor-neutral response code will be defined, it MUST be vendor-neutral response code will be defined, it MUST be
registered with IANA through the guidelines specified in registered with IANA through the guidelines specified in
Section 13.6. If the new response code is intended to be used Section 12.6. If the new response code is intended to be used
privately by a vendor, there is no need for IANA management. privately by a vendor, there is no need for IANA management.
Instead, the vendor MUST use the private extension mechanism Instead, the vendor MUST use the private extension mechanism
(Section 7.1.2) to convey its message and MUST indicate this by (Section 7.1.2) to convey its message and MUST indicate this by
putting zero in the Response field. putting zero in the Response field.
o RTP Seqnum of the First Packet (16 bits): TLV element that o RTP Seqnum of the First Packet (16 bits): TLV element that
specifies the RTP sequence number of the first packet that will be specifies the RTP sequence number of the first packet that will be
sent in the retransmission session. This allows RR to know sent in the retransmission session. This allows RTP_Rx to know
whether one or more packets sent by RS have been dropped at the whether one or more packets sent by RS have been dropped at the
beginning of the retransmission session. If RS accepts the RAMS beginning of the retransmission session. If RS accepts the RAMS
request, this element MUST exist. If RS rejects the RAMS request, request, this element MUST exist. If RS rejects the RAMS request,
this element SHALL NOT exist. this element SHALL NOT exist.
Type: 31 Type: 31
o Earliest Multicast Join Time (32 bits): Optional TLV element that o Earliest Multicast Join Time (32 bits): Optional TLV element that
specifies the time difference (i.e., delta time) between the specifies the time difference (i.e., delta time) between the
arrival of this RAMS-I message and the earliest time instant when arrival of this RAMS-I message and the earliest time instant when
RR could join the primary multicast session in RTP ticks. A zero RTP_Rx could join the primary multicast session in RTP ticks. A
value in this field means that RR can join the primary multicast zero value in this field means that RTP_Rx can join the primary
session right away. multicast session right away.
Note that if the RAMS request has been accepted, RS MUST send this Note that if the RAMS request has been accepted, RS MUST send this
field at least once, so that RR knows when to join the primary field at least once, so that RTP_Rx knows when to join the primary
multicast session. If the burst request has been rejected as multicast session. If the burst request has been rejected as
indicated in the Response field, this field MAY be omitted or set indicated in the Response field, this field MAY be omitted or set
to 0. In that case, it is up to RR when or whether to join the to 0. In that case, it is up to RTP_Rx when or whether to join
primary multicast session. the primary multicast session.
Type: 32 Type: 32
o Burst Duration (32 bits): Optional TLV element that denotes the o Burst Duration (32 bits): Optional TLV element that denotes the
duration of the burst that RS is planning to send (in RTP ticks). duration of the burst that RS is planning to send (in RTP ticks).
In the absence of additional stimulus, RS will send a burst of In the absence of additional stimulus, RS will send a burst of
this duration. However, the burst duration may be modified by this duration. However, the burst duration may be modified by
subsequent events, including changes in the primary multicast subsequent events, including changes in the primary multicast
stream and reception of RAMS-T messages. stream and reception of RAMS-T messages.
Note that RS MUST terminate the flow in a deterministic timeframe, Note that RS MUST terminate the flow in a deterministic timeframe,
even if it does not get an RAMS-T or a BYE from RR. It is even if it does not get an RAMS-T or a BYE from RTP_Rx. It is
optional to send this field in an RAMS-I message when the burst optional to send this field in an RAMS-I message when the burst
request is accepted. If the burst request has been rejected as request is accepted. If the burst request has been rejected as
indicated in the Response field, this field MAY be omitted or set indicated in the Response field, this field MAY be omitted or set
to 0. to 0.
Type: 33 Type: 33
o Max Transmit Bitrate (32 bits): Optional TLV element that denotes o Max Transmit Bitrate (32 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that will be used by RS. the maximum bitrate (in bits per second) that will be used by RS.
skipping to change at page 30, line 19 skipping to change at page 30, line 23
7.4. RAMS Termination 7.4. RAMS Termination
The RAMS Termination message is identified by SFMT=3. The RAMS Termination message is identified by SFMT=3.
The FCI field MUST contain only one RAMS Termination. The FCI field MUST contain only one RAMS Termination.
The RAMS Termination may be used to assist RS in determining when to The RAMS Termination may be used to assist RS in determining when to
stop the burst. stop the burst.
If prior to sending the RAMS-T message RR has already joined the If prior to sending the RAMS-T message RTP_Rx has already joined the
primary multicast session and received at least one RTP packet from primary multicast session and received at least one RTP packet from
the multicast session, RR includes the sequence number of the first the multicast session, RTP_Rx includes the sequence number of the
RTP packet in the RAMS-T message. With this information, RS can first RTP packet in the RAMS-T message. With this information, RS
decide when to terminate the unicast burst. can decide when to terminate the unicast burst.
If RR issues the RAMS-T message before it has joined and/or begun If RTP_Rx issues the RAMS-T message before it has joined and/or begun
receiving RTP packets from the primary multicast session, RR does not receiving RTP packets from the primary multicast session, RTP_Rx does
specify any sequence number in the RAMS-T message, which indicates RS not specify any sequence number in the RAMS-T message, which
to stop the burst immediately. However, the RAMS-T message may get indicates RS to stop the burst immediately. However, the RAMS-T
lost and RS may not receive this message. message may get lost and RS may not receive this message.
The FCI field has the structure depicted in Figure 8. The FCI field has the structure depicted in Figure 8.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=3 | Optional TLV-encoded Fields | | SFMT=3 | Optional TLV-encoded Fields |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
: Optional TLV-encoded Fields (and Padding, if needed) : : Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FCI field syntax for the RAMS Termination message Figure 8: FCI field syntax for the RAMS Termination message
o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional
TLV element that specifies the extended RTP sequence number of the TLV element that specifies the extended RTP sequence number of the
of the first multicast packet received by RR. If no RTP packet of the first multicast packet received by RTP_Rx. If no RTP
has been received from the primary multicast session, this field packet has been received from the primary multicast session, this
does not exist and tells RS to stop the burst immediately. field does not exist and tells RS to stop the burst immediately.
Type: 61 Type: 61
The semantics of the RAMS-T feedback message is independent of the The semantics of the RAMS-T feedback message is independent of the
payload type. payload type.
8. SDP Definitions and Examples 8. SDP Definitions and Examples
8.1. Definitions 8.1. Definitions
skipping to change at page 31, line 36 skipping to change at page 31, line 38
The following parameter is defined in this document for use with The following parameter is defined in this document for use with
'nack': 'nack':
o 'ssli' stands for Stream Synchronization Loss Indication and o 'ssli' stands for Stream Synchronization Loss Indication and
indicates the use of RAMS messages as defined in Section 7. indicates the use of RAMS messages as defined in Section 7.
This document also defines a new SDP attribute ('rams-updates') that This document also defines a new SDP attribute ('rams-updates') that
indicates whether RS supports updated request messages or not. This indicates whether RS supports updated request messages or not. This
attribute is used in a declarative manner. If RS supports updated attribute is used in a declarative manner. If RS supports updated
request messages and this attribute is included in the SDP request messages and this attribute is included in the SDP
description, RR MAY send updated requests. RS may or may not be able description, RTP_Rx MAY send updated requests. RS may or may not be
to accept value changes in every field in an RAMS-R message. able to accept value changes in every field in an RAMS-R message.
However, if the 'rams-updates' attribute is not included in the SDP However, if the 'rams-updates' attribute is not included in the SDP
description, RR SHALL NOT send updated requests (RR MAY repeat its description, RTP_Rx SHALL NOT send updated requests (RTP_Rx MAY
initial request without changes, though). repeat its initial request without changes, though).
8.2. Examples 8.2. Examples
This section provides a declarative SDP [RFC4566] example for This section provides a declarative SDP [RFC4566] example for
enabling rapid acquisition of multicast RTP sessions. The following enabling rapid acquisition of multicast RTP sessions. The following
example uses the SDP grouping semantics [I-D.ietf-mmusic-rfc3388bis], example uses the SDP grouping semantics [I-D.ietf-mmusic-rfc3388bis],
the RTP/AVPF profile [RFC4585], the RTP retransmissions [RFC4588], the RTP/AVPF profile [RFC4585], the RTP retransmissions [RFC4588],
the RTCP extensions for SSM sessions with unicast feedback the RTCP extensions for SSM sessions with unicast feedback
[I-D.ietf-avt-rtcpssm] and the source-specific media attributes [I-D.ietf-avt-rtcpssm] and the source-specific media attributes
[RFC5576]. [RFC5576].
In the example shown Figure 9, we have a primary multicast stream and In the example shown Figure 9, we have a primary multicast stream and
a unicast retransmission stream. The source stream is multicast from a unicast retransmission stream. The source stream is multicast from
a distribution source (with a source IP address of 192.0.2.2) to the a distribution source (with a source IP address of 192.0.2.2) to the
multicast destination address of 233.252.0.2 and port 41000. A multicast destination address of 233.252.0.2 and port 41000. A
Retransmission Server including feedback target functionality (with Retransmission Server including feedback target functionality (with
an address of 192.0.2.1 and port of 41001) is specified with the an address of 192.0.2.1 and port of 41001) is specified with the
'rtcp' attribute. The RTP receiver(s) can report missing packets on 'rtcp' attribute. The RTP receiver(s) can report missing packets on
the source stream to the feedback target and request retransmissions. the source stream to the feedback target and request retransmissions.
skipping to change at page 32, line 19 skipping to change at page 32, line 21
Retransmission Server including feedback target functionality (with Retransmission Server including feedback target functionality (with
an address of 192.0.2.1 and port of 41001) is specified with the an address of 192.0.2.1 and port of 41001) is specified with the
'rtcp' attribute. The RTP receiver(s) can report missing packets on 'rtcp' attribute. The RTP receiver(s) can report missing packets on
the source stream to the feedback target and request retransmissions. the source stream to the feedback target and request retransmissions.
In the RAMS context, the parameter 'rtx-time' specifies the time in In the RAMS context, the parameter 'rtx-time' specifies the time in
milliseconds that the Retransmission Server keeps an RTP packet in milliseconds that the Retransmission Server keeps an RTP packet in
its buffer available for retransmission (measured from the time the its buffer available for retransmission (measured from the time the
packet was received by the Retransmission Server). packet was received by the Retransmission Server).
The RTP retransmissions are sent on a unicast session with a The RTP retransmissions are sent on a unicast session with a
destination port of 41002. destination port of 41002. The RTCP port for the unicast session
(41003) is specified with the 'rtcp' attribute. In this example,
Editor's note: This text will be updated in a later version to both the conventional retransmission and rapid acquisition support
reflect the capability for RRs to use their desired ports to receive are enabled. This is achieved by the additional "a=rtcp-fb:98 nack
the burst and retransmission packets. ssli" line. Note that this SDP includes the "a=sendonly" line for
the media description of the retransmission stream and is for the
The RTCP port for the unicast session (41003) is specified with the Retransmission Server (RS). Its counterpart for the RTP Receiver
'rtcp' attribute. In this example, both the conventional (RTP_Rx) includes the "a=recvonly" line as shown in Figure 10.
retransmission and rapid acquisition support are enabled. This is
achieved by the additional "a=rtcp-fb:98 nack ssli" line. Note that
this SDP includes the "a=sendonly" line for the media description of
the retransmission stream and is for the Retransmission Server (RS).
Its counterpart for the RTP Receiver (RR) includes the "a=recvonly"
line as shown in Figure 10.
When an RTP receiver requires rapid acquisition for a new multicast When an RTP receiver requires rapid acquisition for a new multicast
session it wants to join, it sends an RAMS-R message to the feedback session it wants to join, it sends an RAMS-R message to the feedback
target of that primary multicast session. This feedback message has target of that primary multicast session. This feedback message has
to have the SSRC of the primary multicast stream for which rapid to have the SSRC of the primary multicast stream for which rapid
acquisition is requested for. However, since this RTP receiver has acquisition is requested for. However, since this RTP receiver has
not received any RTP packets from the primary multicast session yet, not received any RTP packets from the primary multicast session yet,
the RTP receiver MUST learn the SSRC value from the 'ssrc' attribute the RTP receiver MUST learn the SSRC value from the 'ssrc' attribute
of the media description [I-D.ietf-avt-rtcpssm]. In addition to the of the media description [I-D.ietf-avt-rtcpssm]. In addition to the
SSRC value, the 'cname' source attribute MUST also be present in the SSRC value, the 'cname' source attribute MUST also be present in the
skipping to change at page 34, line 32 skipping to change at page 34, line 32
a=mid:3 a=mid:3
m=video 41002 RTP/AVPF 99 m=video 41002 RTP/AVPF 99
i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support) i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=recvonly a=recvonly
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=rtcp:41003 a=rtcp:41003
a=fmtp:99 apt=98; rtx-time=5000 a=fmtp:99 apt=98; rtx-time=5000
a=mid:4 a=mid:4
Figure 10: Example SDP for RR when RAMS support is enabled Figure 10: Example SDP for RTP_Rx when RAMS support is enabled
The offer/answer model considerations [RFC3264] for the 'rtcp-fb' In the above SDP descriptions, the ports for the unicast session are
attribute are provided in Section 4.2 of [RFC4585]. also declaratively specified and the RTP receivers are required to
use them. In certain scenarios, however, RTP receivers may want to
use other desired ports to receive the burst and retransmission
packets. A current work considers this feature in more general terms
and provides the recommended mechanisms
[I-D.begen-avt-ports-for-ucast-mcast-rtp].
In this section, we considered the simplest scenario where the In this section, we considered the simplest scenario where the
primary multicast session carried only one multicast stream and the primary multicast session carried only one multicast stream and the
RTP receiver wanted to rapidly acquire this stream only. Discussions RTP receiver wanted to rapidly acquire this stream only. Discussions
on scenarios and associated SDP examples where the primary multicast on scenarios where the primary multicast session carries two or more
session carries two or more multicast streams or the RTP receiver multicast streams or the RTP receiver wants to acquire one or more
wants to acquire one or more multicast streams from multiple multicast streams from multiple multicast RTP sessions at the same
multicast RTP sessions at the same time are presented in time are presented in [I-D.begen-avt-rams-scenarios].
[I-D.begen-avt-rams-scenarios].
9. NAT Considerations 9. NAT Considerations
For a variety of reasons, one or more NAPT devices (hereafter simply For a variety of reasons, one or more NAPT devices (hereafter simply
called NAT) are expected to exist between RR and RS. NATs have a called NAT) are expected to exist between RTP_Rx and RS. NATs have a
variety of operating characteristics for UDP traffic [RFC4787]. For variety of operating characteristics for UDP traffic [RFC4787]. For
a NAT to permit traffic from RS to arrive at RR, the NAT(s) must a NAT to permit traffic from RS to arrive at RTP_Rx, the NAT(s) must
first either: first either:
a. See UDP traffic sent from RR (which is on the 'inside' of the a. See UDP traffic sent from RTP_Rx (which is on the 'inside' of the
NAT) to RS (which is on the 'outside' of the NAT). This traffic NAT) to RS (which is on the 'outside' of the NAT). This traffic
is sent to the same transport address as the subsequent response is sent to the same transport address as the subsequent response
traffic, OR; traffic, OR;
b. Be configured to forward certain ports (e.g., using HTML b. Be configured to forward certain ports (e.g., using HTML
configuration, UPnP IGD [UPnP-IGD], DLNA [DLNA]). Details of configuration, UPnP IGD [UPnP-IGD], DLNA [DLNA]). Details of
this are out of scope of this document. this are out of scope of this document.
For both (a) and (b), RR is responsible for maintaining the NAT's For both (a) and (b), RTP_Rx is responsible for maintaining the NAT's
state if it wants to receive traffic from the RS on that port. For state if it wants to receive traffic from the RS on that port. For
(a), RR MUST send UDP traffic to keep the NAT binding alive, at least (a), RTP_Rx MUST send UDP traffic to keep the NAT binding alive, at
every 30 seconds [RFC4787]. Note that while (a) is more like an least every 30 seconds [RFC4787]. Note that while (a) is more like
automatic/dynamic configuration, (b) is more like a manual/static an automatic/dynamic configuration, (b) is more like a manual/static
configuration. configuration.
When using (a), RR will need to first learn the UDP port(s) of the
NAT's binding(s) from the perspective of RS. This is done by sending
a STUN [RFC5389] message from RR to the RTP port of RS which will be
used for incoming RTP traffic. If RTP/RTCP multiplexing on a single
port [I-D.ietf-avt-rtp-and-rtcp-mux] is not supported by RR, it will
need to send a second STUN message to the RTCP port of RS which will
be used for incoming RTCP traffic. If RTP/RTCP multiplexing is
supported by RR, it only needs to learn one port. RS receives the
STUN message(s) and responds to them. RR now knows the UDP ports
from the perspective of RS.
Editor's note: The issues related to using ports across multicast
and unicast RTP sessions are discussed in
[I-D.begen-avt-ports-for-ucast-mcast-rtp]. The updated text for this
section will be provided in a later version.
10. Known Implementations 10. Known Implementations
10.1. Open Source RTP Receiver Implementation by Cisco 10.1. Open Source RTP Receiver Implementation by Cisco
An open source RTP Receiver code that implements the functionalities An open source RTP Receiver code that implements the functionalities
introduced in this document is available. For documentation, visit introduced in this document is available. For documentation, visit
the following URL: the following URL:
http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_4/user/guide/ http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_4/user/guide/
vqe_guide3_4.html vqe_guide3_4.html
skipping to change at page 36, line 25 skipping to change at page 36, line 16
Rapid Acquisition of Multicast RTP Sessions is supported as part of Rapid Acquisition of Multicast RTP Sessions is supported as part of
the Microsoft Mediaroom Internet Protocol Television (IPTV) and the Microsoft Mediaroom Internet Protocol Television (IPTV) and
multimedia software platform. This system is in wide commercial multimedia software platform. This system is in wide commercial
deployment. More information can be found at: deployment. More information can be found at:
http://www.microsoft.com/mediaroom http://www.microsoft.com/mediaroom
http://informitv.com/articles/2008/10/13/channelchangetimes/ http://informitv.com/articles/2008/10/13/channelchangetimes/
11. Open Issues 11. Security Considerations
o Updating the NAT section and SDP examples.
12. Security Considerations
Applications that are using RAMS make heavy use of the unicast Applications that are using RAMS make heavy use of the unicast
feedback mechanism described in [I-D.ietf-avt-rtcpssm] and the feedback mechanism described in [I-D.ietf-avt-rtcpssm] and the
payload format defined in [RFC4588]. Thus, these applications are payload format defined in [RFC4588]. Thus, these applications are
subject to the general security considerations discussed in subject to the general security considerations discussed in
[I-D.ietf-avt-rtcpssm] and [RFC4588]. In this section, we give an [I-D.ietf-avt-rtcpssm] and [RFC4588]. In this section, we give an
overview of the guidelines and suggestions described in these overview of the guidelines and suggestions described in these
specifications from a RAMS perspective. We also discuss the security specifications from a RAMS perspective. We also discuss the security
considerations that explicitly apply to RAMS applications. considerations that explicitly apply to RAMS applications.
skipping to change at page 38, line 9 skipping to change at page 37, line 43
[RFC4588] RECOMMENDS that the cryptography mechanisms are used for [RFC4588] RECOMMENDS that the cryptography mechanisms are used for
the retransmission payload format to provide protection against known the retransmission payload format to provide protection against known
plaintext attacks. As discussed in [RFC4588], the retransmission plaintext attacks. As discussed in [RFC4588], the retransmission
payload format sets the timestamp field in the RTP header to the payload format sets the timestamp field in the RTP header to the
media timestamp of the original packet and this does not compromise media timestamp of the original packet and this does not compromise
the confidentiality. Furthermore, if cryptography is used to provide the confidentiality. Furthermore, if cryptography is used to provide
security services on the original stream, then the same services, security services on the original stream, then the same services,
with equivalent cryptographic strength, MUST be provided on the with equivalent cryptographic strength, MUST be provided on the
retransmission stream per [RFC4588]. retransmission stream per [RFC4588].
13. IANA Considerations 12. IANA Considerations
The following contact information shall be used for all registrations The following contact information shall be used for all registrations
in this document: in this document:
Ali Begen Ali Begen
abegen@cisco.com abegen@cisco.com
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 USA San Jose, CA 95134 USA
Note to the RFC Editor: In the following, please replace "XXXX" with Note to the RFC Editor: In the following, please replace "XXXX" with
the number of this document prior to publication as an RFC. the number of this document prior to publication as an RFC.
13.1. Registration of SDP Attributes 12.1. Registration of SDP Attributes
This document registers a new attribute name in SDP. This document registers a new attribute name in SDP.
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: rams-updates Attribute name: rams-updates
Long form: Support for Updated RAMS Request Messages Long form: Support for Updated RAMS Request Messages
Type of name: att-field Type of name: att-field
Type of attribute: Media level Type of attribute: Media level
Subject to charset: No Subject to charset: No
Purpose: See this document Purpose: See this document
Reference: [RFCXXXX] Reference: [RFCXXXX]
Values: None Values: None
13.2. Registration of SDP Attribute Values 12.2. Registration of SDP Attribute Values
This document registers a new value for the 'nack' attribute to be This document registers a new value for the 'nack' attribute to be
used with the 'rtcp-fb' attribute in SDP. For more information about used with the 'rtcp-fb' attribute in SDP. For more information about
'rtcp-fb', refer to [RFC4585]. 'rtcp-fb', refer to [RFC4585].
Value name: ssli Value name: ssli
Long name: Stream Synchronization Loss Indication Long name: Stream Synchronization Loss Indication
Usable with: nack Usable with: nack
Reference: [RFCXXXX] Reference: [RFCXXXX]
13.3. Registration of FMT Values 12.3. Registration of FMT Values
Within the RTPFB range, the following format (FMT) value is Within the RTPFB range, the following format (FMT) value is
registered: registered:
Name: RAMS Name: RAMS
Long name: Rapid Acquisition of Multicast Sessions Long name: Rapid Acquisition of Multicast Sessions
Value: 6 Value: 6
Reference: [RFCXXXX] Reference: [RFCXXXX]
13.4. SFMT Values for RAMS Messages Registry 12.4. SFMT Values for RAMS Messages Registry
This document creates a new sub-registry for the sub-feedback message This document creates a new sub-registry for the sub-feedback message
type (SFMT) values to be used with the FMT value registered for RAMS type (SFMT) values to be used with the FMT value registered for RAMS
messages. The registry is called the SFMT Values for RAMS Messages messages. The registry is called the SFMT Values for RAMS Messages
Registry. This registry is to be managed by the IANA according to Registry. This registry is to be managed by the IANA according to
the Specification Required policy of [RFC5226]. the Specification Required policy of [RFC5226].
The length of the SFMT field in the RAMS messages is a single octet, The length of the SFMT field in the RAMS messages is a single octet,
allowing 256 values. The registry is initialized with the following allowing 256 values. The registry is initialized with the following
entries: entries:
skipping to change at page 40, line 7 skipping to change at page 39, line 43
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new SFMT represents and how it o A detailed description of what the new SFMT represents and how it
shall be interpreted. shall be interpreted.
Note that new RAMS functionality should be introduced by using the Note that new RAMS functionality should be introduced by using the
extension mechanism within the existing RAMS message types not by extension mechanism within the existing RAMS message types not by
introducing new message types unless it is absolutely necessary. introducing new message types unless it is absolutely necessary.
13.5. RAMS TLV Space Registry 12.5. RAMS TLV Space Registry
This document creates a new IANA TLV space registry for the RAMS This document creates a new IANA TLV space registry for the RAMS
extensions. The registry is called the RAMS TLV Space Registry. extensions. The registry is called the RAMS TLV Space Registry.
This registry is to be managed by the IANA according to the This registry is to be managed by the IANA according to the
Specification Required policy of [RFC5226]. Specification Required policy of [RFC5226].
The length of the Type field in the TLV elements is a single octet, The length of the Type field in the TLV elements is a single octet,
allowing 256 values. The Type values 0 and 255 are reserved for allowing 256 values. The Type values 0 and 255 are reserved for
future use. The Type values between (and including) 128 and 254 are future use. The Type values between (and including) 128 and 254 are
reserved for private extensions. reserved for private extensions.
skipping to change at page 40, line 41 skipping to change at page 40, line 30
Any registration for an unassigned Type value MUST contain the Any registration for an unassigned Type value MUST contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new TLV element represents and o A detailed description of what the new TLV element represents and
how it shall be interpreted. how it shall be interpreted.
13.6. RAMS Response Code Space Registry 12.6. RAMS Response Code Space Registry
This document creates a new IANA TLV space registry for the RAMS This document creates a new IANA TLV space registry for the RAMS
response codes. The registry is called the RAMS Response Code Space response codes. The registry is called the RAMS Response Code Space
Registry. This registry is to be managed by the IANA according to Registry. This registry is to be managed by the IANA according to
the Specification Required policy of [RFC5226]. the Specification Required policy of [RFC5226].
The length of the Response field is two octets, allowing 65536 codes. The length of the Response field is two octets, allowing 65536 codes.
However, the response codes have been classified and registered However, the response codes have been classified and registered
following an HTTP-style code numbering in this document. New following an HTTP-style code numbering in this document. New
response codes SHALL follow the guidelines below: response codes SHALL follow the guidelines below:
skipping to change at page 41, line 39 skipping to change at page 41, line 28
400 Invalid RAMS-R message syntax 400 Invalid RAMS-R message syntax
401 Invalid min buffer requirement in RAMS-R message [RFCXXXX] 401 Invalid min buffer requirement in RAMS-R message [RFCXXXX]
402 Invalid max buffer requirement in RAMS-R message [RFCXXXX] 402 Invalid max buffer requirement in RAMS-R message [RFCXXXX]
403 Invalid max bw requirement in RAMS-R message [RFCXXXX] 403 Invalid max bw requirement in RAMS-R message [RFCXXXX]
500 An unspecified RS internal error has occurred [RFCXXXX] 500 An unspecified RS internal error has occurred [RFCXXXX]
501 RS has no bandwidth to start RAMS session [RFCXXXX] 501 RS has no bandwidth to start RAMS session [RFCXXXX]
502 RS has no CPU available to start RAMS session [RFCXXXX] 502 RS has no CPU available to start RAMS session [RFCXXXX]
503 RAMS functionality is not available on RS [RFCXXXX] 503 RAMS functionality is not available on RS [RFCXXXX]
504 RAMS functionality is not available for RR [RFCXXXX] 504 RAMS functionality is not available for RTP_Rx [RFCXXXX]
505 RAMS functionality is not available for 505 RAMS functionality is not available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
506 RS has no a valid starting point available for 506 RS has no a valid starting point available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
507 RS has no reference information available for 507 RS has no reference information available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
Any registration for an unassigned Response code MUST contain the Any registration for an unassigned Response code MUST contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new Response code describes and o A detailed description of what the new Response code describes and
how it shall be interpreted. how it shall be interpreted.
14. Acknowledgments 13. Acknowledgments
The authors would like to specially thank Peilin Yang for his The authors would like to specially thank Peilin Yang for his
contributions to this document and detailed reviews. contributions to this document and detailed reviews.
The authors also thank the following individuals for their The authors also thank the following individuals for their
contributions, comments and suggestions to this document: Dave Oran, contributions, comments and suggestions to this document: Dave Oran,
Dan Wing, Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin, Dan Wing, Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin,
Roni Even, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan Roni Even, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan
Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox and Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox and
Sean Sheedy. Sean Sheedy.
15. Change Log 14. Change Log
15.1. draft-ietf-avt-rapid-acquisition-for-rtp-04 14.1. draft-ietf-avt-rapid-acquisition-for-rtp-05
The following are the major changes compared to version 02: The following are the major changes compared to version 04:
o Editorial changes throughout the document.
14.2. draft-ietf-avt-rapid-acquisition-for-rtp-04
The following are the major changes compared to version 03:
o Clarifications for the definition of RS. o Clarifications for the definition of RS.
o Response codes have been defined. o Response codes have been defined.
15.2. draft-ietf-avt-rapid-acquisition-for-rtp-03 14.3. draft-ietf-avt-rapid-acquisition-for-rtp-03
The following are the major changes compared to version 02: The following are the major changes compared to version 02:
o Clarifications for the RAMS-I message. o Clarifications for the RAMS-I message.
o Type values have been assigned. o Type values have been assigned.
15.3. draft-ietf-avt-rapid-acquisition-for-rtp-02 14.4. draft-ietf-avt-rapid-acquisition-for-rtp-02
The following are the major changes compared to version 01: The following are the major changes compared to version 01:
o Port mapping discussion has been removed since it will be o Port mapping discussion has been removed since it will be
discussed in a separate draft. discussed in a separate draft.
o Security considerations section has been added. o Security considerations section has been added.
o Burst shaping section has been completed. o Burst shaping section has been completed.
o Most of the outstanding open issues have been addressed. o Most of the outstanding open issues have been addressed.
15.4. draft-ietf-avt-rapid-acquisition-for-rtp-01 14.5. draft-ietf-avt-rapid-acquisition-for-rtp-01
The following are the major changes compared to version 00: The following are the major changes compared to version 00:
o Formal definitions of vendor-neutral and private extensions and o Formal definitions of vendor-neutral and private extensions and
their IANA registries have been added. their IANA registries have been added.
o SDP examples were explained in more detail. o SDP examples were explained in more detail.
o The sub-FMT field has been introduced in the RAMS messages for o The sub-FMT field has been introduced in the RAMS messages for
message type identification. message type identification.
o Some terminology has been fixed. o Some terminology has been fixed.
o NAT considerations section has been added. o NAT considerations section has been added.
15.5. draft-ietf-avt-rapid-acquisition-for-rtp-00 14.6. draft-ietf-avt-rapid-acquisition-for-rtp-00
This is a resubmission of version 03 as a WG item. This is a resubmission of version 03 as a WG item.
15.6. draft-versteeg-avt-rapid-synchronization-for-rtp-03 14.7. draft-versteeg-avt-rapid-synchronization-for-rtp-03
The following are the major changes compared to version 02: The following are the major changes compared to version 02:
o The title and message names have been changed. o The title and message names have been changed.
o RTCP message semantics have been added. RAMS protocol has been o RTCP message semantics have been added. RAMS protocol has been
revised to handle updated requests and responses. revised to handle updated requests and responses.
o Definitions have been revised. o Definitions have been revised.
o RTP/RTCP muxing reference has been added. o RTP/RTCP muxing reference has been added.
15.7. draft-versteeg-avt-rapid-synchronization-for-rtp-02 14.8. draft-versteeg-avt-rapid-synchronization-for-rtp-02
The following are the major changes compared to version 01: The following are the major changes compared to version 01:
o The discussion around MPEG2-TS has been moved to another document. o The discussion around MPEG2-TS has been moved to another document.
o The RAMS-R, RAMS-I and RAMS-T messages have been extensively o The RAMS-R, RAMS-I and RAMS-T messages have been extensively
modified and they have been made mandatory. modified and they have been made mandatory.
o IANA Considerations section has been updated. o IANA Considerations section has been updated.
o The discussion of RTCP XR report has been moved to another o The discussion of RTCP XR report has been moved to another
document. document.
o A new section on protocol design considerations has been added. o A new section on protocol design considerations has been added.
15.8. draft-versteeg-avt-rapid-synchronization-for-rtp-01 14.9. draft-versteeg-avt-rapid-synchronization-for-rtp-01
The following are the major changes compared to version 00: The following are the major changes compared to version 00:
o The core of the rapid synchronization method is now payload- o The core of the rapid synchronization method is now payload-
independent. But, the draft still defines payload-specific independent. But, the draft still defines payload-specific
messages that are required for enabling rapid synch for the RTP messages that are required for enabling rapid synch for the RTP
flows carrying MPEG2-TS. flows carrying MPEG2-TS.
o RTCP APP packets have been removed, new RTCP transport-layer and o RTCP APP packets have been removed, new RTCP transport-layer and
payload-specific feedback messages have been defined. payload-specific feedback messages have been defined.
o The step for leaving the current multicast session has been o The step for leaving the current multicast session has been
removed from Section 6.2. removed from Section 6.2.
o A new RTCP XR (Multicast Join) report has been defined. o A new RTCP XR (Multicast Join) report has been defined.
o IANA Considerations section have been updated. o IANA Considerations section have been updated.
o Editorial changes to clarify several points. o Editorial changes to clarify several points.
16. References 15. References
16.1. Normative References 15.1. Normative 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
skipping to change at page 45, line 12 skipping to change at page 45, line 7
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006. Specific Multicast", RFC 4604, August 2006.
[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.
[I-D.ietf-mmusic-rfc3388bis] [I-D.ietf-mmusic-rfc3388bis]
Camarillo, G., "The SDP (Session Description Protocol) Camarillo, G. and H. Schulzrinne, "The SDP (Session
Grouping Framework", draft-ietf-mmusic-rfc3388bis-03 (work Description Protocol) Grouping Framework",
in progress), July 2009. draft-ietf-mmusic-rfc3388bis-04 (work in progress),
November 2009.
[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.
[I-D.ietf-avt-rtcpssm] [I-D.ietf-avt-rtcpssm]
Schooler, E., Ott, J., and J. Chesterfield, "RTCP Ott, J. and J. Chesterfield, "RTCP Extensions for Single-
Extensions for Single-Source Multicast Sessions with Source Multicast Sessions with Unicast Feedback",
Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in draft-ietf-avt-rtcpssm-19 (work in progress),
progress), March 2009. November 2009.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, June 2009.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009. and Consequences", RFC 5506, April 2009.
[I-D.begen-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions",
draft-begen-avt-ports-for-ucast-mcast-rtp-00 (work in
progress), September 2009.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
16.2. Informative References 15.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[I-D.ietf-rmt-pi-norm-revised] [I-D.ietf-rmt-pi-norm-revised]
Adamson, B., Bormann, C., Handley, M., and J. Macker, Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast Transport Protocol", "NACK-Oriented Reliable Multicast Transport Protocol",
draft-ietf-rmt-pi-norm-revised-14 (work in progress), draft-ietf-rmt-pi-norm-revised-14 (work in progress),
September 2009. September 2009.
[I-D.begen-avt-rams-scenarios] [I-D.begen-avt-rams-scenarios]
Begen, A., "Considerations for RAMS Scenarios", Begen, A., "Considerations for RAMS Scenarios",
draft-begen-avt-rams-scenarios-00 (work in progress), draft-begen-avt-rams-scenarios-00 (work in progress),
October 2009. October 2009.
[I-D.begen-avt-rtp-mpeg2ts-preamble] [I-D.begen-avt-rtp-mpeg2ts-preamble]
Begen, A. and E. Friedrich, "RTP Payload Format for Begen, A. and E. Friedrich, "RTP Payload Format for
MPEG2-TS Preamble", MPEG2-TS Preamble",
draft-begen-avt-rtp-mpeg2ts-preamble-02 (work in draft-begen-avt-rtp-mpeg2ts-preamble-03 (work in
progress), August 2009. progress), October 2009.
[I-D.begen-avt-rapid-sync-rtcp-xr] [I-D.begen-avt-rapid-sync-rtcp-xr]
Begen, A. and E. Friedrich, "Multicast Acquisition Report Begen, A. and E. Friedrich, "Multicast Acquisition Report
Block Type for RTCP XR", Block Type for RTCP XR",
draft-begen-avt-rapid-sync-rtcp-xr-02 (work in progress), draft-begen-avt-rapid-sync-rtcp-xr-03 (work in progress),
August 2009. October 2009.
[I-D.ietf-avt-rapid-rtp-sync] [I-D.ietf-avt-rapid-rtp-sync]
Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", draft-ietf-avt-rapid-rtp-sync-05 (work in Flows", draft-ietf-avt-rapid-rtp-sync-07 (work in
progress), July 2009. progress), November 2009.
[I-D.westerlund-avt-ecn-for-rtp] [I-D.westerlund-avt-ecn-for-rtp]
Westerlund, M., Johansson, I., Perkins, C., and K. Westerlund, M., Johansson, I., Perkins, C., and K.
Carlberg, "Explicit Congestion Notification (ECN) for RTP Carlberg, "Explicit Congestion Notification (ECN) for RTP
over UDP", draft-westerlund-avt-ecn-for-rtp-01 (work in over UDP", draft-westerlund-avt-ecn-for-rtp-02 (work in
progress), October 2009. progress), October 2009.
[I-D.ietf-avt-rtp-and-rtcp-mux] [I-D.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007. August 2007.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[I-D.begen-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions",
draft-begen-avt-ports-for-ucast-mcast-rtp-01 (work in
progress), October 2009.
[UPnP-IGD] [UPnP-IGD]
Forum, UPnP., "Universal Plug and Play (UPnP) Internet Forum, UPnP., "Universal Plug and Play (UPnP) Internet
Gateway Device (IGD)", November 2001. Gateway Device (IGD)", November 2001.
[DLNA] , DLNA., "http://www.dlna.org/home". [DLNA] , DLNA., "http://www.dlna.org/home".
[CCNC09] Begen, A., Glazebrook, N., and W. VerSteeg, "A Unified [CCNC09] Begen, A., Glazebrook, N., and W. VerSteeg, "A Unified
Approach for Repairing Packet Loss and Accelerating Approach for Repairing Packet Loss and Accelerating
Channel Changes in Multicast IPTV (IEEE CCNC)", Channel Changes in Multicast IPTV (IEEE CCNC)",
January 2009. January 2009.
[IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing [IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing
Channel Change Times in IPTV with Real-Time Transport Channel Change Times in IPTV with Real-Time Transport
Protocol (IEEE Internet Computing)", May 2009. Protocol (IEEE Internet Computing)", May 2009.
Authors' Addresses Authors' Addresses
Bill VerSteeg Bill VerSteeg
Cisco Systems Cisco
5030 Sugarloaf Parkway 5030 Sugarloaf Parkway
Lawrenceville, GA 30044 Lawrenceville, GA 30044
USA USA
Email: billvs@cisco.com Email: billvs@cisco.com
Ali Begen Ali Begen
Cisco Systems Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: abegen@cisco.com Email: abegen@cisco.com
Tom VanCaenegem Tom VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Copernicuslaan 50 Copernicuslaan 50
Antwerpen, 2018 Antwerpen, 2018
Belgium Belgium
Email: Tom.Van_Caenegem@alcatel-lucent.be Email: Tom.Van_Caenegem@alcatel-lucent.be
Zeev Vax Zeev Vax
Microsoft Corporation Microsoft Corporation
1065 La Avenida 1065 La Avenida
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: zeevvax@microsoft.com Email: zeevvax@microsoft.com
 End of changes. 141 change blocks. 
428 lines changed or deleted 420 lines changed or added

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