draft-ietf-avt-rtcp-report-extns-01.txt   draft-ietf-avt-rtcp-report-extns-02.txt 
Internet Engineering Task Force Expires: 3 May 2003 Internet Engineering Task Force Expires: 24 July 2003
Audio/Video Transport Working Group Audio/Video Transport Working Group
Timur Friedman, Paris 6 Timur Friedman, Paris 6
Ramon Caceres, ShieldIP Ramon Caceres, ShieldIP
Kevin Almeroth, UCSB
Kamil Sarac, UCSB
Alan Clark, Telchemy Alan Clark, Telchemy
Robert Cole, AT&T Editors
Kaynam Hedayat, Brix Networks
RTCP Reporting Extensions RTP Extended Reports (RTP XR)
draft-ietf-avt-rtcp-report-extns-01.txt draft-ietf-avt-rtcp-report-extns-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 38
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document defines the XR (extended report) RTCP packet type and This document defines the extended report (XR) packet type for the
seven XR block types. The purpose of the extended reporting format is RTP control protocol (RTCP). XR packets are composed of report
to convey information that supplements the six statistics that are blocks, and seven block types are defined here. The purpose of the
contained in the report blocks used by SR (sender report) and RR extended reporting format is to convey information that supplements
(receiver report) packets. Some applications, such as MINC the six statistics that are contained in the report blocks used by
(multicast inference of network characteristics) or VoIP (voice over RTCP's sender report (SR) and receiver report (RR) packets. Some
IP) monitoring, require other and more detailed statistics. In applications, such as multicast inference of network characteristics
addition to the block types defined here, additional block types may (MINC) or voice over IP (VoIP) monitoring, require other and more
be defined in the future by adhereing to the simple framework that detailed statistics. In addition to the block types defined here,
this document provides. additional block types may be defined in the future by adhereing to
the framework that this document provides.
Table of Contents
1. Introduction .............................................. 2
1.1 Terminology ............................................... 3
2. XR Packet Format .......................................... 4
3. Extended Report Block Framework ........................... 5
4. Extended Report Blocks .................................... 6
4.1 Loss RLE Report Block ..................................... 6
4.1.1 Run Length Chunk .......................................... 12
4.1.2 Bit Vector Chunk .......................................... 12
4.1.3 Terminating Null Chunk .................................... 12
4.2 Duplicate RLE Report Block ................................ 13
4.3 Timestamp Report Block .................................... 13
4.4 Statistics Summary Report Block ........................... 16
4.5 Receiver Timestamp Report Block ........................... 19
4.6 DLRR Report Block ......................................... 20
4.7 VoIP Metrics Report Block ................................. 21
4.7.1 Packet Loss and Discard Metrics ........................... 23
4.7.2 Burst Metrics ............................................. 23
4.7.3 Delay Metrics ............................................. 26
4.7.4 Signal Related Metrics .................................... 26
4.7.5 Call Quality or Transmission Quality Metrics .............. 29
4.7.6 Configuration Parameters .................................. 30
4.7.7 Jitter Buffer Parameters .................................. 31
5. IANA Considerations ....................................... 32
5.1 XR Packet Type ............................................ 32
5.2 RTP XR Block Type Registry ................................ 32
6. Security Considerations ................................... 33
A. Algorithms ................................................ 34
A.1 Sequence Number Interpretation ............................ 34
A.2 Example Burst Packet Loss Calculation ..................... 35
Intellectual Property ..................................... 37
Full Copyright Statement .................................. 38
Acknowledegments .......................................... 38
Contributors .............................................. 39
Authors' Addresses ........................................ 39
References ................................................ 40
Normative References ...................................... 40
Non-Normative References .................................. 41
1. Introduction 1. Introduction
This document defines the XR (extended report) RTCP packet type for This document defines the extended report (XR) packet type for the
RTCP, the control portion of RTP [8]. The definition consists of RTP control protocol (RTCP) [7]. XR packets convey information
three parts. First, Section 2 of this document defines a general beyond that already contained in the reception report blocks of
packet framework capable of including a number of different "extended RTCP's sender report (SR) or receiver report (RR) packets. The
report blocks." Second, Section 3 defines the general format for information is of use across RTP profiles, and so is not
such blocks. Third, Section 4 defines a number of such blocks. appropriately carried in SR or RR profile-specific extensions.
Information used for network management falls into this category, for
instance.
The extended report blocks convey information beyond that which is The definition is broken out over the three following sections of
already contained in the reception report blocks of RTCP's SR or RR this document, starting with a general framework and finishing with
packets. XR report blocks carry information that is not appropriately the specific information conveyed. The framework defined by Section
carried in SR or RR profile-specific extensions because it is of use 2 contains common header information followed by a series of
across profiles. Information that is useful to network management components called report blocks. Section 3 defines the format common
falls into this category, for instance. to such blocks. Section 4 defines seven block types.
Seven report block formats are defined by this document: Seven report block formats are defined by this document:
- Loss RLE Report Block (Section 4.1): Run-length encoding of RTP - Loss RLE Report Block (Section 4.1): Run length encoding of RTP
packet loss reports. packet loss reports.
- Duplicate RLE Report Block (Section 4.2): Run-length encoding of - Duplicate RLE Report Block (Section 4.2): Run length encoding of
reports of RTP packet duplicates. reports of RTP packet duplicates.
- Timestamp Report Block (Section 4.3): A list of timestamps of - Timestamp Report Block (Section 4.3): A list of timestamps of
received RTP packets. received RTP packets.
- Statistics Summary Report Block (Section 4.4): Statistics on RTP - Statistics Summary Report Block (Section 4.4): Statistics on RTP
packet sequence numbers, losses, duplicates, jitter, and TTL values. packet sequence numbers, losses, duplicates, jitter, and TTL values.
- Receiver Timestamp Report Block (Section 4.5): Receiver-end - Receiver Timestamp Report Block (Section 4.5): Receiver-end
timestamps that complement the sender-end timestamps already defined timestamps that complement the sender-end timestamps already defined
for RTCP. for RTCP.
- DLRR Report Block (Section 4.6): The delay since the last receiver - DLRR Report Block (Section 4.6): The delay since the last Receiver
timestamp report block was received, allowing non-senders to Timestamp Report Block was received, allowing non-senders to
calculate round-trip times. calculate round-trip times.
- VoIP Metrics Report Block (Section 4.7): Metrics for monitoring - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring
Voice over IP (VoIP) calls. Voice over IP (VoIP) calls.
These blocks are defined within a minimal framework: a type field and These blocks are defined within a minimal framework: a type field and
a length field are common to all XR blocks. The purpose is to a length field are common to all XR blocks. The purpose is to
maintain flexibility and to keep overhead low. 0ther block formats, maintain flexibility and to keep overhead low. 0ther block formats,
beyond the seven defined here, may be defined within this framework beyond the seven defined here, may be defined within this framework
as the need arises. as the need arises.
skipping to change at page 3, line 12 skipping to change at page 4, line 4
- VoIP Metrics Report Block (Section 4.7): Metrics for monitoring - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring
Voice over IP (VoIP) calls. Voice over IP (VoIP) calls.
These blocks are defined within a minimal framework: a type field and These blocks are defined within a minimal framework: a type field and
a length field are common to all XR blocks. The purpose is to a length field are common to all XR blocks. The purpose is to
maintain flexibility and to keep overhead low. 0ther block formats, maintain flexibility and to keep overhead low. 0ther block formats,
beyond the seven defined here, may be defined within this framework beyond the seven defined here, may be defined within this framework
as the need arises. as the need arises.
1.1 Terminology 1.1 Terminology
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 RFC 2119 [2] and document are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliance with this specification. indicate requirement levels for compliance with this specification.
2. XR Packet Format 2. XR Packet Format
The XR packet consists of a header of two 32-bit words, followed by a The XR packet consists of a header of two 32-bit words, followed by a
number, possibly zero, of extended report blocks. number, possibly zero, of extended report blocks.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=XP=205 | length | |V=2|P|reserved | PT=XP=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC | | SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: report blocks : : report blocks :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
version (V): 2 bits version (V): 2 bits
Identifies the version of RTP. This specification applies to RTP ver- Identifies the version of RTP. This specification applies to
sion two (2). RTP version two.
padding (P): 1 bit padding (P): 1 bit
If the padding bit is set, this individual RTCP packet contains some If the padding bit is set, this XR packet contains some
additional padding octets at the end that are not part of the control additional padding octets at the end. The semantics of this
information but are included in the length field. The last octet of field are identical to the semantics of the padding field in the
the padding is a count of how many padding octets should be ignored, the SR packet, as defined by the RTP specification.
including itself (it will be a multiple of four). A full description
of padding in RTCP packets may be found in the RTP specification.
reserved: 5 bits reserved: 5 bits
This field is reserved for future definition. In the absence of such This field is reserved for future definition. In the absence of
definition, the bits in this field MUST be set to zero and MUST be such definition, the bits in this field MUST be set to zero and
ignored by the receiver. the receiver MUST ignore any XR packet with a non-zero value in
this field.
packet type (PT): 8 bits packet type (PT): 8 bits
Contains the constant 205 to identify this as an RTCP XR packet. Contains the constant 207 to identify this as an RTCP XR packet.
This is a proposed value, pending assignment of a number by the This value is registered with the Internet Assigned Numbers
Internet Assigned Numbers Authority (IANA) [7]. Authority (IANA), as described in Section 5.1.
length: 16 bits length: 16 bits
The length of this RTCP packet in 32-bit words minus one, including As described for the RTP sender report (SR) packet (see Section
the header and any padding. (The offset of one makes zero a valid 6.3.1 of the RTP specification [7]). Briefly, the length of
length and avoids a possible infinite loop in scanning a compound this XR packet in 32-bit words minus one, including the header
RTCP packet, while counting 32-bit words avoids a validity check for and any padding.
a multiple of 4.)
SSRC: 32 bits SSRC: 32 bits
The synchronization source identifier for the originator of this XR The synchronization source identifier for the originator of this
packet. XR packet.
report blocks: variable length. report blocks: variable length.
Zero or more extended report blocks. Each block MUST be a multiple Zero or more extended report blocks. In keeping with the
of 32 bits long. A block MAY be zero bits long. extended report block framework defined below, each block MUST
consist of one or more 32-bit words.
3. Extended Report Block Framework 3. Extended Report Block Framework
Extended report blocks are stacked, one after the other, at the end 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 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 octets. The XR header's length field describes the total length of
the packet, including these extended report blocks. the packet, including these extended report blocks.
Each block has block type and length fields that facilitate parsing. Each block has block type and length fields that facilitate parsing.
A receiving application can demultiplex the blocks based upon their A receiving application can demultiplex the blocks based upon their
type, and can use the length information to locate each successive type, and can use the length information to locate each successive
block, even in the presence of block types it does not recognize. block, even in the presence of block types it does not recognize.
An extended report block has the following format: An extended report block has the following format:
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 | type-specific | length | | BT | type-specific | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: type-specific data : : type-specific data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
Identifies the specific block format. 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 5.2.
type-specific: 8 bits type-specific: 8 bits
The use of these bits is defined by the particular block type. The use of these bits is determined by the block type
definition.
length: 16 bits block length: 16 bits
The length of this report block in 32-bit words minus one, including The length of this report block including the header, in 32-bit
the header. 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 data field.
type-specific data: variable length type-specific data: variable length
This field MUST be a multiple of 32 bits long. It MAY be zero bits 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. long.
4. Specific Extended Report Blocks 4. Extended Report Blocks
This section defines seven extended report blocks: block types for This section defines seven extended report blocks: block types for
losses, duplicates, packet reception timestamps, detailed reception losses, duplicates, packet reception timestamps, detailed reception
statistics, receiver timestamps, receiver inter-report delays, and statistics, receiver timestamps, receiver inter-report delays, and
VoIP metrics. An implementation MAY ignore incoming blocks with voice over IP (VoIP) metrics. An implementation MAY ignore incoming
types either not relevant or unknown to it. Additional block types blocks with types either not relevant or unknown to it. Additional
MUST be registered with the Internet Assigned Numbers Authority block types MUST be registered with the Internet Assigned Numbers
(IANA) [7], as described in Section 5. Authority (IANA) [5], as described in Section 5.2.
4.1 Loss RLE Report Block 4.1 Loss RLE Report Block
This block type permits detailed reporting upon individual packet This block type permits detailed reporting upon individual packet
receipt and loss events. Such reports could be used, for example, receipt and loss events. Such reports can be used, for example, for
for MINC inference [1] of the topology of the multicast tree used for multicast inference of network characteristics (MINC) [8]. 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 distributing a source's RTP packets, and of the loss rates along
links within that tree. Since a Boolean trace of lost and received links within that tree. Or they could be used to provide raw data to
RTP packets is potentially lengthy, this block type permits the trace a network management application.
to be compressed through run length encoding.
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 [9].
A participant that generates a Loss RLE Report Block should favor
accuracy in reporting on observed events over interpretation of those
events whenever possible. Interpretation should be left to those who
observe the report blocks. Following this approach implies that
accounting for Loss RLE Report Blocks will differ from the accounting
for the generation of the SR and RR packets described in the RTP
specification [7] in the following two areas: per-sender accounting
and per-packet accounting.
In its per-sender accounting, an RTP session participant SHOULD NOT
make the receipt of a threshold minimum number of RTP packets a
condition for reporting upon the sender of those packets. This
accounting technique differs from the technique described in Section
6.2.1 and Appendix A.1 of the RTP specification that allows a
threshold to determine whether a sender is considered valid.
In its per-packet accounting, an RTP session participant SHOULD treat
all sequence numbers as valid. This accouting technique differs from
the technique described in Appendix A.1 of the RTP specification that
suggests ruling a sequence number valid or invalid on the basis of
its contiguity with the sequence numbers of previously received
packets.
Sender validity and sequence number validity are interpretations of
the raw data. Such interpretations are justified in the interest,
for example, of excluding the stray old packet from an unrelated
session from having an effect upon the calculation of the RTCP
transmission interval. The presence of stray packets might, on the
other hand, be of interest to a network monitoring application.
One accounting interpretation that is still necessary is for a
participant to decide whether the 16 bit sequence number has rolled
over. Under ordinary circumstances this is not a difficult task.
For example, if packet number 65,535 (the highest possible sequence
number) is followed shortly by packet number 0, it is reasonable to
assume that there has been a rollover. However it is possible that
the packet is an earlier one (from 65,535 packets earlier). It is
also possible that the sequence numbers have rolled over multiple
times, either forward or backward. The interpretation becomes more
difficult when there are large gaps between the sequence numbers,
even accounting for rollover, and when there are long intervals
between received packets.
The per-packet accounting technique mandated here is for a
participant to keep track of the sequence number of the packet most
recently received from a sender. For the next packet that arrives
from that sender, the sequence number MUST be judged to fall no more
than 32,768 packets ahead or behind the most recent one, whichever
choice places it closer. In the event that both choices are equally
distant (only possible when the distance is 32,768), the choice MUST
be the one that does not require a rollover. Appendix A.1 presents
an algorithm that implements this technique.
Each block reports on a single source, identified by its SSRC. The Each block reports on a single source, identified by its SSRC. The
receiver that is supplying the report is identified in the header of receiver that is supplying the report is identified in the header of
the RTCP packet. the RTCP packet.
The beginning and ending RTP packet sequence numbers for the trace Choice of beginning and ending RTP packet sequence numbers for the
are specified in the block, the ending sequence number being the last trace is left to the application. These values are reported in the
sequence number in the trace plus one. The last sequence number in block. The last sequence number in the trace MAY differ from the
the trace MAY differ from the sequence number reported on in any sequence number reported on in any accompanying SR or RR report.
accompanying SR or RR packet.
The ending sequence number MAY be less than the beginning sequence Note that because of sequence number wrap around the ending sequence
number. This happens when the sequence numbers that are being number MAY be less than the beginning sequence number. A Loss RLE
reported upon have wrapped around. However, a Loss RLE Block MUST Report Block MUST NOT be used to report upon a range of 65,534 or
NOT be used to report upon a range of 65,534 or greater in the greater in the sequence number space, as there is no means to
sequence number space, as there is no means to identify multiple identify multiple wrap arounds.
wrap-arounds.
The encoding itself consists of a series of 16 bit chunks that The trace described by a Loss RLE report consists of a sequence of
describe packet receipts or losses. Each chunk either specifies a Boolean values, one for each sequence number of the trace. A value
run length or a bit vector, or is a null chunk. A run length of one represents a packet receipt, meaning that one or more packets
describes between 1 and 16,383 events that are all the same (either having that sequence number have been received since the most recent
all receipts or all losses). A bit vector describes 15 events that wrap around of sequence numbers (or since the beginning of the RTP
may be mixed receipts and losses. A null chunk describes no events, session if no wrap around has been judged to have occurred). A value
and is used to to round out the block to a 32 bit word boundary. of zero represents a packet loss, meaning that there has been no
packet receipt for that sequence number as of the time of the report.
If a packet with a given sequence number is received after a report
of a loss for that sequence number, a later Loss RLE report MAY
report a packet receipt for that sequence number.
The encoding itself consists of a series of 16 bit units called
chunks that describe sequences of packet receipts or losses in the
trace. Each chunk either specifies a run length or a bit vector, or
is a null chunk. A run length describes between 1 and 16,383 events
that are all the same (either all receipts or all losses). A bit
vector describes 15 events that may be mixed receipts and losses. A
null chunk describes no events, and is used to to round out the block
to a 32 bit word boundary.
The mapping from a sequence of lost and received packets into a The mapping from a sequence of lost and received packets into a
sequence of chunks is not necessarily unique. For example, the fol- sequence of chunks is not necessarily unique. For example, the
lowing trace covers 45 packets, of which the 22nd and 24th have been following trace covers 45 packets, of which the 22nd and 24th have
lost and the others received: been lost and the others received:
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
One way to encode this would be: One way to encode this would be:
bit vector 1111 1111 1111 111 bit vector 1111 1111 1111 111
bit vector 1111 1101 0111 111 bit vector 1111 1101 0111 111
bit vector 1111 1111 1111 111 bit vector 1111 1111 1111 111
null chunk null chunk
skipping to change at page 7, line 16 skipping to change at page 9, line 31
bit vector 0101 1111 1111 111 bit vector 0101 1111 1111 111
bit vector 1111 1110 1000 000 bit vector 1111 1110 1000 000
null chunk null chunk
In this example, the last five bits of the second bit vector describe In this example, the last five bits of the second bit vector describe
a part of the sequence number space that extends beyond the last a part of the sequence number space that extends beyond the last
sequence number in the trace. These bits have been set to zero. sequence number in the trace. These bits have been set to zero.
All bits in a bit vector chunk that describe a part of the sequence All bits in a bit vector chunk that describe a part of the sequence
number space that extends beyond the last sequence number in the number space that extends beyond the last sequence number in the
trace MUST be set to zero and MUST be ignored by the receiver. trace MUST be set to zero, and MUST be ignored by the receiver.
A null packet MUST appear at the end of a Loss RLE Block if the num- A null packet MUST appear at the end of a Loss RLE Report Block if
ber of run length plus bit vector chunks is odd. The null chunk MUST the number of run length plus bit vector chunks is odd. The null
NOT appear in any other context. chunk MUST NOT appear in any other context.
Caution should be used in sending Loss RLE Blocks because, even with Caution should be used in sending Loss RLE Report Blocks because,
the compression provided by run-length encoding, they can easily con- even with the compression provided by run length encoding, they can
sume bandwidth out of proportion with normal RTCP packets. The block easily consume bandwidth out of proportion with normal RTCP packets.
type includes a mechanism, called thinning, that allows an applica- The block type includes a mechanism, called thinning, that allows an
tion to limit report sizes. application to limit report sizes.
A thinning value, T, selects a subset of packets within the sequence A thinning value, T, selects a subset of packets within the sequence
number space: those with sequence numbers that are multiples of 2^T. number space: those with sequence numbers that are multiples of 2^T.
Packet reception and loss reports apply only to those packets. T can Packet reception and loss reports apply only to those packets. T can
vary between 0 and 15. If T is zero then every packet in the vary between 0 and 15. If T is zero then every packet in the
sequence number space is reported upon. If T is fifteen then one in sequence number space is reported upon. If T is fifteen then one in
every 32,768 packets is reported upon. every 32,768 packets is reported upon.
Suppose that the trace just described begins at sequence number Suppose that the trace just described begins at sequence number
13,821. The last sequence number in the trace is 13,865. If the 13,821. The last sequence number in the trace is 13,865. If the
trace were to be thinned with a thinning value of T=2, then the fol- trace were to be thinned with a thinning value of T=2, then the
lowing sequence numbers would be reported upon: 13,824, 13,828, following sequence numbers would be reported upon: 13,824, 13,828,
13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860,
13,864. The thinned trace would be as follows: 13,864. The thinned trace would be as follows:
1 1 1 1 1 0 1 1 1 1 0 1 1 1 1 1 0 1 1 1 1 0
This could be encoded as follows: This could be encoded as follows:
bit vector 1111 1011 1100 000 bit vector 1111 1011 1100 000
null chunk null chunk
The last four bits in the bit vector, representing sequence numbers The last four bits in the bit vector, representing sequence numbers
13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are
thus set to zero and are ignored by the receiver. With thinning, the thus set to zero and are ignored by the receiver. With thinning, the
loss of the 22nd packet goes unreported because its sequence number, loss of the 22nd packet goes unreported because its sequence number,
13,842, is not a multiple of four. Packet receipts for all sequence 13,842, is not a multiple of four. Packet receipts for all sequence
numbers that are not multiples of four also go unreported. However, numbers that are not multiples of four also go unreported. However,
in this example thinning has permitted the Loss RLE Block to be in this example thinning has permitted the Loss RLE Report Block to
shortened by one 32 bit word. be shortened by one 32 bit word.
Choice of the thinning value is left to the application. Choice of the thinning value is left to the application.
The Loss RLE Block has the following format: The Loss RLE Report Block has the following format:
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=17 | rsvd. | T | block length | | BT=1 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 | | chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n | | chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Loss RLE block is identified by the constant 17. A Loss RLE Report Block is identified by the constant 1.
rsvd.: 4 bits rsvd.: 4 bits
This field is reserved for future definition. In the absence of such This field is reserved for future definition. In the absence of
definition, the bits in this field MUST be set to zero and receivers such definition, the bits in this field MUST be set to zero and
MUST ignore this field. the receiver MUST ignore any Loss RLE Report Block with a non-
zero value in this field.
thinning (T): 4 bits thinning (T): 4 bits
The amount of thinning performed on the sequence number space. Only The amount of thinning performed on the sequence number space.
those packets with sequence numbers 0 mod 2^T are reported on by this Only those packets with sequence numbers 0 mod 2^T are reported
block. A value of 0 indicates that there is no thinning, and all on by this block. A value of 0 indicates that there is no
packets are reported on. The maximum thinning is one packet in every thinning, and all packets are reported on. The maximum thinning
32,768 (amounting to two packets within each 16-bit sequence space). is one packet in every 32,768 (amounting to two packets within
each 16-bit sequence space).
length: 16 bits block length: 16 bits
Defined in Section 3. Defined in Section 3.
begin_seq: 16 bits begin_seq: 16 bits
The first sequence number that this block reports on. The first sequence number that this block reports on.
end_seq: 16 bits end_seq: 16 bits
The last sequence number that this block reports on plus one. The last sequence number that this block reports on plus one.
chunk i: 16 bits chunk i: 16 bits
There are three chunk types: run length, bit vector, and terminating There are three chunk types: run length, bit vector, and
null. If the chunk is all zeroes then it is a terminating null terminating null, defined in the following sections. If the
chunk. Otherwise, the leftmost bit of the chunk determines its type: chunk is all zeroes then it is a terminating null chunk.
0 for run length and 1 for bit vector. Otherwise, the leftmost bit of the chunk determines its type: 0
for run length and 1 for bit vector.
4.1.1 Run-Length Chunk 4.1.1 Run Length Chunk
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R| run length | |C|R| run length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
chunk type (C): 1 bit chunk type (C): 1 bit
A zero identifies this as a runlength chunk. A zero identifies this as a runlength chunk.
run type (R): 1 bit run type (R): 1 bit
Zero indicates a run of losses. One indicates a run of received Zero indicates a run of 0s. One indicates a run of 1s.
packets.
run length: 14 bits run length: 14 bits
A value between 1 and 16,383. The value MUST not be zero (zeroes in A value between 1 and 16,383. The value MUST not be zero for a
both the run type and run length fields would make the chunk a termi- run length chunk (zeroes in both the run type and run length
nating null chunk). Run lengths of 15 or less MAY be described with fields would make the chunk a terminating null chunk). Run
a run length chunk despite the fact that they could also be described lengths of 15 or less MAY be described with a run length chunk
as part of a bit vector chunk. despite the fact that they could also be described as part of a
bit vector chunk.
4.1.2 Bit Vector Chunk 4.1.2 Bit Vector Chunk
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| bit vector | |C| bit vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
chunk type (C): 1 bit chunk type (C): 1 bit
A one identifies this as a bit vector chunk. A one identifies this as a bit vector chunk.
bit vector: 15 bits bit vector: 15 bits
skipping to change at page 10, line 15 skipping to change at page 12, line 41
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| bit vector | |C| bit vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
chunk type (C): 1 bit chunk type (C): 1 bit
A one identifies this as a bit vector chunk. A one identifies this as a bit vector chunk.
bit vector: 15 bits bit vector: 15 bits
The vector is read from left to right, in order of increasing The vector is read from left to right, in order of increasing
sequence number (with the appropriate allowance for wrap around). A sequence number (with the appropriate allowance for wrap
zero indicates a packet loss and a one indicates a received packet. around).
4.1.3 Terminating Null Chunk 4.1.3 Terminating Null Chunk
This chunk is all zeroes. This chunk is all zeroes.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2 Duplicate RLE Report Block 4.2 Duplicate RLE Report Block
This block type permits per-sequence-number reports on duplicates in This block type permits per-sequence-number reports on duplicates in
a source's RTP packet stream. Such information can be used for net- a source's RTP packet stream. Such information can be used for
work diagnosis, and provide an alternative to packet losses as a network diagnosis, and provide an alternative to packet losses as a
basis for multicast tree topology inference. basis for multicast tree topology inference.
The Duplicate RLE Block format is identical to the Loss RLE Block The Duplicate RLE Report Block format is identical to the Loss RLE
format. Only the interpretation is different, in that the informa- Report Block format. Only the interpretation is different, in that
tion concerns packet duplicates rather than packet losses. The trace the information concerns packet duplicates rather than packet losses.
to be encoded in this case also consists of zeros and ones, but a The trace to be encoded in this case also consists of zeros and ones,
zero here indicates the presence of duplicate packets for a given but a zero here indicates the presence of duplicate packets for a
sequence number, whereas a one indicates that no duplicates were given sequence number, whereas a one indicates that no duplicates
received. were received.
The existence of a duplicate for a given sequence number is deter- The existence of a duplicate for a given sequence number is
mined over the entire reporting period. For example, if packet num- determined over the entire reporting period. For example, if packet
ber 12,593 arrives, followed by other packets with other sequence number 12,593 arrives, followed by other packets with other sequence
numbers, the arrival later in the reporting period of another packet numbers, the arrival later in the reporting period of another packet
numbered 12,593 counts as a duplicate for that sequence number. The numbered 12,593 counts as a duplicate for that sequence number. The
duplicate does not need to follow immediately upon the first packet duplicate does not need to follow immediately upon the first packet
of that number. Care must be taken that a report does not cover a of that number. Care must be taken that a report does not cover a
range of 65,534 or greater in the sequence number space. range of 65,534 or greater in the sequence number space.
No distinction is made between the existance of a single duplicate No distinction is made between the existance of a single duplicate
packet and multiple duplicate packets for a given sequence number. packet and multiple duplicate packets for a given sequence number.
Note also that since there is no duplicate for a lost packet, a loss Note also that since there is no duplicate for a lost packet, a loss
is encoded as a one in a Duplicate RLE Block. is encoded as a one in a Duplicate RLE Report Block.
The Duplicate RLE Block has the following format: The Duplicate RLE Report Block has the following format:
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=33 | rsvd. | T | length | | BT=2 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 | | chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n | | chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Duplicate RLE block is identified by the constant 33. A Duplicate RLE Report Block is identified by the constant 2.
rsvd.: 4 bits rsvd.: 4 bits
This field is reserved for future definition. In the absence of such This field is reserved for future definition. In the absence of
definition, the bits in this field MUST be set to zero and receivers such definition, the bits in this field MUST be set to zero and
MUST ignore this field. the receiver MUST ignore any Duplicate RLE Report Block with a
non-zero value in this field.
thinning (T): 4 bits thinning (T): 4 bits
The amount of thinning performed on the sequence number space. As defined in Section 4.1.
length: 16 bits block length: 16 bits
Defined in Section 3. Defined in Section 3.
begin_seq: 32 bits begin_seq: 16 bits
The first sequence number that this block reports on. As defined in Section 4.1.
end_seq: 32 bits end_seq: 16 bits
The last sequence number that this block reports on plus one. As defined in Section 4.1.
chunk i: 16 bits chunk i: 16 bits
There are three chunk types: run length, bit vector, and terminating As defined in Section 4.1.
null. All zeroes indicates a terminating null. Otherwise, the left-
most bit of the chunk determines its type: 0 for run length and 1 for
bit vector. See the descriptions of these block types in the section
on the Loss RLE Block, above, for details.
4.3 Timestamp Report Block 4.3 Timestamp Report Block
This block type permits per-sequence-number reports on packet receipt This block type permits per-sequence-number reports on packet receipt
timestamps for a given source's RTP packet stream. Such information timestamps for a given source's RTP packet stream. Such information
can be used for MINC inference of the topology of the multicast tree can be used for MINC inference of the topology of the multicast tree
used to distribute the source's RTP packets, and of the delays along used to distribute the source's RTP packets, and of the delays along
the links within that tree. It can also be used to measure partial the links within that tree. It can also be used to measure partial
path characteristics and to model distributions for packet jitter. path characteristics and to model distributions for packet jitter.
At least one packet MUST have been received for each sequence number
reported upon in this block. If this block type is used to report
timestamps for a series of sequence numbers that includes lost
packets, several blocks are required. If duplicate packets have been
received for a given sequence number, and those packets differ in
their receiver timestamps, any timestamp other than the earliest MUST
NOT be reported. This is to ensure consistency among reports.
Timestamps consume more bits than loss or duplicate information, and Timestamps consume more bits than loss or duplicate information, and
do not lend themselves to run length encoding. The use of thinning do not lend themselves to run length encoding. The use of thinning
is encouraged to limit the size of Timestamp Report Blocks. is encouraged to limit the size of Timestamp Report Blocks.
The Timestamp Report Block has the following format: The Timestamp Report Block has the following format:
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=48 | rsvd. | T | length | | BT=3 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp 1 | | RTP timestamp 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp 2 | | RTP timestamp 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp n | | RTP timestamp n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Timestamp Report Block is identified by the constant 48. A Timestamp Report Block is identified by the constant 3.
rsvd.: 4 bits rsvd.: 4 bits
This field is reserved for future definition. In the absence of such This field is reserved for future definition. In the absence of
definition, the bits in this field MUST be set to zero and receivers such definition, the bits in this field MUST be set to zero and
MUST ignore this field. the receiver MUST ignore any Timestamp Report Block with a non-
zero value in this field.
thinning (T): 4 bits thinning (T): 4 bits
The amount of thinning performed on the sequence number space. As defined in Section 4.1.
length: 16 bits block length: 16 bits
Defined in Section 3. Defined in Section 3.
begin_seq: 32 bits begin_seq: 16 bits
The first sequence number that this block reports on. As defined in Section 4.1.
end_seq: 32 bits end_seq: 16 bits
The last sequence number that this block reports on plus one. As defined in Section 4.1.
RTP timestamp i: 32 bits RTP timestamp i: 32 bits
The timestamp reflects the packet arrival time at the receiver. It The timestamp reflects the packet arrival time at the receiver.
is preferable for the timestamp to be established at the link layer It is preferable for the timestamp to be established at the link
interface, or in any case as close as possible to the wire arrival layer interface, or in any case as close as possible to the wire
time. Units and format are the same as for the timestamp in RTP data arrival time. Units and format are the same as for the
packets. As opposed to RTP data packet timestamps, in which nominal timestamp in RTP data packets. As opposed to RTP data packet
values may be used instead of system clock values in order to convey timestamps, in which nominal values may be used instead of
information useful for periodic playout, the receiver timestamps system clock values in order to convey information useful for
should reflect the actual time as closely as possible. The initial periodic playout, the receiver timestamps should reflect the
value of the timestamp is random, and subsequent timestamps are off- actual time as closely as possible. The initial value of the
set from this value. timestamp is random, and subsequent timestamps are offset from
this value.
4.4 Statistics Summary Report Block 4.4 Statistics Summary Report Block
This block reports statistics beyond the information carried in the This block reports statistics beyond the information carried in the
standard RTCP packet format, but not as fine grained as that carried standard RTCP packet format, but not as fine grained as that carried
in the report blocks previously described. Information is recorded in the report blocks previously described. Information is recorded
about lost packets, duplicate packets, jitter measurements, and TTL about lost packets, duplicate packets, jitter measurements, and TTL
values (TTL values being taken from the TTL field of IPv4 packets, if values (TTL values being taken from the TTL field of IPv4 packets, if
the data packets are carried over IPv4). Such information can be the data packets are carried over IPv4). Such information can be
useful for network management. useful for network management.
The packet contents are dependent upon a bit vector carried in the The report block contents are dependent upon a bit vector carried in
first part of the header. Not all values need to be carried in each the first part of the header. Not all parameters need to be reported
packet. Header fields for values not carried are not included in the in each block. Flags indicate which are and which are not reported.
packet. The fields corresponding to unreported parameters MUST be set to
zero. The receiver MUST ignore any Statistics Summary Report Block
with a non-zero value in any field flagged as unreported.
The Statistics Summary Report Block has the following format: The Statistics Summary Report Block has the following format:
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=1 |L|D|J|T|resvd. | length | | BT=4 |L|D|J|T|resvd. | block length = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lost_packets | | lost_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dup_packets | | dup_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_jitter | | min_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max_jitter | | max_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| avg_jitter | | avg_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dev_jitter | | dev_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_ttl | max_ttl | avg_ttl | dev_ttl | | min_ttl | max_ttl | avg_ttl | dev_ttl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Statistics Summary block is identified by the constant 1. A Statistics Summary Report Block is identified by the constant
4.
content bits (L,D,J,T): 4 bits loss report flag (L): 1 bit
Bit set to 1 if packet contains (L)oss, (D)uplicate, (J)itter, and/or Bit set to 1 if the lost_packets field contains a report, 0
(T)TL report. otherwise.
duplicate report flag (D): 1 bit
Bit set to 1 if the dup_packets field contains a report, 0
otherwise.
jitter flag (J): 1 bit
Bit set to 1 if the min_jitter, max_jitter, avg_jitter, and
dev_jitter fields all contain reports, 0 if none of them do.
TTL flag (T): 1 bit
Bit set to 1 if the min_ttl, max_ttl, avg_ttl, and dev_ttl
fields all contain reports, 0 if none of them do.
resvd.: 4 bits resvd.: 4 bits
This field is reserved for future definition. In the absence of such This field is reserved for future definition. In the absence of
definition, all bits in this field MUST be set to zero, and receivers such definition, all bits in this field MUST be set to zero, and
MUST ignore this field. the receiver MUST ignore any Statistics Summary Report Block
with a non-zero value in this field.
length: 16 bits block length: 16 bits
Defined in Section 3. The constant 9, in accordance with the definition of this field
in Section 3.
begin_seq: 32 bits begin_seq: 16 bits
The first sequence number that this block reports on. As defined in Section 4.1.
end_seq: 32 bits end_seq: 16 bits
The last sequence number that this block reports on plus one. As defined in Section 4.1.
lost_packets: 32 bits lost_packets: 32 bits
Number of lost packets in the above sequence number interval. Number of lost packets in the above sequence number interval.
dup_packets: 32 bits dup_packets: 32 bits
Number of duplicate packets in the above sequence number interval. Number of duplicate packets in the above sequence number
interval.
min_jitter: 32 bits min_jitter: 32 bits
The minimum relative transit time between two packets in the above The minimum relative transit time between two packets in the
sequence number interval. All jitter values are measured as the dif- above sequence number interval. All jitter values are measured
ference between a packet's RTP timestamp and the reporter's clock at as the difference between a packet's RTP timestamp and the
the time of arrival, measured in the same units. reporter's clock at the time of arrival, measured in the same
units.
max_jitter: 32 bits max_jitter: 32 bits
The maximum relative transit time between two packets in the above The maximum relative transit time between two packets in the
sequence number interval. above sequence number interval.
avg_jitter: 32 bits avg_jitter: 32 bits
The average relative transit time between each two packet series in The average relative transit time between each two packet series
the above sequence number interval. in the above sequence number interval.
dev_jitter: 32 bits dev_jitter: 32 bits
The standard deviation of the relative transit time between each two The standard deviation of the relative transit time between each
packet series in the above sequence number interval. two packet series in the above sequence number interval.
min_ttl: 8 bits min_ttl: 8 bits
The minimum TTL value of data packets in sequence number range. The minimum TTL value of data packets in sequence number range.
max_ttl: 8 bits max_ttl: 8 bits
The maximum TTL value of data packets in sequence number range. The maximum TTL value of data packets in sequence number range.
avg_ttl: 8 bits avg_ttl: 8 bits
The average TTL value of data packets in sequence number range. The average TTL value of data packets in sequence number range.
dev_ttl: 8 bits dev_ttl: 8 bits
The standard deviation of TTL values of data packets in sequence num- The standard deviation of TTL values of data packets in sequence
ber range. number range.
4.5 Receiver Timestamp Report Block 4.5 Receiver Timestamp Report Block
This block extends RTCP's timestamp reporting so that non-senders may This block extends RTCP's timestamp reporting so that non-senders may
also send timestamps. It recapitulates the NTP timestamp fields from also send timestamps. It recapitulates the NTP timestamp fields from
the RTCP Sender Report [7, Sec. 6.3.1]. A non-sender may estimate the RTCP Sender Report [7, Sec. 6.3.1]. A non-sender may estimate
its RTT to other participants, as proposed in [9], by sending this its RTT to other participants, as proposed in [11], by sending this
report block and receiving DLRR report blocks (see next section) in report block and receiving DLRR Report Blocks (see next section) in
reply. reply.
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=2 | reserved | | BT=5 | reserved | block length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, most significant word | | NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word | | NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Receiver Timestamp block is identified by the constant 2. A Receiver Timestamp Report Block is identified by the constant
5.
reserved: 24 bits reserved: 8 bits
This field is reserved for future definition. In the absence of such This field is reserved for future definition. In the absence of
definition, the bits in this field MUST be set to zero, and receivers such definition, the bits in this field MUST be set to zero and
MUST ignore this field. the receiver MUST ignore any Receiver Timestamp Report Block
with a non-zero value in this field.
block length: 16 bits
The constant 2, in accordance with the definition of this field
in Section 3.
NTP timestamp: 64 bits NTP timestamp: 64 bits
Indicates the wallclock time when this block was sent so that it may Indicates the wallclock time when this block was sent so that it
be used in combination with timestamps returned in DLRR report blocks may be used in combination with timestamps returned in DLRR
from other receivers to measure round-trip propagation to those Report Blocks (see next section) from other receivers to measure
receivers. Receivers should expect that the measurement accuracy of round-trip propagation to those receivers. Receivers should
the timestamp may be limited to far less than the resolution of the expect that the measurement accuracy of the timestamp may be
NTP timestamp. The measurement uncertainty of the timestamp is not limited to far less than the resolution of the NTP timestamp.
indicated as it may not be known. A report block sender that can keep The measurement uncertainty of the timestamp is not indicated as
track of elapsed time but has no notion of wallclock time may use the it may not be known. A report block sender that can keep track
elapsed time since joining the session instead. This is assumed to be of elapsed time but has no notion of wallclock time may use the
less than 68 years, so the high bit will be zero. It is permissible elapsed time since joining the session instead. This is assumed
to use the sampling clock to estimate elapsed wallclock time. A to be less than 68 years, so the high bit will be zero. It is
report sender that has no notion of wallclock or elapsed time may set permissible to use the sampling clock to estimate elapsed
the NTP timestamp to zero. wallclock time. A report sender that has no notion of wallclock
or elapsed time may set the NTP timestamp to zero.
4.6 DLRR Report Block 4.6 DLRR Report Block
This block extends RTCP's DLSR mechanism [7, Sec. 6.3.1] so that non- This block extends RTCP's delay since last sender report (DLSR)
senders may also calculate round trip times, as proposed in [9]. It mechanism [7, Sec. 6.3.1] so that non-senders may also calculate
is termed DLRR for Delay since Last Receiver Report, and may be sent round trip times, as proposed in [11]. It is termed DLRR for delay
in response to a Receiver Timestamp report block (see previous sec- since last receiver report, and may be sent in response to a Receiver
tion) from a receiver to allow that receiver to calculate its round Timestamp Report Block (see previous section) from a receiver to
trip time to the respondant. The report consists of one or more 3 allow that receiver to calculate its round trip time to the
word sub-blocks: one sub-block per receiver report. respondant. The report consists of one or more 3 word sub-blocks:
one sub-block per receiver 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=3 | reserved | length | | BT=6 | reserved | block length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first receiver) | sub- | SSRC_1 (SSRC of first receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| last RR (LRR) | 1 | last RR (LRR) | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last RR (DLRR) | | delay since last RR (DLRR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second receiver) | sub- | SSRC_2 (SSRC of second receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2 : ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
block type (BT): 8 bits block type (BT): 8 bits
A DLRR block is identified by the constant 3. A DLRR Report Block is identified by the constant 6.
reserved: 8 bits reserved: 8 bits
This field is reserved for future definition. In the absence of such This field is reserved for future definition. In the absence of
definition, all bits in this field MUST be set to zero, and receivers such definition, all bits in this field MUST be set to zero, the
MUST ignore this field. receiver MUST ignore any DLRR Report Block with a non-zero value
in this field.
length: 16 bits block length: 16 bits
Defined in Section 3. Defined in Section 3.
last RR timestamp (LRR): 32 bits last RR timestamp (LRR): 32 bits
The middle 32 bits out of 64 in the NTP timestamp (as explained in The middle 32 bits out of 64 in the NTP timestamp (as explained
the previous section) received as part of a Receiver Timestamp report in the previous section) received as part of a Receiver
block from participant SSRC_n. If no such block has been received, Timestamp Report Block from participant SSRC_n. If no such block
the field is set to zero. has been received, the field is set to zero.
delay since last RR (DLRR): 32 bits delay since last RR (DLRR): 32 bits
The delay, expressed in units of 1/65536 seconds, between receiving The delay, expressed in units of 1/65536 seconds, between
the last Receiver Timestamp report block from participant SSRC_n and receiving the last Receiver Timestamp Report Block from
sending this DLRR report block. If no Receiver Timestamp report participant SSRC_n and sending this DLRR Report Block. If no
block has been received yet from SSRC_n, the DLRR field is set to Receiver Timestamp Report Block has been received yet from
zero (or the DLRR is omitted entirely). Let SSRC_r denote the SSRC_n, the DLRR field is set to zero (or the DLRR is omitted
receiver issuing this DLRR report block. Participant SSRC_n can com- entirely). Let SSRC_r denote the receiver issuing this DLRR
pute the round-trip propagation delay to SSRC_r by recording the time Report Block. Participant SSRC_n can compute the round-trip
A when this Receiver Timestamp report block is received. It calcu- propagation delay to SSRC_r by recording the time A when this
lates the total round-trip time A-LSR using the last SR timestamp Receiver Timestamp Report Block is received. It calculates the
(LSR) field, and then subtracting this field to leave the round-trip total round-trip time A-LSR using the last SR timestamp (LSR)
propagation delay as (A- LSR - DLSR). This is illustrated in [7, Fig. field, and then subtracting this field to leave the round-trip
propagation delay as A-LSR-DLSR. This is illustrated in [7, Fig.
2]. 2].
4.7 VoIP Metrics Report Block 4.7 VoIP Metrics Report Block
4.7.1 Summary The VoIP Metrics Report Block provides metrics for monitoring voice
The VoIP Metrics report block provides metrics for monitoring voice
over IP (VoIP) calls. These metrics include packet loss and discard over IP (VoIP) calls. These metrics include packet loss and discard
metrics, delay metrics, analog metrics, and voice quality metrics. metrics, delay metrics, analog metrics, and voice quality metrics.
The block reports separately on packets lost on the IP channel, and The block reports separately on packets lost on the IP channel, and
those that have been received but then discarded by the receiving those that have been received but then discarded by the receiving
jitter buffer. It also reports on the combined effect of losses and jitter buffer. It also reports on the combined effect of losses and
discards, as both have equal effect on call quality. discards, as both have equal effect on call quality.
In order to properly assess the quality of a Voice over IP call it is In order to properly assess the quality of a Voice over IP call it is
desirable to consider the degree of burstiness of packet loss [4]. desirable to consider the degree of burstiness of packet loss [10].
Following a Gilbert-Elliott model [5], an interval, bounded by lost Following a Gilbert-Elliott model [2], a period of time, bounded by
and/or discarded packets, with a high rate of losses and/or discards lost and/or discarded packets, with a high rate of losses and/or
is a "burst," and an interval between two bursts is a "gap." Bursts discards is a "burst," and a period of time between two bursts is a
correspond to intervals of time during which the packet loss rate is "gap." Bursts correspond to periods of time during which the packet
high enough to produce noticeable degradation in audio quality. Gaps loss rate is high enough to produce noticeable degradation in audio
correspond to periods of time during which only isolated lost packets quality. Gaps correspond to periods of time during which only
may occur, and in general these can be masked by packet loss con- isolated lost packets may occur, and in general these can be masked
cealment. Delay reports include the transit delay between RTCP end by packet loss concealment. Delay reports include the transit delay
points and the VoIP end system processing delays, both of which con- between RTCP end points and the VoIP end system processing delays,
tribute to the user perceived delay. Additional metrics include sig- both of which contribute to the user perceived delay. Additional
nal, echo, noise, and distortion levels. Call quality metrics metrics include signal, echo, noise, and distortion levels. Call
include R factors (E Model) [5] and MOS scores (Mean Opinion Scores). quality metrics include R factors (as described by the E Model
defined in [2]) and mean opinion scores (MOS scores).
An implementation that sends these blocks SHOULD send at least one An implementation that sends these blocks SHOULD send at least one
every ten seconds for the duration of a call, and SHOULD send one every ten seconds for the duration of the call, SHOULD send one
upon call termination. An implementation MUST supply values for all whenever a CODEC type change or other significant change occurs,
fields defined here. SHOULD send one when significant call quality degradation is detected
and SHOULD send one upon call termination. Implementations MUST
4.7.2 VoIP Metrics block structure provide values for all the fields defined here. For certain metrics,
if the value is undefined or unknown, then the specified default or
unknown field value MUST be provided.
The block is encoded as seven 32-bit words: The block is encoded as seven 32-bit words:
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=64 | reserved | length=6 | | BT=7 | reserved | block length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| loss rate | discard rate | burst duration | | loss rate | discard rate | burst density | gap density |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burst density | gap duration | gap density | | burst duration | gap duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| round trip delay | end system delay | | round trip delay | end system delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signal power | doubletalk | noise level | Gmin | | signal power | RERL | noise level | Gmin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R factor | ext. R factor | MOS-LQ | MOS-CQ | | R factor | ext. R factor | MOS-LQ | MOS-CQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RX Config | JB Nominal | JB Maximum | JB Abs Max | | RX config | JB nominal | JB maximum | JB abs max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A VoIP Metrics block is identified by the constant 64. A VoIP Metrics Report Block is identified by the constant 7.
reserved: 8 bits reserved: 8 bits
This field is reserved for future definition. In the absence of such This field is reserved for future definition. In the absence of
definition, all bits in this field MUST be set to zero, and receivers such definition, all bits in this field MUST be set to zero and
MUST ignore this field. the receiver MUST ignore any VoIP Metrics Report Block with a
non-zero value in this field.
length: 16 bits block length: 16 bits
As defined in Section 3, this is the constant 6 for this block type. The constant 6, in accordance with the definition of this field
in Section 3.
4.7.3 Packet loss and discard metrics The remaining fields are described in the following six sections:
Packet Loss and Discard Metrics, Delay Metrics, Signal Related
Metrics, Call Quality or Transmission Quality Metrics, Configuration
Metrics, and Jitter Buffer Parameters.
4.7.1 Packet Loss and Discard Metrics
It is very useful to distinguish between packets lost by the network It is very useful to distinguish between packets lost by the network
and those discarded due to jitter. Both have equal effect on the and those discarded due to jitter. Both have equal effect on the
quality of the voice stream however having separate counts helps quality of the voice stream however having separate counts helps
identify the source of quality degradation. These fields MUST be pop- identify the source of quality degradation. These fields MUST be
ulated. populated.
loss rate: 8 bits loss rate: 8 bits
The fraction of RTP data packets from the source lost since the The fraction of RTP data packets from the source lost since the
beginning of reception, expressed as a fixed point number with the beginning of reception, expressed as a fixed point number with
binary point at the left edge of the field. This value is calculated the binary point at the left edge of the field. This value is
by dividing the total number of packets lost (after the effects of calculated by dividing the total number of packets lost (after
applying any error protection such as FEC) by the total number of the effects of applying any error protection such as FEC) by the
packets expected, multiplying the result of the division by 256, and total number of packets expected, multiplying the result of the
taking the integer part. The numbers of duplicated packets and dis- division by 256, limiting the maximum value to 255 (to avoid
carded packets do not enter into this calculation. Since receivers overflow), and taking the integer part. The numbers of
cannot be required to maintain unlimited buffers, a receiver MAY cat- duplicated packets and discarded packets do not enter into this
egorize late-arriving packets as lost. The degree of lateness that calculation. Since receivers cannot be required to maintain
triggers a loss SHOULD be significantly greater than that which trig- unlimited buffers, a receiver MAY categorize late-arriving
gers a discard. packets as lost. The degree of lateness that triggers a loss
SHOULD be significantly greater than that which triggers a
discard.
discard rate: 8 bits discard rate: 8 bits
The fraction of RTP data packets from the source that have been dis The fraction of RTP data packets from the source that have been
carded since the beginning of reception, due to late or early discarded since the beginning of reception, due to late or early
arrival, under-run or overflow at the receiving jitter buffer. This arrival, under-run or overflow at the receiving jitter buffer.
value is expressed as a fixed point number with the binary point at This value is expressed as a fixed point number with the binary
the left edge of the field. It is calculated by dividing the total point at the left edge of the field. It is calculated by
number of packets discarded (excluding duplicate packet discards) by dividing the total number of packets discarded (excluding
the total number of packets expected, multiplying the result of the duplicate packet discards) by the total number of packets
division by 256, and taking the integer part. expected, multiplying the result of the division by 256,
limiting the maximum value to 255 (to avoid overflow), and
taking the integer part.
burst metrics: 4.7.2 Burst Metrics
A burst is defined as a longest sequence of packets bounded by lost
or discarded packets with the constraint that within a burst the num-
ber of successive packets that were received, and not discarded due
to delay variation, is less than some value Gmin. A gap is defined
as the interval between bursts, and has the property that any lost or
discarded packets must be preceded and followed by at least Gmin
packets that were received and not discarded. This gives a maximum
loss/discard density within a gap of: 1 / (Gmin + 1).
burst duration: 16 bits A burst, informally, is a period of high packet losses and/or
The mean duration, expressed in milliseconds, of the burst intervals discards. Formally, a burst is defined as a longest sequence of
that have occurred since the beginning of reception. The duration of packets bounded by lost or discarded packets with the constraint that
each interval is calculated based upon the packets that mark the within a burst any sequence of successive packets that were received,
beginning and end of that interval. It is equal to the timestamp of and not discarded due to delay variation, is of length less than a
the end packet, plus the duration of the end packet, minus the times value Gmin.
tamp of the beginning packet. If the actual values are not avail
able, estimated values MUST be used. If there have been no burst
intervals, the burst duration value MUST be zero.
burst density: 8 bits A gap, informally, is a period of low packet losses and/or discards.
The fraction of RTP data packets within burst intervals since the Formally, a gap is defined as any of the following: (a) the period
beginning of reception that were either lost or discarded. This from the start of an RTP session to the receipt time of the last
value is expressed as a fixed point number with the binary point at received packet before the first burst, (b) the period from the end
the left edge of the field. It is calculated by dividing the total of the last burst to either the time of the report or the end of the
number of packets lost or discarded (excluding duplicate packet dis- RTP session, whichever comes first, or (c) the period of time between
cards) within burst intervals by the total number of packets expected two bursts.
within the burst intervals, multiplying the result of the division by
256, and taking the integer part.
gap duration: 16 bits For the purpose of determining if a lost or discarded packet near the
The mean duration, expressed in milliseconds, of the gap intervals start or end of an RTP session is within a gap or a burst it is
that have occurred since the beginning of reception. The duration of assumed that the RTP session is preceded and followed by at least
each interval is calculated based upon the packet that marks the end Gmin received packets, and that the time of the report is followed by
of the prior burst and the packet that marks the beginning of the at least Gmin received packets.
subsequent burst. It is equal to the timestamp of the subsequent
burst packet, minus the timestamp of the prior burst packet, plus the
duration of the prior burst packet. If the actual values are not
available, estimated values MUST be used. In the case of a gap that
occurs at the beginning of reception, the sum of the timestamp of the
prior burst packet and the duration of the prior burst packet are
replaced by the reception start time. In the case of a gap that
occurs at the end of reception, the timestamp of the subsequent burst
packet is replaced by the reception end time. If there have been no
gap intervals, the gap duration value MUST be zero.
gap density: 8 bits A gap has the property that any lost or discarded packets within the
The fraction of RTP data packets within inter-burst gaps since the gap must be preceded and followed by at least Gmin packets that were
beginning of reception that were either lost or discarded. The value received and not discarded. This gives a maximum loss/discard
is expressed as a fixed point number with the binary point at the density within a gap of: 1 / (Gmin + 1).
left edge of the field. It is calculated by dividing the total num-
ber of packets lost or discarded (excluding duplicate packet dis
cards) within gap intervals by the total number of packets expected
within the gap intervals, multiplying the result of the division by
256, and taking the integer part.
For example, if the packet spacing is 10mS and a 1 denotes a received A Gmin value of 16 is RECOMMENDED as it results in gap
packet and 0, a lost, and X, a discarded, packet then the following characteristics that correspond to good quality (i.e. low packet loss
pattern: rate, a minimum distance of 16 received packets between lost packets)
and hence differentiates nicely between good and poor quality
periods.
For example, a 1 denotes a received, 0 a lost, and X a discarded
packet in the following pattern covering 64 packets:
11110111111111111111111X111X1011110111111111111111111X111111111 11110111111111111111111X111X1011110111111111111111111X111111111
|--burst---| |---------gap----------|--burst---|------------gap------------|
would have a burst duration of 120mS, a burst density of 0.33, a gap The burst consists of the twelve packets indicated above, starting at
duration of 510mS and a gap density of 0.04, for a GMIN value of 4 or a discarded packet and ending at a lost packet. The first gap starts
larger. at the beginning of the session and the second gap ends at the time
of the report.
4.7.4 Delay metrics If the packet spacing is 10 ms and the Gmin value is the recommended
value of 16, the burst duration is 120 ms, the burst density 0.33,
the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04.
This would result in reported values as follows (see field
descriptions for semantics and details on how these are calculated):
loss density 12, which corresponds to 5%
discard density 12, which corresponds to 5%
burst density 84, which corresponds to 33%
gap density 10, which corresponds to 4%
burst duration 120, value in milliseconds
gap duration 520, value in milliseconds
burst density: 8 bits
The fraction of RTP data packets within burst periods since the
beginning of reception that were either lost or discarded. This
value is expressed as a fixed point number with the binary point
at the left edge of the field. It is calculated by dividing the
total number of packets lost or discarded (excluding duplicate
packet discards) within burst periods by the total number of
packets expected within the burst periods, multiplying the
result of the division by 256, limiting the maximum value to 255
(to avoid overflow), and taking the integer part.
gap density: 8 bits
The fraction of RTP data packets within inter-burst gaps since
the beginning of reception that were either lost or discarded.
The value is expressed as a fixed point number with the binary
point at the left edge of the field. It is calculated by
dividing the total number of packets lost or discarded
(excluding duplicate packet discards) within gap periods by the
total number of packets expected within the gap periods,
multiplying the result of the division by 256, limiting the
maximum value to 255 (to avoid overflow), and taking the integer
part.
burst duration: 16 bits
The mean duration, expressed in milliseconds, of the burst
periods that have occurred since the beginning of reception.
The duration of each period is calculated based upon the packets
that mark the beginning and end of that period. It is equal to
the timestamp of the end packet, plus the duration of the end
packet, minus the timestamp of the beginning packet. If the
actual values are not available, estimated values MUST be used.
If there have been no burst periods, the burst duration value
MUST be zero.
gap duration: 16 bits
The mean duration, expressed in milliseconds, of the gap periods
that have occurred since the beginning of reception. The
duration of each period is calculated based upon the packet that
marks the end of the prior burst and the packet that marks the
beginning of the subsequent burst. It is equal to the timestamp
of the subsequent burst packet, minus the timestamp of the prior
burst packet, plus the duration of the prior burst packet. If
the actual values are not available, estimated values MUST be
used. In the case of a gap that occurs at the beginning of
reception, the sum of the timestamp of the prior burst packet
and the duration of the prior burst packet are replaced by the
reception start time. In the case of a gap that occurs at the
end of reception, the timestamp of the subsequent burst packet
is replaced by the reception end time. If there have been no
gap periods, the gap duration value MUST be zero.
4.7.3 Delay Metrics
For the purpose of the following definitions, the RTP interface is For the purpose of the following definitions, the RTP interface is
the interface between the RTP instance and the voice application the interface between the RTP instance and the voice application
(i.e. FEC/de-interleaving/ de-multiplexing, jitter buffer). For (i.e. FEC, de-interleaving, de-multiplexing, jitter buffer). For
example, the time delay due to RTP payload multiplexing would be con- example, the time delay due to RTP payload multiplexing would be
sidered to be part of the voice application or end-system delay considered to be part of the voice application or end-system delay
whereas delay due to multiplexing RTP frames within a UDP frame would whereas delay due to multiplexing RTP frames within a UDP frame would
be considered part of the RTP reported delay. This distinction is be considered part of the RTP reported delay. This distinction is
consistent with the use of RTCP for delay measurements. consistent with the use of RTCP for delay measurements.
round trip delay: 16 bits round trip delay: 16 bits
The most recently calculated round trip time between RTP interfaces, The most recently calculated round trip time between RTP
expressed in milliseconds. This value is the time of receipt of the interfaces, expressed in milliseconds. This value is the time of
most recent RTCP packet from source SSRC, minus the LSR (last SR) receipt of the most recent RTCP packet from source SSRC, minus
time reported in its SR (sender report), minus the DLSR (delay since the LSR (last SR) time reported in its SR (sender report), minus
last SR) reported in its SR. A non-zero LSR value is REQUIRED in the DLSR (delay since last SR) reported in its SR. A non-zero
order to calculate round trip delay. A value of 0 is permissible dur- LSR value is REQUIRED in order to calculate round trip delay. A
ing the first 2-3 RTCP exchanges as insufficient data may be avail- value of 0 is permissible during the first two or three RTCP
able to determine delay however MUST be populated as soon as a delay exchanges as insufficient data may be available to determine
estimate is available. delay however MUST be populated as soon as a delay estimate is
available.
end system delay: 16 bits end system delay: 16 bits
The most recently estimated end system delay, expressed in millisec- The most recently estimated end system delay, expressed in
onds. End system delay is defined as the total encoding, decoding milliseconds. End system delay is defined as the total
and jitter buffer delay determined at the reporting endpoint. This encoding, decoding and jitter buffer delay determined at the
is the time required for an RTP frame to be buffered, decoded, con- reporting endpoint. This is the time required for an RTP frame
verted to analog form, looped back at the local analog interface, to be buffered, decoded, converted to analog form, looped back
encoded, and made available for transmission as an RTP frame. The at the local analog interface, encoded, and made available for
manner in which this value is estimated is implementation dependent. transmission as an RTP frame. The manner in which this value is
This parameter MUST be provided in all VoIP metrics reports. estimated is implementation dependent. This parameter MUST be
provided in all VoIP metrics reports.
Note that the one way symmetric VoIP segment delay may be calculated Note that the one way symmetric VoIP segment delay may be calculated
from the round trip and end system delays as follows. If the round from the round trip and end system delays as follows. If the round
trip delay is denoted RTD and the end system delays associated with trip delay is denoted RTD and the end system delays associated with
the two endpoints are ESD(A) and ESD(B) then: the two endpoints are ESD(A) and ESD(B) then:
one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2 one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2
4.7.5 Signal related metrics 4.7.4 Signal Related Metrics
The following metrics are intended to provide real time information The following metrics are intended to provide real time information
related to the non-packet elements of the voice over IP system to related to the non-packet elements of the voice over IP system to
assist with the identification of problems affecting call quality. assist with the identification of problems affecting call quality.
The values identified below must be determined for the received audio The values identified below must be determined for the received audio
signal. The information required to populate these fields may not be signal. The information required to populate these fields may not be
available in all systems, although it is strongly recommended that available in all systems, although it is strongly recommended that
this data SHOULD be provided to support problem diagnosis. this data SHOULD be provided to support problem diagnosis.
signal level: 8 bits signal power: 8 bits
The voice signal relative level is defined as the ratio of the signal The voice signal relative level is defined as the ratio of the
level to overflow signal level, expressed in decibels as a signed signal level to overflow signal level, expressed in decibels as
integer in two's complement form. This is measured only for packets a signed integer in two's complement form. This is measured
containing speech energy. The intent of this metric is not to pro- only for packets containing speech energy. The intent of this
vide a precise measurement of the signal level but to provide a real metric is not to provide a precise measurement of the signal
time indication that the signal level may be excessively high or low. level but to provide a real time indication that the signal
If the full range (overflow level) of the Vocoder's Digital to Analog level may be excessively high or low. If the full range
conversion function is +/- L and the value of a decoded sample during (overflow level) of the Vocoder's digital to analog conversion
a talkspurt is V then the signal level is given by function is +/- L and the value of a decoded sample during a
talkspurt is V then the signal level is given by:
Signal level = 10 log10 ( mean( abs(V) / L ) ) signal level = 10 log10 ( mean( abs(V) / L ) )
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
doubletalk level: 8 bits residual echo return loss (RERL): 8 bits
The doubletalk level is defined as the proportion of voice frame The residual echo return loss is defined as the sum of the
intervals during which speech energy was present in both sending and measured echo return loss (ERL) and the echo return loss
receiving directions. High levels of doubletalk can provide an indi- enhancement (ERLE) expressed in dB as a signed integer in two's
cation of delay or echo related problems. The value is expressed as a complement form. It defines the ratio of a transmitted voice
fixed point number with the binary point at the left edge of the signal that is reflected back to the talker. A low level of
field. It is calculated by dividing the total number of voice frame echo return loss (say less than 20 dB) in conjunction with some
intervals by the number of voice frame intervals during which energy delay can lead to hollowness or audible echo. A high level of
was present in both sending and receiving directions, multiplying echo return loss (say over 40 dB) is preferable.
the result of the division by 256, and taking the integer part.
A value of 255 indicates that this value is unavailable The ERL and ERLE parameters are often available directly from the
echo cancellor contained within the VoIP end system. They relate to
the echo on the external network attached to the end point.
noise level: 8 bits In the case of a VoIP gateway this would be line echo that typically
The noise level is defined as the ratio of the silent period back occurs at 2-4 wire conversion points in the network. Echo return
ground noise level to overflow signal power, expressed in decibels as loss from typical 2-4 wire conversions can be in the 8-12 dB range.
a signed integer in two's complement form. If the full range (over- A line echo cancellor can provide an ERLE of 30 dB or more and hence
flow level) of the Vocoder's Digital to Analog conversion function is reduce this to 40-50 dB. In the case of an IP phone this could be
+/- L and the value of a decoded sample during a silence period is V residual acoustic echo from speakerphone operation, and may more
then the noise level is given by correctly be termed terminal coupling loss (TCL). A typical handset
would result in 40-50 dB of echo due to acoustic feedback.
Noise level = 10 log10 ( mean( abs(V) / L ) ) Typical values for RERL are as follows:
(i) IP gateway connected to circuit switched network with 2 wire loop
Without echo cancellation, typical 2-4 wire convertor ERL of 12 dB
RERL = ERL + ERLE = 12 + 0 = 12 dB
(ii) IP gateway connected to circuit switched network with 2 wire loop
With echo cancellor that improves echo by 30 dB
RERL = ERL + ERLE = 12 + 30 = 42 dB
(iii) IP phone with conventional handset
Acoustic coupling from handset speaker to microphone 40 dB
Residual echo return loss = TCL = 40 dB
If we denote the "local" end of the VoIP path as A and the remote end
as B and if the sender loudness rating (SLR) and receiver loudness
rating (RLR) are known for A (default values 8 dB and 2 dB
respectively), then the echo loudness level at end A (talker echo
loudness rating or TELR) is given by:
TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)
TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)
Hence in order to incorporate echo into a voice quality estimate at
the A end of a VoIP connection it is desirable to send the ERL + ERLE
value from B to A.
For an IP phone with handset this metric MUST be set to the designed
or measured terminal coupling loss, which would typically be 40-50
dB.
For a PC softphone or speakerphone this metric MUST be set to either
the value reported by the acoustic echo cancellor or to 127 to
indicate an undefined value.
For an IP gateway with ERL and ERLE measurements this metric MUST be
reported as ERL + ERLE.
For an IP gateway without ERL and ERLE measurement capability then
this metric MUST be reported as 12 dB if line echo cancellation is
disabled and 40 dB if line echo cancellation is enabled.
noise level: 8 bits
The noise level is defined as the ratio of the silent period
back ground noise level to overflow signal power, expressed in
decibels as a signed integer in two's complement form. If the
full range (overflow level) of the Vocoder's digital to analog
conversion function is +/- L and the value of a decoded sample
during a silence period is V then the noise level is given by
noise level = 10 log10 ( mean( abs(V) / L ) )
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
4.7.6 Call quality/ transmission quality metrics Gmin
See Configuration Parameters (Section 4.7.6, below).
The following metrics are direct measures of the transmission quality 4.7.5 Call Quality or Transmission Quality Metrics
or call quality, and incorporate the effects of CODEC type, packet
loss, discard, burstiness, delay etc. These metrics may not be The following metrics are direct measures of the call quality or
available in all systems however SHOULD be provided in order to sup- transmission quality, and incorporate the effects of CODEC type,
port problem diagnosis. packet loss, discard, burstiness, delay etc. These metrics may not
be available in all systems however SHOULD be provided in order to
support problem diagnosis.
R factor: 8 bits R factor: 8 bits
The R factor is a voice quality metric describing the segment of the The R factor is a voice quality metric describing the segment of
call that is carried over this RTP session. It is expressed as an the call that is carried over this RTP session. It is expressed
integer in the range 0 to 100, with a value of 94 corresponding to as an integer in the range 0 to 100, with a value of 94
"toll quality" and values of 50 or less regarded as unusable. This corresponding to "toll quality" and values of 50 or less
metric is defined as including the effects of delay, consistent with regarded as unusable. This metric is defined as including the
ITU-T G.107 [6] and ETSI TS 101 329-5 [5]. effects of delay, consistent with ITU-T G.107 [4] and ETSI TS
101 329-5 [2].
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
ext. R factor: 8 bits ext. R factor: 8 bits
The external R factor is a voice quality metric describing the seg The external R factor is a voice quality metric describing the
ment of the call that is carried over a network segment external to seg ment of the call that is carried over a network segment
the RTP segment, for example a cellular network. Its values are external to the RTP segment, for example a cellular network. Its
interpreted in the same manner as for the RTP R factor. This metric values are interpreted in the same manner as for the RTP R
is defined as including the effects of delay, consistent with ITU-T factor. This metric is defined as including the effects of
G.107 [6] and ETSI TS 101 329-5 [5], and relates to the outward voice delay, consistent with ITU-T G.107 [4] and ETSI TS 101 329-5
path from the Voice over IP termination for which this metrics block [2], and relates to the outward voice path from the Voice over
applies. IP termination for which this metrics block applies.
A value of 127 indicates that this parameter is unavailable.
Note that an overall R factor may be estimated from the RTP segment R Note that an overall R factor may be estimated from the RTP segment R
factor and the external R factor, as follows: factor and the external R factor, as follows:
R total = RTP R factor + ext. R factor - 94 R total = RTP R factor + ext. R factor - 94
A value of 127 indicates that this parameter is unavailable.
MOS-LQ: 8 bits MOS-LQ: 8 bits
The estimated mean opinion score for listening quality (MOS-LQ) is a The estimated mean opinion score for listening quality (MOS-LQ)
voice quality metric on a scale from 1 to 5, in which 5 represents is a voice quality metric on a scale from 1 to 5, in which 5
excellent and 1 represents unacceptable. This metric is defined as represents excellent and 1 represents unacceptable. This metric
not including the effects of delay and can be compared to MOS scores is defined as not including the effects of delay and can be
obtained from listening quality (ACR) tests. It is expressed as an compared to MOS scores obtained from listening quality (ACR)
integer in the range 10 to 50, corresponding to MOS x 10. For exam- tests. It is expressed as an integer in the range 10 to 50,
ple, a value of 35 would correspond to an estimated MOS score of 3.5. corresponding to MOS x 10. For example, a value of 35 would
correspond to an estimated MOS score of 3.5.
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
MOS-CQ: 8 bits MOS-CQ: 8 bits
The estimated mean opinion score for conversational quality (MOS-CQ) The estimated mean opinion score for conversational quality
is defined as including the effects of delay and other effects that (MOS-CQ) is defined as including the effects of delay and other
would affect conversational quality. The metric may be calculated by effects that would affect conversational quality. The metric
converting an R factor determined according to ITU-T G.107 [6] or may be calculated by converting an R factor determined according
ETSI TS 101 329-5 [5] into an estimated MOS using the equation speci- to ITU-T G.107 [4] or ETSI TS 101 329-5 [2] into an estimated
fied in G.107 MOS using the equation specified in G.107. It is expressed as
an integer in the range 10 to 50, corresponding to MOS x 10, as
for MOS-LQ.
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
4.7.7 Configuration parameters: 4.7.6 Configuration Parameters
Gmin: 8 bits Gmin: 8 bits
The gap threshold. This field contains the value used for this The gap threshold. This field contains the value used for this
report block to determine if a gap exists. The recommended value of report block to determine if a gap exists. The recommended
16 (octal 0x10) corresponds to a burst interval having a minimum den- value of 16 corresponds to a burst period having a minimum
sity of 6.25% of lost or discarded packets, which may cause notice- density of 6.25% of lost or discarded packets, which may cause
able degradation in call quality; during gap intervals, if packet noticeable degradation in call quality; during gap periods, if
loss or dis card occurs, each lost or discarded packet would be pre- packet loss or dis card occurs, each lost or discarded packet
ceded by and followed by a sequence of at least 16 received non-dis- would be preceded by and followed by a sequence of at least 16
carded packets. Note that lost or discarded packets that occur received non-discarded packets. Note that lost or discarded
within Gmin packets of a report being generated may be reclassified packets that occur within Gmin packets of a report being
as being part of a burst or gap in later reports. ETSI TS 101 329-5 generated may be reclassified as being part of a burst or gap in
[5] defines a computationally efficient algorithm for measuring burst later reports. ETSI TS 101 329-5 [2] defines a computationally
and gap density using a packet loss/discard event driven approach. efficient algorithm for measuring burst and gap density using a
Gmin MUST not be zero and MUST be provided. packet loss/discard event driven approach. This algorithm is
reproduced in Appendix A.2 of the present document. Gmin MUST
not be zero and MUST be provided.
Receiver Configuration byte: receiver configuration byte (RX config): 8 bits
This byte consists of the following fields:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|PLC|JBA|JB rate| |PLC|JBA|JB rate|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
packet loss concealment (PLC): 2 bits
Standard (11) / enhanced (10) / disabled (01) / unspecified
(00). When PLC = 11 then a simple replay or interpolation
algorithm is being used to fill-in the missing packet.
This is typically able to conceal isolated lost packets
with loss rates under 3%. When PLC = 10 then an enhanced
interpolation algorithm is being used. This would
typically be able to conceal lost packets for loss rates of
10% or more. When PLC = 01 then silence is inserted in
place of lost packets. When PLC = 00 then no information
is available concerning the use of PLC however for some
CODECs this may be inferred.
PLC - packet loss concealment jitter buffer adaptive (JBA): 2 bits
Standard (11) / enhanced (10) / disabled (01) / unspecified (00). Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown
When PLC=11 then a simple replay or interpolation algorithm is being (00). When the jitter buffer is adaptive then its size is
used to fill-in the missing packet - this is typically able to con- being dynamically adjusted to deal with varying levels of
ceal isolated lost packets with loss rates under 3%. When PLC=10 jitter. When non-adaptive, the jitter buffer size is
then an enhanced interpolation algorithm is being used - this would maintained at a fixed level. When either adaptive or non-
typically be able to conceal lost packets for loss rates of 10% or adaptive modes are specified then the jitter buffer size
more. When PLC=01 then silence is inserted in place of lost packets.
When PLC = 00 then no information is available concerning the use of
PLC however for some CODECs this may be inferred.
JBA - Jitter Buffer Adaptive
Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When
Jitter Buffer is adaptive then its size is being dynamically adjusted
to deal with varying levels of jitter. When non-adaptive then the
Jitter Buffer size is maintained at a fixed level. When either adap-
tive or non-adaptive modes are specified then the Jitter Buffer Size
parameters below MUST be specified. parameters below MUST be specified.
JB Rate - Jitter Buffer Rate jitter buffer rate (JB rate): 4 bits
J = adjustment rate (0-15). This represents the implementation spe- J = adjustment rate (0-15). This represents the
cific adjustment rate of a Jitter Buffer in adaptive mode. This implementation specific adjustment rate of a jitter buffer
parameter is defined in terms of the approximate time taken to fully in adaptive mode. This parameter is defined in terms of the
adjust to a step change in peak to peak jitter from 30mS to 100mS approximate time taken to fully adjust to a step change in
such that: peak to peak jitter from 30 ms to 100 ms such that:
adjustment time = 2* J * frame size (mS) adjustment time = 2 * J * frame size (ms)
This parameter is intended only to provide a guide to the degree of This parameter is intended only to provide a guide to the
"aggressiveness" of a an adaptive jitter buffer and may be estimated. degree of "aggressiveness" of a an adaptive jitter buffer
A value of 0 indicates that the adjustment time is unknown for this and may be estimated. A value of 0 indicates that the
implementation. adjustment time is unknown for this implementation.
4.7.7 Jitter Buffer Parameters 4.7.7 Jitter Buffer Parameters
Jitter Buffer - nominal size in frames (8 bit) jitter buffer nominal size in frames (JB nominal): 8 bits
This is the current nominal fill point within the jitter buffer, This is the current nominal fill point within the jitter buffer,
which corresponds to the nominal jitter buffer delay for packets that which corresponds to the nominal jitter buffer delay for packets
arrive exactly on time. This parameter MUST be provided for both that arrive exactly on time. This parameter MUST be provided
fixed and adaptive jitter buffer implementations. for both fixed and adaptive jitter buffer implementations.
Jitter Buffer Maximum - size in frames (8 bit) jitter buffer maximum size in frames (JB maximum): 8 bits
This is the current maximum jitter buffer level corresponding to the This is the current maximum jitter buffer level corresponding to
earliest arriving packet that would not be discarded. In simple the earliest arriving packet that would not be discarded. In
queue implementations this may correspond to the nominal size. In simple queue implementations this may correspond to the nominal
adaptive jitter buffer implementations this value may dynamically size. In adaptive jitter buffer implementations this value may
vary up to Jitter Buffer Absolute Maximum. This parameter MUST be dynamically vary up to JB abs max (see below). This parameter
provided for both fixed and adaptive jitter buffer implementations. MUST be provided for both fixed and adaptive jitter buffer
implementations.
Jitter Buffer Absolute Maximum - size in frames (8 bit) jitter buffer absolute maximum size in frames (JB abs max): 8 bits
This is the absolute maximum size that the adaptive jitter buffer can This is the absolute maximum size that the adaptive jitter
reach under worst case jitter conditions. This parameter MUST be buffer can reach under worst case jitter conditions. This
provided for adaptive jitter buffer implementations and its value parameter MUST be provided for adaptive jitter buffer
MUST be set to JB Maximum for fixed jitter buffer implementations. implementations and its value MUST be set to JB maximum for
fixed jitter buffer implementations.
Example of burst packet loss calculation. 5. IANA Considerations
This is an event driven algorithm for measuring burst characteristics This document defines a new RTP packet type, the extended report (XR)
and is hence extremely computationally efficient. type, within the existing Internet Assigned Numbers Authority (IANA)
registry of RTP RTCP Control Packet Types. This document also
defines a new IANA registry: the registry of RTP XR Block Types.
Within this new registry, this document defines an initial set of
seven block types and describes how the remaining types are to be
allocated.
5.1 XR Packet Type
The IANA SHALL register the RTP extended report (XR) packet defined
by this document as packet type 207 in the registry of RTP RTCP
Control Packet types (PT).
5.2 RTP XR Block Type Registry
The IANA SHALL create the RTP XR Block Type Registry to cover the
name space of the extended report block type (BT) field specified in
Section 3 of this document. The BT field contains eight bits,
allowing 256 values. The IANA SHALL manage the RTP XR Block Type
Registry according to the Specification Required policy of RFC 2434
[6]. Future specifications SHOULD attribute block type values in
strict numeric order following the values attributed in this
document:
BT name
-- ----
1 Loss RLE Report Block
2 Duplicate RLE Report Block
3 Timestamp Report Block
4 Statistics Summary Report Block
5 Receiver Timestamp Report Block
6 DLRR Report Block
7 VoIP Metrics Report Block
Furthermore, future specifications SHOULD avoid the values 0 and 255.
Doing so facilitates packet validity checking, since all-zeros and
all-ones are values that might commonly be found in ill-formed
packets.
6. Security Considerations
This document extends the RTCP reporting mechanism. The security
considerations that apply to RTCP reports also apply to XR reports.
This section details the additional security considerations that
apply to the extensions.
The extensions introduce heightened confidentiality concerns.
Standard RTCP reports contain a limited number of summary statistics.
The information contained in XR reports is both more detailed and
more extensive (covering a larger number of parameters). The per-
packet information contained in Loss RLE, Duplicate RLE, and
Timestamp Report Blocks facilitates MINC inference of multicast
distribution trees for RTP data packets, and inference of link
characteristics such as loss and delay. This inference reveals
information that might otherwise be considered confidential to
autonomous system administrators. The VoIP Metrics Report Block
provides information on the quality of ongoing voice calls. Though
such information might be carried in application specific format in
standard RTP sessions, making it available in a standard format here
makes it more available to potential eavesdroppers.
No new mechanisms are introduced in this document to ensure
confidentiality. Standard encryption procedures can be used when
confidentiality is a concern to end hosts. Autonomous system
administrators concerned about the loss of confidentiality regarding
their networks can encrypt traffic, or filter it to exclude RTCP
packets containing the XR report blocks concerned.
Any encryption or filtering of XR report blocks entails a loss of
monitoring information to third parties. For example, a network that
establishes a tunnel to encrypt VoIP Report Blocks denies that
information to the service providers traversed by the tunnel. The
service providers cannot then monitor or respond to the quality of
the VoIP calls that they carry, potentially creating problems for the
network's users. As a default, XR packets SHOULD NOT be encrypted or
filtered.
The extensions also make certain denial of service attacks easier.
This is because of the potential to create RTCP packets much larger
than average with the per packet reporting capabilities of the Loss
RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the
automatic bandwidth adjustment mechanisms in RTCP, if some session
participants are sending large RTCP packets, all participants will
see their RTCP reporting intervals lengthened, meaning they will be
able to report less frequently. To limit the effects of large
packets, even in the absence of denial of service attacks,
applications SHOULD limit the size of XR report blocks and employ the
thinning techniques described in this document in order to fit
reports into the space available.
A. Algorithms
A.1 Sequence Number Interpretation
This the algorithm suggested by Section 4.1 for keeping track of the
sequence numbers from a given sender. It implements the accounting
practice required for the generation of Loss RLE Report Blocks.
This algorithm keeps track of 16 bit sequence numbers by translating
them into a 32 bit sequence number space. The first packet received
from a source is considered to have arrived roughly in the middle of
that space. Each packet that follows is placed either ahead or
behind the prior one in this 32 bit space, depending upon which
choice would place it closer (or, in the event of a tie, which choice
would not require a rollover in the 16 bit sequence number).
// The reference sequence number is an extended sequence number
// that serves as the basis for determining whether a new 16 bit
// sequence number comes earlier or later in the 32 bit sequence
// space.
u_int32 _src_ref_seq;
bool _uninitialized_src_ref_seq;
// Place seq into a 32-bit sequence number space based upon a
// heuristic for its most likely location.
u_int32 extend_seq(const u_int16 seq) {
u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b;
if(_uninitialized_src_ref_seq) {
// This is the first sequence number received. Place
// it in the middle of the extended sequence number
// space.
_src_ref_seq = seq | 0x80000000u;
_uninitialized_src_ref_seq = false;
extended_seq = _src_ref_seq;
}
else {
// Prior sequence numbers have been received.
// Propose two candidates for the extended sequence
// number: seq_a is without wraparound, seq_b with
// wraparound.
seq_a = seq | (_src_ref_seq & 0xFFFF0000u);
if(_src_ref_seq < seq_a) {
seq_b = seq_a - 0x00010000u;
diff_a = seq_a - _src_ref_seq;
diff_b = _src_ref_seq - seq_b;
}
else {
seq_b = seq_a + 0x00010000u;
diff_a = _src_ref_seq - seq_a;
diff_b = seq_b - _src_ref_seq;
}
// Choose the closer candidate. If they are equally
// close, the choice is somewhat arbitrary: we choose
// the candidate for which no rollover is necessary.
if(diff_a < diff_b) {
extended_seq = seq_a;
}
else {
extended_seq = seq_b;
}
// Set the reference sequence number to be this most
// recently-received sequence number.
_src_ref_seq = extended_seq;
}
// Return our best guess for a 32-bit sequence number that
// corresponds to the 16-bit number we were given.
return extended_seq;
}
A.2 Example Burst Packet Loss Calculation.
This is an algorithm for measuring the burst characteristics for the
VoIP Metrics Report Block (Section 4.7). It is reproduced from ETSI
TS 101 329-5 [2]. The algorithm is event driven and hence extremely
computationally efficient.
Given the following definition of states: Given the following definition of states:
State 1 = received a packet during a gap state 1 = received a packet during a gap
State 2 = received a packet during a burst state 2 = received a packet during a burst
State 3 = lost a packet during a burst state 3 = lost a packet during a burst
State 4 = lost an isolated packet during a gap state 4 = lost an isolated packet during a gap
The "c" variables below correspond to state transition counts, i.e. The "c" variables below correspond to state transition counts, i.e.
c14 is the transition from state 1 to state 4. It is possible to c14 is the transition from state 1 to state 4. It is possible to
infer one of a pair of state transition counts to an accuracy of 1 infer one of a pair of state transition counts to an accuracy of 1
which is generally sufficient for this application. "pkt" is the which is generally sufficient for this application.
count of packets received since the last packet was declared lost or
discarded and "lost" is the number of packets lost within the current
burst.
if ( packet_lost ) loss_count++; "pkt" is the count of packets received since the last packet was
if ( packet_discarded ) discard_count++; declared lost or discarded and "lost" is the number of packets lost
if (pkt >= gmin) within the current burst. "packet_lost" and "packet_discarded" are
{ boolean variables that indicate if the event that resulted in this
if (lost == 1) function being invoked was a lost or discarded packet.
if(packet_lost) {
loss_count++;
}
if(packet_discarded) {
discard_count++;
}
if(!packet_lost && !packet_discarded) {
pkt++;
}
else {
if(pkt >= gmin) {
if(lost == 1) {
c14++; c14++;
else }
else {
c13++; c13++;
}
lost = 1; lost = 1;
c11 += pkt; c11 += pkt;
} }
else else {
{
lost++; lost++;
if (pkt == 0) if(pkt == 0) {
c33++; c33++;
else }
{ else {
c23++; c23++;
c22 += (pkt - 1); c22 += (pkt - 1);
} }
} }
pkt = 0;
}
At each reporting interval the burst and gap metrics can be calcu- At each reporting interval the burst and gap metrics can be
lated as follows. calculated as follows.
/* calculate additional transition counts */ // Calculate additional transition counts.
c31 = c13; c31 = c13;
c32 = c23; c32 = c23;
ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33; ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33;
/* calculate burst and densities */ // Calculate burst and densities.
p32 = c32 / (c31 + c32 + c33); p32 = c32 / (c31 + c32 + c33);
if ((c22 + c23) < 1) if((c22 + c23) < 1) {
p23 = 1; p23 = 1;
else }
else {
p23 = 1 - c22/(c22 + c23); p23 = 1 - c22/(c22 + c23);
}
burst_density = 256 * p23 / (p23 + p32); burst_density = 256 * p23 / (p23 + p32);
gap_density = 256 * c14 / (c11 + c14); gap_density = 256 * c14 / (c11 + c14);
/* calculate burst and gap durations in mS */ // Calculate burst and gap durations in ms
m = frameDuration_in_mS * framesPerRTPPkt; m = frameDuration_in_ms * framesPerRTPPkt;
gap_length = (c11 + c14 + c13) * m / c13; gap_length = (c11 + c14 + c13) * m / c13;
burst_length = ctotal * m / c13 - lgap; burst_length = ctotal * m / c13 - lgap;
/* calculate loss and discard densities */ /* calculate loss and discard densities */
loss_density = 256 * loss_count / ctotal; loss_density = 256 * loss_count / ctotal;
discard_density = 256 * discard_count / ctotal; discard_density = 256 * discard_count / ctotal;
5. IANA Considerations Intellectual Property
The extended report block type (BT) field defined by this document is
a name space to be managed by the Internet Assigned Numbers Authority
(IANA). The field contains eight bits, allowing 256 values, of which
seven are defined here:
1 (Statistics Summary Block, see Section 4.4)
2 (Receiver Timestamp Report Block, see Section 4.5)
3 (DLRR Report Block, see Section 4.6)
17 (Loss RLE Block, see Section 4.1)
33 (Duplicate RLE Block, see Section 4.2)
48 (Timestamp Report Block, see Section 4.3)
64 (VoIP Metrics Report Block, see Section 4.7)
In addition, the value 0 is reserved for experimental use.
No review is necessary by the IANA in order for it to record the
assignment of additional numbers from this name space. Such numbers
are to be assigned as part of the IETF standards process.
6. Security Considerations
This document extends the RTCP reporting mechanism, so all security
considerations for RTCP reports also apply to the XR packets
described here. This section details the additional security consid-
erations that apply to the extensions.
The extensions introduce heightened confidentiality concerns. Stan-
dard RTCP reports contain a limited number of summary statistics.
The information contained in XR reports is both more detailed and
more extensive (covering a larger number of parameters). The per
packet information contained in Loss RLE, Duplicate RLE, and Times-
tamp Report Blocks facilitates MINC inference of multicast distribu-
tion trees for RTP data packets, and inference of link characteris-
tics such as loss and delay. This inference reveals information that
might otherwise be considered confidential to autonomous system
administrators. The VoIP Metrics Report Block provides information
on the quality of ongoing voice calls. Though such information might
be carried in application specific format in standard RTP sessions,
making it available in a standard format here makes it more available
to potential eavesdroppers.
No new mechanisms are introduced in this document to ensure confiden-
tiality. Already available authentification and encryption proce-
dures should be used when confidentiality is a concern to end hosts.
Autonomous system administrators concerned about the loss of confi-
dentiality regarding their networks can filter traffic to exclude
RTCP packets containing the XR report blocks concerned.
The extensions also make certain denial of service attacks easier.
This is because of the potential to create RTCP packets much larger
than average with the per packet reporting capabilities of the Loss
RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the
automatic bandwidth adjustment mechanisms in RTCP, if some session
participants are sending large RTCP packets, all participants will
see their RTCP reporting intervals lengthened, meaning they will be
able to report less frequently.
No new mechanisms are introduced in this document to prevent such
denial of service attacks.
7. Acknowledgements
We thank the following people: Colin Perkins, Steve Casner, and Hen-
ning Schulzrinne for their considered guidance; Nick Duffield for
extensive ongoing contributions; Sue Moon for helping foster collabo-
ration between the authors of this document; and Mounir Benzaid for
drawing our attention to the reporting needs of MLDA.
8. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to per- intellectual property or other rights that might be claimed to
tain to the implementation or use of the technology described in this pertain to the implementation or use of the technology described in
document or the extent to which any license under such rights might this document or the extent to which any license under such rights
or might not be available; neither does it represent that it has made might or might not be available; neither does it represent that it
any effort to identify any such rights. Information on the IETF's has made any effort to identify any such rights. Information on the
procedures with respect to rights in standards-track and standards- IETF's procedures with respect to rights in standards-track and
related documentation can be found in BCP 11 [7]. Copies of claims standards-related documentation can be found in BCP 11 [3]. Copies
of rights made available for publication and any assurances of of claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made to of licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such propri- obtain a general license or permission for the use of such
etary rights by implementors or users of this specification can be proprietary rights by implementors or users of this specification can
obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
9. References Full Copyright Statement
[1] A. Adams, T. Bu, R. Caceres, N.G. Duffield, T. Friedman, J.
Horowitz, F. Lo Presti, S.B. Moon, V. Paxson, and D. Towsley, "The
Use of End-to-End Multicast Measurements for Characterizing Internal
Network Behavior," IEEE Communications Magazine, May 2000.
[2] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," BCP 14, RFC 2119, IETF, March 1997.
[3] R. Caceres, N.G. Duffield, and T. Friedman, "Impromptu measure-
ment infrastructures using RTP," Proc. IEEE Infocom 2002.
[4] A. D. Clark, "Modeling the Effects of Burst Packet Loss and
Recency on Subjective Voice Quality," Proc. IP Telephony Workshop
2001.
[5] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI
TS 101 329-5 V1.1.1 (2000-11), November 2000.
[6] ITU-T, "The E-Model, a computational model for use in transmis-
sion planning," Recommendation G.107 (05/00), May 2000.
[7] J. Reynolds and J. Postel, "Assigned Numbers," STD 2, RFC 1700,
IETF, October 1994.
[8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
transport protocol for real-time applications," RFC 1889, IETF,
February 1996.
[9] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Con-
trol Framework for Heterogeneous Multicast Environments", Proc. IWQoS
2000.
10. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this doc- included on all such copies and derivative works. However, this
ument itself may not be modified in any way, such as by removing the document itself may not be modified in any way, such as by removing
copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop- Internet organizations, except as needed for the purpose of
ing Internet standards in which case the procedures for copyrights developing Internet standards in which case the procedures for
defined in the Internet Standards process must be followed, or as copyrights defined in the Internet Standards process must be
required to translate it into languages other than English. followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
9. Authors' Addresses Acknowledgements
Timur Friedman <timur.friedman@lip6.fr> We thank the following people: Colin Perkins, Steve Casner, and
University of Paris 6 Henning Schulzrinne for their considered guidance; Sue Moon for
Laboratoire LiP6-CNRS helping foster collaboration between the authors; Magnus Westerlund
8, rue du Capitaine Scott for his detailed comments; Mounir Benzaid for drawing our attention
75015 PARIS, FRANCE to the reporting needs of MLDA; and Dorgham Sisalem and Adam Wolisz
Ramon Caceres <ramon@shieldip.com> for encouraging us to incorporate MLDA block types.
ShieldIP, Inc.
11 West 42nd Street, 31st Floor Contributors
New York, NY 10036, USA
The following people are the authors of this document:
Kevin Almeroth, UCSB
Ramon Caceres, ShieldIP
Alan Clark, Telchemy
Robert Cole, AT&T Labs
Nick Duffield, AT&T Labs-Research
Timur Friedman, Paris 6
Kaynam Hedayat, Brix Networks
Kamil Sarac, UT Dallas
The principal people to contact regarding the individual report
blocks described in this document are as follows:
sec. report block principal contributors
---- ------------ ----------------------
4.1 Loss RLE Report Block Friedman, Caceres, Duffield
4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield
4.3 Timestamp Report Block Friedman, Caceres, Duffield
4.4 Statistics Summary Report Block Almeroth, Sarac
4.5 Receiver Timestamp Report Block Friedman
4.6 DLRR Report Block Friedman
4.7 VoIP Metrics Report Block Clark, Cole, Hedayat
Authors' Addresses
Kevin Almeroth <almeroth@cs.ucsb.edu> Kevin Almeroth <almeroth@cs.ucsb.edu>
Department of Computer Science Department of Computer Science
University of California University of California
Santa Barbara, CA 93106, USA Santa Barbara, CA 93106 USA
Kamil Sarac <ksarac@cs.uscb.edu> Ramon Caceres <ramon@shieldip.com>
Department of Computer Science ShieldIP, Inc.
University of California 11 West 42nd Street, 31st Floor
Santa Barbara, CA 93106, USA New York, NY 10036 USA
Alan Clark <alan@telchemy.com> Alan Clark <alan@telchemy.com>
Telchemy Incorporated Telchemy Incorporated
3360 Martins Farm Road, Suite 200 3360 Martins Farm Road, Suite 200
Suwanee, GA 30024 Suwanee, GA 30024 USA
Tel: +1 770 614-6944 Tel: +1 770 614 6944
Fax: +1 770 614-3951 Fax: +1 770 614 3951
Robert Cole <rgcole@att.com> Robert Cole <rgcole@att.com>
AT&T Labs AT&T Labs
330 Saint Johns Street, 330 Saint Johns Street,
2nd Floor 2nd Floor
Havre de Grace, MD, USA 21078 Havre de Grace, MD 21078 USA
Tel: +1 410 939-8732 Tel: +1 410 939 8732
Fax: +1 410 939-8732 Fax: +1 410 939 8732
Nick Duffield <duffield@research.att.com>
AT&T Labs-Research
180 Park Avenue, P.O. Box 971
Florham Park, NJ 07932-0971 USA
Tel: +1 973 360 8726
Fax: +1 973 360 8050
Timur Friedman <timur.friedman@lip6.fr>
Universite Pierre et Marie Curie (Paris 6)
Laboratoire LiP6-CNRS
8, rue du Capitaine Scott
75015 PARIS France
Tel: +33 1 44 27 71 06
Fax: +33 1 44 27 74 95
Kaynam Hedayat <khedayat@brixnet.com> Kaynam Hedayat <khedayat@brixnet.com>
Brix Networks Brix Networks
285 Mill Road 285 Mill Road
Chelmsford, MA 01824 Chelmsford, MA 01824 USA
Tel: +1 978 367-5600 Tel: +1 978 367 5600
Fax: +1 978 367-5700 Fax: +1 978 367 5700
Kamil Sarac <ksarac@utdallas.edu>
Department of Computer Science (ES 4.207)
Eric Jonsson School of Engineering & Computer Science
University of Texas at Dallas
Richardson, TX 75083-0688 USA
Tel: +1 972 883 2337
Fax: +1 972 883 2349
References
The references are divided into normative references and non-
normative references.
Normative References
[1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," BCP 14, RFC 2119, IETF, March 1997.
[2] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI
TS 101 329-5 V1.1.1 (2000-11), November 2000.
[3] R. Hovey and S. Bradner, "The Organizations Involved in the IETF
Standards Process," best current practice BCP 11, RFC 2028, IETF,
October 1996.
[4] ITU-T, "The E-Model, a computational model for use in
transmission planning," Recommendation G.107 (05/00), May 2000.
[5] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2,
RFC 1700, IETF, October 1994.
[6] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs," best current practice BCP 26, RFC
2434, IETF, October 1998.
[7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
transport protocol for real-time applications," RFC 1889, IETF,
February 1996.
Non-Normative References
[8] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J.
Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The
Use of End-to-End Multicast Measurements for Characterizing Internal
Network Behavior," IEEE Communications Magazine, May 2000.
[9] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu
measurement infrastructures using RTP," Proc. IEEE Infocom 2002.
[10] A. D. Clark, "Modeling the Effects of Burst Packet Loss and
Recency on Subjective Voice Quality," Proc. IP Telephony Workshop
2001.
[11] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion
Control Framework for Heterogeneous Multicast Environments", Proc.
IWQoS 2000.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/