Request for Comments: 3611 Paris 6
Category: Standards Track R. Caceres, Ed.
IBM Research
A. Clark, Ed.
Telchemy
November 2003
RTP Control Protocol Extended Reports (RTCP XR)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document defines the Extended Report (XR) packet type for the
RTP Control Protocol (RTCP), and defines how the use of XR packets
can be signaled by an application if it employs the Session
Description Protocol (SDP). XR packets are composed of report
blocks, and seven block types are defined here. The purpose of the
extended reporting format is to convey information that supplements
the six statistics that are contained in the report blocks used by
RTCP’s Sender Report (SR) and Receiver Report (RR) packets. Some
applications, such as multicast inference of network characteristics
(MINC) or voice over IP (VoIP) monitoring, require other and more
detailed statistics. In addition to the block types defined here,
additional block types may be defined in the future by adhering to
the framework that this document provides.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 7
2. XR Packet Format . . . . . . . . . . . . . . . . . . . . . . . 7
3. Extended Report Block Framework. . . . . . . . . . . . . . . . 8
4. Extended Report Blocks . . . . . . . . . . . . . . . . . . . . 9
4.1. Loss RLE Report Block. . . . . . . . . . . . . . . . . . 9
4.1.1. Run Length Chunk . . . . . . . . . . . . . . . . 15
4.1.2. Bit Vector Chunk . . . . . . . . . . . . . . . . 15
4.1.3. Terminating Null Chunk . . . . . . . . . . . . . 16
4.2. Duplicate RLE Report Block . . . . . . . . . . . . . . . 16
4.3. Packet Receipt Times Report Block. . . . . . . . . . . . 18
4.4. Receiver Reference Time Report Block . . . . . . . . . . 20
4.5. DLRR Report Block. . . . . . . . . . . . . . . . . . . . 21
4.6. Statistics Summary Report Block. . . . . . . . . . . . . 22
4.7. VoIP Metrics Report Block. . . . . . . . . . . . . . . . 25
4.7.1. Packet Loss and Discard Metrics. . . . . . . . . 27
4.7.2. Burst Metrics. . . . . . . . . . . . . . . . . . 27
4.7.3. Delay Metrics. . . . . . . . . . . . . . . . . . 30
4.7.4. Signal Related Metrics . . . . . . . . . . . . . 31
4.7.5. Call Quality or Transmission Quality Metrics . . 33
4.7.6. Configuration Parameters . . . . . . . . . . . . 34
4.7.7. Jitter Buffer Parameters . . . . . . . . . . . . 36
5. SDP Signaling. . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1. The SDP Attribute. . . . . . . . . . . . . . . . . . . . 37
5.2. Usage in Offer/Answer. . . . . . . . . . . . . . . . . . 40
5.3. Usage Outside of Offer/Answer. . . . . . . . . . . . . . 42
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 42
6.1. XR Packet Type . . . . . . . . . . . . . . . . . . . . . 42
6.2. RTCP XR Block Type Registry. . . . . . . . . . . . . . . 42
6.3. The "rtcp-xr" SDP Attribute. . . . . . . . . . . . . . . 43
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 44
A. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.1. Sequence Number Interpretation . . . . . . . . . . . . . 46
A.2. Example Burst Packet Loss Calculation. . . . . . . . . . 47
Intellectual Property Notice . . . . . . . . . . . . . . . . . . . 49
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 50
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Normative References . . . . . . . . . . . . . . . . . . . . . . . 51
Informative References . . . . . . . . . . . . . . . . . . . . . . 51
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction
This document defines the Extended Report (XR) packet type for the
RTP Control Protocol (RTCP) [9], and defines how the use of XR
packets can be signaled by an application if it employs the Session
Description Protocol (SDP) [4]. XR packets convey information beyond
that already contained in the reception report blocks of RTCP’s
sender report (SR) or Receiver Report (RR) packets. The information
is of use across RTP profiles, and so is not appropriately carried in
SR or RR profile-specific extensions. Information used for network
management falls into this category, for instance.
The definition is broken out over the three sections that follow the
Introduction. Section 2 defines the XR packet as consisting of an
eight octet header followed by a series of components called report
blocks. Section 3 defines the common format, or framework,
consisting of a type and a length field, required for all report
blocks. Section 4 defines several specific report block types.
Other block types can be defined in future documents as the need
arises.
The report block types defined in this document fall into three
categories. The first category consists of packet-by-packet reports
on received or lost RTP packets. Reports in the second category
convey reference time information between RTP participants. In the
third category, reports convey metrics relating to packet receipts,
that are summary in nature but that are more detailed, or of a
different type, than that conveyed in existing RTCP packets.
All told, seven report block formats are defined by this document.
Of these, three are packet-by-packet block types:
- Loss RLE Report Block (Section 4.1): Run length encoding of
reports concerning the losses and receipts of RTP packets.
- Duplicate RLE Report Block (Section 4.2): Run length encoding of
reports concerning duplicates of received RTP packets.
- Packet Receipt Times Report Block (Section 4.3): A list of
reception timestamps of RTP packets.
There are two reference time related block types:
- Receiver Reference Time Report Block (Section 4.4): Receiver-end
wallclock timestamps. Together with the DLRR Report Block
mentioned next, these allow non-senders to calculate round-trip
times.
- DLRR Report Block (Section 4.5): The delay since the last Receiver
Reference Time Report Block was received. An RTP data sender that
receives a Receiver Reference Time Report Block can respond with a
DLRR Report Block, in much the same way as, in the mechanism
already defined for RTCP [9, Section 6.3.1], an RTP data receiver
that receives a sender’s NTP timestamp can respond by filling in
the DLSR field of an RTCP reception report block.
Finally, this document defines two summary metric block types:
- Statistics Summary Report Block (Section 4.6): Statistics on RTP
packet sequence numbers, losses, duplicates, jitter, and TTL or
Hop Limit values.
- VoIP Metrics Report Block (Section 4.7): Metrics for monitoring
Voice over IP (VoIP) calls.
Before proceeding to the XR packet and report block definitions, this
document provides an applicability statement (Section 1.1) that
describes the contexts in which these report blocks can be used. It
also defines (Section 1.2) the normative use of key words, such as
MUST and SHOULD, as they are employed in this document.
Following the definitions of the various report blocks, this document
describes how applications that employ SDP can signal their use
(Section 5). The document concludes with a discussion (Section 6) of
numbering considerations for the Internet Assigned Numbers Authority
(IANA), of security considerations (Section 7), and with appendices
that provide examples of how to implement algorithms discussed in the
text.
1.1. Applicability
The XR packets are useful across multiple applications, and for that
reason are not defined as profile-specific extensions to RTCP sender
or Receiver Reports [9, Section 6.4.3]. Nonetheless, they are not of
use in all contexts. In particular, the VoIP metrics report block
(Section 4.7) is specific to voice applications, though it can be
employed over a wide variety of such applications.
The VoIP metrics report block can be applied to any one-to-one or
one-to-many voice application for which the use of RTP and RTCP is
specified. The use of conversational metrics (Section 4.7.5),
including the R factor (as described by the E Model defined in [3])
and the mean opinion score for conversational quality (MOS-CQ), in
applications other than simple two party calls is not defined; hence,
these metrics should be identified as unavailable in multicast
conferencing applications.
The packet-by-packet report block types, Loss RLE (Section 4.1),
Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3),
have been defined with network tomography applications, such as
multicast inference of network characteristics (MINC) [11], in mind.
MINC requires detailed packet receipt traces from multicast session
receivers in order to infer the gross structure of the multicast
distribution tree and the parameters, such as loss rates and delays,
that apply to paths between the branching points of that tree.
Any real time multicast multimedia application can use the packet-
by-packet report block types. Such an application could employ a
MINC inference subsystem that would provide it with multicast tree
topology information. One potential use of such a subsystem would be
for the identification of high loss regions in the multicast tree and
the identification of multicast session participants well situated to
provide retransmissions of lost packets.
Detailed packet-by-packet reports do not necessarily have to consume
disproportionate bandwidth with respect to other RTCP packets. An
application can cap the size of these blocks. A mechanism called
"thinning" is provided for these report blocks, and can be used to
ensure that they adhere to a size limit by restricting the number of
packets reported upon within any sequence number interval. The
rationale for, and use of this mechanism is described in [13].
Furthermore, applications might not require report blocks from all
receivers in order to answer such important questions as where in the
multicast tree there are paths that exceed a defined loss rate
threshold. Intelligent decisions regarding which receivers send
these report blocks can further restrict the portion of RTCP
bandwidth that they consume.
The packet-by-packet report blocks can also be used by dedicated
network monitoring applications. For such an application, it might
be appropriate to allow more than 5% of RTP data bandwidth to be used
for RTCP packets, thus allowing proportionately larger and more
detailed report blocks.
Nothing in the packet-by-packet block types restricts their use to
multicast applications. In particular, they could be used for
network tomography similar to MINC, but using striped unicast packets
instead. In addition, if it were found useful, they could be used
for applications limited to two participants.
One use to which the packet-by-packet reports are not immediately
suited is for data packet acknowledgments as part of a packet
retransmission mechanism. The reason is that the packet accounting
technique suggested for these blocks differs from the packet
accounting normally employed by RTP. In order to favor measurement
applications, an effort is made to interpret as little as possible at
the data receiver, and leave the interpretation as much as possible
to participants that receive the report blocks. Thus, for example, a
packet with an anomalous SSRC ID or an anomalous sequence number
might be excluded by normal RTP accounting, but would be reported
upon for network monitoring purposes.
The Statistics Summary Report Block (Section 4.6) has also been
defined with network monitoring in mind. This block type can be used
equally well for reporting on unicast and multicast packet reception.
The reference time related block types were conceived for receiver-
based TCP-friendly multicast congestion control [18]. By allowing
data receivers to calculate their round trip times to senders, they
help the receivers estimate the downstream bandwidth they should
request. Note that if every receiver is to send Receiver Reference
Time Report Blocks (Section 4.4), a sender might potentially send a
number of DLRR Report Blocks (Section 4.5) equal to the number of
receivers whose RTCP packets have arrived at the sender within its
reporting interval. As the number of participants in a multicast
session increases, an application should use discretion regarding
which participants send these blocks, and how frequently.
XR packets supplement the existing RTCP packets, and may be stacked
with other RTCP packets to form compound RTCP packets [9, Section 6].
The introduction of XR packets into a session in no way changes the
rules governing the calculation of the RTCP reporting interval [9,
Section 6.2]. As XR packets are RTCP packets, they count as such for
bandwidth calculations. As a result, the addition of extended
reporting information may tend to increase the average RTCP packet
size, and thus the average reporting interval. This increase may be
limited by limiting the size of XR packets.
The SDP signaling defined for XR packets in this document (Section 5)
was done so with three use scenarios in mind: a Real Time Streaming
Protocol (RTSP) controlled streaming application, a one-to-many
multicast multimedia application such as a course lecture with
enhanced feedback, and a Session Initiation Protocol (SIP) controlled
conversational session involving two parties. Applications that
employ SDP are free to use additional SDP signaling for cases not
covered here. In addition, applications are free to use signaling
mechanisms other than SDP.
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [1]
and indicate requirement levels for compliance with this
specification.
2. XR Packet Format
An XR packet consists of a header of two 32-bit words, followed by a
number, possibly zero, of extended report blocks. This type of
packet is laid out in a manner consistent with other RTCP packets, as
concerns the essential version, packet type, and length information.
XR packets are thus backwards compatible with RTCP receiver
implementations that do not recognize them, but that ought to be able
to parse past them using the length information. A padding field and
an SSRC field are also provided in the same locations that they
appear in other RTCP packets, for simplicity. The format is as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: report blocks :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
version (V): 2 bits
Identifies the version of RTP. This specification applies to
RTP version two.
padding (P): 1 bit
If the padding bit is set, this XR packet contains some
additional padding octets at the end. The semantics of this
field are identical to the semantics of the padding field in
the SR packet, as defined by the RTP specification.
reserved: 5 bits
This field is reserved for future definition. In the absence
of such definition, the bits in this field MUST be set to zero
and MUST be ignored by the receiver.
packet type (PT): 8 bits
Contains the constant 207 to identify this as an RTCP XR
packet. This value is registered with the Internet Assigned
Numbers Authority (IANA), as described in Section 6.1.
length: 16 bits
As described for the RTCP Sender Report (SR) packet (see
Section 6.4.1 of the RTP specification [9]). Briefly, the
length of this XR packet in 32-bit words minus one, including
the header and any padding.
SSRC: 32 bits
The synchronization source identifier for the originator of
this XR packet.
report blocks: variable length.
Zero or more extended report blocks. In keeping with the
extended report block framework defined below, each block MUST
consist of one or more 32-bit words.
3. Extended Report Block Framework
Extended report blocks are stacked, one after the other, at the end
of an XR packet. An individual block’s length is a multiple of 4
octets. The XR header’s length field describes the total length of
the packet, including these extended report blocks.
Each block has block type and length fields that facilitate parsing.
A receiving application can demultiplex the blocks based upon their
type, and can use the length information to locate each successive
block, even in the presence of block types it does not recognize.
An extended report block has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT | type-specific | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: type-specific block contents :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
Identifies the block format. Seven block types are defined in
Section 4. Additional block types may be defined in future
specifications. This field’s name space is managed by the
Internet Assigned Numbers Authority (IANA), as described in
Section 6.2.
type-specific: 8 bits
The use of these bits is determined by the block type
definition.
block length: 16 bits
The length of this report block, including the header, in 32-
bit words minus one. If the block type definition permits,
zero is an acceptable value, signifying a block that consists
of only the BT, type-specific, and block length fields, with a
null type-specific block contents field.
type-specific block contents: variable length
The use of this field is defined by the particular block type,
subject to the constraint that it MUST be a multiple of 32 bits
long. If the block type definition permits, It MAY be zero
bits long.
4. Extended Report Blocks
This section defines seven extended report blocks: block types for
reporting upon received packet losses and duplicates, packet
reception times, receiver reference time information, receiver
inter-report delays, detailed reception statistics, and voice over IP
(VoIP) metrics. An implementation SHOULD ignore incoming blocks with
types not relevant or unknown to it. Additional block types MUST be
registered with the Internet Assigned Numbers Authority (IANA) [16],
as described in Section 6.2.
4.1. Loss RLE Report Block
This block type permits detailed reporting upon individual packet
receipt and loss events. Such reports can be used, for example, for
multicast inference of network characteristics (MINC) [11]. With
MINC, one can discover the topology of the multicast tree used for
distributing a source’s RTP packets, and of the loss rates along
links within that tree, or they could be used to provide raw data to
a network management application.
Since a Boolean trace of lost and received RTP packets is potentially
lengthy, this block type permits the trace to be compressed through
run length encoding. To further reduce block size, loss event
reports can be systematically dropped from the trace in a mechanism
called thinning that is described below and that is studied in [13].
A participant that generates a Loss RLE Report Block should favor