draft-ietf-avt-rapid-acquisition-for-rtp-07.txt   draft-ietf-avt-rapid-acquisition-for-rtp-08.txt 
AVT B. VerSteeg AVT B. VerSteeg
Internet-Draft A. Begen Internet-Draft A. Begen
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: August 22, 2010 T. VanCaenegem Expires: September 9, 2010 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
February 18, 2010 March 8, 2010
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-07 draft-ietf-avt-rapid-acquisition-for-rtp-08
Abstract Abstract
When an RTP receiver joins a multicast session, it may need to When an RTP receiver joins a multicast session, it may need to
acquire and parse certain Reference Information before it can process acquire and parse certain Reference Information before it can process
any data sent in the multicast session. Depending on the join time, any data sent in the multicast session. Depending on the join time,
length of the Reference Information repetition (or appearance) length of the Reference Information repetition (or appearance)
interval, size of the Reference Information as well as the interval, size of the Reference Information as well as the
application and transport properties, the time lag before an RTP application and transport properties, the time lag before an RTP
receiver can usefully consume the multicast data, which we refer to receiver can usefully consume the multicast data, which we refer to
as the Acquisition Delay, varies and may be large. This is an as the Acquisition Delay, varies and may be large. This is an
undesirable phenomenon for receivers that frequently switch among undesirable phenomenon for receivers that frequently switch among
different multicast sessions, such as video broadcasts. different multicast sessions, such as video broadcasts.
In this document, we describe a method using the existing RTP and In this document, we describe a method using the existing RTP and
RTCP protocol machinery that reduces the acquisition delay. In this RTCP protocol machinery that reduces the acquisition delay. In this
method, an auxiliary unicast RTP session carrying the Reference method, an auxiliary unicast RTP session carrying the Reference
Information to the receiver precedes/accompanies the multicast Information to the receiver precedes/accompanies the multicast
stream. This unicast RTP flow may be transmitted at a faster than stream. This unicast RTP flow may be transmitted at a faster than
natural birate to further accelerate the acquisition. The motivating natural bitrate to further accelerate the acquisition. The
use case for this capability is multicast applications that carry motivating use case for this capability is multicast applications
real-time compressed audio and video. However, the proposed method that carry real-time compressed audio and video. However, the
can also be used in other types of multicast applications where the proposed method can also be used in other types of multicast
acquisition delay is long enough to be a problem. 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. provisions of BCP 78 and BCP 79.
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.
skipping to change at page 2, line 14 skipping to change at page 2, line 16
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 August 22, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 31 skipping to change at page 3, line 31
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 27 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 27
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . 28 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . 28
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 29 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 29
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 29 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 29
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . 30 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . 30
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . 32 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . 32
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . 35 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . 35
8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 36 8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 36
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 36 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 36
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 37 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 37
8.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 37 8.3. Example and Discussion . . . . . . . . . . . . . . . . . 37
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 40 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 40
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
11.1. Registration of SDP Attributes . . . . . . . . . . . . . 43 11.1. Registration of SDP Attributes . . . . . . . . . . . . . 43
11.2. Registration of SDP Attribute Values . . . . . . . . . . 44 11.2. Registration of SDP Attribute Values . . . . . . . . . . 43
11.3. Registration of FMT Values . . . . . . . . . . . . . . . 44 11.3. Registration of FMT Values . . . . . . . . . . . . . . . 43
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . 44 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . 44
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 45 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 44
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 46 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 45
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 48 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 48
14.1. draft-ietf-avt-rapid-acquisition-for-rtp-07 . . . . . . . 48 14.1. draft-ietf-avt-rapid-acquisition-for-rtp-08 . . . . . . . 48
14.2. draft-ietf-avt-rapid-acquisition-for-rtp-06 . . . . . . . 48 14.2. draft-ietf-avt-rapid-acquisition-for-rtp-07 . . . . . . . 48
14.3. draft-ietf-avt-rapid-acquisition-for-rtp-05 . . . . . . . 49 14.3. draft-ietf-avt-rapid-acquisition-for-rtp-06 . . . . . . . 48
14.4. draft-ietf-avt-rapid-acquisition-for-rtp-04 . . . . . . . 49 14.4. draft-ietf-avt-rapid-acquisition-for-rtp-05 . . . . . . . 48
14.5. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 49 14.5. draft-ietf-avt-rapid-acquisition-for-rtp-04 . . . . . . . 49
14.6. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 49 14.6. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 49
14.7. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 49 14.7. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 49
14.8. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 50 14.8. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 49
14.9. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 50 14.9. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 50
14.10. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 50 14.10. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 50
14.11. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 50 14.11. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 50
14.12. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 50
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
15.1. Normative References . . . . . . . . . . . . . . . . . . 51 15.1. Normative References . . . . . . . . . . . . . . . . . . 51
15.2. Informative References . . . . . . . . . . . . . . . . . 52 15.2. Informative References . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
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 (although its content may change over time) and usually session (although its content may change over time) and usually
consists of items such as a description of the schema for the rest of consists of items such as a description of the schema for the rest of
skipping to change at page 6, line 11 skipping to change at page 6, line 11
receivers that frequently switch among multicast sessions. In this receivers that frequently switch among multicast sessions. In this
specification, we address this problem for RTP-based multicast specification, we address this problem for RTP-based multicast
applications and describe a method that uses the fundamental tools applications and describe a method that uses the fundamental tools
offered by the existing RTP and RTCP protocols [RFC3550]. In this offered by the existing RTP and RTCP protocols [RFC3550]. In this
method, either the multicast source (or the distribution source in a method, either the multicast source (or the distribution source in a
source-specific multicast (SSM) session) retains the Reference source-specific multicast (SSM) session) retains the Reference
Information for a period after its transmission, or an intermediary Information for a period after its transmission, or an intermediary
network element (that we refer to as Retransmission Server) joins the network element (that we refer to as Retransmission Server) joins the
multicast session and continuously caches the Reference Information multicast session and continuously caches the Reference Information
as it is sent in the session and acts as a feedback target (See as it is sent in the session and acts as a feedback target (See
[I-D.ietf-avt-rtcpssm]) for the session. When an RTP receiver wishes [RFC5760]) for the session. When an RTP receiver wishes to join the
to join the same multicast session, instead of simply issuing a same multicast session, instead of simply issuing a Source Filtering
Source Filtering Group Management Protocol (SFGMP) Join message, it Group Management Protocol (SFGMP) Join message, it sends a request to
sends a request to the feedback target for the session and asks for the feedback target for the session and asks for the Reference
the Reference Information. The Retransmission Server starts a new Information. The retransmission server starts a new unicast RTP
unicast RTP (retransmission) session and sends the Reference (retransmission) session and sends the Reference Information to the
Information to the RTP receiver over that session. If there is spare RTP receiver over that session. If there is spare bandwidth, the
bandwidth, the Retransmission Server may burst the Reference retransmission server may burst the Reference Information faster than
Information faster than its natural rate. As soon as the receiver its natural rate. As soon as the receiver acquires the Reference
acquires the Reference Information, it can join the multicast session Information, it can join the multicast session and start processing
and start processing the multicast data. A simplified network the multicast data. A simplified network diagram showing this method
diagram showing this method through an intermediary network element through an intermediary network element is depicted in Figure 1.
is depicted in Figure 1.
This method potentially reduces the acquisition delay. We refer to This method potentially reduces the acquisition delay. We refer to
this method as Unicast-based Rapid Acquisition of Multicast RTP this method as Unicast-based Rapid Acquisition of Multicast RTP
Sessions. A primary use case for this method is to reduce the Sessions. A primary use case for this method is to reduce the
channel-change times in IPTV networks where compressed video streams channel-change times in IPTV networks where compressed video streams
are multicast in different SSM sessions and viewers randomly join are multicast in different SSM sessions and viewers randomly join
these sessions. these sessions.
----------------------- -----------------------
+--->| Intermediary | +--->| Intermediary |
skipping to change at page 8, line 12 skipping to change at page 8, line 12
Developing a protocol that can jointly handle the rapid acquisition Developing a protocol that can jointly handle the rapid acquisition
of all of the RTP sessions in an SSM session is neither practical nor of all of the RTP sessions in an SSM session is neither practical nor
necessary. Rather, in this specification we focus on developing a necessary. Rather, in this specification we focus on developing a
protocol that handles the rapid acquisition of a single RTP session protocol that handles the rapid acquisition of a single RTP session
(called primary multicast RTP session) carrying one or more RTP (called primary multicast RTP session) carrying one or more RTP
streams (called primary multicast streams). If desired, multiple streams (called primary multicast streams). If desired, multiple
instances of this protocol may be run in parallel to acquire multiple instances of this protocol may be run in parallel to acquire multiple
RTP sessions simultaneously. RTP sessions simultaneously.
When an RTP receiver requests the Reference Information from the When an RTP receiver requests the Reference Information from the
Retransmission Server, it may opt to rapidly acquire a specific retransmission server, it may opt to rapidly acquire a specific
subset of the available RTP streams in the primary multicast RTP subset of the available RTP streams in the primary multicast RTP
session. Alternatively, it may request the rapid acquisition of all session. Alternatively, it may request the rapid acquisition of all
of the RTP streams in that RTP session. Regardless of how many RTP of the RTP streams in that RTP session. Regardless of how many RTP
streams are requested by the RTP receiver or how many will be streams are requested by the RTP receiver or how many will be
actually sent by the Retransmission Server, only one unicast RTP actually sent by the retransmission server, only one unicast RTP
(retransmission) session will be established by the Retransmission (retransmission) session will be established by the retransmission
Server serving as the feedback target for that RTP session. The RTP server serving as the feedback target for that RTP session. The RTP
receiver multiplexes this unicast RTP session with the primary receiver multiplexes this unicast RTP session with the primary
multicast RTP session it receives as part of the SSM session. If the multicast RTP session it receives as part of the SSM session. If the
RTP receiver wants to rapidly acquire multiple RTP sessions RTP receiver wants to rapidly acquire multiple RTP sessions
simultaneously, separate unicast RTP (retransmission) sessions will simultaneously, separate unicast RTP (retransmission) sessions will
be established for each of them. be established for each of them.
1.2. Outline 1.2. Outline
In the rest of this specification, we have the following outline: In In the rest of this specification, we have the following outline: In
Section 4, we describe the delay components in generic multicast Section 4, we describe the delay components in generic multicast
skipping to change at page 9, line 27 skipping to change at page 9, line 27
definition in [RFC4604], SFGMP refers to the Internet Group definition in [RFC4604], SFGMP refers to the Internet Group
Management Protocol (IGMP) version 3 [RFC3376] and the Multicast Management Protocol (IGMP) version 3 [RFC3376] and the Multicast
Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and
IPv6 networks, respectively. However, the rapid acquisition method IPv6 networks, respectively. However, the rapid acquisition method
introduced in this document does not depend on a specific version of introduced in this document does not depend on a specific version of
either of these group management protocols. In the remainder of this either of these group management protocols. In the remainder of this
document, SFGMP will refer to any group management protocol that has document, SFGMP will refer to any group management protocol that has
Join and Leave functionalities. Join and Leave functionalities.
Feedback Target (FT): Unicast RTCP feedback target as defined in Feedback Target (FT): Unicast RTCP feedback target as defined in
[I-D.ietf-avt-rtcpssm]. FT_Ap denotes a specific feedback target [RFC5760]. FT_Ap denotes a specific feedback target running on a
running on a particular address and port. particular address and port.
Retransmission (Burst) Packet: An RTP packet that is formatted as Retransmission (Burst) Packet: An RTP packet that is formatted as
defined in [RFC4588]. defined in [RFC4588].
Reference Information: The set of certain media content and metadata Reference Information: The set of certain media content and metadata
information that is sufficient for an RTP receiver to start usefully information that is sufficient for an RTP receiver to start usefully
consuming a media stream. The meaning, format and size of this consuming a media stream. The meaning, format and size of this
information are specific to the application and are out of scope of information are specific to the application and are out of scope of
this document. this document.
skipping to change at page 13, line 41 skipping to change at page 13, line 41
The protocol described in the next section allows either method of The protocol described in the next section allows either method of
controlling the rapid acquisition unicast burst. controlling the rapid acquisition unicast burst.
6. Rapid Acquisition of Multicast RTP Sessions 6. Rapid Acquisition of Multicast RTP Sessions
We start this section with an overview of the rapid acquisition of We start this section with an overview of the rapid acquisition of
multicast sessions (RAMS) method. multicast sessions (RAMS) method.
6.1. Overview 6.1. Overview
[I-D.ietf-avt-rtcpssm] specifies an extension to the RTP Control [RFC5760] specifies an extension to the RTP Control Protocol (RTCP)
Protocol (RTCP) to use unicast feedback in an SSM session. It to use unicast feedback in an SSM session. It defines an
defines an architecture that introduces the concept of Distribution architecture that introduces the concept of Distribution Source,
Source, which - in an SSM context - distributes the RTP data and which - in an SSM context - distributes the RTP data and
redistributes RTCP information to all RTP receivers. This RTCP redistributes RTCP information to all RTP receivers. This RTCP
information is retrieved from the Feedback Target, to which RTCP information is retrieved from the Feedback Target, to which RTCP
unicast feedback traffic is sent. The feedback target MAY be unicast feedback traffic is sent. The feedback target MAY be
implemented in one or more entities different from the Distribution implemented in one or more entities different from the Distribution
Source, and different RTP receivers MAY use different feedback Source, and different RTP receivers MAY use different feedback
targets. targets.
This document builds further on these concepts to reduce the This document builds further on these concepts to reduce the
acquisition delay when an RTP receiver joins a multicast session at a acquisition delay when an RTP receiver joins a multicast session at a
random point in time by introducing the concept of the Burst Source random point in time by introducing the concept of the Burst Source
skipping to change at page 15, line 33 skipping to change at page 15, line 33
---------------- -------------- ---------------- --------------
-------> Multicast RTP Flow -------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow .-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports .=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages ~~~~~~~> Unicast RTCP Feedback Messages
.......> Unicast RTP Flow .......> Unicast 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 [RFC5760], to
[I-D.ietf-avt-rtcpssm], to which RTP_Rx sends its RTCP feedback which RTP_Rx sends its RTCP feedback messages indicating packet loss
messages indicating packet loss by means of an RTCP NACK message or by means of an RTCP NACK message or indicating RTP_Rx's desire to
indicating RTP_Rx's desire to rapidly acquire the primary multicast rapidly acquire the primary multicast RTP session by means of an RTCP
RTP session by means of an RTCP feedback message defined in this feedback message defined in this document. While the Burst/
document. While the Burst/Retransmission Source is responsible for Retransmission Source is responsible for responding to these messages
responding to these messages and for further RTCP interaction with and for further RTCP interaction with RTP_Rx in the case of a rapid
RTP_Rx in the case of a rapid acquisition process, it is assumed in acquisition process, it is assumed in the remainder of the document
the remainder of the document that these two logical entities (FT and that these two logical entities (FT and Burst/Retransmission Source)
Burst/Retransmission Source) are combined in a single physical entity are combined in a single physical entity and they share state. In
and they share state. In the remainder of the text, the term the remainder of the text, the term Retransmission Server (RS) will
Retransmission Server (RS) will be used whenever appropriate, to be used whenever appropriate, to refer to the combined functionality
refer to the combined functionality of the FT and Burst/ of the FT and Burst/Retransmission Source.
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 RTP session, whereas the Burst/Retransmission Source multicast RTP session, whereas the Burst/Retransmission Source
transmits the unicast burst and retransmission packets both formatted transmits the unicast burst and retransmission packets both formatted
as RTP retransmission packets [RFC4588] in a single separate unicast as RTP retransmission packets [RFC4588] in a single separate unicast
RTP retransmission session to each RTP_Rx. In the retransmission RTP retransmission session to each RTP_Rx. In the retransmission
session, as in any other RTP session, RS and RTP_Rx regularly send session, as in any other RTP session, RS and RTP_Rx regularly send
the periodic sender and receiver reports, respectively. the periodic sender and receiver reports, respectively.
The unicast burst is triggered by an RTCP feedback message that is The unicast burst is triggered by an RTCP feedback message that is
skipping to change at page 18, line 18 skipping to change at page 18, line 18
join the multicast session and stop the burst. These implementations join the multicast session and stop the burst. These implementations
send messages to each other, but there must be provisions for the send messages to each other, but there must be provisions for the
cases where the control messages get lost, or re-ordered, or are not cases where the control messages get lost, or re-ordered, or are not
being 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. Port Mapping Setup: For the primary multicast RTP session, the 1. Port Mapping Setup: For the primary multicast RTP session, the
RTP and RTCP destination ports are declaratively specified RTP and RTCP destination ports are declaratively specified
(Refer to Section 8 for examples in SDP). However, in the (Refer to Section 8 for examples in SDP). However, in the
unicast RTP retransmission session, RTP_Rx often needs to choose unicast RTP retransmission session, RTP_Rx needs to choose its
its receive ports for RTP and RTCP. Since this unicast session receive ports for RTP and RTCP. Since this unicast session is
is established after RTP_Rx sends its rapid acquisition request established after RTP_Rx sends its rapid acquisition request and
and it is received by RS in the primary multicast RTP session, it is received by RS in the primary multicast RTP session,
RTP_Rx MUST setup the port mappings between the unicast and RTP_Rx MUST setup the port mappings between the unicast and
multicast sessions and send this mapping information to RS multicast sessions and send this mapping information to RS
before it sends its request so that RS knows how to communicate before it sends its request so that RS knows how to communicate
with RTP_Rx. with RTP_Rx.
The details of this setup procedure and other NAT-related issues The details of this setup procedure and other NAT-related issues
are left to Section 9 to keep the present discussion focused on are left to Section 9 to keep the present discussion focused on
the RAMS message flows. the RAMS message flows.
2. Request: RTP_Rx sends a rapid acquisition request for the 2. Request: RTP_Rx sends a rapid acquisition request for the
skipping to change at page 23, line 29 skipping to change at page 23, line 29
to minimize the impact of receiving duplicate packets will be to minimize the impact of receiving duplicate packets will be
addressed in Section 6.4. addressed in Section 6.4.
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 further packets in that RTP session. Thus, in this case there
is no need for sending explicit RAMS-T messages, which would is no need for sending explicit RAMS-T messages, which would
only terminate their respective bursts. only terminate their respective bursts.
For the purpose of gathering detailed information about RTP_Rx's For the purpose of gathering detailed information about RTP_Rx's
rapid acquisition experience, [I-D.begen-avt-rapid-sync-rtcp-xr] rapid acquisition experience, [I-D.ietf-avt-multicast-acq-rtcp-xr]
defines an RTCP Extended Report (XR) Block. This report is designed defines an RTCP Extended Report (XR) Block. This report is designed
to be payload-independent, thus, it can be used by any multicast to be payload-independent, thus, it can be used by any multicast
application that supports rapid acquisition. Support for this XR application that supports rapid acquisition. Support for this XR
report is, however, OPTIONAL. report is, however, OPTIONAL.
6.3. Synchronization of Primary Multicast Streams 6.3. Synchronization of Primary Multicast Streams
When RTP_Rx acquires multiple primary multicast streams, it may need When RTP_Rx acquires multiple primary multicast streams, it may need
to synchronize them for the playout. This synchronization is to synchronize them for the playout. This synchronization is
traditionally achieved by the help of the RTCP sender reports traditionally achieved by the help of the RTCP sender reports
skipping to change at page 25, line 19 skipping to change at page 25, line 19
path from RS to RTP_Rx. path from RS to RTP_Rx.
c. Information obtained via RTCP NACKs provided by RTP_Rx in the c. Information obtained via RTCP NACKs provided by RTP_Rx in the
primary multicast RTP session, allowing in-session bitrate primary multicast RTP session, allowing in-session bitrate
adaptations for the burst. Such RTCP NACKs are transmitted by adaptations for the burst. Such RTCP NACKs are transmitted by
RTP_Rx in response to packet loss detection in the burst. NACKs RTP_Rx in response to packet loss detection in the burst. NACKs
may indicate a certain congestion state on the path from RS to may indicate a certain congestion state on the path from RS to
RTP_Rx. RTP_Rx.
d. There may be other feedback received from RTP_Rx, e.g., in the d. There may be other feedback received from RTP_Rx, e.g., in the
form of ECN-CE markings [I-D.westerlund-avt-ecn-for-rtp] that may form of ECN-CE markings [I-D.ietf-avt-ecn-for-rtp] that may
influence in-session bitrate adaptation. influence in-session bitrate adaptation.
e. Information obtained via updated RAMS-R messages, allowing in- e. Information obtained via updated RAMS-R messages, allowing in-
session bitrate adaptations, if supported by RS. session bitrate adaptations, if supported by RS.
f. Transport protocol-specific information. For example, when DCCP f. Transport protocol-specific information. For example, when DCCP
is used to transport the RTP burst, the ACKs from the DCCP client is used to transport the RTP burst, the ACKs from the DCCP client
can be leveraged by the RS / DCCP server for burst shaping and can be leveraged by the RS / DCCP server for burst shaping and
congestion control. congestion control.
skipping to change at page 27, line 51 skipping to change at page 27, line 51
Section 6.3.5 of [RFC3550] explains the rules pertaining to timing Section 6.3.5 of [RFC3550] explains the rules pertaining to timing
out an SSRC. When RS accepts to serve the requested burst(s) and out an SSRC. When RS accepts to serve the requested burst(s) and
establishes the retransmission session, it should check the liveness establishes the retransmission session, it should check the liveness
of RTP_Rx via the RTCP messages and reports RTP_Rx sends. The of RTP_Rx via the RTCP messages and reports RTP_Rx sends. The
default rules explained in [RFC3550] apply in RAMS as well. default rules explained in [RFC3550] apply in RAMS as well.
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 (RTP_Rx) during rapid acquisition. These messages and RTP receiver (RTP_Rx) during rapid acquisition. These messages
are referred to as the RAMS Messages. They are payload-independent are referred to as the RAMS Messages. They are payload-independent
and 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.
However, further optional payload-independent and payload-specific However, further optional payload-independent and payload-specific
information can be included in the exchange. information can be included 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
skipping to change at page 32, line 45 skipping to change at page 32, line 45
The semantics of the RAMS-R feedback message is independent of the The semantics of the RAMS-R feedback message is independent of the
payload type. payload type.
7.3. RAMS Information 7.3. RAMS Information
The RAMS Information message is identified by SFMT=2. This message The RAMS Information message is identified by SFMT=2. This message
is used to describe the unicast burst that will be sent for rapid is used to describe the unicast burst that will be sent for rapid
acquisition. It also includes other useful information for RTP_Rx as acquisition. It also includes other useful information for RTP_Rx as
described below. described below.
A separate RAMS-I message with the appropriate media sender SSRC and A separate RAMS-I message with the appropriate response code is sent
response code is sent by RS for each primary multicast stream that by RS for each primary multicast stream that has been requested by
has been requested by RTP_Rx. RTP_Rx. In the RAMS-I messages, the media sender SSRC and packet
sender SSRC fields are both set to the SSRC of the respective primary
multicast stream.
The FCI field MUST contain only one RAMS Information. The FCI field The FCI field MUST contain only one RAMS Information. The FCI field
has the structure depicted in Figure 7. 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
A RAMS-I message has the following fields:
o Message Sequence Number (8 bits) : Mandatory field that denotes o Message Sequence Number (8 bits) : Mandatory field that denotes
the sequence number of the RAMS-I message for the particular media the sequence number of the RAMS-I message for the particular media
sender SSRC specified in the message header. The MSN value SHALL sender SSRC specified in the message header. The MSN value SHALL
be set to zero only when a new RAMS request is received. During be set to zero only when a new RAMS request is received. During
rapid acquisition, the same RAMS-I message MAY be repeated for rapid acquisition, the same RAMS-I message MAY be repeated for
redundancy purposes without incrementing the MSN value. If an redundancy purposes without incrementing the MSN value. If an
updated RAMS-I message will be sent (either with a new information updated RAMS-I message will be sent (either with a new information
or an updated information), the MSN value SHALL be incremented by or an updated information), the MSN value SHALL be incremented by
one. In the MSN field, the regular wrapping rules apply. one. In the MSN field, the regular wrapping rules apply.
skipping to change at page 33, line 36 skipping to change at page 33, line 38
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 11.6. If the new response code is intended to be used Section 11.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.
The following TLV elements have been defined for the RAMS-I messages:
o Media Sender SSRC (32 bits): Optional TLV element that specifies o Media Sender SSRC (32 bits): Optional TLV element that specifies
the media sender SSRC of the unicast burst stream. While this the media sender SSRC of the unicast burst stream. While this
information is already available in the message header, it may be information is already available in the message header, it may be
useful to repeat it in an explicit field. For example, if FT_Ap useful to repeat it in an explicit field. For example, if FT_Ap
that received the RAMS-R message is associated with a single that received the RAMS-R message is associated with a single
primary multicast stream but the requested media sender SSRC does primary multicast stream but the requested media sender SSRC does
not match the SSRC of the RTP stream associated with this FT_Ap, not match the SSRC of the RTP stream associated with this FT_Ap,
RS SHOULD include this TLV element in the initial RAMS-I message RS SHOULD include this TLV element in the initial RAMS-I message
to let RTP_Rx know that the media sender SSRC has changed. If the to let RTP_Rx know that the media sender SSRC has changed. If the
two SSRCs match, there is no need to include this TLV element. two SSRCs match, there is no need to include this TLV element.
skipping to change at page 34, line 21 skipping to change at page 34, line 26
specifies the delta time (in ms) between the arrival of the first specifies the delta time (in ms) between the arrival of the first
RTP packet in the RTP stream (which could be a burst packet or a RTP packet in the RTP stream (which could be a burst packet or a
payload-specific packet) and the earliest time instant when RTP_Rx payload-specific packet) and the earliest time instant when RTP_Rx
SHOULD send an SFGMP Join message to join the multicast session. SHOULD send an SFGMP Join message to join the multicast session.
A zero value in this field means that RTP_Rx may send the SFGMP A zero value in this field means that RTP_Rx may send the SFGMP
Join message right away. Join message right away.
If the RAMS request has been accepted, RS MUST send this field at If the RAMS request has been accepted, RS MUST send this field at
least once, so that RTP_Rx knows when to join the multicast least once, so that RTP_Rx knows when to join the multicast
session. If the burst request has been rejected as indicated in session. If the burst request has been rejected as indicated in
the Response field, this field MAY be omitted or set to zero. In the Response field, this field MUST be set to zero. In that case,
that case, it is up to RTP_Rx when or whether to join the it is up to RTP_Rx when or whether to join the multicast session.
multicast session.
It should be noted that when RS serves two or more bursts and It should be noted that when RS serves two or more bursts and
sends a separate RAMS-I message for each burst, the join times sends a separate RAMS-I message for each burst, the join times
specified in these RAMS-I messages should correspond to more or specified in these RAMS-I messages should correspond to more or
less the same time instant, and RTP_Rx sends the SFGMP Join less the same time instant, and RTP_Rx sends the SFGMP Join
message based on the earliest join time. message based on the earliest join time.
Type: 33 Type: 33
o Burst Duration (32 bits): Optional TLV element that denotes the o Burst Duration (32 bits): Optional TLV element that denotes the
skipping to change at page 36, line 46 skipping to change at page 36, line 46
feedback type and optional parameters are all case sensitive): feedback type and optional parameters are all case sensitive):
(In the following ABNF [RFC5234], fmt, SP and CRLF are used as (In the following ABNF [RFC5234], fmt, SP and CRLF are used as
defined in [RFC4566].) defined in [RFC4566].)
rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF
rtcp-fb-pt = "*" ; wildcard: applies to all formats rtcp-fb-pt = "*" ; wildcard: applies to all formats
/ fmt ; as defined in SDP spec / fmt ; as defined in SDP spec
rtcp-fb-val = "nack" SP "ssli" rtcp-fb-val = "nack" SP "rai"
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 'rai' stands for Rapid Acquisition Indication and indicates the
indicates the use of RAMS messages as defined in Section 7. use of RAMS messages as defined in Section 7.
This document also defines a new media-level SDP attribute ('rams- This document also defines a new media-level SDP attribute ('rams-
updates') that indicates whether RS supports updated request messages updates') that indicates whether RS supports updated request messages
or not. This attribute is used in a declarative manner. If RS or not. This attribute is used in a declarative manner. If RS
supports updated request messages and this attribute is included in supports updated request messages and this attribute is included in
the SDP description, RTP_Rx may send updated requests. RS may or may the SDP description, RTP_Rx may send updated requests. RS may or may
not be able to accept value changes in every field in an updated not be able to accept value changes in every field in an updated
RAMS-R message. However, if the 'rams-updates' attribute is not RAMS-R message. However, if the 'rams-updates' attribute is not
included in the SDP description, RTP_Rx SHALL NOT send updated included in the SDP description, RTP_Rx SHALL NOT send updated
requests (RTP_Rx MAY still repeat its initial request without requests (RTP_Rx MAY still repeat its initial request without
changes, though). changes, though).
8.2. Requirements 8.2. Requirements
The use of SDP to describe the RAMS entities normatively requires the The use of SDP to describe the RAMS entities normatively requires the
support for: support for:
o The SDP grouping semantics [I-D.ietf-mmusic-rfc3388bis] o The SDP grouping framework and flow identification (FID) semantics
[I-D.ietf-mmusic-rfc3388bis]
o The RTP/AVPF profile [RFC4585] o The RTP/AVPF profile [RFC4585]
o The RTP retransmissions [RFC4588] o The RTP retransmission payload format [RFC4588]
o The RTCP extensions for SSM sessions with unicast feedback o The RTCP extensions for SSM sessions with unicast feedback
[I-D.ietf-avt-rtcpssm] [RFC5760]
The support for the source-specific media attributes [RFC5576] may be The support for the source-specific media attributes [RFC5576] may be
required in some deployments as described below. required in some deployments as described below.
8.3. Examples 8.3. Example and Discussion
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. enabling rapid acquisition of multicast RTP sessions.
In the example shown Figure 9, we have a primary multicast (source)
stream and a unicast retransmission stream. The source stream is
multicast from a distribution source (with a source IP address of
198.51.100.1) to the multicast destination address of 233.252.0.2 and
port 41000. A Retransmission Server including feedback target
functionality (with 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 the source stream to the feedback target and
request retransmissions. In the RAMS context, the parameter 'rtx-
time' specifies the time in milliseconds that the Retransmission
Server keeps an RTP packet in its cache available for retransmission
(measured from the time the packet was received by the Retransmission
Server).
In this example, both the conventional retransmission and rapid
acquisition support are enabled. This is achieved by the "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 (RTP_Rx) includes the "a=recvonly" line as shown in
Figure 10.
When an RTP receiver asks for rapid acquisition before it joins a
primary multicast RTP session, it sends a RAMS-R message to the
feedback target of that primary multicast RTP session. If FT_Ap is
associated with only one RTP stream, the RTP receiver does not need
to learn the SSRC of that stream via an out-of-band method. If RS
accepts the request, it will send an RAMS-I message with the correct
SSRC identifier. If FT_Ap is associated with a multi-stream RTP
session and the RTP receiver is willing to request rapid acquisition
for the entire session, the RTP receiver again does not need to learn
the SSRCs via an out-of-band method. However, if the RTP receiver is
willing to request a particular subset of the primary multicast
streams, it must learn their SSRC identifiers and list them in the
RAMS-R message. Since this RTP receiver has not yet received any RTP
packets for the primary multicast stream(s), the RTP receiver must in
this case learn the SSRC value(s) from the 'ssrc' attribute of the
media description. In addition to the SSRC value, the 'cname' source
attribute must also be present in the SDP description [RFC5576].
Note that listing the SSRC values for the primary multicast streams
in the SDP file does not create a problem in SSM sessions when an
SSRC collision occurs. This is because in SSM sessions, an RTP
receiver that observed an SSRC collision with a media sender MUST
change its own SSRC [I-D.ietf-avt-rtcpssm] by following the rules
defined in [RFC3550].
A feedback target that receives a RAMS-R feedback message becomes
aware that the prediction chain at the RTP receiver side has been
broken or does not exist anymore. If the necessary conditions are
satisfied (as outlined in Section 7 of [RFC4585]) and available
resources exist, RS may react to the RAMS-R message by sending any
transport-layer and payload-specific feedback message(s) and starting
the unicast burst.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=Rapid Acquisition Example s=Rapid Acquisition Example
t=0 0 t=0 0
a=group:FID 1 2 a=group:FID 1 2
a=rtcp-unicast:rsi a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98 m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream i=Primary Multicast Stream
c=IN IP4 233.252.0.2/255 c=IN IP4 233.252.0.2/255
a=source-filter: incl IN IP4 233.252.0.2 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=recvonly
a=rtpmap:98 MP2T/90000 a=rtpmap:98 MP2T/90000
a=rtcp:41001 IN IP4 192.0.2.1 a=rtcp:41001 IN IP4 192.0.2.1
a=rtcp-fb:98 nack a=rtcp-fb:98 nack
a=rtcp-fb:98 nack ssli a=rtcp-fb:98 nack rai
a=ssrc:123321 cname:iptv-ch32@rams.example.com a=ssrc:123321 cname:iptv-ch32@rams.example.com
a=rams-updates a=rams-updates
a=mid:1 a=mid:1
m=video 41002 RTP/AVPF 99 m=video 41002 RTP/AVPF 99
i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support) i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=sendonly a=sendonly
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:2 a=mid:2
Figure 9: Example SDP for RS when RAMS support is enabled Figure 9: Example SDP for a single-channel RAMS scenario
v=0 In this example SDP description, we have a primary multicast (source)
o=ali 1122334455 1122334466 IN IP4 rams.example.com stream and a unicast retransmission stream. The source stream is
s=Rapid Acquisition Example multicast from a distribution source (with a source IP address of
t=0 0 198.51.100.1) to the multicast destination address of 233.252.0.2 and
a=group:FID 1 2 port 41000. Here, we are assuming that the multicast RTP and RTCP
a=rtcp-unicast:rsi ports are carefully chosen so that different RTP and RTCP streams do
m=video 41000 RTP/AVPF 98 not collide with each other.
i=Primary Multicast Stream
c=IN IP4 233.252.0.2/255
a=source-filter: incl IN IP4 233.252.0.2 198.51.100.1
a=recvonly
a=rtpmap:98 MP2T/90000
a=rtcp:41001 IN IP4 192.0.2.1
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack ssli
a=ssrc:123321 cname:iptv-ch32@rams.example.com
a=rams-updates
a=mid:1
m=video 41002 RTP/AVPF 99
i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1
a=recvonly
a=rtpmap:99 rtx/90000
a=rtcp:41003
a=fmtp:99 apt=98; rtx-time=5000
a=mid:2
Figure 10: Example SDP for RTP_Rx when RAMS support is enabled The feedback target (FT_Ap) residing on the retransmission server
(with an address of 192.0.2.1) at port 41001 is declared with the
"a=rtcp" line [RFC3605]. The RTP receiver(s) can report missing
packets on the source stream to the feedback target and request
retransmissions. In the RAMS context, the parameter 'rtx-time'
specifies the time in milliseconds that the retransmission server
keeps an RTP packet in its cache available for retransmission
(measured from the time the packet was received by the retransmission
server, not from the time indicated in the packet timestamp).
In the example shown in Figure 9, support for both the conventional
retransmission (through the "a=rtcp-fb:98 nack" line) and rapid
acquisition (through the "a=rtcp-fb:98 nack rai" line) is enabled.
Note that this SDP includes the "a=sendonly" line for the media
description of the retransmission stream.
Once an RTP receiver has acquired an SDP description, it may ask for
rapid acquisition before it joins a primary multicast RTP session.
To do so, it sends a RAMS-R message to the feedback target of that
primary multicast RTP session. If FT_Ap is associated with only one
RTP stream, the RTP receiver does not need to learn the SSRC of that
stream via an out-of-band method. If RS accepts the rapid
acquisition request, it will send an RAMS-I message with the correct
SSRC identifier. If FT_Ap is associated with a multi-stream RTP
session and the RTP receiver is willing to request rapid acquisition
for the entire session, the RTP receiver again does not need to learn
the SSRCs via an out-of-band method. However, if the RTP receiver
intends to request a particular subset of the primary multicast
streams, it must learn their SSRC identifiers and list them in the
RAMS-R message. Since this RTP receiver has not yet received any RTP
packets for the primary multicast stream(s), the RTP receiver must in
this case learn the SSRC value(s) from the 'ssrc' attribute of the
media description [RFC5576]. In addition to the SSRC value, the
'cname' source attribute must also be present in the SDP description
[RFC5576].
Note that listing the SSRC values for the primary multicast streams
in the SDP file does not create a problem in SSM sessions when an
SSRC collision occurs. This is because in SSM sessions, an RTP
receiver that observed an SSRC collision with a media sender MUST
change its own SSRC [RFC5760] by following the rules defined in
[RFC3550].
A feedback target that receives a RAMS-R feedback message becomes
aware that the prediction chain at the RTP receiver side has been
broken or does not exist anymore. If the necessary conditions are
satisfied (as outlined in Section 7 of [RFC4585]) and available
resources exist, RS may react to the RAMS-R message by sending any
transport-layer (and optional payload-specific, when allowed)
feedback message(s) and starting the unicast burst.
In this section, we considered the simplest scenario where the In this section, we considered the simplest scenario where the
primary multicast RTP session carried only one stream and the RTP primary multicast RTP session carried only one stream and the RTP
receiver wanted to rapidly acquire this stream only. Best practices receiver wanted to rapidly acquire this stream only. Best practices
for scenarios where the primary multicast RTP session carries two or for scenarios where the primary multicast RTP session carries two or
more streams or the RTP receiver wants to acquire one or more streams more streams or the RTP receiver wants to acquire one or more streams
from multiple primary multicast RTP sessions at the same time are from multiple primary multicast RTP sessions at the same time are
presented in [I-D.begen-avt-rams-scenarios]. presented in [I-D.begen-avt-rams-scenarios].
9. NAT Considerations 9. NAT Considerations
skipping to change at page 41, line 37 skipping to change at page 40, line 45
ports it wants to use on its side for the new session. Since there ports it wants to use on its side for the new session. Since there
are two RTP sessions involved during this process and one of them is are two RTP sessions involved during this process and one of them is
established upon a feedback message sent in the other one, this established upon a feedback message sent in the other one, this
requires an explicit port mapping method. This problem equally requires an explicit port mapping method. This problem equally
applies to scenarios where the RTP media is multicast in an SSM applies to scenarios where the RTP media is multicast in an SSM
session, and an RTP receiver requests retransmission from a local session, and an RTP receiver requests retransmission from a local
repair server by using the RTCP NACK messages for the missing packets repair server by using the RTCP NACK messages for the missing packets
and the repair server retransmits the requested packets over a and the repair server retransmits the requested packets over a
unicast session. Thus, instead of laying out a specific solution for unicast session. Thus, instead of laying out a specific solution for
the RAMS applications, a general solution is introduced in the RAMS applications, a general solution is introduced in
[I-D.begen-avt-ports-for-ucast-mcast-rtp]. [I-D.ietf-avt-ports-for-ucast-mcast-rtp].
Applications using RAMS MUST support this solution both on the RS and Applications using RAMS MUST support this solution both on the RS and
RTP_Rx side to allow RTP receivers to use their desired ports and to RTP_Rx side to allow RTP receivers to use their desired ports and to
support RAMS behind NAT devices. support RAMS behind NAT devices.
10. Security Considerations 10. 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 [RFC5760] and the payload format
payload format defined in [RFC4588]. Thus, these applications are defined in [RFC4588]. Thus, these applications are subject to the
subject to the general security considerations discussed in general security considerations discussed in [RFC5760] and [RFC4588].
[I-D.ietf-avt-rtcpssm] and [RFC4588]. In this section, we give an In this section, we give an overview of the guidelines and
overview of the guidelines and suggestions described in these suggestions described in these specifications from a RAMS
specifications from a RAMS perspective. We also discuss the security perspective. We also discuss the security considerations that
considerations that explicitly apply to applications using RAMS. explicitly apply to applications using RAMS.
First of all, much of the session description information is First of all, much of the session description information is
available in the SDP descriptions that are distributed to the media available in the SDP descriptions that are distributed to the media
senders, Retransmission Servers and RTP receivers. Adequate security senders, retransmission servers and RTP receivers. Adequate security
measures are RECOMMENDED to ensure the integrity and authenticity of measures are RECOMMENDED to ensure the integrity and authenticity of
the SDP descriptions so that transport addresses of the media the SDP descriptions so that transport addresses of the media
senders, distribution sources, feedback targets as well as other senders, distribution sources, feedback targets as well as other
session-specific information can be authenticated. session-specific information can be authenticated.
Compared to an RTCP NACK message that triggers one or more Compared to an RTCP NACK message that triggers one or more
retransmissions, a RAMS Request (RAMS-R) message may trigger a new retransmissions, a RAMS Request (RAMS-R) message may trigger a new
burst stream to be sent by the Retransmission Server. Depending on burst stream to be sent by the retransmission server. Depending on
the application-specific requirements and conditions existing at the the application-specific requirements and conditions existing at the
time of the RAMS-R reception by the Retransmission Server, the time of the RAMS-R reception by the retransmission server, the
resulting burst stream may contain potentially a large number of resulting burst stream may contain potentially a large number of
retransmission packets. Since these packets are sent at a faster retransmission packets. Since these packets are sent at a faster
than the nominal rate, RAMS consumes more resources on the than the nominal rate, RAMS consumes more resources on the
Retransmission Server, the RTP receiver and the network. This retransmission server, the RTP receiver and the network. This may
particularly makes denial-of-service attacks more intense, and hence, particularly make denial-of-service attacks more intense, and hence,
more harmful than attacks that target ordinary retransmission more harmful than attacks that target ordinary retransmission
sessions. sessions.
Following the suggestions given in [RFC4588], counter-measures SHOULD Following the suggestions given in [RFC4588], counter-measures SHOULD
be taken to prevent tampered or spoofed RTCP packets. Tampered be taken to prevent tampered or spoofed RTCP packets. Tampered
RAMS-R messages may trigger inappropriate burst streams or alter the RAMS-R messages may trigger inappropriate burst streams or alter the
existing burst streams in an inappropriate way. For example, if the existing burst streams in an inappropriate way. For example, if the
Max Receive Bitrate field is altered by a tampered RAMS-R message, Max Receive Bitrate field is altered by a tampered RAMS-R message,
the updated burst may overflow the buffer on the receiver side, or the updated burst may overflow the buffer at the receiver side, or
oppositely, may slow down the burst to the point that it becomes oppositely, may slow down the burst to the point that it becomes
useless. Tampered RAMS Termination (RAMS-T) messages may terminate useless. Tampered RAMS Termination (RAMS-T) messages may terminate
valid burst streams pre-maturely resulting in gaps in the received valid burst streams prematurely resulting in gaps in the received RTP
RTP packets. RAMS Information (RAMS-I) messages contain fields that packets. RAMS Information (RAMS-I) messages contain fields that are
are critical for the success of the RAMS operation. Any tampered critical for a successful rapid acquisition. Any tampered
information in the RAMS-I message may easily cause the RTP receiver information in the RAMS-I message may easily cause the RTP receiver
to make wrong decisions. Consequently, the RAMS operation may fail. to make wrong decisions. Consequently, the RAMS operation may fail.
While most of the denial-of-service attacks can be prevented by the While most of the denial-of-service attacks can be prevented by the
integrity and authenticity checks enabled by SRTP, an attack can integrity and authenticity checks enabled by Secure RTP (SRTP)
still be started by legitimate endpoints that send several valid
RAMS-R messages to a particular feedback target in a synchronized [RFC3711], an attack can still be started by legitimate endpoints
fashion and very short amount of time. Since a RAMS operation may that send several valid RAMS-R messages to a particular feedback
temporarily consume a large amount of resources, a series of the target in a synchronized fashion and very short amount of time.
RAMS-R messages may temporarily overload the Retransmission Server. Since a RAMS operation may temporarily consume a large amount of
In these circumstances, the Retransmission Server may, for example, resources, a series of the RAMS-R messages may temporarily overload
reject incoming RAMS requests until its resources become available the retransmission server. In these circumstances, the
again. One means to ameliorate this threat is to apply a per- retransmission server may, for example, reject incoming RAMS requests
endpoint policing mechanism on the incoming RAMS requests. A until its resources become available again. One means to ameliorate
reasonable policing mechanism should consider application-specific this threat is to apply a per-endpoint policing mechanism on the
requirements and minimize false negatives. incoming RAMS requests. A reasonable policing mechanism should
consider application-specific requirements and minimize false
negatives.
In addition to the denial-of-service attacks, man-in-the-middle and In addition to the denial-of-service attacks, man-in-the-middle and
replay attacks can also be harmful. However, RAMS itself does not replay attacks can also be harmful. However, RAMS itself does not
bring any new risks or threats other than the ones discussed in bring any new risks or threats other than the ones discussed in
[I-D.ietf-avt-rtcpssm]. [RFC5760].
[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 plain-text 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].
To protect the RTCP messages from man-in-the-middle and replay
attacks, the RTP receivers and retransmission server SHOULD perform a
DTLS-SRTP handshake [I-D.ietf-avt-dtls-srtp] over the RTCP channel.
Because there is no integrity-protected signaling channel between an
RTP receiver and the retransmission server, the retransmission server
MUST maintain a list of certificates owned by legitimate RTP
receivers, or their certificates MUST be signed by a trusted
Certificate Authority. Once the DTLS-SRTP security is established,
non-SRTCP-protected messages received from a particular RTP receiver
are ignored by the retransmission server. To reduce the impact of
DTLS-SRTP overhead when communicating with different feedback targets
on the same retransmission server, it is RECOMMENDED that RTP
receivers and the retransmission server both support TLS Session
Resumption without Server-side State [RFC5077].
11. IANA Considerations 11. 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
skipping to change at page 44, line 19 skipping to change at page 43, line 32
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
11.2. Registration of SDP Attribute Values 11.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]. the 'rtcp-fb' attribute, refer to Sections 4.2 and 6.2 of [RFC4585].
Value name: ssli Value name: rai
Long name: Stream Synchronization Loss Indication Long name: Rapid Acquisition Indication
Usable with: nack Usable with: nack
Reference: [RFCXXXX] Reference: [RFCXXXX]
11.3. Registration of FMT Values 11.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
skipping to change at page 45, line 11 skipping to change at page 44, line 28
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:
Value Name Reference Value Name Reference
----- -------------------------------------------------- ------------- ----- -------------------------------------------------- -------------
0 Reserved [RFCXXXX] 0 Reserved [RFCXXXX]
1 RAMS Request [RFCXXXX] 1 RAMS Request [RFCXXXX]
2 RAMS Information [RFCXXXX] 2 RAMS Information [RFCXXXX]
3 RAMS Termination [RFCXXXX] 3 RAMS Termination [RFCXXXX]
4-254 Specification Required 4-254 Assignable - Specification Required
255 Reserved [RFCXXXX] 255 Reserved [RFCXXXX]
The SFMT values 0 and 255 are reserved for future use. The SFMT values 0 and 255 are reserved for future use.
Any registration for an unassigned SFMT value MUST contain the Any registration for an unassigned SFMT 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.
skipping to change at page 46, line 13 skipping to change at page 45, line 21
The registry is initialized with the following entries: The registry is initialized with the following entries:
Type Description Reference Type Description Reference
---- -------------------------------------------------- ------------- ---- -------------------------------------------------- -------------
0 Reserved [RFCXXXX] 0 Reserved [RFCXXXX]
1 Requested Media Sender SSRC(s) [RFCXXXX] 1 Requested Media Sender SSRC(s) [RFCXXXX]
2 Min RAMS Buffer Fill Requirement [RFCXXXX] 2 Min RAMS Buffer Fill Requirement [RFCXXXX]
3 Max RAMS Buffer Fill Requirement [RFCXXXX] 3 Max RAMS Buffer Fill Requirement [RFCXXXX]
4 Max Receive Bitrate [RFCXXXX] 4 Max Receive Bitrate [RFCXXXX]
5 Request for Preamble Only [RFCXXXX] 5 Request for Preamble Only [RFCXXXX]
6-30 Specification Required 6-30 Assignable - Specification Required
31 Media Sender SSRC [RFCXXXX] 31 Media Sender SSRC [RFCXXXX]
32 RTP Seqnum of the First Packet [RFCXXXX] 32 RTP Seqnum of the First Packet [RFCXXXX]
33 Earliest Multicast Join Time [RFCXXXX] 33 Earliest Multicast Join Time [RFCXXXX]
34 Burst Duration [RFCXXXX] 34 Burst Duration [RFCXXXX]
35 Max Transmit Bitrate [RFCXXXX] 35 Max Transmit Bitrate [RFCXXXX]
36-60 Specification Required 36-60 Assignable - Specification Required
61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX] 61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX]
62-127 Specification Required 62-127 Assignable - Specification Required
128-254 No IANA Maintenance 128-254 No IANA Maintenance
255 Reserved [RFCXXXX] 255 Reserved [RFCXXXX]
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
skipping to change at page 48, line 25 skipping to change at page 48, line 12
this specification by providing text and solutions to some of the this specification by providing text and solutions to some of the
issues raised during the development of this specification. issues raised during the development of this specification.
13. Acknowledgments 13. Acknowledgments
The following individuals have reviewed the earlier versions of this The following individuals have reviewed the earlier versions of this
specification and provided helpful comments: Colin Perkins, Joerg specification and provided helpful comments: Colin Perkins, Joerg
Ott, Roni Even, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, Ott, Roni Even, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg,
Muriel Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, Muriel Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou,
Ye-Kui Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, Ye-Kui Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong,
Jonathan Lennox and Sean Sheedy. Jonathan Lennox, Jose Rey and Sean Sheedy.
14. Change Log 14. Change Log
14.1. draft-ietf-avt-rapid-acquisition-for-rtp-07 14.1. draft-ietf-avt-rapid-acquisition-for-rtp-08
The following are the major changes compared to version 07:
o Fixes and changes requested by Magnus W. and Jose R. have been
addressed throuhout the document.
o Some references have been updated.
14.2. draft-ietf-avt-rapid-acquisition-for-rtp-07
The following are the major changes compared to version 06: The following are the major changes compared to version 06:
o Congestion control considerations text has been added to Section o Congestion control considerations text has been added to Section
6.4. 6.4.
14.2. draft-ietf-avt-rapid-acquisition-for-rtp-06 14.3. draft-ietf-avt-rapid-acquisition-for-rtp-06
The following are the major changes compared to version 05: The following are the major changes compared to version 05:
o Comments from WGLC have been addressed. See the mailing list for o Comments from WGLC have been addressed. See the mailing list for
the list of changes. the list of changes.
o Support for multi-stream RTP sessions has been added. o Support for multi-stream RTP sessions has been added.
o NAT section has been revised. o NAT section has been revised.
14.3. draft-ietf-avt-rapid-acquisition-for-rtp-05 14.4. draft-ietf-avt-rapid-acquisition-for-rtp-05
The following are the major changes compared to version 04: The following are the major changes compared to version 04:
o Editorial changes throughout the document. o Editorial changes throughout the document.
14.4. draft-ietf-avt-rapid-acquisition-for-rtp-04 14.5. draft-ietf-avt-rapid-acquisition-for-rtp-04
The following are the major changes compared to version 03: 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.
14.5. draft-ietf-avt-rapid-acquisition-for-rtp-03 14.6. 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.
14.6. draft-ietf-avt-rapid-acquisition-for-rtp-02 14.7. 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.
14.7. draft-ietf-avt-rapid-acquisition-for-rtp-01 14.8. 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.
14.8. draft-ietf-avt-rapid-acquisition-for-rtp-00 14.9. 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.
14.9. draft-versteeg-avt-rapid-synchronization-for-rtp-03 14.10. 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.
14.10. draft-versteeg-avt-rapid-synchronization-for-rtp-02 14.11. 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.
14.11. draft-versteeg-avt-rapid-synchronization-for-rtp-01 14.12. 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.
skipping to change at page 52, line 4 skipping to change at page 51, line 49
Description Protocol) Grouping Framework", Description Protocol) Grouping Framework",
draft-ietf-mmusic-rfc3388bis-04 (work in progress), draft-ietf-mmusic-rfc3388bis-04 (work in progress),
November 2009. 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] [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Ott, J. and J. Chesterfield, "RTCP Extensions for Single- Protocol (RTCP) Extensions for Single-Source Multicast
Source Multicast Sessions with Unicast Feedback", Sessions with Unicast Feedback", RFC 5760, February 2010.
draft-ietf-avt-rtcpssm-19 (work in progress),
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.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605,
October 2003.
[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.
[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.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
[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-09 (work in Flows", draft-ietf-avt-rapid-rtp-sync-09 (work in
progress), January 2010. progress), January 2010.
[I-D.begen-avt-ports-for-ucast-mcast-rtp] [I-D.ietf-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions", Multicast RTP Sessions",
draft-begen-avt-ports-for-ucast-mcast-rtp-02 (work in draft-ietf-avt-ports-for-ucast-mcast-rtp-00 (work in
progress), February 2010. progress), February 2010.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[I-D.ietf-avt-dtls-srtp]
McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)",
draft-ietf-avt-dtls-srtp-07 (work in progress),
February 2009.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008.
[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.
15.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.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-04 (work in draft-begen-avt-rtp-mpeg2ts-preamble-04 (work in
progress), December 2009. progress), December 2009.
[I-D.begen-avt-rapid-sync-rtcp-xr] [I-D.ietf-avt-multicast-acq-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 RTP Control Protocol (RTCP) Extended
draft-begen-avt-rapid-sync-rtcp-xr-03 (work in progress), Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-00
October 2009. (work in progress), February 2010.
[I-D.westerlund-avt-ecn-for-rtp] [I-D.ietf-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-02 (work in over UDP", draft-ietf-avt-ecn-for-rtp-00 (work in
progress), October 2009. progress), February 2010.
[I-D.ietf-fecframe-interleaved-fec-scheme] [I-D.ietf-fecframe-interleaved-fec-scheme]
Begen, A., "RTP Payload Format for 1-D Interleaved Parity Begen, A., "RTP Payload Format for 1-D Interleaved Parity
FEC", draft-ietf-fecframe-interleaved-fec-scheme-09 (work FEC", draft-ietf-fecframe-interleaved-fec-scheme-09 (work
in progress), January 2010. in progress), January 2010.
[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.
 End of changes. 77 change blocks. 
238 lines changed or deleted 260 lines changed or added

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