draft-ietf-avt-rapid-acquisition-for-rtp-08.txt   draft-ietf-avt-rapid-acquisition-for-rtp-09.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: September 9, 2010 T. VanCaenegem Expires: October 28, 2010 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
March 8, 2010 April 26, 2010
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-08 draft-ietf-avt-rapid-acquisition-for-rtp-09
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
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 bitrate to further accelerate the acquisition. The natural bitrate to further accelerate the acquisition. The
motivating use case for this capability is multicast applications motivating use case for this capability is multicast applications
that carry real-time compressed audio and video. However, the that carry real-time compressed audio and video. However, the
proposed method can also be used in other types of multicast proposed method can also be used in other types of multicast
applications where the acquisition delay is long enough to be a applications where the acquisition delay is long enough to be a
problem. 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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 28, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 18 skipping to change at page 3, line 18
1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 7 1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 7
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 8 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 8
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Elements of Delay in Multicast Applications . . . . . . . . . 10 4. Elements of Delay in Multicast Applications . . . . . . . . . 10
5. Protocol Design Considerations and Their Effect on 5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Acquisition . . . . . . . . . . 11 Resource Management for Rapid Acquisition . . . . . . . . . . 11
6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 13 6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 13
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 14
6.3. Synchronization of Primary Multicast Streams . . . . . . 23 6.3. Synchronization of Primary Multicast Streams . . . . . . 24
6.4. Burst Shaping and Congestion Control in RAMS . . . . . . 24 6.4. Burst Shaping and Congestion Control in RAMS . . . . . . 24
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 27 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . 28 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 29 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 29 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . 30 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . 30
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . 32 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . 33
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. Example and Discussion . . . . . . . . . . . . . . . . . 37 8.3. Example and Discussion . . . . . . . . . . . . . . . . . 38
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 40 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 40
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
11.1. Registration of SDP Attributes . . . . . . . . . . . . . 43 11.1. Registration of SDP Attributes . . . . . . . . . . . . . 43
11.2. Registration of SDP Attribute Values . . . . . . . . . . 43 11.2. Registration of SDP Attribute Values . . . . . . . . . . 44
11.3. Registration of FMT Values . . . . . . . . . . . . . . . 43 11.3. Registration of FMT Values . . . . . . . . . . . . . . . 44
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . 44 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . 44
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 44 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 45
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 45 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 46
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 48 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 48
14.1. draft-ietf-avt-rapid-acquisition-for-rtp-08 . . . . . . . 48 14.1. draft-ietf-avt-rapid-acquisition-for-rtp-09 . . . . . . . 48
14.2. draft-ietf-avt-rapid-acquisition-for-rtp-07 . . . . . . . 48 14.2. draft-ietf-avt-rapid-acquisition-for-rtp-08 . . . . . . . 48
14.3. draft-ietf-avt-rapid-acquisition-for-rtp-06 . . . . . . . 48 14.3. draft-ietf-avt-rapid-acquisition-for-rtp-07 . . . . . . . 49
14.4. draft-ietf-avt-rapid-acquisition-for-rtp-05 . . . . . . . 48 14.4. draft-ietf-avt-rapid-acquisition-for-rtp-06 . . . . . . . 49
14.5. draft-ietf-avt-rapid-acquisition-for-rtp-04 . . . . . . . 49 14.5. draft-ietf-avt-rapid-acquisition-for-rtp-05 . . . . . . . 49
14.6. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 49 14.6. draft-ietf-avt-rapid-acquisition-for-rtp-04 . . . . . . . 49
14.7. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 49 14.7. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 49
14.8. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 49 14.8. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 49
14.9. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 50 14.9. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 50
14.10. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 50 14.10. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 50
14.11. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 50 14.11. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 50
14.12. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 50 14.12. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 50
14.13. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 51
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
15.1. Normative References . . . . . . . . . . . . . . . . . . 51 15.1. Normative References . . . . . . . . . . . . . . . . . . 51
15.2. Informative References . . . . . . . . . . . . . . . . . 53 15.2. Informative References . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 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
skipping to change at page 7, line 38 skipping to change at page 7, line 38
A principle design goal in this solution is to use the existing tools A principle design goal in this solution is to use the existing tools
in the RTP/RTCP protocol family. This improves the versatility of in the RTP/RTCP protocol family. This improves the versatility of
the existing implementations, and promotes faster deployment and the existing implementations, and promotes faster deployment and
better interoperability. To this effect, we use the unicast better interoperability. To this effect, we use the unicast
retransmission support of RTP [RFC4588] and the capabilities of RTCP retransmission support of RTP [RFC4588] and the capabilities of RTCP
to handle the signaling needed to accomplish the acquisition. to handle the signaling needed to accomplish the acquisition.
1.1. Acquisition of RTP Streams vs. RTP Sessions 1.1. Acquisition of RTP Streams vs. RTP Sessions
By the definition given in [RFC3550], an RTP session may involve one In this memo we describe a protocol that handles the rapid
or more RTP streams each identified with a unique SSRC. All RTP acquisition of a single multicast RTP session (called primary
streams within a single RTP session are sent towards the same multicast RTP session) carrying one or more RTP streams (called
transport address, i.e., they share the same destination IP address primary multicast streams). If desired, multiple instances of this
and port. In RTP jargon, these streams are said to be SSRC- protocol may be run in parallel to acquire multiple RTP sessions
multiplexed. On the other hand, an SSM session is uniquely simultaneously.
identified by its source address and destination group address.
However, it may carry one or more RTP sessions, each associated with
a different destination port. Consequently, while it is not very
practical, it is still possible for an SSM session to carry multiple
RTP sessions each carrying multiple SSRC-multiplexed RTP streams.
Developing a protocol that can jointly handle the rapid acquisition
of all of the RTP sessions in an SSM session is neither practical nor
necessary. Rather, in this specification we focus on developing a
protocol that handles the rapid acquisition of a single RTP session
(called primary multicast RTP session) carrying one or more RTP
streams (called primary multicast streams). If desired, multiple
instances of this protocol may be run in parallel to acquire multiple
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 session will be established by the retransmission server. This
server serving as the feedback target for that RTP session. The RTP unicast RTP session is separate from the associated primary multicast
receiver multiplexes this unicast RTP session with the primary RTP session. As a result, there are always two different RTP
multicast RTP session it receives as part of the SSM session. If the sessions in a single instance of the rapid acquisition protocol: (i)
RTP receiver wants to rapidly acquire multiple RTP sessions the primary multicast RTP session with its associated unicast
simultaneously, separate unicast RTP (retransmission) sessions will feedback and (ii) the unicast RTP session.
be established for each of them.
If the RTP receiver wants to rapidly acquire multiple RTP sessions
simultaneously, separate unicast RTP sessions will 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
applications. Section 5 presents an overview of the protocol design applications. Section 5 presents an overview of the protocol design
considerations for rapid acquisition. We provide the protocol considerations for rapid acquisition. We provide the protocol
details of the rapid acquisition method in Section 6 and Section 7. details of the rapid acquisition method in Section 6 and Section 7.
Section 8 and Section 9 discuss the SDP signaling issues with Section 8 and Section 9 discuss the SDP signaling issues with
examples and NAT-related issues, respectively. Finally, Section 10 examples and NAT-related issues, respectively. Finally, Section 10
skipping to change at page 9, line 6 skipping to change at page 8, line 40
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Definitions 3. Definitions
This document uses the following acronyms and definitions frequently: This document uses the following acronyms and definitions frequently:
(Primary) SSM (or Multicast) Session: The multicast session to which (Primary) SSM (or Multicast) Session: The multicast session to which
RTP receivers can join at a random point in time. RTP receivers can join at a random point in time. A primary SSM
session may carry multiple RTP streams.
Primary Multicast RTP Session: The multicast RTP session an RTP Primary Multicast RTP Session: The multicast RTP session an RTP
receiver is interested in acquiring rapidly. A primary SSM session receiver is interested in acquiring rapidly. From the RTP receiver's
may carry multiple multicast RTP sessions, but only one of them can viewpoint, the primary multicast RTP session has one associated
be the primary from the viewpoint of rapid acquisition. unicast RTCP feedback stream to a Feedback Target, in addition to the
primary multicast RTP stream(s).
Primary Multicast (RTP) Streams: The RTP stream(s) carried in the Primary Multicast (RTP) Streams: The RTP stream(s) carried in the
primary multicast RTP session. primary multicast RTP session.
Source Filtering Group Management Protocol (SFGMP): Following the Source Filtering Group Management Protocol (SFGMP): Following the
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
[RFC5760]. FT_Ap denotes a specific feedback target running on a [RFC5760]. FT_Ap denotes a specific feedback target running on a
particular address and port. particular address and port.
Retransmission (Burst) Packet: An RTP packet that is formatted as Retransmission (or Burst) Packet: An RTP packet that is formatted as
defined in [RFC4588]. defined in Section 4 of [RFC4588]. The payload of a retransmission
or burst packet comprises the retransmission payload header followed
by the payload of the original RTP packet.
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.
Preamble Information: A more compact form of the whole or a subset Preamble Information: A more compact form of the whole or a subset
of the Reference Information transmitted out-of-band. of the Reference Information transmitted out-of-band.
(Unicast) Burst (or Retransmission) RTP Session: The unicast RTP
session used to send one or more unicast burst RTP streams and their
associated RTCP messages. The terms "burst RTP session" and
"retransmission RTP session" can be used interchangeably.
(Unicast) Burst (Stream): A unicast stream of RTP retransmission (Unicast) Burst (Stream): A unicast stream of RTP retransmission
packets that enable an RTP receiver to rapidly acquire the Reference packets that enable an RTP receiver to rapidly acquire the Reference
Information associated with a primary multicast stream. Each burst Information associated with a primary multicast stream. Each burst
stream is identified by its SSRC identifier that is unique in the stream is identified by its SSRC identifier that is unique in the
primary multicast RTP session. The burst streams are typically primary multicast RTP session. Following the session-multiplexing
transmitted at an accelerated rate. guidelines in [RFC4588], each unicast burst stream must use the same
SSRC and CNAME as its primary multicast RTP stream.
Retransmission Server (RS): The RTP/RTCP endpoint that can generate Retransmission Server (RS): The RTP/RTCP endpoint that can generate
the retransmission packets and the burst streams. RS may also the retransmission packets and the burst streams. RS may also
generate other non-retransmission packets to aid the rapid generate other non-retransmission packets to aid rapid acquisition.
acquisition process.
4. Elements of Delay in Multicast Applications 4. Elements of Delay in Multicast Applications
In an any-source (ASM) or a source-specific (SSM) multicast delivery In a source-specific (SSM) multicast delivery system, there are three
system, there are three major elements that contribute to the overall major elements that contribute to the overall acquisition delay when
acquisition delay when an RTP receiver switches from one multicast an RTP receiver switches from one multicast session to another one.
session to another one. These are: These are:
o Multicast switching delay o Multicast switching delay
o Reference Information latency o Reference Information latency
o Buffering delays o Buffering delays
Multicast switching delay is the delay that is experienced to leave Multicast switching delay is the delay that is experienced to leave
the current multicast session (if any) and join the new multicast the current multicast session (if any) and join the new multicast
session. In typical systems, the multicast join and leave operations session. In typical systems, the multicast join and leave operations
skipping to change at page 10, line 52 skipping to change at page 10, line 52
proximity of the actual time the receiver joined the session to the proximity of the actual time the receiver joined the session to the
next time the Reference Information will be sent to the receivers in next time the Reference Information will be sent to the receivers in
the session, whether the Reference Information is sent contiguously the session, whether the Reference Information is sent contiguously
or not, and the size of the Reference Information. For some or not, and the size of the Reference Information. For some
multicast flows, there is a little or no interdependency in the data, multicast flows, there is a little or no interdependency in the data,
in which case the Reference Information latency will be nil or in which case the Reference Information latency will be nil or
negligible. For other multicast flows, there is a high degree of negligible. For other multicast flows, there is a high degree of
interdependency. One example of interest is the multicast flows that interdependency. One example of interest is the multicast flows that
carry compressed audio/video. For these flows, the Reference carry compressed audio/video. For these flows, the Reference
Information latency may become quite large and be a major contributor Information latency may become quite large and be a major contributor
to the overall delay. Refer to [I-D.begen-avt-rtp-mpeg2ts-preamble] to the overall delay.
for details.
The buffering component of the overall acquisition delay is driven by The buffering component of the overall acquisition delay is driven by
the way the application layer processes the payload. In many the way the application layer processes the payload. In many
multicast applications, an unreliable transport protocol such as UDP multicast applications, an unreliable transport protocol such as UDP
[RFC0768] is often used to transmit the data packets, and the [RFC0768] is often used to transmit the data packets, and the
reliability, if needed, is usually addressed through other means such reliability, if needed, is usually addressed through other means such
as Forward Error Correction (e.g., as Forward Error Correction (e.g.,
[I-D.ietf-fecframe-interleaved-fec-scheme]) and retransmission. [I-D.ietf-fecframe-interleaved-fec-scheme]) and retransmission.
These loss-repair methods require buffering at the receiver side to These loss-repair methods require buffering at the receiver side to
function properly. In many applications, it is also often necessary function properly. In many applications, it is also often necessary
skipping to change at page 14, line 11 skipping to change at page 14, line 11
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
and new RTCP feedback messages. The Burst Source has a cache where and new RTCP feedback messages. The Burst Source has a cache where
the most recent packets from the primary multicast RTP session are the most recent packets from the primary multicast RTP session are
continuously stored. When an RTP receiver wants to receive a primary continuously stored. When an RTP receiver wants to receive a primary
multicast stream prior to joining the SSM session, it may first multicast stream, it may first request a unicast burst from the Burst
request a unicast burst from the Burst Source. In this burst, the Source before it joins the SSM session. In this burst, the packets
packets are formatted as RTP retransmission packets [RFC4588] and are formatted as RTP retransmission packets [RFC4588] and carry the
carry the Reference Information. This information allows the RTP Reference Information. This information allows the RTP receiver to
receiver to start usefully consuming the RTP packets sent in the start usefully consuming the RTP packets sent in the primary
primary multicast RTP session. multicast RTP session.
Using an accelerated bitrate (as compared to the nominal bitrate of Using an accelerated bitrate (as compared to the nominal bitrate of
the primary multicast stream) for the unicast burst implies that at a the primary multicast stream) for the unicast burst implies that at a
certain point in time, the payload transmitted in the unicast burst certain point in time, the payload transmitted in the unicast burst
is going to be the same as the payload in the associated multicast is going to be the same as the payload in the associated multicast
stream, i.e., the unicast burst will catch up with the primary stream, i.e., the unicast burst will catch up with the primary
multicast stream. At this point, the RTP receiver no longer needs to multicast stream. At this point, the RTP receiver no longer needs to
receive the unicast burst and can join the SSM session. This method receive the unicast burst and can join the SSM session. This method
is referred to as the Rapid Acquisition of Multicast Sessions (RAMS). is referred to as the Rapid Acquisition of Multicast Sessions (RAMS).
skipping to change at page 14, line 40 skipping to change at page 14, line 40
6.2. Message Flows 6.2. Message Flows
Figure 2 shows the main entities involved in rapid acquisition and Figure 2 shows the main entities involved in rapid acquisition and
the message flows. They are the message flows. They are
o Multicast Source o Multicast Source
o Feedback Target (FT) o Feedback Target (FT)
o Burst/Retransmission Source o Burst/Retransmission Source (BRS)
o RTP Receiver (RTP_Rx) o RTP Receiver (RTP_Rx)
----------- -------------- ----------- --------------
| |----------------------------------->| | | |------------------------------------>| |
| |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>| | | |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| |
| | | | | | | |
| Multicast | ---------------- | | | Multicast | ---------------- | |
| Source | | Retransmission | | | | Source | | Retransmission | | |
| |------->| Server (RS) |--------->| | | |-------->| Server (RS) | | |
| |.-.-.-.>| |.-.-.-.-.>| | | |.-.-.-.->| | | |
| | | ------------ | | | | | | ------------ | | |
----------- | | Feedback | |<.=.=.=.=.| | ----------- | | Feedback | |<.=.=.=.=.| |
| | Target | |<~~~~~~~~~| RTP Receiver | | | Target | |<~~~~~~~~~| RTP Receiver |
| ------------ | | (RTP_Rx) | PRIMARY MULTICAST | ------------ | | (RTP_Rx) |
| | | | RTP SESSION with | | | |
| ------------ | | | UNICAST FEEDBACK | | | |
| | Burst and | |<~~~~~~~~>| | | | | |
| | Retrans. | |.........>| | - - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- -
| | Source | |<.=.=.=.=>| | | | | |
| ------------ | | | UNICAST BURST | ------------ | | |
| | | | (or RETRANSMISSION) | | Burst and | |<~~~~~~~~>| |
---------------- -------------- RTP SESSION | | Retrans. | |.........>| |
| | Source | |<.=.=.=.=>| |
| ------------ | | |
| | | |
---------------- --------------
-------> 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 [RFC5760], to The feedback target (FT) is the entity as defined in [RFC5760], to
which RTP_Rx sends its RTCP feedback messages indicating packet loss which RTP_Rx sends its RTCP feedback messages indicating packet loss
by means of an RTCP NACK message or indicating RTP_Rx's desire to by means of an RTCP NACK message or indicating RTP_Rx's desire to
rapidly acquire the primary multicast RTP session by means of an RTCP rapidly acquire the primary multicast RTP session by means of an RTCP
feedback message defined in this document. While the Burst/ feedback message defined in this document. While the Burst/
Retransmission Source is responsible for responding to these messages Retransmission Source (BRS) is responsible for responding to these
and for further RTCP interaction with RTP_Rx in the case of a rapid messages and for further RTCP interaction with RTP_Rx in the case of
acquisition process, it is assumed in the remainder of the document a rapid acquisition process, it is assumed in the remainder of the
that these two logical entities (FT and Burst/Retransmission Source) document that these two logical entities (FT and BRS) are combined in
are combined in a single physical entity and they share state. In a single physical entity and they share state. In the remainder of
the remainder of the text, the term Retransmission Server (RS) will the text, the term Retransmission Server (RS) may be used whenever
be used whenever appropriate, to refer to the combined functionality appropriate, to refer to this single physical entity.
of the FT and Burst/Retransmission Source.
However, it must be noted that only FT is involved in the primary FT is involved in the primary multicast RTP session and receives
multicast RTP session, whereas the Burst/Retransmission Source unicast feedback for that session as in [RFC5760]. BRS is involved
transmits the unicast burst and retransmission packets both formatted in the unicast burst (or retransmission) RTP session and transmits
as RTP retransmission packets [RFC4588] in a single separate unicast the unicast burst and retransmission packets formatted as RTP
RTP retransmission session to each RTP_Rx. In the retransmission retransmission packets [RFC4588] in a single separate unicast RTP
session, as in any other RTP session, RS and RTP_Rx regularly send session to each RTP_Rx. In the unicast burst RTP session, as in any
the periodic sender and receiver reports, respectively. other RTP session, the BRS and RTP_Rx regularly send the periodic
sender and receiver reports, respectively.
The unicast burst is triggered by an RTCP feedback message that is The unicast burst is started by an RTCP feedback message that is
defined in this document based on the common packet format provided defined in this document based on the common packet format provided
in [RFC4585], whereas an RTP retransmission is triggered by an RTCP in [RFC4585]. An RTP retransmission is triggered by an RTCP NACK
NACK message defined in [RFC4585]. In the RTP/AVPF profile, there message defined in [RFC4585]. Both of these messages are sent to FT
are certain rules that apply to scheduling of both of these messages, of the primary multicast RTP session, and may start the unicast
which are detailed in Section 3.5 of [RFC4585]. One of the rules burst/retransmission RTP session.
states that in a multi-party session such as the SSM sessions we are
considering in this specification, an RTP receiver cannot send an In the RTP/AVPF profile, there are certain rules that apply to
RTCP feedback message for a minimum of one second period after scheduling of both of these messages sent to FT in the primary
joining the session (i.e., Tmin=1.0 second). While this rule has the multicast RTP session, and these are detailed in Section 3.5 of
goal of avoiding problems associated with flash crowds in typical [RFC4585]. One of the rules states that in a multi-party session
multi-party sessions, it defeats the purpose of rapid acquisition. such as the SSM sessions we are considering in this specification, an
Furthermore, when RTP receivers delay their messages requesting a RTP receiver cannot send an RTCP feedback message for a minimum of
burst by a deterministic or even a random amount, it still does not one second period after joining the session (i.e., Tmin=1.0 second).
make a difference since such messages are not related and their While this rule has the goal of avoiding problems associated with
timings are independent from each other. Thus, in this specification flash crowds in typical multi-party sessions, it defeats the purpose
we initialize Tmin to zero and allow the RTP receivers to send a of rapid acquisition. Furthermore, when RTP receivers delay their
burst request message right at the beginning. It should, however, be messages requesting a burst by a deterministic or even a random
emphasized that for the subsequent messages during rapid acquisition, amount, it still does not make a difference since such messages are
the timing rules of [RFC4585] still apply. not related and their timings are independent from each other. Thus,
in this specification we initialize Tmin to zero and allow the RTP
receivers to send a burst request message right at the beginning. It
should, however, be emphasized that for the subsequent messages
during rapid acquisition, the timing rules of [RFC4585] still apply.
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. The optional The RTCP feedback messages are explained below. The optional
messages are indicated in parentheses and they may or may not be messages are indicated in parentheses and they may or may not be
present during rapid acquisition. Note that in a scenario where present during rapid acquisition. Note that in a scenario where
rapid acquisition is performed by a feedback target co-located with rapid acquisition is performed by a feedback target co-located with
the media sender, the same method (with the identical message flows) the media sender, the same method (with the identical message flows)
still applies. still applies.
------------------------- -------------------------
skipping to change at page 17, line 30 skipping to change at page 17, line 38
| | | | | | | | | |
| | | |<= SFGMP Join ==| | | | |<= SFGMP Join ==|
| | | | | | | | | |
|-- RTP Multicast ------------------------------------------->| |-- RTP Multicast ------------------------------------------->|
|-. RTCP Multicast -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>| |-. RTCP Multicast -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>|
| | | | | | | | | |
| | | | | | | | | |
| | |<~~~~~~~~~~~~~~~ RTCP RAMS-T ~~~| | | |<~~~~~~~~~~~~~~~ RTCP RAMS-T ~~~|
| | | | | | | | | |
| | | | | | | | | |
| |<~~~~~~~~~~~~~~~~~~~~~~~~~~ (RTCP NACK) ~~|
| | | | |
| | | | |
| | |...(Unicast Retransmissions)...>|
| | | | | | | | | |
: : : : : : : : : :
: : : : : : : : : :
| | |<.=.= Unicast RTCP Reports .=.=>| | | |<.=.= Unicast RTCP Reports .=.=>|
: : : : : : : : (for the unicast session) :
: : : : : : : : : :
| | | | | | | | | |
-------> 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
=======> SFGMP Messages =======> SFGMP Messages
.......> Unicast RTP Flow .......> Unicast RTP Flow
skipping to change at page 18, line 17 skipping to change at page 18, line 20
RTP_Rx that request the burst, describe the burst, start the burst, RTP_Rx that request the burst, describe the burst, start the burst,
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, RTP_Rx needs
unicast RTP retransmission session, RTP_Rx needs to choose its to choose its RTP and RTCP receive ports in the unicast burst
receive ports for RTP and RTCP. Since this unicast session is RTP session. Since this unicast session is established after
established after RTP_Rx sends its rapid acquisition request and RTP_Rx has sent a RAMS-Request (RAMS-R) message as unicast
it is received by RS in the primary multicast RTP session, feedback in the primary multicast RTP session, RTP_Rx MUST first
RTP_Rx MUST setup the port mappings between the unicast and setup the port mappings between the unicast and multicast
multicast sessions and send this mapping information to RS sessions and send this mapping information to FT along with the
before it sends its request so that RS knows how to communicate RAMS-R message so that BRS 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 are explained in
are left to Section 9 to keep the present discussion focused on [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Other NAT-related
the RAMS message flows. issues are left to Section 9 to keep the present discussion
focused on the RAMS message flows.
2. Request: RTP_Rx sends a rapid acquisition request for the 2. Request: RTP_Rx sends a rapid acquisition request (RAMS-R) for
primary multicast RTP session to the feedback target address of the primary multicast RTP session to the unicast feedback target
that session. The request contains the SSRC identifier of of that session. The request contains the SSRC identifier of
RTP_Rx and may contain the media sender SSRC identifier(s) RTP_Rx (aka SSRC of packet sender) and may contain the media
associated with the desired primary multicast stream(s). This sender SSRC identifier(s) of the primary multicast stream(s) of
RTCP feedback message is defined as the RAMS-Request (RAMS-R) interest (aka SSRC of media source). The RAMS-R message may
message and may contain parameters that constrain the burst, contain parameters that constrain the burst, such as the buffer
such as the buffer and bandwidth limits. and bandwidth limits.
Before joining the SSM session, RTP_Rx learns the addresses for Before joining the SSM session, RTP_Rx learns the addresses for
the multicast source, group and RS by out-of-band means. If the multicast source, group and RS by out-of-band means. If
RTP_Rx desires to rapidly acquire only a subset of the primary RTP_Rx desires to rapidly acquire only a subset of the primary
multicast streams available in the primary multicast RTP multicast streams available in the primary multicast RTP
session, the SSRC identifiers for the desired RTP streams MUST session, the SSRC identifiers for the desired RTP streams MUST
also be obtained out-of-band, since no RTP packets have been also be obtained out-of-band. Based on this information, RTP_Rx
received yet for those streams. Based on this information, populates the desired SSRC(s) in the RAMS-R message.
RTP_Rx populates the desired SSRC(s) in its request message.
When RS successfully receives the RAMS-R message, it responds to When FT successfully receives the RAMS-R message, BRS responds
it by accepting or rejecting the request. Right before RS sends to it by accepting or rejecting the request. Right before BRS
any RTP or RTCP packet(s) described below, it establishes the sends any RTP or RTCP packet(s) described below, it establishes
unicast RTP retransmission session. the unicast burst RTP session.
3. Response: RS sends RAMS-Information (RAMS-I) message(s) to 3. Response: BRS sends RAMS-Information (RAMS-I) message(s) to
RTP_Rx to convey the status for the burst(s) requested by RTP_Rx to convey the status for the burst(s) requested by
RTP_Rx. The RAMS-I message is sent by the Burst/Retransmission RTP_Rx.
Source logical entity that is part of RS.
In cases where the primary multicast RTP session associated with If the primary multicast RTP session associated with FT_Ap on
FT_Ap on which the RAMS-R message was received contains only a which the RAMS-R message was received contains only a single
single primary multicast stream, RS SHALL always use the SSRC of primary multicast stream, BRS SHALL always use the SSRC of the
the RTP stream associated with FT_Ap in the RAMS-I message(s) RTP stream associated with FT_Ap in the RAMS-I message(s)
regardless of the media sender SSRC specified in the RAMS-R regardless of the media sender SSRC requested in the RAMS-R
message. In such cases the 'ssrc' attribute MAY be omitted from message. In such cases the 'ssrc' attribute MAY be omitted from
the media description. If the requested SSRC and the actual the media description. If the requested SSRC and the actual
media sender SSRC do not match, RS SHOULD explicitly populate media sender SSRC do not match, BRS SHOULD explicitly populate
the correct media sender SSRC in the initial RAMS-I message. the correct media sender SSRC in the initial RAMS-I message (See
Section 7.3).
FT_Ap could also be associated with an RTP session that carries FT_Ap could also be associated with an RTP session that carries
two or more primary multicast streams. If RTP_Rx will issue a two or more primary multicast streams. If RTP_Rx will issue a
collective request to receive the whole primary multicast RTP collective request to receive the whole primary multicast RTP
session, it does not need the 'ssrc' attributes to be described session, it does not need the 'ssrc' attributes to be described
in the media description. Note that if FT_Ap is associated with in the media description. Note that if FT_Ap is associated with
two or more RTP sessions, RTP_Rx's request will be ambiguous. two or more RTP sessions, RTP_Rx's request will be ambiguous.
Thus, each FT_Ap MUST be associated with a single RTP session. Thus, each FT_Ap MUST be associated with a single RTP session.
If RTP_Rx is willing to rapidly acquire only a subset of the If RTP_Rx is willing to rapidly acquire only a subset of the
primary multicast streams, the RAMS-R message MUST explicitly primary multicast streams, the RAMS-R message MUST explicitly
list the media sender SSRCs. Upon receiving such a message, RS list the media sender SSRCs. Upon receiving such a message, BRS
MAY accept the request for only the media sender SSRC(s) that MAY accept the request for only the media sender SSRC(s) that
matched one of the RTP streams it serves. It MUST reject all matched the RTP stream(s) it serves. It MUST reject all other
other requests with the appropriate response code. requests with the appropriate response code.
* Reject Responses: RS MUST take into account any limitations * Reject Responses: BRS MUST take into account any limitations
that MAY have been specified by RTP_Rx in the RAMS-R message that MAY have been specified by RTP_Rx in the RAMS-R message
when making a decision regarding the request. If RTP_Rx has when making a decision regarding the request. If RTP_Rx has
requested to acquire the whole primary multicast RTP session requested to acquire the whole primary multicast RTP session
but RS cannot provide a rapid acquisition service for any of but BRS cannot provide a rapid acquisition service for any of
the primary multicast streams, RS MUST reject the request via the primary multicast streams, BRS MUST reject the request
a single RAMS-I message with a collective reject response via a single RAMS-I message with a collective reject response
code and whose media sender SSRC field is set to one of SSRCs code and whose media sender SSRC field is set to one of SSRCs
served by this FT_Ap. Upon receiving this RAMS-I message, served by this FT_Ap. Upon receiving this RAMS-I message,
RTP_Rx abandons the rapid acquisition attempt and may RTP_Rx abandons the rapid acquisition attempt and may
immediately join the multicast session by sending an SFGMP immediately join the multicast session by sending an SFGMP
Join message towards its upstream multicast router. Join message towards its upstream multicast router.
In all other cases, RS MUST send a separate RAMS-I message In all other cases, BRS MUST send a separate RAMS-I message
with the appropriate response code for each primary multicast with the appropriate response code for each primary multicast
stream that has been requested by RTP_Rx but cannot be served stream that has been requested by RTP_Rx but cannot be served
by RS. by BRS.
* Accept Responses: RS MUST send a separate RAMS-I message * Accept Responses: BRS MUST send a separate RAMS-I message
with the appropriate response code for each primary multicast with the appropriate response code for each primary multicast
stream that has been requested by RTP_Rx and will be served stream that has been requested by RTP_Rx and will be served
by RS. Such RAMS-I messages comprise fields that can be used by BRS. Such RAMS-I messages comprise fields that can be
to describe the individual unicast burst streams. used to describe the individual unicast burst streams.
A particularly important field carries the RTP sequence A particularly important field carries the RTP sequence
number of the first packet transmitted in the respective RTP number of the first packet transmitted in the respective RTP
stream to allow RTP_Rx to detect any missing initial stream to allow RTP_Rx to detect any missing initial
packet(s). Note that the first RTP packet transmitted in an packet(s). When BRS accepts the request, this field MUST be
RTP stream is not necessarily a burst packet. It could be a populated in the RAMS-I message and the initial RAMS-I
payload-specific RTP packet, which is payload-type- message SHOULD precede the unicast burst or be sent at the
multiplexed with the burst packets (See start of the burst so that RTP_Rx may quickly detect any
[I-D.begen-avt-rtp-mpeg2ts-preamble] for an example). When missing initial packet(s).
RS accepts the request, this field MUST be populated in the
RAMS-I message and the initial RAMS-I message SHOULD precede
the unicast burst or be sent at the start of the burst so
that RTP_Rx may quickly detect any missing initial packet(s).
Where possible, it is RECOMMENDED to include all RAMS-I messages Where possible, it is RECOMMENDED to include all RAMS-I messages
in the same compound RTCP packet. However, it is possible that in the same compound RTCP packet. However, it is possible that
the RAMS-I message for a primary multicast stream may get the RAMS-I message for a primary multicast stream may get
delayed or lost, and RTP_Rx may start receiving RTP packets delayed or lost, and RTP_Rx may start receiving RTP packets
before receiving a RAMS-I message. Thus, RTP_Rx SHOULD NOT make before receiving a RAMS-I message. Thus, RTP_Rx SHOULD NOT make
protocol dependencies on quickly receiving the initial RAMS-I protocol dependencies on quickly receiving the initial RAMS-I
message. For redundancy purposes, it is RECOMMENDED that RS message. For redundancy purposes, it is RECOMMENDED that BRS
repeats the RAMS-I messages multiple times as long as it follows repeats the RAMS-I messages multiple times as long as it follows
the RTCP timer rules defined in [RFC4585]. the RTCP timer rules defined in [RFC4585].
4. Unicast Burst: For the primary multicast stream(s) for which 4. Unicast Burst: For the primary multicast stream(s) for which
the request is accepted, RS starts sending the unicast burst(s) the request is accepted, BRS starts sending the unicast burst(s)
that comprises one or more RTP retransmission packets. The that comprises one or more RTP retransmission packets sent in
burst packet(s) are sent by the Burst/Retransmission Source the unicast burst RTP session. In addition, BRS MAY send
logical entity. In addition, there MAY be optional payload- preamble information data to RTP_Rx in addition to the requested
specific information that RS chooses to send to RTP_Rx. Such an burst, to prime the media decoder(s). The format of this data
example is discussed in [I-D.begen-avt-rtp-mpeg2ts-preamble] for is RTP-payload specific and not specified here.
transmitting the payload-specific information for MPEG2
Transport Streams.
5. Updated Request: RTP_Rx MAY send an updated RAMS-R message (to 5. Updated Request: RTP_Rx MAY send an updated RAMS-R message (as
the FT entity of RS) with a different value for one or more unicast feedback in the primary multicast RTP session) with a
fields of an earlier RAMS-R message. Upon receiving an updated different value for one or more fields of an earlier RAMS-R
request, RS may use the updated values for sending/shaping the message. If there is already a burst planned for or being
burst, or refine the values and use the refined values for transmitted to a particular RTP_Rx for a particular stream, the
sending/shaping the burst. Subsequently, RS MAY send an updated newly arriving RAMS-R is an updated request; otherwise, it is a
RAMS-I message to indicate the changes it made. new request. BRS determines the identity of the requesting
RTP_Rx by looking at its canonical name identifier (CNAME item
in the SDES source description). To choose a globally unique
CNAME identifier, RTP_Rx SHOULD follow the guidelines given in
[RFC3550] Section 6.5.1 as updated by
[I-D.begen-avt-rtp-cnames].
Upon receiving an updated request, BRS may use the updated
values for sending/shaping the burst, or refine the values and
use the refined values for sending/shaping the burst.
Subsequently, BRS MAY send an updated RAMS-I message in the
unicast burst RTP session to indicate the changes it made.
However, the updated RAMS-I message may get lost. It is also However, the updated RAMS-I message may get lost. It is also
possible that the updated RAMS-R message could have been lost. possible that the updated RAMS-R message could have been lost.
Thus, RTP_Rx SHOULD NOT make protocol dependencies on quickly Thus, RTP_Rx SHOULD NOT make protocol dependencies on quickly
(or ever) receiving an updated RAMS-I message, or assume that RS (or ever) receiving an updated RAMS-I message, or assume that
will honor the requested changes. BRS will honor the requested changes.
RTP_Rx may be in an environment where the available resources RTP_Rx may be in an environment where the available resources
are time-varying, which may or may not deserve sending a new are time-varying, which may or may not deserve sending a new
updated request. Determining the circumstances where RTP_Rx updated request. Determining the circumstances where RTP_Rx
should or should not send an updated request and the methods should or should not send an updated request and the methods
that RTP_Rx can use to detect and evaluate the time-varying that RTP_Rx can use to detect and evaluate the time-varying
available resources are not specified in this document. available resources are not specified in this document.
6. Updated Response: RS may send more than one RAMS-I messages, 6. Updated Response: BRS may send more than one RAMS-I messages in
e.g., to update the value of one or more fields in an earlier the unicast burst RTP session, e.g., to update the value of one
RAMS-I message. The updated RAMS-I messages may or may not be a or more fields in an earlier RAMS-I message. The updated RAMS-I
direct response to a RAMS-R message. RS may also send updated messages may or may not be a direct response to a RAMS-R
RAMS-I messages to signal RTP_Rx in real time to join the message. BRS may also send updated RAMS-I messages to signal
multicast session. RTP_Rx depends on RS to learn the join time, RTP_Rx in real time to join the SSM session. RTP_Rx depends on
which can be conveyed by the first RAMS-I message, or can be BRS to learn the join time, which can be conveyed by the first
sent/revised in a later RAMS-I message. If RS is not capable of RAMS-I message, or can be sent/revised in a later RAMS-I
determining the join time in the initial RAMS-I message, it MUST message. If BRS is not capable of determining the join time in
send another RAMS-I message (with the join time information) the initial RAMS-I message, it MUST send another RAMS-I message
later. (with the join time information) later.
7. Multicast Join Signaling: The RAMS-I message allows RS to 7. Multicast Join Signaling: The RAMS-I message allows BRS to
signal explicitly when RTP_Rx SHOULD send the SFGMP Join signal explicitly when RTP_Rx SHOULD send the SFGMP Join
message. If the request is accepted, this information MUST be message. If the request is accepted, this information MUST be
conveyed in at least one RAMS-I message and its value MAY be conveyed in at least one RAMS-I message and its value MAY be
updated by subsequent RAMS-I messages. If RTP_Rx has received updated by subsequent RAMS-I messages. If RTP_Rx has received
multiple RAMS-I messages, it SHOULD use the information from the multiple RAMS-I messages, it SHOULD use the information from the
most recent RAMS-I message. most recent RAMS-I message.
There may be missing packets if RTP_Rx joins the multicast There may be missing packets if RTP_Rx joins the multicast
session too early or too late. For example, if RTP_Rx starts session too early or too late. For example, if RTP_Rx starts
receiving the primary multicast stream while it is still receiving the primary multicast stream while it is still
receiving the unicast burst at a high excess bitrate, this may receiving the unicast burst at a high excess bitrate, this may
result in an increased risk of packet loss. Or, if RTP_Rx joins result in an increased risk of packet loss. Or, if RTP_Rx joins
the multicast session some time after the unicast burst is the multicast session some time after the unicast burst is
finished, there may be a gap between the burst and multicast finished, there may be a gap between the burst and multicast
data (a number of RTP packets may be missing). In both cases, data (a number of RTP packets may be missing). In both cases,
RTP_Rx may issue retransmissions requests (via RTCP NACK RTP_Rx may issue retransmissions requests (via RTCP NACK
messages) [RFC4585] to the FT entity of RS to fill the gap. RS messages sent as unicast feedback in the primary multicast RTP
session) [RFC4585] to the FT entity of RS to fill the gap. BRS
may or may not respond to such requests. When it responds and may or may not respond to such requests. When it responds and
the response causes significant changes in one or more values the response causes significant changes in one or more values
reported earlier to RTP_Rx, an updated RAMS-I should be sent to reported earlier to RTP_Rx, an updated RAMS-I should be sent to
RTP_Rx. RTP_Rx.
8. Multicast Receive: After the join, RTP_Rx starts receiving the 8. Multicast Receive: After the join, RTP_Rx starts receiving the
primary multicast stream(s). primary multicast stream(s).
9. Terminate: RS may know when it needs to ultimately stop the 9. Terminate: BRS may know when it needs to ultimately stop the
unicast burst based on its parameters. However, RTP_Rx may need unicast burst based on its parameters. However, RTP_Rx may need
to ask RS to terminate the burst prematurely or at a specific to ask BRS to terminate the burst prematurely or at a specific
sequence number. For this purpose, it uses the RAMS-Termination sequence number. For this purpose, it uses the RAMS-Termination
(RAMS-T) message. A separate RAMS-T message is sent for each (RAMS-T) message sent as RTCP feedback in the unicast burst RTP
primary multicast stream served by RS unless an RTCP BYE message session. A separate RAMS-T message is sent for each primary
has been sent as described in Step 10. For the burst requests multicast stream served by BRS unless an RTCP BYE message has
that were rejected by RS, there is no need to send a RAMS-T been sent in the unicast burst RTP session as described in Step
message. 10. For the burst requests that were rejected by BRS, there is
no need to send a RAMS-T message.
If RTP_Rx wants to terminate a burst prematurely, it SHALL send If RTP_Rx wants to terminate a burst prematurely, it SHALL send
a plain RAMS-T message for the particular primary multicast a plain RAMS-T message for the SSRC of the primary multicast
stream, and upon receiving this message RS MUST terminate the stream it wishes to terminate. This message is sent in the
unicast burst. If RTP_Rx requested to acquire the entire unicast burst RTP session. Upon receiving this message BRS MUST
primary multicast RTP session but wants to terminate this terminate the unicast burst. If RTP_Rx requested to acquire the
entire primary multicast RTP session but wants to terminate this
request before it learns the individual media sender SSRC(s) via request before it learns the individual media sender SSRC(s) via
RAMS-I message(s), it cannot use RAMS-T message(s) and thus MUST RAMS-I message(s) or RTP packets, it cannot use RAMS-T
send an RTCP BYE message to terminate the request. message(s) and thus MUST send an RTCP BYE message in the unicast
burst RTP session to terminate the request.
Otherwise, the default behavior for RTP_Rx is to send a RAMS-T Otherwise, the default behavior for RTP_Rx is to send a RAMS-T
message right after it joined the multicast session and started message in the unicast burst RTP session immediately after it
receiving multicast packets. In that case, RTP_Rx SHALL send a joins the multicast session and started receiving multicast
RAMS-T message with the sequence number of the first RTP packet packets. In that case, RTP_Rx SHALL send a RAMS-T message with
received in the primary multicast stream, and RS SHOULD the sequence number of the first RTP packet received in the
terminate the respective burst after it sends the unicast burst primary multicast stream, and BRS SHOULD terminate the
packet whose Original Sequence Number (OSN) field in the RTP respective burst after it sends the unicast burst packet whose
retransmission payload header matches this number minus one. Original Sequence Number (OSN) field in the RTP retransmission
payload header matches this number minus one.
RTP_Rx MUST send at least one RAMS-T message for each primary RTP_Rx MUST send at least one RAMS-T message for each primary
multicast stream served by RS (if an RTCP BYE message has not multicast stream served by BRS (if an RTCP BYE message has not
been issued yet as described in Step 10). The RAMS-T message(s) been issued yet as described in Step 10). The RAMS-T message(s)
MUST be addressed to the Burst/Retransmission Source logical MUST be addressed to BRS and sent in the unicast burst RTP
entity. Against the possibility of a message loss, it is session. Against the possibility of a message loss, it is
RECOMMENDED that RTP_Rx repeats the RAMS-T messages multiple RECOMMENDED that RTP_Rx repeats the RAMS-T messages multiple
times as long as it follows the RTCP timer rules defined in times as long as it follows the RTCP timer rules defined in
[RFC4585]. [RFC4585].
The binding between RAMS-T and ongoing bursts is achieved
through RTP_Rx's CNAME identifier, and packet sender and media
sender SSRCs. Choosing a globally unique CNAME makes sure that
the RAMS-T messages are processed correctly.
10. Terminate with RTCP BYE: When RTP_Rx is receiving one or more 10. Terminate with RTCP BYE: When RTP_Rx is receiving one or more
burst streams, if RTP_Rx becomes no longer interested in burst streams, if RTP_Rx becomes no longer interested in
acquiring any of the primary multicast streams, RTP_Rx SHALL acquiring any of the primary multicast streams, RTP_Rx SHALL
issue an RTCP BYE message for the RTP retransmission session and issue an RTCP BYE message for the unicast burst RTP session and
another RTCP BYE message for the primary multicast RTP session. another RTCP BYE message for the primary multicast RTP session.
These RTCP BYE messages are sent to the Burst/Retransmission These RTCP BYE messages are sent to BRS and FT logical entities,
Source and FT logical entities, respectively. respectively.
Upon receiving an RTCP BYE message, the Burst/Retransmission Upon receiving an RTCP BYE message, BRS MUST terminate the rapid
Source logical entity MUST terminate the rapid acquisition acquisition operation, and cease transmitting any further burst
operation, and cease transmitting any further burst packets and packets and retransmission packets. If support for [RFC5506]
retransmission packets. If support for [RFC5506] has been has been signaled, the RTCP BYE message MAY be sent in a
signaled, the RTCP BYE message MAY be sent in a reduced-size reduced-size RTCP packet. Otherwise, Section 6.1 of [RFC3550]
RTCP packet. Otherwise, Section 6.1 of [RFC3550] mandates the mandates the RTCP BYE message always to be sent with a sender or
RTCP BYE message always to be sent with a sender or receiver receiver report in a compound RTCP packet (If no data has been
report in a compound RTCP packet (If no data has been received, received, an empty receiver report MUST be still included).
an empty receiver report MUST be still included). With the With the information contained in the receiver report, RS can
information contained in the receiver report, RS can figure out figure out how many duplicate RTP packets have been delivered to
how many duplicate RTP packets have been delivered to RTP_Rx RTP_Rx (Note that this will be an upper-bound estimate as one or
(Note that this will be an upper-bound estimate as one or more more packets might have been lost during the burst
packets might have been lost during the burst transmission). transmission). The impact of duplicate packets and measures
The impact of duplicate packets and measures that can be taken that can be taken to minimize the impact of receiving duplicate
to minimize the impact of receiving duplicate packets will be 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 unicast burst RTP
session terminates the whole session and ceases transmitting any session terminates that session and ceases transmitting any
further packets in that RTP session. Thus, in this case there further packets in that session. Thus, in this case there is no
is no need for sending explicit RAMS-T messages, which would need for sending explicit RAMS-T messages, which would only
only terminate their respective bursts. 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.ietf-avt-multicast-acq-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
[RFC3550]. If the playout will start before RTP_Rx has joined the [RFC3550]. If the playout will start before RTP_Rx has joined the
multicast session, RTP_Rx must receive the information reflecting the multicast session, RTP_Rx must receive the information reflecting the
synchronization among the primary multicast streams early enough so synchronization among the primary multicast streams early enough so
that it can play out the media in a synchronized fashion. However, that it can play out the media in a synchronized fashion.
this would require RS to cache the sender reports sent in the primary
multicast RTP session(s), and piggyback the latest synchronization
information on its own sender report and send an early sender report
in the unicast RTP retransmission session. This issue and its
implications are discussed in detail in
[I-D.ietf-avt-rapid-rtp-sync].
An alternative approach is to use the RTP header extension mechanism The suggested approach is to use the RTP header extension mechanism
[RFC5285] and convey the synchronization information in a header [RFC5285] and convey the synchronization information in a header
extension as defined in [I-D.ietf-avt-rapid-rtp-sync]. extension as defined in [I-D.ietf-avt-rapid-rtp-sync]. [RFC4588]
says that retransmission packets SHOULD carry the same header
[RFC4588] says that retransmission packets SHOULD carry the same extension carried in the header of the original RTP packets. Thus,
header extension carried in the header of the original RTP packets. as long as the multicast source emits a header extension with the
Thus, as long as the multicast source emits a header extension with synchronization information frequently enough, there is no additional
the synchronization information frequently enough, there is no task that needs to be carried out by BRS. The synchronization
additional task that needs to be carried out by RS. The information will be sent to RTP_Rx along with the burst packets. The
synchronization information will be sent to RTP_Rx along with the frequent header extensions sent in the primary multicast RTP sessions
burst packets. The frequent header extensions sent in the primary also allow rapid synchronization of the RTP streams for the RTP
multicast RTP sessions also allow rapid synchronization of the RTP receivers that do not support RAMS or that directly join the
streams for the RTP receivers that do not support RAMS or that multicast session without running RAMS. Thus, in RAMS applications,
directly join the multicast session without running RAMS. Thus, in it is RECOMMENDED that the multicast sources frequently send
RAMS applications, it is RECOMMENDED that the multicast sources synchronization information by using header extensions following the
frequently send synchronization information by using header rules presented in [I-D.ietf-avt-rapid-rtp-sync]. It should be noted
extensions following the rules presented in that the regular sender reports are still sent in the unicast session
[I-D.ietf-avt-rapid-rtp-sync]. It should be noted that the regular by following the rules of [RFC3550].
sender reports are still sent in the unicast session by following the
rules of [RFC3550].
6.4. Burst Shaping and Congestion Control in RAMS 6.4. Burst Shaping and Congestion Control in RAMS
This section provides informative guidelines about how RS can shape This section provides informative guidelines about how BRS can shape
the transmission of the unicast burst and how congestion can be dealt the transmission of the unicast burst and how congestion can be dealt
within the RAMS process. within the RAMS process. Note that if RTP_Rx detects that the
unicast burst is causing severe congestion, it can prefer to send a
RAMS-T message immediately to stop 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 RTP_Rx faster. This way, Reference Information and media content to RTP_Rx faster. This way,
RTP_Rx 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. A higher bitrate also represents a better utilization acquisition. A higher bitrate also represents a better utilization
of RS resources. As the burst may continue until it catches up with of BRS resources. As the burst may continue until it catches up with
the primary multicast stream, the higher the bursting bitrate, the the primary multicast stream, the higher the bursting bitrate, the
less data RS needs to transmit. However, a higher bitrate for the less data BRS needs to transmit. However, a higher bitrate for the
burst also increases the chances for congestion-caused packet loss. burst also increases the chances for congestion-caused packet loss.
Thus, as discussed in Section 5, there must be an upper bound on the Thus, as discussed in Section 5, there must be an upper bound on the
bandwidth used by the burst. bandwidth used by the burst.
When RS transmits the burst, it should take into account all When BRS transmits the unicast 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 RTP_Rx and at RTP_Rx itself. The bursting bitrate may between RS and RTP_Rx and at RTP_Rx itself. The bursting bitrate may
be determined by taking into account the following information, when be determined by taking into account the following information, when
available: 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).
skipping to change at page 25, line 23 skipping to change at page 25, line 34
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.ietf-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 BRS.
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 BRS / DCCP server for burst shaping and
congestion control. congestion control.
g. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that g. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that
indicate the upper-bound bursting bitrates for which no packet indicate the upper-bound bursting bitrates for which no packet
loss will occur as a result of congestion along the path of RS to loss will occur as a result of congestion along the path of RS to
RTP_Rx. For example, in managed IPTV networks, where the RTP_Rx. For example, in managed IPTV networks, where the
bottleneck bandwidth along the end-to-end path is known and where bottleneck bandwidth along the end-to-end path is known and where
the network between RS and this link is provisioned and the network between RS and this link is provisioned and
dimensioned to carry the burst streams, the bursting bitrate does dimensioned to carry the burst streams, the bursting bitrate does
not exceed the provisioned value. These settings may also be not exceed the provisioned value. These settings may also be
dynamically adapted using application-aware knowledge. dynamically adapted using application-aware knowledge.
RS chooses the initial burst bitrate as follows: BRS chooses the initial burst bitrate as follows:
o When using RAMS in environments as described in (g), RS MUST o When using RAMS in environments as described in (g), BRS MUST
transmit the burst packets at an initial bitrate higher than the transmit the burst packets at an initial bitrate higher than the
nominal bitrate, but within the engineered or reserved bandwidth nominal bitrate, but within the engineered or reserved bandwidth
limit. limit.
o When RS cannot determine a reliable bitrate value for the unicast o When BRS cannot determine a reliable bitrate value for the unicast
burst (through a or g), RS should choose an appropriate initial burst (through a or g), BRS should choose an appropriate initial
bitrate not above the nominal bitrate and increase it gradually bitrate not above the nominal bitrate and increase it gradually
unless a congestion is detected. unless a congestion is detected.
In both cases, during the burst transmission RS MUST continuously In both cases, during the burst transmission BRS MUST continuously
monitor for packet losses as a result of congestion by means of one monitor for packet losses as a result of congestion by means of one
or more of the mechanisms described in (b,c,d,e,f). When RS relies or more of the mechanisms described in (b,c,d,e,f). When BRS relies
on RTCP receiver reports, sufficient bandwidth must be provided to on RTCP receiver reports, sufficient bandwidth must be provided to
RTP Rx for RTCP transmission. To achieve a reasonable fast RTP Rx for RTCP transmission in the unicast burst RTP session. To
adaptation against congestion, it is recommended that RTP_Rx sends a achieve a reasonable fast adaptation against congestion, it is
receiver report at least once every two RTTs between RS and RTP_Rx. recommended that RTP_Rx sends a receiver report at least once every
Although the specific heuristics and algorithms that deduce a two RTTs between RS and RTP_Rx. Although the specific heuristics and
congestion state and how subsequently RS should act are outside the algorithms that deduce a congestion state and how subsequently BRS
scope of this specification, the following two practices are should act are outside the scope of this specification, the following
recommended: two practices are recommended:
o Upon detection of a significant packet loss, which RS attributes o Upon detection of a significant packet loss, which BRS attributes
to congestion, RS should decrease the burst bitrate. The rate by to congestion, BRS should decrease the burst bitrate. The rate by
which RS increases and decreases the bitrate for the burst may be which BRS increases and decreases the bitrate for the burst may be
determined by a TCP-friendly bitrate adaptation algorithm for RTP determined by a TCP-friendly bitrate adaptation algorithm for RTP
over UDP , or in the case of (f) by the congestion control over UDP , or in the case of (f) by the congestion control
algorithms defined in DCCP [I-D.ietf-dccp-rtp]. algorithms defined in DCCP [I-D.ietf-dccp-rtp].
o If the congestion is persistent and RS has to reduce the burst o If the congestion is persistent and BRS has to reduce the burst
bitrate to a point where the RTP Rx buffer may underrun or the bitrate to a point where the RTP Rx buffer may underrun or the
burst will consume too much RS resources, RS should terminate the burst will consume too many resources, BRS should terminate the
burst and transmit a RAMS-I message to RTP Rx with the appropriate burst and transmit a RAMS-I message to RTP Rx with the appropriate
response code. It is then up to RTP Rx to decide when to join the response code. It is then up to RTP Rx to decide when to join the
multicast session. multicast session.
In case there is no congestion experienced during the burst, a In case there is no congestion experienced during the burst, a
specific situation occurs near the end of the unicast burst, when RS specific situation occurs near the end of the unicast burst, when BRS
has almost no more additional data to sustain the relatively higher has almost no more additional data to sustain the relatively higher
burst bitrate, thus, the upper-bound burst bitrate automatically gets burst bitrate, thus, the upper-bound burst bitrate automatically gets
limited by the nominal bitrate of the primary multicast stream. limited by the nominal bitrate of the primary multicast stream.
During this time frame, RTP_Rx eventually needs to join the multicast During this time frame, RTP_Rx eventually needs to join the multicast
session. This means that both the burst packets and the multicast session. This means that both the burst packets and the multicast
packets may be simultaneously received by RTP_Rx for a period of packets may be simultaneously received by RTP_Rx for a period of
time, enhancing the risk of congestion again. time, enhancing the risk of congestion again.
Since RS signals RTP_Rx when it should send the SFGMP Join message, Since BRS signals RTP_Rx when it should send the SFGMP Join message,
RS may have a rough estimate of when RTP_Rx will start receiving BRS may have a rough estimate of when RTP_Rx will start receiving
multicast packets in the SSM session. RS may keep on sending burst multicast packets in the SSM session. BRS may keep on sending burst
packets but should reduce the bitrate accordingly at the appropriate packets but should reduce the bitrate accordingly at the appropriate
instant by taking the bitrate of the whole SSM session into account. instant by taking the bitrate of the whole SSM session into account.
If RS ceases transmitting the burst packets before the burst catches If BRS ceases transmitting the burst packets before the burst catches
up, any gap resulting from this imperfect switch-over by RTP_Rx can up, any gap resulting from this imperfect switch-over by RTP_Rx can
be later repaired by requesting retransmissions for the missing be later repaired by requesting retransmissions for the missing
packets from RS. The retransmissions may be shaped by RS to make packets from RS. The retransmissions may be shaped by BRS to make
sure that they do not cause collateral loss in the primary multicast sure that they do not cause collateral loss in the primary multicast
RTP session and the RTP retransmission session. RTP session and the unicast burst RTP session.
6.5. Failure Cases 6.5. Failure Cases
In the following, we examine the implications of losing the RAMS-R, In the following, we examine the implications of losing the RAMS-R,
RAMS-I or RAMS-T messages and other failure cases. RAMS-I or RAMS-T messages and other failure cases.
When RTP_Rx sends a RAMS-R message to initiate a rapid acquisition When RTP_Rx sends a RAMS-R message to initiate a rapid acquisition
but the message gets lost and RS does not receive it, RTP_Rx will get but the message gets lost and FT does not receive it, RTP_Rx will get
neither a RAMS-I message, nor a unicast burst. In this case, RTP_Rx neither a RAMS-I message, nor a unicast burst. In this case, RTP_Rx
MAY resend the request when it is eligible to do so based on the RTCP MAY resend the request when it is eligible to do so based on the RTCP
timer rules defined in [RFC4585]. Or, after a reasonable amount of timer rules defined in [RFC4585]. Or, after a reasonable amount of
time, RTP_Rx may time out (based on the previous observed response time, RTP_Rx may time out (based on the previous observed response
times) and immediately join the SSM session. times) and immediately join the SSM session.
In the case RTP_Rx 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, RTP_Rx may either discard the burst data or decide not to time, RTP_Rx may either discard the burst data or decide not to
interrupt the unicast burst, and be prepared to join the SSM session interrupt the unicast burst, and be prepared to join the SSM session
at an appropriate time it determines or as indicated in a subsequent at an appropriate time it determines or as indicated in a subsequent
RAMS-I message (if available). To minimize the chances of losing the RAMS-I message (if available). To minimize the chances of losing the
RAMS-I messages, it is RECOMMENDED that RS repeats the RAMS-I RAMS-I messages, it is RECOMMENDED that BRS repeats the RAMS-I
messages multiple times based on the RTCP timer rules defined in messages multiple times based on the RTCP timer rules defined in
[RFC4585]. [RFC4585].
In the failure cases where the RAMS-R message is lost and RTP_Rx In the failure cases where the RAMS-R message is lost and RTP_Rx
gives up, or the RAMS-I message is lost, RTP_Rx MUST still terminate gives up, or the RAMS-I message is lost, RTP_Rx MUST still terminate
the burst(s) it requested by following the rules described in the burst(s) it requested by following the rules described in
Section 6.2. Section 6.2.
In the case a RAMS-T message sent by RTP_Rx does not reach its In the case a RAMS-T message sent by RTP_Rx does not reach its
destination, RS may continue sending burst packets even though RTP_Rx destination, BRS may continue sending burst packets even though
no longer needs them. In such cases, it is RECOMMENDED that RTP_Rx RTP_Rx no longer needs them. In such cases, it is RECOMMENDED that
repeats the RAMS-T message multiple times based on the RTCP timer RTP_Rx repeats the RAMS-T message multiple times based on the RTCP
rules defined in [RFC4585]. In the worst case, RS MUST be timer rules defined in [RFC4585]. In the worst case, BRS MUST be
provisioned to deterministically terminate the burst when it can no provisioned to deterministically terminate the burst when it can no
longer send the burst packets faster than it receives the primary longer send the burst packets faster than it receives the primary
multicast stream packets. multicast stream packets.
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 BRS 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] and is also sketched in Figure 4.
field for version, padding, feedback message type (FMT), payload type
(PT), length, SSRC of packet sender, SSRC of media sender as well as 0 1 2 3
a variable-length field for feedback control information (FCI). 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Figure 4: The common packet format for the RTCP feedback messages
Each feedback message has a fixed-length field for version, padding,
feedback message type (FMT), payload type (PT), length, SSRC of
packet sender, SSRC of media sender as well as a variable-length
field for feedback control information (FCI).
In the RAMS messages, the PT field is set to RTPFB (205) and the FMT In the RAMS messages, the PT field is set to RTPFB (205) and the FMT
field is set to RAMS (6). Individual RAMS messages are identified by field is set to RAMS (6). Individual RAMS messages are identified by
a sub-field called Sub Feedback Message Type (SFMT). Any Reserved a sub-field called Sub Feedback Message Type (SFMT). Any Reserved
field SHALL be set to zero and ignored. field SHALL be set to zero and ignored.
Depending on the specific scenario and timeliness/importance of a Depending on the specific scenario and timeliness/importance of a
RAMS message, it may be desirable to send it in a reduced-size RTCP RAMS message, it may be desirable to send it in a reduced-size RTCP
packet [RFC5506]. However, unless support for [RFC5506] has been packet [RFC5506]. However, unless support for [RFC5506] has been
signaled, compound RTCP packets MUST be used by following [RFC3550] signaled, compound RTCP packets MUST be used by following [RFC3550]
skipping to change at page 28, line 40 skipping to change at page 29, line 19
Following the rules specified in [RFC3550], all integer fields in the Following the rules specified in [RFC3550], all integer fields in the
messages defined below are carried in network-byte order, that is, messages defined below are carried in network-byte order, that is,
most significant byte (octet) first, also known as big-endian. most significant byte (octet) first, also known as big-endian.
Unless otherwise noted, numeric constants are in decimal (base 10). Unless otherwise noted, numeric constants are in decimal (base 10).
7.1. Extensions 7.1. Extensions
To improve the functionality of the RAMS method in certain To improve the functionality of the RAMS method in certain
applications, it may be desirable to define new fields in the RAMS applications, it may be desirable to define new fields in the RAMS
Request, Information and Termination messages. Such fields MUST be Request, Information and Termination messages. Such fields MUST be
encoded as TLV elements as described below and sketched in Figure 4: encoded as TLV elements as described below and sketched in Figure 5:
o Type: A single-octet identifier that defines the type of the o Type: A single-octet identifier that defines the type of the
parameter represented in this TLV element. parameter represented in this TLV element.
o Length: A two-octet field that indicates the length (in octets) o Length: A two-octet field that indicates the length (in octets)
of the TLV element excluding the Type and Length fields, and the of the TLV element excluding the Type and Length fields, and the
8-bit Reserved field between them. Note that this length does not 8-bit Reserved field between them. Note that this length does not
include any padding that is required for alignment. include any padding that is required for alignment.
o Value: Variable-size set of octets that contains the specific o Value: Variable-size set of octets that contains the specific
value for the parameter. value for the parameter.
In the extensions, the Reserved field SHALL be set to zero and In the extensions, the Reserved field SHALL be set to zero and
ignored. If a TLV element does not fall on a 32-bit boundary, the ignored. If a TLV element does not fall on a 32-bit boundary, the
last word MUST be padded to the boundary using further bits set to last word MUST be padded to the boundary using further bits set to
zero. zero.
In a RAMS message, any vendor-neutral or private extension MUST be In a RAMS message, any vendor-neutral or private extension MUST be
placed after the mandatory fields (if any). The extensions MAY be placed after the mandatory fields and mandatory TLV elements (if
placed in any order. The support for extensions is OPTIONAL. any). The extensions MAY be placed in any order. The support for
extensions (unless noted otherwise) is OPTIONAL.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value : : Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Structure of a TLV element Figure 5: 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 11.5. with IANA through the guidelines provided in Section 11.5.
The current document defines several vendor-neutral extensions in the The current document defines several vendor-neutral extensions in the
subsequent sections. subsequent sections.
skipping to change at page 29, line 45 skipping to change at page 30, line 26
It is desirable to allow vendors to use private extensions in a TLV It is desirable to allow vendors to use private extensions in a 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 (between - and including - 128 and 254 ) A certain range of TLV Types (between - and including - 128 and 254 )
is reserved for private extensions (Refer to Section 11.5). IANA is reserved for private extensions (Refer to Section 11.5). IANA
management for these extensions is unnecessary and they are the management for these extensions is unnecessary and they are the
responsibility of individual vendors. 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 6. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number | | Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value : : Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Structure of a private extension Figure 6: Structure of a private extension
7.2. RAMS Request 7.2. RAMS Request
The RAMS Request message is identified by SFMT=1. This message is The RAMS Request message is identified by SFMT=1. This message is
used by RTP_Rx to request rapid acquisition for a primary multicast sent as unicast feedback in the primary multicast RTP session by
RTP session, or one or more primary multicast streams belonging to RTP_Rx to request rapid acquisition of a primary multicast RTP
the same primary multicast RTP session. session, or one or more primary multicast streams belonging to the
same primary multicast RTP session. In the RAMS-R message, both the
Unless signaled otherwise, a RAMS-R message is used to request a packet sender SSRC and media sender SSRC fields MUST be set to the
single primary multicast stream whose SSRC is indicated in the media SSRC of RTP_Rx, and RTP_Rx MUST provide explicit signaling as
sender SSRC field of the message header. In cases where RTP_Rx does described below to request stream(s). This minimizes the chances of
not know the media sender SSRC, it MUST set that field to its own
SSRC.
If RTP_Rx wants to request two or more primary multicast streams or
all of the streams in the primary multicast RTP session, RTP_Rx MUST
provide explicit signaling as described below and set the media
sender SSRC field to its own SSRC to minimize the chances of
accidentally requesting a wrong primary multicast stream. accidentally requesting a wrong primary multicast stream.
The FCI field MUST contain only one RAMS Request. The FCI field has The FCI field MUST contain only one RAMS Request. The FCI field has
the structure depicted in Figure 6. 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=1 | Reserved | | SFMT=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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 7: FCI field syntax for the RAMS Request message
o Requested Media Sender SSRC(s): Optional TLV element that lists o Requested Media Sender SSRC(s): Mandatory TLV element that lists
the media sender SSRC(s) requested by RTP_Rx. If this TLV element the media sender SSRC(s) requested by RTP_Rx. BRS MUST ignore the
does not exist in the RAMS-R message, it means that RTP_Rx is only media sender SSRC specified in the header of the RAMS-R message.
interested in a single primary multicast stream whose media sender
SSRC is already specified in the header of the RAMS-R message. If the Length field is set to zero (i.e., no media sender SSRC is
However, if this TLV element exists, RS MUST ignore the media listed), it means that RTP_Rx is requesting to rapidly acquire the
sender SSRC specified in the header of the RAMS-R message. If entire primary multicast RTP session. Otherwise, RTP_Rx lists the
this TLV element exists but the Length field is set to zero, individual media sender SSRCs in this TLV element and sets the
meaning that no media sender SSRC is listed, it means that RTP_Rx Length field of the TLV element to 4*n, where n is the number of
is requesting to rapidly acquire the entire primary multicast RTP SSRC entries.
session. Otherwise, RTP_Rx lists the individual media sender
SSRCs in this TLV element and sets the Length field of the TLV
element to 4*n, where n is the number of SSRC entries.
Type: 1 Type: 1
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 RTP_Rx desires that denotes the minimum milliseconds of data that RTP_Rx desires
to have in its buffer before allowing the data to be consumed by to have in its buffer before allowing the data to be consumed by
the application. the application.
RTP_Rx 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, RTP_Rx 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 BRS is told the minimum
buffering requirement of the receiver, it may tailor the burst(s) buffering requirement of the receiver, it may tailor the burst(s)
more precisely, e.g., by choosing an appropriate starting point. more precisely, e.g., by choosing an appropriate starting point.
The methods used by RTP_Rx 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 bursts and any payload-specific information MUST NOT be unicast bursts and any payload-specific information MUST NOT be
smaller than the specified value since it will not be able to smaller than the specified value since it will not be able to
build up the desired level of buffer at RTP_Rx and may cause build up the desired level of buffer at RTP_Rx and may cause
buffer underruns. buffer underruns.
Type: 2 Type: 2
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 RTP_Rx can that denotes the maximum milliseconds of data that RTP_Rx can
buffer without losing the data due to buffer overflow. buffer without losing the data due to buffer overflow.
RTP_Rx 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 RTP_Rx may have more physical memory than another one particular RTP_Rx may have more physical memory than another
RTP_Rx, and thus, can buffer more data. If RS knows the buffering RTP_Rx, and thus, can buffer more data. If BRS knows the
ability of the receiver, it may tailor the burst(s) more buffering ability of the receiver, it may tailor the burst(s) more
precisely. The methods used by the receiver to determine this precisely. The methods used by the receiver to determine this
value are application specific, and thus, out of scope. value are 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 bursts and any payload-specific information MUST NOT be unicast bursts and any payload-specific information MUST NOT be
larger than this value since it may cause buffer overflows at larger than this value since it may cause buffer overflows at
RTP_Rx. RTP_Rx.
Type: 3 Type: 3
o Max Receive Bitrate (64 bits): Optional TLV element that denotes o Max Receive Bitrate (64 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 aggregation of the unicast burst(s) and any payload- process the aggregation of the unicast burst(s) and any payload-
specific information that will be provided by RS. The limits may specific information that will be provided by BRS. The limits may
include local receiver limits as well as network limits that are include local receiver limits as well as network limits that are
known to the receiver. known to the receiver.
If specified, the total bitrate of the unicast burst(s) plus any If specified, the total bitrate of the unicast burst(s) plus any
payload-specific information MUST NOT be larger than this value payload-specific information MUST NOT be larger than this value
since it may cause congestion and packet loss. since it may cause congestion and packet loss.
Type: 4 Type: 4
o Request for Preamble Only (0 bits): Optional TLV element that o Request for Preamble Only (0 bits): Optional TLV element that
indicates that RTP_Rx is only requesting the preamble information indicates that RTP_Rx is only requesting the preamble information
for the desired primary multicast stream(s). If this TLV element for the desired primary multicast stream(s). If this TLV element
exists in the RAMS-R message, RS SHOULD NOT send any burst packets exists in the RAMS-R message, BRS SHOULD NOT send any burst
other than the preamble packets. Note that this TLV element does packets other than the preamble packets. Note that this TLV
not carry a Value field. Thus, the Length field MUST be set to element does not carry a Value field. Thus, the Length field MUST
zero. be set to zero.
Type: 5 Type: 5
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 response code is sent A separate RAMS-I message with the appropriate response code is sent
by RS for each primary multicast stream that has been requested by in the unicast burst RTP session by BRS for each primary multicast
RTP_Rx. In the RAMS-I messages, the media sender SSRC and packet stream that has been requested by RTP_Rx. In the RAMS-I messages,
sender SSRC fields are both set to the SSRC of the respective primary the media sender SSRC and packet sender SSRC fields are both set to
multicast stream. 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 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=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 8: FCI field syntax for the RAMS Information message
A RAMS-I message has the following fields: 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.
o Response (16 bits): Mandatory field that denotes the RS response o Response (16 bits): Mandatory field that denotes the 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 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: 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 BRS 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.
Type: 31 Type: 31
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 respective RTP stream. This allows RTP_Rx to know sent in the respective RTP stream. 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 BRS have been dropped at the
beginning of the stream. If RS accepts the RAMS request, this beginning of the stream. If BRS accepts the RAMS request, this
element MUST exist. If RS rejects the RAMS request, this element element MUST exist. If BRS rejects the RAMS request, this element
SHALL NOT exist. SHALL NOT exist.
Type: 32 Type: 32
o Earliest Multicast Join Time (32 bits): TLV element that o Earliest Multicast Join Time (32 bits): TLV element that
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, BRS 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 MUST be set to zero. In that case, the Response field, this field MUST be set to zero. In that case,
it is up to RTP_Rx when or whether to join the multicast session. it is up to RTP_Rx when or whether to join the multicast session.
It should be noted that when RS serves two or more bursts and It should be noted that when BRS 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
duration of the burst, i.e., the delta difference between the duration of the burst, i.e., the delta difference between the
first and the last burst packet, that RS is planning to send (in first and the last burst packet, that BRS is planning to send (in
ms) in the respective RTP stream. In the absence of additional ms) in the respective RTP stream. In the absence of additional
stimulus, RS will send a burst of this duration. However, the stimulus, BRS will send a burst of this duration. However, the
burst duration may be modified by subsequent events, including burst duration may be modified by subsequent events, including
changes in the primary multicast stream and reception of RAMS-T changes in the primary multicast stream and reception of RAMS-T
messages. messages.
Note that RS MUST terminate the flow in a deterministic timeframe, Note that BRS MUST terminate the flow in a deterministic
even if it does not get a RAMS-T or a BYE from RTP_Rx. It is timeframe, even if it does not get a RAMS-T or a BYE from RTP_Rx.
OPTIONAL to send this field in a RAMS-I message when the burst It is OPTIONAL to send this field in a RAMS-I message when the
request is accepted. If the burst request has been rejected as burst request is accepted. If the burst request has been rejected
indicated in the Response field, this field MAY be omitted or set as indicated in the Response field, this field MAY be omitted or
to zero. set to zero.
Type: 34 Type: 34
o Max Transmit Bitrate (64 bits): Optional TLV element that denotes o Max Transmit Bitrate (64 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 BRS
for the RTP stream associated with this RAMS-I message. for the RTP stream associated with this RAMS-I message.
Type: 35 Type: 35
The semantics of the RAMS-I feedback message is independent of the The semantics of the RAMS-I feedback message is independent of the
payload type. payload type.
The initial RAMS-I message SHOULD precede the unicast burst or be The initial RAMS-I message SHOULD precede the unicast burst or be
sent at the start of the burst. Subsequent RAMS-I message(s) MAY be sent at the start of the burst. Subsequent RAMS-I message(s) MAY be
sent during the unicast burst and convey changes in any of the sent during the unicast burst and convey changes in any of the
fields. fields.
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 RAMS Termination is used to assist RS in determining when to stop The RAMS Termination is used to assist BRS in determining when to
the burst. A separate RAMS-T message is sent by RTP_Rx for each stop the burst. A separate RAMS-T message is sent in the unicast
primary multicast stream that has been served by RS. Each of these burst RTP session by RTP_Rx for each primary multicast stream that
RAMS-T messages has the appropriate media sender SSRC populated in has been served by BRS. Each of these RAMS-T messages has the
its message header. appropriate media sender SSRC populated in its message header.
If RTP_Rx wants RS to stop a burst prematurely, it sends a plain If RTP_Rx wants BRS to stop a burst prematurely, it sends a plain
RAMS-T message as described below. Upon receiving this message, RS RAMS-T message as described below. Upon receiving this message, BRS
stops the respective burst immediately. If RTP_Rx wants RS to stops the respective burst immediately. If RTP_Rx wants BRS to
terminate all of the bursts, it should send all of the respective terminate all of the bursts, it should send all of the respective
RAMS-T messages in a single compound RTCP packet. RAMS-T messages in a single compound RTCP packet.
The default behavior for RTP_Rx is to send a RAMS-T message right The default behavior for RTP_Rx is to send a RAMS-T message
after it joined the multicast session and started receiving multicast immediately after it joined the multicast session and started
packets. In that case, RTP_Rx includes the sequence number of the receiving multicast packets. In that case, RTP_Rx includes the
first RTP packet received in the primary multicast stream in the sequence number of the first RTP packet received in the primary
RAMS-T message. With this information, RS can decide when to multicast stream in the RAMS-T message. With this information, BRS
terminate the unicast burst. can decide when to terminate the unicast burst.
The FCI field MUST contain only one RAMS Termination. The FCI field The FCI field MUST contain only one RAMS Termination. The FCI field
has the structure depicted in Figure 8. has the structure depicted in Figure 9.
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 | Reserved | | SFMT=3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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 9: 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
first packet received from the SSM session for a particular first packet received from the SSM session for a particular
primary multicast stream. The low 16 bits contain the sequence primary multicast stream. The low 16 bits contain the sequence
number of the first packet received from the SSM session, and the number of the first packet received from the SSM session, and the
most significant 16 bits extend that sequence number with the most significant 16 bits extend that sequence number with the
corresponding count of sequence number cycles, which may be corresponding count of sequence number cycles, which may be
maintained according to the algorithm in Appendix A.1 of maintained according to the algorithm in Appendix A.1 of
[RFC3550]. [RFC3550].
skipping to change at page 37, line 9 skipping to change at page 37, line 18
rtcp-fb-val = "nack" SP "rai" 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 'rai' stands for Rapid Acquisition Indication and indicates the o 'rai' stands for Rapid Acquisition Indication and 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 BRS supports updated request
or not. This attribute is used in a declarative manner. If RS messages or not. This attribute is used in a declarative manner and
supports updated request messages and this attribute is included in no Offer/Answer Model behavior is specified. If BRS supports updated
the SDP description, RTP_Rx may send updated requests. RS may or may request messages and this attribute is included in the SDP
not be able to accept value changes in every field in an updated description, RTP_Rx may send updated requests. BRS may or may not be
RAMS-R message. However, if the 'rams-updates' attribute is not able to accept value changes in every field in an updated RAMS-R
included in the SDP description, RTP_Rx SHALL NOT send updated message. However, if the 'rams-updates' attribute is not included in
requests (RTP_Rx MAY still repeat its initial request without the SDP description, RTP_Rx SHALL NOT send updated requests (RTP_Rx
changes, though). MAY still repeat its initial request without 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 framework and flow identification (FID) semantics o The SDP grouping framework and flow identification (FID) semantics
[I-D.ietf-mmusic-rfc3388bis] [I-D.ietf-mmusic-rfc3388bis]
o The RTP/AVPF profile [RFC4585] o The RTP/AVPF profile [RFC4585]
o The RTP retransmission payload format [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
[RFC5760] [RFC5760]
The support for the source-specific media attributes [RFC5576] may be o Multiplexing RTP and RTCP on a single port on both endpoints in
required in some deployments as described below. the unicast session[I-D.ietf-avt-rtp-and-rtcp-mux]
The support for the source-specific media attributes [RFC5576] and
multicast RTCP port attribute [I-D.begen-avt-rtcp-port-for-ssm] may
also be needed.
8.3. Example and Discussion 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.
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=rtpmap:98 MP2T/90000 a=rtpmap:98 MP2T/90000
a=rtcp:41001 IN IP4 192.0.2.1 a=multicast-rtcp:42000
a=rtcp:43000 IN IP4 192.0.2.1
a=rtcp-fb:98 nack a=rtcp-fb:98 nack
a=rtcp-fb:98 nack rai 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 51000 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-mux
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 a single-channel RAMS scenario Figure 10: Example SDP for a single-channel RAMS scenario
In this example SDP description, we have a primary multicast (source) In this example SDP description, we have a primary multicast (source)
stream and a unicast retransmission stream. The source stream is stream and a unicast retransmission stream. The source stream is
multicast from a distribution source (with a source IP address of 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 198.51.100.1) to the multicast destination address of 233.252.0.2 and
port 41000. Here, we are assuming that the multicast RTP and RTCP port 41000. The corresponding RTCP traffic is multicast to the same
ports are carefully chosen so that different RTP and RTCP streams do multicast destination address at port 42000. Here, we are assuming
not collide with each other. that the multicast RTP and RTCP ports are carefully chosen so that
different RTP and RTCP streams do not collide with each other.
The feedback target (FT_Ap) residing on the retransmission server 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 (with an address of 192.0.2.1) at port 43000 is declared with the
"a=rtcp" line [RFC3605]. The RTP receiver(s) can report missing "a=rtcp" line [RFC3605]. The support for the conventional
packets on the source stream to the feedback target and request retransmission is indicated through the "a=rtcp-fb:98 nack" line.
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 The RTP receiver(s) can report missing packets on the source stream
retransmission (through the "a=rtcp-fb:98 nack" line) and rapid to the feedback target and request retransmissions. Note that this
acquisition (through the "a=rtcp-fb:98 nack rai" line) is enabled. SDP includes the "a=sendonly" line for the media description of the
Note that this SDP includes the "a=sendonly" line for the media retransmission stream since the retransmissions are sent in only one
description of the retransmission stream. direction.
The support for rapid acquisition is indicated through the "a=rtcp-
fb:98 nack rai" line. The parameter 'rtx-time' applies to both the
conventional retransmissions and rapid acquisition. However, when
rapid acquisition is enabled, the standard definition for the
parameter 'rtx-time' given in [RFC4588] is not followed. Instead,
when rapid acquisition support is enabled, '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).
Once an RTP receiver has acquired an SDP description, it may ask for Once an RTP receiver has acquired an SDP description, it may ask for
rapid acquisition before it joins a primary multicast RTP session. 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 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 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 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 stream via an out-of-band method. If BRS accepts the rapid
acquisition request, it will send an RAMS-I message with the correct acquisition request, it will send an RAMS-I message with the correct
SSRC identifier. If FT_Ap is associated with a multi-stream RTP SSRC identifier. If FT_Ap is associated with a multi-stream RTP
session and the RTP receiver is willing to request rapid acquisition session and the RTP receiver is willing to request rapid acquisition
for the entire session, the RTP receiver again does not need to learn 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 the SSRCs via an out-of-band method. However, if the RTP receiver
intends to request a particular subset of the primary multicast intends to request a particular subset of the primary multicast
streams, it must learn their SSRC identifiers and list them in the 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 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 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 this case learn the SSRC value(s) from the 'ssrc' attribute of the
skipping to change at page 39, line 39 skipping to change at page 40, line 4
in the SDP file does not create a problem in SSM sessions when an 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 SSRC collision occurs. This is because in SSM sessions, an RTP
receiver that observed an SSRC collision with a media sender MUST receiver that observed an SSRC collision with a media sender MUST
change its own SSRC [RFC5760] by following the rules defined in change its own SSRC [RFC5760] by following the rules defined in
[RFC3550]. [RFC3550].
A feedback target that receives a RAMS-R feedback message becomes A feedback target that receives a RAMS-R feedback message becomes
aware that the prediction chain at the RTP receiver side has been aware that the prediction chain at the RTP receiver side has been
broken or does not exist anymore. If the necessary conditions are broken or does not exist anymore. If the necessary conditions are
satisfied (as outlined in Section 7 of [RFC4585]) and available satisfied (as outlined in Section 7 of [RFC4585]) and available
resources exist, RS may react to the RAMS-R message by sending any resources exist, BRS may react to the RAMS-R message by sending any
transport-layer (and optional payload-specific, when allowed) transport-layer (and optional payload-specific, when allowed)
feedback message(s) and starting the unicast burst. 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
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) may exist between RTP_Rx and RS. NATs have a variety of called NAT) may exist between RTP_Rx and RS. NATs have a variety of
operating characteristics for UDP traffic [RFC4787]. For a NAT to operating characteristics for UDP traffic [RFC4787]. For a NAT to
permit traffic from RS to arrive at RTP_Rx, the NAT(s) must first permit traffic from BRS to arrive at RTP_Rx, the NAT(s) must first
either: either:
a. See UDP traffic sent from RTP_Rx (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 BRS (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), RTP_Rx 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 BRS on that port. For
(a), RTP_Rx MUST send UDP traffic to keep the NAT binding alive, at (a), RTP_Rx MUST send UDP traffic to keep the NAT binding alive, at
least every 30 seconds [RFC4787]. Note that while (a) is more like least every 30 seconds [RFC4787]. Note that while (a) is more like
an automatic/dynamic configuration, (b) is more like a manual/static an automatic/dynamic configuration, (b) is more like a manual/static
configuration. configuration.
When RTP_Rx sends a RAMS-R message in the primary multicast RTP When RTP_Rx sends a RAMS-R message to FT as unicast feedback in the
session and the request is received by RS, a new unicast RTP primary multicast RTP session, and the request is received by FT, a
retransmission session will be established between RS and RTP_Rx. new unicast burst RTP session will be established between BRS and
RTP_Rx.
While the ports on the RS side are already signaled via out-of-band While the FT and BRS ports on RS are already signaled via out-of-band
means (e.g., SDP), RTP_Rx may need to convey to RS the RTP and RTCP means (e.g., SDP), RTP_Rx needs to convey the RTP and RTCP ports it
ports it wants to use on its side for the new session. Since there wants to use on its side for the new session. Since there are two
are two RTP sessions involved during this process and one of them is 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.ietf-avt-ports-for-ucast-mcast-rtp]. [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. This generic solution
implies the exchange of port mapping RTCP messages between RTP_Rx and
BRS.
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. The port mapping message exchange
needs to take place whenever RTP_Rx intends to make use of the RAMS
protocol for rapidly acquiring a specific multicast RTP session,
prior to joining the associated SSM session.
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 [RFC5760] and the payload format feedback mechanism described in [RFC5760], the payload format defined
defined in [RFC4588]. Thus, these applications are subject to the in [RFC4588] and the port mapping solution specified in
general security considerations discussed in [RFC5760] and [RFC4588]. [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Thus, these applications
are subject to the general security considerations discussed in
[RFC5760], [RFC4588] and [I-D.ietf-avt-ports-for-ucast-mcast-rtp].
In this section, we give an overview of the guidelines and In this section, we give an overview of the guidelines and
suggestions described in these specifications from a RAMS suggestions described in these specifications from a RAMS
perspective. We also discuss the security considerations that perspective. We also discuss the security 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
skipping to change at page 47, line 19 skipping to change at page 47, line 31
100 Parameter update for RAMS session [RFCXXXX] 100 Parameter update for RAMS session [RFCXXXX]
200 RAMS request has been accepted [RFCXXXX] 200 RAMS request has been accepted [RFCXXXX]
201 Unicast burst has been completed [RFCXXXX] 201 Unicast burst has been completed [RFCXXXX]
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 bitrate requirement in RAMS-R message [RFCXXXX] 403 Invalid max bitrate requirement in RAMS-R message [RFCXXXX]
500 An unspecified RS internal error has occurred [RFCXXXX] 500 An unspecified BRS internal error has occurred [RFCXXXX]
501 RS has no bandwidth to start RAMS session [RFCXXXX] 501 BRS has insufficient bandwidth to start RAMS
session [RFCXXXX]
502 Burst is terminated due to network congestion [RFCXXXX] 502 Burst is terminated due to network congestion [RFCXXXX]
503 RS has no CPU available to start RAMS session [RFCXXXX] 503 BRS has insufficient CPU cycles to start RAMS
504 RAMS functionality is not available on RS [RFCXXXX] session [RFCXXXX]
504 RAMS functionality is not available on BRS [RFCXXXX]
505 RAMS functionality is not available for RTP_Rx [RFCXXXX] 505 RAMS functionality is not available for RTP_Rx [RFCXXXX]
506 RAMS functionality is not available for 506 RAMS functionality is not available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
507 RS has no valid starting point available for 507 BRS has no valid starting point available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
508 RS has no reference information available for 508 BRS has no reference information available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
509 RS has no RTP stream matching the requested SSRC [RFCXXXX] 509 BRS has no RTP stream matching the requested SSRC [RFCXXXX]
510 RAMS request to acquire the entire session 510 RAMS request to acquire the entire session
has been denied [RFCXXXX] has been denied [RFCXXXX]
511 Only the preamble information is sent [RFCXXXX] 511 Only the preamble information is sent [RFCXXXX]
512 RAMS request has been denied due to a policy [RFCXXXX] 512 RAMS request has been denied due to a policy [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.
12. Contributors 12. Contributors
skipping to change at page 47, line 48 skipping to change at page 48, line 15
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.
12. Contributors 12. Contributors
Dave Oran and Magnus Westerlund have contributed significantly to Dave Oran, Magnus Westerlund and Colin Perkins have contributed
this specification by providing text and solutions to some of the significantly to this specification by providing text and solutions
issues raised during the development of this specification. to some of the 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, Jose Rey 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-08 14.1. draft-ietf-avt-rapid-acquisition-for-rtp-09
The following are the major changes compared to version 08:
o Further fixes and changes requested by Magnus W. and Colin P. have
been addressed throughout the document.
14.2. draft-ietf-avt-rapid-acquisition-for-rtp-08
The following are the major changes compared to version 07: The following are the major changes compared to version 07:
o Fixes and changes requested by Magnus W. and Jose R. have been o Fixes and changes requested by Magnus W. and Jose R. have been
addressed throuhout the document. addressed throughout the document.
o Some references have been updated. o Some references have been updated.
14.2. draft-ietf-avt-rapid-acquisition-for-rtp-07 14.3. 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.3. draft-ietf-avt-rapid-acquisition-for-rtp-06 14.4. 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.4. draft-ietf-avt-rapid-acquisition-for-rtp-05 14.5. 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.5. draft-ietf-avt-rapid-acquisition-for-rtp-04 14.6. 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.6. draft-ietf-avt-rapid-acquisition-for-rtp-03 14.7. 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.7. draft-ietf-avt-rapid-acquisition-for-rtp-02 14.8. 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.8. draft-ietf-avt-rapid-acquisition-for-rtp-01 14.9. 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.9. draft-ietf-avt-rapid-acquisition-for-rtp-00 14.10. 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.10. draft-versteeg-avt-rapid-synchronization-for-rtp-03 14.11. 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.11. draft-versteeg-avt-rapid-synchronization-for-rtp-02 14.12. 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.12. draft-versteeg-avt-rapid-synchronization-for-rtp-01 14.13. 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 32 skipping to change at page 53, line 5
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.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007.
[I-D.ietf-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-ietf-avt-ports-for-ucast-mcast-rtp-00 (work in draft-ietf-avt-ports-for-ucast-mcast-rtp-01 (work in
progress), February 2010. progress), April 2010.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[I-D.ietf-avt-dtls-srtp] [I-D.ietf-avt-dtls-srtp]
McGrew, D. and E. Rescorla, "Datagram Transport Layer McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)", Real-time Transport Protocol (SRTP)",
draft-ietf-avt-dtls-srtp-07 (work in progress), draft-ietf-avt-dtls-srtp-07 (work in progress),
skipping to change at page 53, line 19 skipping to change at page 53, line 46
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]
Begen, A. and E. Friedrich, "RTP Payload Format for
MPEG2-TS Preamble",
draft-begen-avt-rtp-mpeg2ts-preamble-04 (work in
progress), December 2009.
[I-D.ietf-avt-multicast-acq-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 RTP Control Protocol (RTCP) Extended Block Type for RTP Control Protocol (RTCP) Extended
Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-00 Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-00
(work in progress), February 2010. (work in progress), February 2010.
[I-D.begen-avt-rtp-cnames]
Begen, A. and C. Perkins, "Guidelines for Choosing an RTP
Control Protocol (RTCP) Canonical Name (CNAME) for Hosts
with Private IP Addresses", draft-begen-avt-rtp-cnames-00
(work in progress), April 2010.
[I-D.ietf-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-ietf-avt-ecn-for-rtp-00 (work in over UDP", draft-ietf-avt-ecn-for-rtp-01 (work in
progress), February 2010. progress), March 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.
[I-D.begen-avt-rtcp-port-for-ssm]
Begen, A., "RTP Control Protocol (RTCP) Port for Multicast
Sessions", draft-begen-avt-rtcp-port-for-ssm-01 (work in
progress), April 2010.
[I-D.ietf-dccp-rtp] [I-D.ietf-dccp-rtp]
Perkins, C., "RTP and the Datagram Congestion Control Perkins, C., "RTP and the Datagram Congestion Control
Protocol (DCCP)", draft-ietf-dccp-rtp-07 (work in Protocol (DCCP)", draft-ietf-dccp-rtp-07 (work in
progress), June 2007. progress), June 2007.
[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".
 End of changes. 177 change blocks. 
523 lines changed or deleted 573 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/