draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt   rfc6332.txt 
AVT A. Begen Internet Engineering Task Force (IETF) A. Begen
Internet-Draft E. Friedrich Request for Comments: 6332 E. Friedrich
Intended status: Standards Track Cisco Category: Standards Track Cisco
Expires: November 30, 2011 May 29, 2011 ISSN: 2070-1721 July 2011
Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Multicast Acquisition Report Block Type for
Extended Reports (XRs) RTP Control Protocol (RTCP) Extended Reports (XRs)
draft-ietf-avtext-multicast-acq-rtcp-xr-06
Abstract Abstract
In most RTP-based multicast applications, the RTP source sends inter- In most RTP-based multicast applications, the RTP source sends inter-
related data. Due to this interdependency, randomly joining RTP related data. Due to this interdependency, randomly joining RTP
receivers usually cannot start consuming the multicast data right receivers usually cannot start consuming the multicast data right
after they join the session. Thus, they often experience a random after they join the session. Thus, they often experience a random
acquisition delay. An RTP receiver can use one or more different acquisition delay. An RTP receiver can use one or more different
approaches to achieve rapid acquisition. Yet, due to various approaches to achieve rapid acquisition. Yet, due to various
factors, performance of the rapid acquisition methods usually varies. factors, performance of the rapid acquisition methods usually varies.
Furthermore, in some cases the RTP receiver can do a simple multicast Furthermore, in some cases, the RTP receiver can do a simple
join (in other cases it is compelled to do so). For quality multicast join (in other cases, it is compelled to do so). For
reporting, monitoring and diagnostics purposes, it is important to quality reporting, monitoring, and diagnostic purposes, it is
collect detailed information from the RTP receivers about their important to collect detailed information from the RTP receivers
acquisition and presentation experiences. This document addresses about their acquisition and presentation experiences. This document
this issue by defining a new report block type, called Multicast addresses this issue by defining a new report block type, called the
Acquisition (MA) Report Block, within the framework of RTP Control Multicast Acquisition (MA) report block, within the framework of RTP
Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also Control Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This
defines the necessary signaling of the new MA report block type in document also defines the necessary signaling of the new MA report
the Session Description Protocol (SDP). block type in the Session Description Protocol (SDP).
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on November 30, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6332.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 21 skipping to change at page 2, line 24
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Multicast Acquisition (MA) Report Block . . . . . . . . . . . 6 4. Multicast Acquisition (MA) Report Block . . . . . . . . . . . 4
4.1. Base Report . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Base Report . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Status Code Rules for New MA Methods . . . . . . . . . 8 4.1.1. Status Code Rules for New MA Methods . . . . . . . . . 6
4.1.2. Status Code Rules for the RAMS Method . . . . . . . . 8 4.1.2. Status Code Rules for the RAMS Method . . . . . . . . 6
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 9 4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 7
4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 12 4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 10
5. Session Description Protocol Signaling . . . . . . . . . . . . 13 5. Session Description Protocol Signaling . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 15 7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 11
7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 15 7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 12
7.3. Multicast Acquisition Method Registry . . . . . . . . . . 15 7.3. Multicast Acquisition Method Registry . . . . . . . . . . 12
7.4. Multicast Acquisition Report Block TLV Space Registry . . 16 7.4. Multicast Acquisition Report Block TLV Space Registry . . 12
7.5. Multicast Acquisition Status Code Space Registry . . . . . 17 7.5. Multicast Acquisition Status Code Space Registry . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
RTP Control Protocol (RTCP) is the out-of-band control protocol for The RTP Control Protocol (RTCP) is the out-of-band control protocol
the applications that are using the Real-time Transport Protocol for applications that use the Real-time Transport Protocol (RTP) for
(RTP) for media transport [RFC3550]. In addition to providing media transport [RFC3550]. In addition to providing minimal control
minimal control functionality to RTP entities, RTCP also enables a functionality to RTP entities, RTCP also enables a basic-level
basic level monitoring of RTP sessions via sender and receiver monitoring of RTP sessions via sender and receiver reports. More
reports. More statistically detailed monitoring as well as statistically detailed monitoring as well as application-specific
application-specific monitoring is usually achieved through the RTCP monitoring are usually achieved through the RTCP Extended Reports
Extended Reports (XRs) [RFC3611]. (XRs) [RFC3611].
In most RTP-based multicast applications such as the ones carrying In most RTP-based multicast applications such as the ones carrying
video content, the RTP source sends inter-related data. video content, the RTP source sends inter-related data.
Consequently, the RTP application may not be able to decode and Consequently, the RTP application may not be able to decode and
present the data in an RTP packet before decoding one or more earlier present the data in an RTP packet before decoding the data in one or
RTP packets and/or before acquiring some Reference Information about more earlier RTP packets and/or before acquiring some Reference
the content itself. Thus, RTP receivers that are randomly joining a Information about the content itself. Thus, RTP receivers that are
multicast session often experience a random acquisition delay. In randomly joining a multicast session often experience a random
order to reduce this delay, [I-D.ietf-avt-rapid-acquisition-for-rtp] acquisition delay. In order to reduce this delay, [RFC6285] proposes
proposes an approach where an auxiliary unicast RTP session is an approach where an auxiliary unicast RTP session is established
established between a retransmission server and the joining RTP between a retransmission server and the joining RTP receiver. Over
receiver. Over this unicast RTP session, the retransmission server this unicast RTP session, the retransmission server provides the
provides the Reference Information, which is all the information the Reference Information, which is all the information the RTP receiver
RTP receiver needs to rapidly acquire the multicast stream. This needs to rapidly acquire the multicast stream. This method is
method is referred to as the Rapid Acquisition of Multicast Sessions referred to as the Rapid Acquisition of Multicast RTP Sessions
(RAMS). However, depending on the variability in the Source (RAMS). However, depending on the variability in the Source
Filtering Group Management Protocol (SFGMP) processing times, Filtering Group Management Protocol (SFGMP) processing times, the
availability of network resources for rapid acquisition and nature of availability of network resources for rapid acquisition, and the
the RTP data, not all RTP receivers can acquire the multicast stream nature of the RTP data, not all RTP receivers can acquire the
in the same amount of time. The performance of rapid acquisition may multicast stream in the same amount of time. The performance of
vary not only for different RTP receivers but also over time. rapid acquisition may vary not only for different RTP receivers but
also over time.
To increase the visibility of the multicast service provider into its To increase the visibility of the multicast service provider in its
network, to diagnose slow multicast acquisition issues and to collect network, to diagnose slow multicast acquisition issues, and to
the acquisition experiences of the RTP receivers, this document collect the acquisition experiences of the RTP receivers, this
defines a new report block type, which is called Multicast document defines a new report block type, which is called the
Acquisition (MA) Report Block, within the framework of RTCP XR. RTP Multicast Acquisition (MA) report block, within the framework of RTCP
receivers that are using the method described in XR. RTP receivers that use the method described in [RFC6285] may use
[I-D.ietf-avt-rapid-acquisition-for-rtp] may use this report every this report every time they join a new multicast RTP session. RTP
time they join a new multicast RTP session. RTP receivers that use a receivers that use a different method for rapid acquisition or those
different method for rapid acquisition or those do not use any method that do not use any method but rather do a simple multicast join may
but rather do a simple multicast join may also use this report to also use this report. This way, the multicast service provider can
collect information. This way, the multicast service provider can
quantitatively compare the improvements achieved by different quantitatively compare the improvements achieved by different
methods. methods.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Definitions 3. Definitions
This document uses the acronyms and definitions from Section 3 of This document uses the acronyms and definitions from Section 3 of
[I-D.ietf-avt-rapid-acquisition-for-rtp]. [RFC6285].
4. Multicast Acquisition (MA) Report Block 4. Multicast Acquisition (MA) Report Block
This section defines the format of the MA report block. The base This section defines the format of the MA report block. The base
report is payload-independent. An extension mechanism is provided report is payload independent. An extension mechanism is provided
where further optional payload-independent and payload-specific where further optional payload-independent and payload-specific
information can be included in the report as desired. information can be included in the report as desired.
The OPTIONAL extensions that are defined in this document are The OPTIONAL extensions that are defined in this document are
primarily developed for the method presented in primarily developed for the method presented in [RFC6285]. Other
[I-D.ietf-avt-rapid-acquisition-for-rtp]. Other methods that provide methods that provide rapid acquisition can define their own
rapid acquisition can define their own extensions to be used in the extensions to be used in the MA report block.
MA report block.
The packet format for the RTCP XR is defined in Section 2 of The packet format for the RTCP XR is defined in Section 2 of
[RFC3611]. Each XR packet has a fixed-length field for version, [RFC3611]. Each XR packet has a fixed-length field for version,
padding, reserved bits, payload type (PT), length, SSRC of packet padding, reserved bits, payload type (PT), length, synchronization
sender as well as a variable-length field for report blocks. In the source (SSRC) of packet sender as well as a variable-length field for
XR packets, the PT field is set to XR (207). report blocks. In the XR packets, the PT field is set to XR (207).
It is better to send the MA report block after all the necessary It is better to send the MA report block after all the necessary
information is collected and computed. Partial reporting is information is collected and computed. Partial reporting is
generally not useful as it cannot give the full picture of the generally not useful as it cannot give the full picture of the
multicast acquisition, and causes additional complexity in terms of multicast acquisition, and it causes additional complexity in terms
report block matching and correlation. The MA report block is only of report block matching and correlation. The MA report block is
sent as a part of an RTCP compound packet, and it is sent in the only sent as a part of an RTCP compound packet, and it is sent in the
primary multicast session. primary multicast session.
The need for reliability of the MA report block is not any greater The need for reliability of the MA report block is not any greater
than other report blocks or types. If desired, the report block than other report blocks or types. If desired, the report block
could be repeated for redundancy purposes while respecting to the could be repeated for redundancy purposes while respecting the RTCP
RTCP scheduling algorithms. scheduling algorithms.
Following the rules specified in [RFC3550], all integer fields in the Following the rules specified in [RFC3550], all integer fields in the
base report and extensions defined below are carried in network-byte base report and extensions defined below are carried in network-byte
order, that is, most significant byte (octet) first, also known as order, that is, most significant byte (octet) first, also known as
big-endian. Unless otherwise stated, numeric constants are in big-endian. Unless otherwise stated, numeric constants are in
decimal (base 10). decimal (base 10).
4.1. Base Report 4.1. Base Report
The base report format is shown in Figure 1. The base report format is shown in Figure 1.
skipping to change at page 7, line 15 skipping to change at page 5, line 19
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=11 | MA Method | Block Length | | BT=11 | MA Method | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of the Primary Multicast Stream | | SSRC of the Primary Multicast Stream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Rsvd. | | Status | Rsvd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Base report format for the MA report block Figure 1: Base Report Format for the MA Report Block
o BT (8 bits): Field that denotes the type for this block format. o BT (8 bits): Field that denotes the type for this block format.
The MA report block is identified by the constant 11. The MA report block is identified by the constant 11.
o MA Method (8 bits): Field that denotes the type of the MA method o MA Method (8 bits): Field that denotes the type of the MA method
(e.g., simple join, RAMS, etc.). See Section 7.3 for the values (e.g., simple join, RAMS, etc.). See Section 7.3 for the values
registered with IANA. registered with IANA.
o Block Length (16 bits): The length of this report block, o Block Length (16 bits): The length of this report block, including
including the header, in 32-bit words minus one. the header, in 32-bit words minus one.
o SSRC of the Primary Multicast Stream (32 bits): Field that o SSRC of the Primary Multicast Stream (32 bits): Field that denotes
denotes the SSRC of the primary multicast stream. the SSRC of the primary multicast stream.
o Status (16 bits): Field that denotes the status code for the MA o Status (16 bits): Field that denotes the status code for the MA
operation. operation.
This document defines several status codes and registers them with This document defines several status codes and registers them with
IANA in Section 7.5. If a new vendor-neutral status code will be IANA in Section 7.5. If a new vendor-neutral status code will be
defined, it MUST be registered with IANA through the guidelines defined, it MUST be registered with IANA according to the
specified in Section 7.5. If the new status code is intended to guidelines specified in Section 7.5. If the new status code is
be used privately by a vendor, there is no need for IANA intended to be used privately by a vendor, there is no need for
management. Section 4.2.2 defines how a vendor defines and uses IANA management. Section 4.2.2 defines how a vendor defines and
private extensions to convey its messages. uses private extensions to convey its messages.
To indicate use of a private extension, the RTP receiver MUST set To indicate use of a private extension, the RTP receiver MUST set
the Status field to zero. A private extension MUST NOT be used in the Status field to zero. A private extension MUST NOT be used in
an XR report unless the RTP receiver knows from out-of-band an XR unless the RTP receiver knows from out-of-band methods that
methods that the entity that will receive and process the XR the entity that will receive and process the XR understands the
report understands the private extension. private extension.
o Rsvd. (16 bits): The RTP receiver MUST set this field to zero. o Rsvd. (16 bits): The RTP receiver MUST set this field to zero.
The recipient MUST ignore this field when received. The recipient MUST ignore this field when received.
If the multicast join was successful meaning that at least one If the multicast join was successful, meaning that at least one
multicast packet has been received, some additional information MUST multicast packet was received, some additional information MUST be
be appended to the base report as will be described in Section 4.2.1. appended to the base report as described in Section 4.2.1.
4.1.1. Status Code Rules for New MA Methods 4.1.1. Status Code Rules for New MA Methods
Different MA methods usually use different status codes, although Different MA methods usually use different status codes, although
some status codes (e.g., a code indicating that multicast join has some status codes (e.g., a code indicating that multicast join has
failed) can be common among multiple MA methods. The status code failed) can be common among multiple MA methods. The status code
reported in the base report MUST always be within the scope of the reported in the base report MUST always be within the scope of the
particular MA method specified in the MA Method field. particular MA method specified in the MA Method field.
In certain MA methods, the RTP receiver can generate a status code In certain MA methods, the RTP receiver can generate a status code
for its multicast acquisition attempt, or can be told by another for its multicast acquisition attempt or can be told by another
network element or RTP endpoint what the current status is via a network element or RTP endpoint what the current status is via a
response code. In such cases, the RTP receiver MAY report the value response code. In such cases, the RTP receiver MAY report the value
of the received response code as its status code if the response code of the received response code as its status code if the response code
has a higher priority. Each MA method needs to outline the rules has a higher priority. Each MA method needs to outline the rules
pertaining to its response and status codes so that RTP receiver pertaining to its response and status codes so that RTP receiver
implementations can determine what to report in any given scenario. implementations can determine what to report in any given scenario.
4.1.2. Status Code Rules for the RAMS Method 4.1.2. Status Code Rules for the RAMS Method
In this section, we provide the status code rules for the RAMS method In this section, we provide the status code rules for the RAMS method
described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. described in [RFC6285].
Section 11.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines Section 11.6 of [RFC6285] defines several response codes. The 1xx-
several response codes. The 1xx and 2xx-level response codes are and 2xx-level response codes are informational and success response
informational and success response codes, respectively. If the RTP codes, respectively. If the RTP receiver receives a 1xx- or 2xx-
receiver receives a 1xx or 2xx-level response code, then the RTP level response code, then the RTP receiver MUST use one of the 1xxx-
receiver MUST use one of the 1xxx-level status codes defined in level status codes defined in Section 7.5 of this document. If the
Section 7.5 of this document. If the RTP receiver receives a 4xx or RTP receiver receives a 4xx- or 5xx-level response code (indicating
5xx-level response code (indicating receiver-side and server-side receiver-side and server-side errors, respectively), then the RTP
errors, respectively), then the RTP receiver MUST use the response receiver MUST use the response code as its status code. In other
code as its status code. In other words, the 4xx and 5xx-level words, the 4xx- and 5xx-level response codes have a higher priority
response codes have a higher priority than the 1xxx-level status than the 1xxx-level status codes.
codes.
4.2. Extensions 4.2. Extensions
To improve the reporting scope, it might be desirable to define new To improve the reporting scope, it might be desirable to define new
fields in the MA report block. Such fields are to be encoded as TLV fields in the MA report block. Such fields are to be encoded as TLV
elements as described below and sketched in Figure 2: elements as described below and sketched in Figure 2:
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
of the TLV element excluding the Type and Length fields, and the the TLV element excluding the Type and Length fields and the 8-bit
8-bit Reserved field between them. Note that this length does not Reserved field between them. Note that this length does not
include any padding that is needed for alignment. include any padding that is needed 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 MUST be set to zero and ignored In the extensions, the Reserved field MUST be set to zero and ignored
on reception. If a TLV element does not fall on a 32-bit boundary, on reception. 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 the last word MUST be padded to the boundary using further bits set
to zero. to zero.
In the MA report block, the RTP receiver MUST place any vendor- In the MA report block, the RTP receiver MUST place any vendor-
neutral or private extension after the base report. neutral or private extension after the base report.
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 2: Structure of a TLV element Figure 2: Structure of a TLV Element
4.2.1. Vendor-Neutral Extensions 4.2.1. Vendor-Neutral Extensions
If the goal in defining new TLV elements is to extend the report If the goal in defining new TLV elements is to extend the report
block in a vendor-neutral manner, they need to be registered with block in a vendor-neutral manner, they need to be registered with
IANA through the guidelines provided in Section 7.4. IANA according to the guidelines provided in Section 7.4.
The current document defines several vendor-neutral extensions. This document defines several vendor-neutral extensions. First, we
First, we present the TLV elements that can be used by any RTP-based present the TLV elements that can be used by any RTP-based multicast
multicast application. application.
o RTP Seqnum of the First Multicast Packet (16 bits): TLV element o RTP Seqnum of the First Multicast Packet (16 bits): TLV element
that specifies the RTP sequence number of the first multicast that specifies the RTP sequence number of the first multicast
packet received for the primary multicast stream. If the packet received for the primary multicast stream. If the
multicast join was successful, this element MUST be included. If multicast join was successful, this element MUST be included. If
no multicast packet has been received, this element MUST NOT exist no multicast packet has been received, this element MUST NOT exist
in the report block. in the report block.
Type: 1 Type: 1
o SFGMP Join Time (32 bits): TLV element that denotes the greater o SFGMP Join Time (32 bits): TLV element that denotes the greater of
of zero or the time difference (in ms) between the instant SFGMP zero or the time difference (in ms) between the instant the SFGMP
Join message has been sent and the instant the first packet was Join message was sent and the instant the first packet was
received in the multicast session. If the multicast join was received in the multicast session. If the multicast join was
successful, this element MUST be included. If no multicast packet successful, this element MUST be included. If no multicast packet
has been received, this element MUST NOT exist in the report has been received, this element MUST NOT exist in the report
block. block.
Type: 2 Type: 2
o Application Request-to-Multicast Delta Time (32 bits): OPTIONAL o Application Request-to-Multicast Delta Time (32 bits): OPTIONAL
TLV element that denotes the time difference (in ms) between the TLV element that denotes the time difference (in ms) between the
instant the application became aware it would join a new multicast instant the application became aware it would join a new multicast
session and the instant the first RTP packet was received from the session and the instant the first RTP packet was received from the
primary multicast stream. If no such packet has been received, primary multicast stream. If no such packet has been received,
this element MUST NOT exist in the report block. this element MUST NOT exist in the report block.
Type: 3 Type: 3
o Application Request-to-Presentation Delta Time (32 bits): o Application Request-to-Presentation Delta Time (32 bits): OPTIONAL
OPTIONAL TLV element that denotes the time difference (in ms) TLV element that denotes the time difference (in ms) between the
between the instant the application became aware it would join a instant the application became aware it would join a new multicast
new multicast session and the instant the media is first session and the instant the media was first presented. If the RTP
presented. If the RTP receiver cannot successfully present the receiver cannot successfully present the media, this element MUST
media, this element MUST NOT exist in the report block. NOT exist in the report block.
Type: 4 Type: 4
We next present the TLV elements that can be used when the RTP We next present the TLV elements that can be used when the RTP
receiver supports and uses the RAMS method described in receiver supports and uses the RAMS method described in [RFC6285].
[I-D.ietf-avt-rapid-acquisition-for-rtp]. However, if the RTP However, if the RTP receiver does not send a rapid acquisition
receiver does not send a rapid acquisition request, the following TLV request, the following TLV elements MUST NOT exist in the MA report
elements MUST NOT exist in the MA report block. Some elements may or block. Some elements may or may not exist depending on whether or
may not exist depending on whether the RTP receiver receives any not the RTP receiver receives any packet from the unicast burst
packet from the unicast burst and/or the primary multicast stream or and/or the primary multicast stream. These are explained below.
not. These are explained below.
o Application Request-to-RAMS Request Delta Time (32 bits): o Application Request-to-RAMS Request Delta Time (32 bits): OPTIONAL
OPTIONAL TLV element that denotes the time difference (in ms) TLV element that denotes the time difference (in ms) between the
between the instant the application became aware it would request instant the application became aware it would request a rapid
a rapid acquisition and the instant the rapid acquisition request acquisition and the instant the rapid acquisition request was
was actually sent by the application. actually sent by the application.
Type: 11 Type: 11
o RAMS Request-to-RAMS Information Delta Time (32 bits): OPTIONAL o RAMS Request-to-RAMS Information Delta Time (32 bits): OPTIONAL
TLV element that denotes the time difference (in ms) between the TLV element that denotes the time difference (in ms) between the
instant the rapid acquisition request has been sent and the instant the rapid acquisition request was sent and the instant the
instant the first RAMS Information message was received in the first RAMS Information message was received in the unicast
unicast session. If no such message has been received, this session. If no such message has been received, this element MUST
element MUST NOT exist in the report block. NOT exist in the report block.
Type: 12 Type: 12
o RAMS Request-to-Burst Delta Time (32 bits): OPTIONAL TLV element o RAMS Request-to-Burst Delta Time (32 bits): OPTIONAL TLV element
that denotes the time difference (in ms) between the instant the that denotes the time difference (in ms) between the instant the
rapid acquisition request has been sent and the instant the first rapid acquisition request was sent and the instant the first burst
burst packet was received in the unicast session. If no burst packet was received in the unicast session. If no burst packet
packet has been received, this element MUST NOT exist in the has been received, this element MUST NOT exist in the report
report block. block.
Type: 13 Type: 13
o RAMS Request-to-Multicast Delta Time (32 bits): OPTIONAL TLV o RAMS Request-to-Multicast Delta Time (32 bits): OPTIONAL TLV
element that denotes the time difference (in ms) between the element that denotes the time difference (in ms) between the
instant the rapid acquisition request has been sent and the instant the rapid acquisition request was sent and the instant the
instant the first RTP packet was received from the primary first RTP packet was received from the primary multicast stream.
multicast stream. If no such packet has been received, this If no such packet has been received, this element MUST NOT exist
element MUST NOT exist in the report block. in the report block.
Type: 14 Type: 14
o RAMS Request-to-Burst-Completion Delta Time (32 bits): OPTIONAL o RAMS Request-to-Burst-Completion Delta Time (32 bits): OPTIONAL
TLV element that denotes the time difference (in ms) between the TLV element that denotes the time difference (in ms) between the
instant the rapid acquisition request has been sent and the instant the rapid acquisition request was sent and the instant the
instant the last burst packet was received in the unicast session. last burst packet was received in the unicast session. If no
If no burst packet has been received, this element MUST NOT exist burst packet has been received, this element MUST NOT exist in the
in the report block. report block.
Type: 15 Type: 15
o Number of Duplicate Packets (32 bits): OPTIONAL TLV element that o Number of Duplicate Packets (32 bits): OPTIONAL TLV element that
denotes the number of duplicate packets due to receiving the same denotes the number of duplicate packets due to receiving the same
packet in both unicast and primary multicast RTP sessions. If no packet in both unicast and primary multicast RTP sessions. If no
RTP packet has been received from the primary multicast stream, RTP packet has been received from the primary multicast stream,
this element MUST NOT exist. If no burst packet has been received this element MUST NOT exist. If no burst packet has been received
in the unicast session, the value of this element MUST be set to in the unicast session, the value of this element MUST be set to
zero. zero.
Type: 16 Type: 16
o Size of Burst-to-Multicast Gap (32 bits): OPTIONAL TLV element o Size of Burst-to-Multicast Gap (32 bits): OPTIONAL TLV element
that denotes the greater of zero or the difference between the that denotes the greater of zero or the difference between the
sequence number of the first multicast packet (received from the sequence number of the first multicast packet (received from the
primary multicast stream) and the sequence number of the last primary multicast stream) and the sequence number of the last
burst packet minus 1 (considering the wrapping of the sequence burst packet minus 1 (considering the wrapping of the sequence
numbers). If no burst packet has been received in the unicast numbers). If no burst packet has been received in the unicast
session or no RTP packet has been received from the primary session or no RTP packet has been received from the primary
multicast stream, this element MUST NOT exist in the report block. multicast stream, this element MUST NOT exist in the report block.
Type: 17 Type: 17
4.2.2. Private Extensions 4.2.2. Private Extensions
It is desirable to allow vendors to use private extensions in TLV It is desirable to allow vendors to use private extensions in TLV
format. The range of [128-254] of TLV Types is reserved for private format. The range of [128-254] of TLV Types is reserved for private
extensions. IANA management for these extensions is unnecessary and extensions. IANA management for these extensions is unnecessary;
they are the responsibility of individual vendors. they are the responsibility of individual vendors.
Implementations use the structure depicted in Figure 3 for the Implementations use the structure depicted in Figure 3 for private
private extensions. Here, the private enterprise numbers are used extensions. Here, the private enterprise numbers are used from
from http://www.iana.org/assignments/enterprise-numbers. This will http://www.iana.org. This will ensure the uniqueness of the private
ensure the uniqueness of the private extensions and avoid any extensions and avoid any collision.
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 3: Structure of a private extension Figure 3: Structure of a Private Extension
5. Session Description Protocol Signaling 5. Session Description Protocol Signaling
A new unilateral parameter is defined for the MA report block to be A new unilateral parameter is defined for the MA report block to be
used with the Session Description Protocol (SDP) [RFC4566] using the used with the Session Description Protocol (SDP) [RFC4566]. In the
Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the following following ABNF [RFC5234], xr-format is used as defined in [RFC3611].
syntax within the 'rtcp-xr' attribute [RFC3611]:
xr-format = <See RFC 3611>
xr-format /= multicast-acq-ext
multicast-acq-ext = "multicast-acq" xr-format =/ multicast-acq-ext
multicast-acq-ext = "multicast-acq"
Refer to Section 5.1 of [RFC3611] for a detailed description and the Refer to Section 5.1 of [RFC3611] for a detailed description and the
full syntax of the "rtcp-xr" attribute. The "multicast-acq-ext" full syntax of the 'rtcp-xr' attribute.
parameter is compatible with the definition of "format-ext" in the
"rtcp-xr" attribute.
6. Security Considerations 6. Security Considerations
The security considerations of [RFC3611] apply in this document as The security considerations of [RFC3611] apply in this document as
well. well.
The information contained in MA reports could be stolen as any other The information contained in MA reports could be stolen as with any
RTCP reports if proper protection mechanism(s) are not in place. If other RTCP reports if proper protection mechanism(s) are not in
desired, similar to other RTCP XR reports, the MA reports MAY be place. If desired, similar to other RTCP XRs, the MA reports MAY be
protected by using Secure RTP (SRTP) and Secure RTP Control Protocol protected by using Secure RTP (SRTP) and Secure RTP Control Protocol
(SRTCP) [RFC3711]. (SRTCP) [RFC3711].
Malicious sniffing or otherwise obtaining MA report blocks can reveal Malicious sniffing or otherwise obtaining MA report blocks can reveal
performance characteristics of the RTP service and underlying performance characteristics of the RTP service and underlying
network. This information is mostly available to an observer with network. This information is mostly available to an observer with
the ability to capture RTP and RTCP session traffic. The contents the ability to capture RTP and RTCP session traffic. The contents
and value of any private extensions need to be studied when and value of any private extension need to be studied when
considering the necessity to secure the MA reports since application- considering the necessity to secure the MA reports since application-
level performance data might be present that is not otherwise level performance data might be present that is not otherwise
available to an attacker as with the required fields and vendor- available to an attacker, as with the required fields and vendor-
neutral extensions. neutral extensions.
Using the MA reports to provide feedback into the acquisition of the Using the MA reports to provide feedback into the acquisition of the
multicast streams can introduce possible additional security multicast streams can introduce possible additional security
implications. If a forged or otherwise modified MA report is implications. If a forged or otherwise modified MA report is
received for an earlier acquisition attempt, invalid data can be used received for an earlier acquisition attempt, invalid data can be used
as input in later rapid acquisition attempts. For example, as input in later rapid acquisition attempts. For example,
incorrectly small SFGMP join times could cause the unicast burst to incorrectly small SFGMP join times could cause the unicast burst to
be too short, leading to gaps in sequence numbers in the approach be too short, leading to gaps in sequence numbers in the approach
discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Additionally, discussed in [RFC6285]. Additionally, forged reports could give the
forged reports could give the appearance that rapid acquisition is appearance that rapid acquisition is performing correctly when it is
performing correctly, when it is in fact failing, or vice versa. in fact failing, or vice versa. While integrity protection can be
While integrity protection can be achieved through different ways, we achieved in different ways, we RECOMMEND the use of SRTCP [RFC3711].
RECOMMEND the use of SRTCP [RFC3711].
7. IANA Considerations 7. IANA Considerations
The following contact information is provided for all registrations The following contact information is provided for all registrations
in this document: in this document:
Ali Begen Ali Begen
abegen@cisco.com abegen@cisco.com
Note to the RFC Editor: In the following, please replace "XXXX" with
the number of this document prior to publication as an RFC.
7.1. RTCP XR Block Type 7.1. RTCP XR Block Type
Note to IANA: Type value 11 has been pre-registered with IANA for Type value 11 has been registered with IANA for the "Multicast
the "Multicast Acquisition Report Block" in the RTCP XR Block Type Acquisition Report Block" in the RTCP XR Block Type Registry.
Registry. Please replace the existing reference with the RFC number
of this document.
7.2. RTCP XR SDP Parameter 7.2. RTCP XR SDP Parameter
This document registers the SDP [RFC4566] parameter 'multicast-acq' The SDP [RFC4566] parameter 'multicast-acq' for the 'rtcp-xr'
for the 'rtcp-xr' attribute in the RTCP XR SDP Parameters Registry. attribute has been registered in the RTCP XR SDP Parameters Registry.
7.3. Multicast Acquisition Method Registry 7.3. Multicast Acquisition Method Registry
This document creates a new IANA registry for the MA methods. The A new IANA registry for the MA methods has been created. The
registry is called the Multicast Acquisition Method Registry. This registry is called the "Multicast Acquisition Method Registry". This
registry is to be managed by the IANA according to the Specification registry is to be managed by IANA according to the Specification
Required policy of [RFC5226]. Required policy of [RFC5226].
The length of the MA Method field is a single octet, allowing 256 The length of the MA Method field is a single octet, allowing 256
values. The registry is initialized with the following entries: values. The registry is initialized with the following entries:
MA Method Description Reference MA Method Description Reference
--------- ------------------------------------ ------------- --------- ------------------------------------ -------------
0 Reserved [RFCXXXX] 0 Reserved [RFC6332]
1 Simple join (No explicit method) [RFCXXXX] 1 Simple join (No explicit method) [RFC6332]
2 RAMS [I-D.ietf-avt-rapid-acquisition-for-rtp] 2 RAMS [RFC6285]
3-254 Specification Required 3-254 Unassigned Specification Required
255 Reserved [RFCXXXX] 255 Reserved [RFC6332]
The MA Method values 0 and 255 are reserved for future use. The MA Method values 0 and 255 are reserved for future use.
Any registration for an unassigned value needs to contain the Any registration for an unassigned value needs to 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 how the MA method works. o A detailed description of how the MA method works.
7.4. Multicast Acquisition Report Block TLV Space Registry 7.4. Multicast Acquisition Report Block TLV Space Registry
This document creates a new IANA TLV space registry for the MA report A new IANA TLV space registry for the MA report block extensions has
block extensions. The registry is called the Multicast Acquisition been created. The registry is called the "Multicast Acquisition
Report Block TLV Space Registry. This registry is to be managed by Report Block TLV Space Registry". This registry is to be managed by
the IANA according to the Specification Required policy of [RFC5226]. the IANA according to the Specification Required policy of [RFC5226].
The length of the Type field in the TLV elements is a single octet, The length of the Type field in the TLV elements is a single octet,
allowing 256 values. The registry is initialized with the following allowing 256 values. The registry is initialized with the following
entries: entries:
Type Description Reference Type Description Reference
------- -------------------------------------------------- --------- ------- -------------------------------------------------- ---------
0 Reserved [RFCXXXX] 0 Reserved [RFC6332]
1 RTP Seqnum of the First Multicast Packet [RFCXXXX] 1 RTP Seqnum of the First Multicast Packet [RFC6332]
2 SFGMP Join Time [RFCXXXX] 2 SFGMP Join Time [RFC6332]
3 Application Request-to-Multicast Delta Time [RFCXXXX] 3 Application Request-to-Multicast Delta Time [RFC6332]
4 Application Request-to-Presentation Delta Time [RFCXXXX] 4 Application Request-to-Presentation Delta Time [RFC6332]
11 Application Request-to-RAMS Request Delta Time [RFCXXXX] 5-10 Unassigned Specification Required
12 RAMS Request-to-RAMS Information Delta Time [RFCXXXX] 11 Application Request-to-RAMS Request Delta Time [RFC6332]
13 RAMS Request-to-Burst Delta Time [RFCXXXX] 12 RAMS Request-to-RAMS Information Delta Time [RFC6332]
14 RAMS Request-to-Multicast Delta Time [RFCXXXX] 13 RAMS Request-to-Burst Delta Time [RFC6332]
15 RAMS Request-to-Burst-Completion Delta Time [RFCXXXX] 14 RAMS Request-to-Multicast Delta Time [RFC6332]
16 Number of Duplicate Packets [RFCXXXX] 15 RAMS Request-to-Burst-Completion Delta Time [RFC6332]
17 Size of Burst-to-Multicast Gap [RFCXXXX] 16 Number of Duplicate Packets [RFC6332]
18-127 Specification Required 17 Size of Burst-to-Multicast Gap [RFC6332]
128-254 Reserved for private extensions [RFCXXXX] 18-127 Unassigned Specification Required
255 Reserved [RFCXXXX] 128-254 Reserved for private extensions [RFC6332]
255 Reserved [RFC6332]
The Type values 0 and 255 are reserved for future use. The Type The Type values 0 and 255 are reserved for future use. The Type
values between (and including) 128 and 254 are reserved for private values between (and including) 128 and 254 are reserved for private
extensions. extensions.
Any registration for an unassigned Type value needs to contain the Any registration for an unassigned Type value needs to contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new TLV element represents and o A detailed description of what the new TLV element represents and
how it is interpreted. how it is interpreted.
7.5. Multicast Acquisition Status Code Space Registry 7.5. Multicast Acquisition Status Code Space Registry
This document creates a new IANA TLV space registry for the status A new IANA TLV space registry for the status codes has been created.
codes. The registry is called the Multicast Acquisition Status Code The registry is called the "Multicast Acquisition Status Code Space
Space Registry. This registry is to be managed by the IANA according Registry". This registry is to be managed by the IANA according to
to the Specification Required policy of [RFC5226]. the Specification Required policy of [RFC5226].
The length of the Status field is two octets, allowing 65536 codes. The length of the Status field is two octets, allowing 65536 codes.
However, the status codes have been registered to allow for an easier However, the status codes have been registered to allow for an easier
classification. For example, the values between (and including) 1 classification. For example, the values between (and including) 1
and 1000 are primarily used by the MA method of simple join. The and 1000 are primarily used by the MA method of simple join. The
values between (and including) 1001 and 2000 are used by the MA values between (and including) 1001 and 2000 are used by the MA
method described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. When method described in [RFC6285]. When registering new status codes for
registering new status codes for the existing MA methods or newly the existing MA methods or newly defined MA methods, registrants are
defined MA methods, registrants are encouraged to allocate sufficient encouraged to allocate sufficient continuous space. Note that
continuous space. Note that because of the limited space, not every because of the limited space, not every MA method can be assigned
MA method can be assigned 1000 different values for its Status codes. 1000 different values for its status codes.
The Status code 65535 is reserved for future use. The registry is The status code 65535 is reserved for future use. The registry is
initialized with the following entries: initialized with the following entries:
Code Description Reference Code Description Reference
----- -------------------------------------------------- ------------- --------- ------------------------------------------------ ---------
0 A private status code is included in the message [RFCXXXX] 0 A private status code is included in the message [RFC6332]
1 Multicast join was successful [RFC6332]
1 Multicast join was successful [RFCXXXX] 2 Multicast join has failed [RFC6332]
2 Multicast join has failed [RFCXXXX] 3 A presentation error has occurred [RFC6332]
3 A presentation error has occurred [RFCXXXX] 4 An unspecified RTP receiver internal error has
4 An unspecified RR internal error has occurred [RFCXXXX] occurred [RFC6332]
5-1000 Unassigned
1001 RAMS has been successfully completed [RFCXXXX] 1001 RAMS has been successfully completed [RFC6332]
1002 No RAMS-R message has been sent [RFCXXXX] 1002 No RAMS-R message has been sent [RFC6332]
1003 Invalid RAMS-I message syntax [RFCXXXX] 1003 Invalid RAMS-I message syntax [RFC6332]
1004 RAMS-I message has timed out [RFCXXXX] 1004 RAMS-I message has timed out [RFC6332]
1005 RAMS unicast burst has timed out [RFCXXXX] 1005 RAMS unicast burst has timed out [RFC6332]
1006 An unspecified RR internal error has occurred 1006 An unspecified RTP receiver internal error has
during RAMS [RFCXXXX] occurred during RAMS [RFC6332]
1007 A presentation error has occurred during RAMS [RFCXXXX] 1007 A presentation error has occurred during RAMS [RFC6332]
65535 Reserved [RFCXXXX] 1008-65534 Unassigned
65535 Reserved [RFC6332]
Any registration for an unassigned Status code needs to contain the Any registration for an unassigned status code needs to 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 Status code describes and o A detailed description of what the new status code describes and
how it is interpreted. how it is interpreted.
8. Acknowledgments 8. Acknowledgments
This specification has greatly benefited from discussions with This specification has greatly benefited from discussions with
Michael Lague, Dong Hsu, Carol Iturralde, Xuan Zhong, Dave Oran, Tom Michael Lague, Dong Hsu, Carol Iturralde, Xuan Zhong, Dave Oran, Tom
Van Caenegem and many others. The authors would like to thank each Van Caenegem, and many others. The authors would like to thank each
of these individuals for their contributions. of these individuals for their contributions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003. November 2003.
[I-D.ietf-avt-rapid-acquisition-for-rtp] [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- Norrman, "The Secure Real-time Transport Protocol (SRTP)",
Based Rapid Acquisition of Multicast RTP Sessions", RFC 3711, March 2004.
draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in
progress), November 2010.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,
Norrman, "The Secure Real-time Transport Protocol (SRTP)", "Unicast-Based Rapid Acquisition of Multicast RTP
RFC 3711, March 2004. Sessions", RFC 6285, June 2011.
9.2. Informative References 9.2. Informative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
Authors' Addresses Authors' Addresses
Ali Begen Ali Begen
Cisco Cisco
181 Bay Street 181 Bay Street
Toronto, ON M5J 2T3 Toronto, ON M5J 2T3
Canada Canada
Email: abegen@cisco.com EMail: abegen@cisco.com
Eric Friedrich Eric Friedrich
Cisco Cisco
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: efriedri@cisco.com EMail: efriedri@cisco.com
 End of changes. 93 change blocks. 
301 lines changed or deleted 282 lines changed or added

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