draft-ietf-avt-rtcp-report-extns-00.txt   draft-ietf-avt-rtcp-report-extns-01.txt 
Internet Engineering Task Force Expires: 16 April 2003 Internet Engineering Task Force Expires: 3 May 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 Kevin Almeroth, UCSB
Kamil Sarac, UCSB Kamil Sarac, UCSB
Alan Clark, Telchemy Alan Clark, Telchemy
Robert Cole, AT&T Robert Cole, AT&T
Kaynam Hedayat, Brix Networks Kaynam Hedayat, Brix Networks
RTCP Reporting Extensions RTCP Reporting Extensions
draft-ietf-avt-rtcp-report-extns-00.txt draft-ietf-avt-rtcp-report-extns-01.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 46 skipping to change at page 1, line 46
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 (2002). All Rights Reserved.
Abstract Abstract
This document defines the XR (extended report) RTCP packet type and This document defines the XR (extended report) RTCP packet type and
eight XR block types. The purpose of the extended reporting format is seven XR block types. The purpose of the extended reporting format is
to convey information that supplements the six statistics that are to convey information that supplements the six statistics that are
contained in the report blocks used by SR (sender report) and RR contained in the report blocks used by SR (sender report) and RR
(receiver report) packets. Some applications, such as MINC (receiver report) packets. Some applications, such as MINC
(multicast inference of network characteristics) or VoIP (voice over (multicast inference of network characteristics) or VoIP (voice over
IP) monitoring, require other and more detailed statistics. In IP) monitoring, require other and more detailed statistics. In
addition to the block types defined here, additional block types may addition to the block types defined here, additional block types may
be defined in the future by adhereing to the simple framework that be defined in the future by adhereing to the simple framework that
this document provides. this document provides.
1. Introduction 1. Introduction
This document defines the XR (extended report) RTCP packet type for This document defines the XR (extended report) RTCP packet type for
RTCP, the control portion of RTP [8]. The definition consists of RTCP, the control portion of RTP [8]. The definition consists of
three parts. First, Section 2 of this document defines a general three parts. First, Section 2 of this document defines a general
packet framework capable of including a number of different "extended packet framework capable of including a number of different "extended
report blocks." Second, Section 3 defines the general format for report blocks." Second, Section 3 defines the general format for
such blocks. Third, Section 4 defines a number of such blocks. such blocks. Third, Section 4 defines a number of such blocks.
The extended report blocks convey information beyond that which is The extended report blocks convey information beyond that which is
already contained in the reception report blocks of RTCP's SR or RR already contained in the reception report blocks of RTCP's SR or RR
packets. For example, while a reception report block contains an packets. XR report blocks carry information that is not appropriately
average loss rate field, an application might opt to use an extended carried in SR or RR profile-specific extensions because it is of use
report block that details exactly which packets were received and across profiles. Information that is useful to network management
which were lost. Or, for example, a voice over IP application might falls into this category, for instance.
require information concerning packets that were discarded from the
jitter buffer, in addition to those that were lost.
The framework for these blocks is minimal: only a type field and a Seven report block formats are defined by this document:
length field are required. The purpose is to maintain flexibility
and to keep overhead low. While some specific block formats are - Loss RLE Report Block (Section 4.1): Run-length encoding of RTP
provided here, others may be defined as the need arises. packet loss reports.
- Duplicate RLE Report Block (Section 4.2): Run-length encoding of
reports of RTP packet duplicates.
- Timestamp Report Block (Section 4.3): A list of timestamps of
received RTP packets.
- Statistics Summary Report Block (Section 4.4): Statistics on RTP
packet sequence numbers, losses, duplicates, jitter, and TTL values.
- Receiver Timestamp Report Block (Section 4.5): Receiver-end
timestamps that complement the sender-end timestamps already defined
for RTCP.
- DLRR Report Block (Section 4.6): The delay since the last receiver
timestamp report block was received, allowing non-senders to
calculate round-trip times.
- VoIP Metrics Report Block (Section 4.7): Metrics for monitoring
Voice over IP (VoIP) calls.
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
maintain flexibility and to keep overhead low. 0ther block formats,
beyond the seven defined here, may be defined within this framework
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 [2] and
indicate requirement levels for compliant RTP implementations. 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.
This packet format has been implemented as an RTCP APP (application-
specific) packet and deployed in the Internet, as described in [3]
and [1]. The differences between the APP packet header and the
header defined here are that the name field is removed and the
subtype field is replaced by a reserved field.
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=205 | 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 RTP ver-
sion two (2). sion two (2).
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 individual RTCP packet contains some
additional padding octets at the end that are not part of the control additional padding octets at the end that are not part of the control
information but are included in the length field. The last octet of information but are included in the length field. The last octet of
the padding is a count of how many padding octets should be ignored, the padding is a count of how many padding octets should be ignored,
including itself (it will be a multiple of four). A full description including itself (it will be a multiple of four). A full description
of padding in RTCP packets may be found in the RTP specification. 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. The bits in this field This field is reserved for future definition. In the absence of such
MUST be set to zero unless otherwise defined. definition, the bits in this field MUST be set to zero and MUST be
ignored by the receiver.
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 205 to identify this as an RTCP XR packet.
This is a proposed value, pending assignment of a number by the This is a proposed value, pending assignment of a number by the
Internet Assigned Numbers Authority (IANA) [7]. Internet Assigned Numbers Authority (IANA) [7].
length: 16 bits length: 16 bits
The length of this RTCP packet in 32-bit words minus one, including The length of this RTCP packet in 32-bit words minus one, including
the header and any padding. (The offset of one makes zero a valid the header and any padding. (The offset of one makes zero a valid
length and avoids a possible infinite loop in scanning a compound length and avoids a possible infinite loop in scanning a compound
RTCP packet, while counting 32-bit words avoids a validity check for RTCP packet, while counting 32-bit words avoids a validity check for
a multiple of 4.) 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 XR
packet. packet.
report blocks: variable length. report blocks: variable length.
Zero or more extended report blocks. The blocks MUST be a multiple Zero or more extended report blocks. Each block MUST be a multiple
of 32 bits long. They MAY be zero bits long. of 32 bits long. A block MAY be zero bits long.
3. Extended Report Block Framework 3. Extended Report Block Framework
Extended report blocks MUST be stacked, one after the other, at the Extended report blocks are stacked, one after the other, at the end
end of an XR packet. An individual block's length MUST be a multiple of an XR packet. An individual block's length is a multiple of 4
of 4 octets. The XR header's length field MUST describe the total octets. The XR header's length field describes the total length of
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
skipping to change at page 4, line 39 skipping to change at page 5, line 13
Identifies the specific block format. Identifies the specific block format.
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 defined by the particular block type.
length: 16 bits length: 16 bits
The length of this report block in 32-bit words minus one, including The length of this report block in 32-bit words minus one, including
the header. the header.
type-specific data: variable length type-specific data: variable length
This MUST be a multiple of 32 bits long. It MAY be zero bits long. This field MUST be a multiple of 32 bits long. It MAY be zero bits
long.
4. Specific Extended Report Blocks 4. Specific Extended Report Blocks
This section defines eight extended report blocks: an experimental This section defines seven extended report blocks: block types for
block type, and block types for losses, duplicates, packet reception losses, duplicates, packet reception timestamps, detailed reception
timestamps, detailed reception statistics, receiver timestamps, statistics, receiver timestamps, receiver inter-report delays, and
receiver inter-report delays, and VoIP metrics. An implementation VoIP metrics. An implementation MAY ignore incoming blocks with
MAY ignore incoming blocks with types either not relevant or unknown types either not relevant or unknown to it. Additional block types
to it. Additional block types MAY be registered with the Internet MUST be registered with the Internet Assigned Numbers Authority
Assigned Numbers Authority (IANA) [7]. (IANA) [7], as described in Section 5.
4.1 Experimental Block 4.1 Loss RLE Report Block
This type MUST be used for extended report block types that have not This block type permits detailed reporting upon individual packet
been standardized. In addition to the standard type and length receipt and loss events. Such reports could be used, for example,
fields, it includes a 32 bit name field that serves to distinguish for MINC inference [1] of the topology of the multicast tree used for
one experimental block type from another. distributing a source's RTP packets, and of the loss rates along
links within that tree. 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.
0 1 2 3 Each block reports on a single source, identified by its SSRC. The
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 receiver that is supplying the report is identified in the header of
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the RTCP packet.
| BT=0 | app-specific | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: application-specific data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits The beginning and ending RTP packet sequence numbers for the trace
Block type 0 identifies this as an experimental block. are specified in the block, the ending sequence number being the last
sequence number in the trace plus one. The last sequence number in
the trace MAY differ from the sequence number reported on in any
accompanying SR or RR packet.
app-specific: 8 bits The ending sequence number MAY be less than the beginning sequence
The use of these bits is defined by the application that uses this number. This happens when the sequence numbers that are being
block. reported upon have wrapped around. However, a Loss RLE Block MUST
NOT be used to report upon a range of 65,534 or greater in the
sequence number space, as there is no means to identify multiple
wrap-arounds.
length: 16 bits The encoding itself consists of a series of 16 bit chunks that
The length of this report block in 32-bit words minus one, including describe packet receipts or losses. Each chunk either specifies a
the header. 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.
name: 4 octets The mapping from a sequence of lost and received packets into a
A name chosen by the person definining the experimental block to be sequence of chunks is not necessarily unique. For example, the fol-
unique with respect to other experimental blocks the application lowing trace covers 45 packets, of which the 22nd and 24th have been
might receive. lost and the others received:
application-specific data: variable length. 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
This MUST be a multiple of 32 bits long. It MAY be zero bits long.
4.2 Loss RLE Block One way to encode this would be:
With this block type, a Boolean trace of lost and received packets bit vector 1111 1111 1111 111
can be conveyed in compressed form using run length encoding. This bit vector 1111 1101 0111 111
block type has been deployed on the Internet, as part of an RTCP APP bit vector 1111 1111 1111 111
(application-specific) packet, as described in [3] and [1]. null chunk
Caution SHOULD be used in sending such blocks because, even with comˇ Another way to encode this would be:
pression, they can easily consume bandwidth out of proportion with
normal RTCP packets.
Each block reports on a single source, identified by its SSRC. The run of 21 receipts
receiver that is supplying the report is identified in the header of bit vector 0101 1111 1111 111
the RTCP packet. run of 9 receipts
null chunk
The beginning and ending sequence numbers for the trace are specified The choice of encoding is left to the application. As part of this
in the block, the ending sequence number being the last sequence numˇ freedom of choice, applications MAY terminate a series of run length
ber in the trace plus one. The last sequence number in the trace MAY and bit vector chunks with a bit vector chunk that runs beyond the
or may not be the sequence number reported on accompanying SR or RR sequence number space described by the report block. For example, if
packets, depending on the needs of the application. the 44th packet in the same sequence were lost:
The encoding itself consists of a series of 16 bit chunks. Each 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
chunk either specifies a run length or a bit vector, or, if the trace
otherwise encodes into an odd number of chunks, MUST be a terminating
null chunk used to round out the block to a 32 bit word boundary.
The mapping from a sequence of lost and received packets into a This could be encoded as:
sequence of chunks is not unique and is left to the application. A
run length chunk can describe runs of between 1 and 16,383 packet
losses or receipts whereas a bit vector chunk can describe a sequence
of 15 packet losses and receipts. It is RECOMMENDED that the
description of run lengths of 14 or shorter be subsumed into bit vecˇ
tor chunks, for purposes of brevity.
A bit vector chunk MAY purport to contain information on packets at run of 21 receipts
or beyond the ending sequence number. Any such purported information bit vector 0101 1111 1111 111
MUST be ignored. bit vector 1111 1110 1000 000
null chunk
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
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
number space that extends beyond the last sequence number in the
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-
ber of run length plus bit vector chunks is odd. The null chunk MUST
NOT appear in any other context.
Caution should be used in sending Loss RLE Blocks because, even with
the compression provided by run-length encoding, they can easily con-
sume bandwidth out of proportion with normal RTCP packets. The block
type includes a mechanism, called thinning, that allows an applica-
tion to limit report sizes.
A thinning value, T, selects a subset of packets within the sequence
number space: those with sequence numbers that are multiples of 2^T.
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
sequence number space is reported upon. If T is fifteen then one in
every 32,768 packets is reported upon.
Suppose that the trace just described begins at sequence number
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-
lowing 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,864. The thinned trace would be as follows:
1 1 1 1 1 0 1 1 1 1 0
This could be encoded as follows:
bit vector 1111 1011 1100 000
null chunk
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
thus set to zero and are ignored by the receiver. With thinning, the
loss of the 22nd packet goes unreported because its sequence number,
13,842, is not a multiple of four. Packet receipts for all sequence
numbers that are not multiples of four also go unreported. However,
in this example thinning has permitted the Loss RLE Block to be
shortened by one 32 bit word.
Choice of the thinning value is left to the application.
The Loss RLE 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=17 | 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 = 0x11. A Loss RLE block is identified by the constant 17.
rsvd.: 4 bits rsvd.: 4 bits
This field is reserved for future definition. The bits in this field This field is reserved for future definition. In the absence of such
MUST be set to zero unless otherwise defined. definition, the bits in this field MUST be set to zero and receivers
MUST ignore this field.
thinning (T): 4 bits thinning (T): 4 bits
The amount of thinning performed on the sequence space. Only those The amount of thinning performed on the sequence number space. Only
packets with sequence numbers 0 mod 2^T are reported on by this those packets with sequence numbers 0 mod 2^T are reported on by this
block. A value of 0 indicates that there is no thinning, and all block. A value of 0 indicates that there is no thinning, and all
packets are reported on. The maximum thinning is one packet in every packets are reported on. The maximum thinning is one packet in every
32,768 (amounting to two packets within each 16-bit sequence space). 32,768 (amounting to two packets within each 16-bit sequence space).
length: 16 bits length: 16 bits
The length of this report block in 32-bit words minus one, including Defined in Section 3.
the header.
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 terminating
null. If the chunk is all zeroes then it is a terminating null null. If the chunk is all zeroes then it is a terminating null
chunk. Otherwise, the leftmost bit of the chunk determines its type: chunk. Otherwise, the leftmost bit of the chunk determines its type:
0 for run length and 1 for bit vector. 0 for run length and 1 for bit vector.
4.2.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 losses. One indicates a run of received
packets. 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 (zeroes in
both the run type and run length fields would make the chunk a termiˇ both the run type and run length fields would make the chunk a termi-
nating null chunk). Run lengths of 15 or less MAY be described with nating null chunk). Run lengths of 15 or less MAY be described with
a run length chunk despite the fact that they could also be described a run length chunk despite the fact that they could also be described
as part of a bit vector chunk. as part of a bit vector chunk.
4.2.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
In the bit vector, as in the run length chunk, a zero indicates a The vector is read from left to right, in order of increasing
loss and a one indicates a received packet. sequence number (with the appropriate allowance for wrap around). A
zero indicates a packet loss and a one indicates a received packet.
4.2.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.3 Duplicate RLE Block 4.2 Duplicate RLE Report Block
This block is identical in format to the Loss RLE Block type but carˇ This block type permits per-sequence-number reports on duplicates in
ries information about individual or runs of duplicate packets. A a source's RTP packet stream. Such information can be used for net-
zero indicates the presence of duplicate packets for a given sequence work diagnosis, and provide an alternative to packet losses as a
number, whereas a one indicates that no duplicates were received. basis for multicast tree topology inference.
Note that a packet loss is encoded as a one in this case.
The Duplicate RLE Block format is identical to the Loss RLE Block
format. Only the interpretation is different, in that the informa-
tion concerns packet duplicates rather than packet losses. The trace
to be encoded in this case also consists of zeros and ones, but a
zero here indicates the presence of duplicate packets for a given
sequence number, whereas a one indicates that no duplicates were
received.
The existence of a duplicate for a given sequence number is deter-
mined over the entire reporting period. For example, if packet num-
ber 12,593 arrives, followed by other packets with other sequence
numbers, the arrival later in the reporting period of another packet
numbered 12,593 counts as a duplicate for that sequence number. The
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
range of 65,534 or greater in the sequence number space.
No distinction is made between the existance of a single duplicate
packet and multiple duplicate packets for a given sequence number.
Note also that since there is no duplicate for a lost packet, a loss
is encoded as a one in a Duplicate RLE Block.
The Duplicate RLE 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 | reserved | length | | BT=33 | rsvd. | T | 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 = 0x21. A Duplicate RLE block is identified by the constant 33.
reserved: 8 bits rsvd.: 4 bits
This field is reserved for future definition All of the bits in this This field is reserved for future definition. In the absence of such
field MUST be set to zero unless otherwise defined. definition, the bits in this field MUST be set to zero and receivers
MUST ignore this field.
thinning (T): 4 bits
The amount of thinning performed on the sequence number space.
length: 16 bits length: 16 bits
The length of this report block in 32-bit words minus one, including Defined in Section 3.
the header.
begin_seq: 32 bits begin_seq: 32 bits
The first sequence number that this block reports on. The first sequence number that this block reports on.
end_seq: 32 bits end_seq: 32 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 terminating
null. All zeroes indicates a terminating null. Otherwise, the leftˇ 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 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 bit vector. See the descriptions of these block types in the section
on the Loss RLE Block, above, for details. on the Loss RLE Block, above, for details.
4.4 Timestamp Report Block 4.3 Timestamp Report Block
This block carries RTCP-style timestamps for each packet in the range This block type permits per-sequence-number reports on packet receipt
of packet sequence numbers. A similar caution, but more emphatic, is timestamps for a given source's RTP packet stream. Such information
made for timestamp report blocks as was made for Loss RLE Block packˇ can be used for MINC inference of the topology of the multicast tree
ets. For each packet in the sequence number range, a 32 bit value used to distribute the source's RTP packets, and of the delays along
MUST be recorded and sent. This could easily consume significant the links within that tree. It can also be used to measure partial
bandwidth. Care SHOULD be taken in the size of the sequence space path characteristics and to model distributions for packet jitter.
over which to monitor timestamps.
Timestamps consume more bits than loss or duplicate information, and
do not lend themselves to run length encoding. The use of thinning
is encouraged to limit the size of Timestamp Report Blocks.
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 | reserved | length | | BT=48 | rsvd. | T | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | | begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end_seq | | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp (pkt n) | | RTP timestamp 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Timestamp block is identified by the constant 48 = 0x30. A Timestamp Report Block is identified by the constant 48.
reserved: 8 bits rsvd.: 4 bits
This field is reserved for future definition. All bits in this field This field is reserved for future definition. In the absence of such
MUST be set to zero unless otherwise defined. definition, the bits in this field MUST be set to zero and receivers
MUST ignore this field.
thinning (T): 4 bits
The amount of thinning performed on the sequence number space.
length: 16 bits length: 16 bits
The length of this report block in 32-bit words minus one, including Defined in Section 3.
the header.
begin_seq: 32 bits begin_seq: 32 bits
The first sequence number that this block reports on. The first sequence number that this block reports on.
end_seq: 32 bits end_seq: 32 bits
The last sequence number that this block reports on plus one. The last sequence number that this block reports on plus one.
RTP timestamp: 32 bits RTP timestamp i: 32 bits
Corresponds to the same units as the RTP timestamp in RTP data packˇ The timestamp reflects the packet arrival time at the receiver. It
ets. The timestamp is established upon packet arrival. It can be is preferable for the timestamp to be established at the link layer
used to measure partial path characteristics and to model distribuˇ interface, or in any case as close as possible to the wire arrival
tions for packet jitter. time. Units and format are the same as for the timestamp in RTP data
packets. As opposed to RTP data packet timestamps, in which nominal
values may be used instead of system clock values in order to convey
information useful for periodic playout, the receiver timestamps
should reflect the actual time as closely as possible. The initial
value of the timestamp is random, and subsequent timestamps are off-
set from this value.
4.5 Statistics Summary Block 4.4 Statistics Summary Report Block
This block reports detailed statistics above and beyond the informaˇ This block reports statistics beyond the information carried in the
tion carried in the standard RTCP packet format. Information is standard RTCP packet format, but not as fine grained as that carried
recorded about lost packets, duplicate packets, jitter measurements, in the report blocks previously described. Information is recorded
and TTL values. The packet contents are dependent upon a bit vector about lost packets, duplicate packets, jitter measurements, and TTL
carried in the first part of the header. Not all values need to be values (TTL values being taken from the TTL field of IPv4 packets, if
carried in each packet. Header fields for values not carried are not the data packets are carried over IPv4). Such information can be
included in the packet. useful for network management.
The packet contents are dependent upon a bit vector carried in the
first part of the header. Not all values need to be carried in each
packet. Header fields for values not carried are not included in the
packet.
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=1 |L|D|J|T|resvd. | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | | begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 32 skipping to change at page 14, line 34
| 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 = 0x01. A Statistics Summary block is identified by the constant 1.
content bits (L,D,J,T): 4 bits content bits (L,D,J,T): 4 bits
Bit set to 1 if packet contains (L)oss, (D)uplicate, (J)itter, and/or Bit set to 1 if packet contains (L)oss, (D)uplicate, (J)itter, and/or
(T)TL report. (T)TL report.
resvd.: 4 bits resvd.: 4 bits
This field is reserved for future definition. All bits in this field This field is reserved for future definition. In the absence of such
MUST be set to zero unless otherwise defined. definition, all bits in this field MUST be set to zero, and receivers
MUST ignore this field.
length: 16 bits length: 16 bits
The length of this report block in 32-bit words minus one, including Defined in Section 3.
the header.
begin_seq: 32 bits begin_seq: 32 bits
The first sequence number that this block reports on. The first sequence number that this block reports on.
end_seq: 32 bits end_seq: 32 bits
The last sequence number that this block reports on plus one. The last sequence number that this block reports on plus one.
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 above
sequence number interval. All jitter values are measured as the difˇ sequence number interval. All jitter values are measured as the dif-
ference between a packet's RTP timestamp and the reporter's clock at ference between a packet's RTP timestamp and the reporter's clock at
the time of arrival, measured in the same units. 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 above
sequence number interval. 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 in
the above sequence number interval. the above sequence number interval.
skipping to change at page 13, line 39 skipping to change at page 15, line 42
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 num-
ber range. ber range.
4.6 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 [9], 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=2 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 = 0x02. A Receiver Timestamp block is identified by the constant 2.
reserved: 24 bits reserved: 24 bits
This field is reserved for future definition. The bits in this field This field is reserved for future definition. In the absence of such
MUST be set to zero unless otherwise defined. definition, the bits in this field MUST be set to zero, and receivers
MUST ignore this field.
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 may
be used in combination with timestamps returned in DLRR report blocks be used in combination with timestamps returned in DLRR report blocks
from other receivers to measure round-trip propagation to those from other receivers to measure round-trip propagation to those
receivers. Receivers should expect that the measurement accuracy of receivers. Receivers should expect that the measurement accuracy of
the timestamp may be limited to far less than the resolution of the the timestamp may be limited to far less than the resolution of the
NTP timestamp. The measurement uncertainty of the timestamp is not NTP timestamp. The measurement uncertainty of the timestamp is not
indicated as it may not be known. A report block sender that can keep indicated as it may not be known. A report block sender that can keep
track of elapsed time but has no notion of wallclock time may use the track of elapsed time but has no notion of wallclock time may use the
elapsed time since joining the session instead. This is assumed to be elapsed time since joining the session instead. This is assumed to be
less than 68 years, so the high bit will be zero. It is permissible less than 68 years, so the high bit will be zero. It is permissible
to use the sampling clock to estimate elapsed wallclock time. A to use the sampling clock to estimate elapsed wallclock time. A
report sender that has no notion of wallclock or elapsed time may set report sender that has no notion of wallclock or elapsed time may set
the NTP timestamp to zero. the NTP timestamp to zero.
4.7 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 DLSR mechanism [7, Sec. 6.3.1] so that non-
senders may also calculate round trip times, as proposed in [9]. It senders may also calculate round trip times, as proposed in [9]. It
is termed DLRR for Delay since Last Receiver Report, and may be sent is termed DLRR for Delay since Last Receiver Report, and may be sent
in response to a Receiver Timestamp report block (see previous secˇ in response to a Receiver Timestamp report block (see previous sec-
tion) from a receiver to allow that receiver to calculate its round tion) from a receiver to allow that receiver to calculate its round
trip time to the respondant. The report consists of one or more 3 trip time to the respondant. The report consists of one or more 3
word sub-blocks: one sub-block per receiver report. 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=3 | reserved | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first receiver) | sub- | SSRC_1 (SSRC of first receiver) | sub-
skipping to change at page 15, line 22 skipping to change at page 17, line 22
| 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 = 0x03. A DLRR block is identified by the constant 3.
reserved: 8 bits reserved: 8 bits
This field is reserved for future definition. All bits in this field This field is reserved for future definition. In the absence of such
MUST be set to zero unless otherwise defined. definition, all bits in this field MUST be set to zero, and receivers
MUST ignore this field.
length: 16 bits length: 16 bits
The length of this report block in 32-bit words minus one, including Defined in Section 3.
the header. The number of sub-blocks is length divided by three (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 in
the previous section) received as part of a Receiver Timestamp report the previous section) received as part of a Receiver Timestamp report
block from participant SSRC_n. If no such block has been received, block from participant SSRC_n. If no such block has been received,
the field is set to zero. 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 receiving
the last Receiver Timestamp report block from participant SSRC_n and the last Receiver Timestamp report block from participant SSRC_n and
sending this DLRR report block. If no Receiver Timestamp report sending this DLRR report block. If no Receiver Timestamp report
block has been received yet from SSRC_n, the DLRR field is set to block has been received yet from SSRC_n, the DLRR field is set to
zero (or the DLRR is omitted entirely). Let SSRC_r denote the zero (or the DLRR is omitted entirely). Let SSRC_r denote the
receiver issuing this DLRR report block. Participant SSRC_n can comˇ receiver issuing this DLRR report block. Participant SSRC_n can com-
pute the round-trip propagation delay to SSRC_r by recording the time pute the round-trip propagation delay to SSRC_r by recording the time
A when this Receiver Timestamp report block is received. It calcuˇ A when this Receiver Timestamp report block is received. It calcu-
lates the total round-trip time A-LSR using the last SR timestamp lates the total round-trip time A-LSR using the last SR timestamp
(LSR) field, and then subtracting this field to leave the round-trip (LSR) field, and then subtracting this field to leave the round-trip
propagation delay as (A- LSR - DLSR). This is illustrated in [7, Fig. propagation delay as (A- LSR - DLSR). This is illustrated in [7, Fig.
2]. 2].
4.8 VoIP Metrics Report Block 4.7 VoIP Metrics Report Block
4.8.1 Summary 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 [4].
Following a Gilbert-Elliott model [5], an interval, bounded by lost Following a Gilbert-Elliott model [5], an interval, bounded by lost
and/or discarded packets, with a high rate of losses and/or discards and/or discarded packets, with a high rate of losses and/or discards
is a "burst," and an interval between two bursts is a "gap." Bursts is a "burst," and an interval between two bursts is a "gap." Bursts
correspond to intervals of time during which the packet loss rate is correspond to intervals of time during which the packet loss rate is
high enough to produce noticeable degradation in audio quality. Gaps high enough to produce noticeable degradation in audio quality. Gaps
correspond to periods of time during which only isolated lost packets correspond to periods of time during which only isolated lost packets
may occur, and in general these can be masked by packet loss conˇ may occur, and in general these can be masked by packet loss con-
cealment. Delay reports include the transit delay between RTCP end cealment. Delay reports include the transit delay between RTCP end
points and the VoIP end system processing delays, both of which conˇ points and the VoIP end system processing delays, both of which con-
tribute to the user perceived delay. Additional metrics include sigˇ tribute to the user perceived delay. Additional metrics include sig-
nal, echo, noise, and distortion levels. Call quality metrics nal, echo, noise, and distortion levels. Call quality metrics
include R factors (E Model) [5] and MOS scores (Mean Opinion Scores). include R factors (E Model) [5] and MOS scores (Mean Opinion 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 a call, and SHOULD send one
upon call termination. An implementation MUST supply values for all upon call termination. An implementation MUST supply values for all
fields defined here. fields defined here.
4.8.2 VoIP Metrics block structure 4.7.2 VoIP Metrics block structure
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=7 | | BT=64 | reserved | length=6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| loss rate | discard rate | burst duration | | loss rate | discard rate | burst duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burst density | gap duration | gap density | | burst density | gap duration | gap density |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| round trip delay | end system delay | | round trip delay | end system delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signal power | doubletalk | noise level | Gmin | | signal power | doubletalk | 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 = 0x40. A VoIP Metrics block is identified by the constant 64.
reserved: 8 bits reserved: 8 bits
This field is reserved for future definition. All bits in this field This field is reserved for future definition. In the absence of such
MUST be set to zero unless otherwise defined. definition, all bits in this field MUST be set to zero, and receivers
MUST ignore this field.
length: 16 bits length: 16 bits
The length of this report block in 32-bit words minus one, including As defined in Section 3, this is the constant 6 for this block type.
the header. This is the constant 6 = 0x06.
4.8.3 Packet loss and discard metrics 4.7.3 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 is very quality of the voice stream however having separate counts helps
useful when trying to identify the source of quality degradation. identify the source of quality degradation. These fields MUST be pop-
These fields MUST be populated. ulated.
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 the
binary point at the left edge of the field. This value is calculated binary point at the left edge of the field. This value is calculated
by dividing the total number of packets lost (after the effects of by dividing the total number of packets lost (after the effects of
applying any error protection such as FEC) by the total number of applying any error protection such as FEC) by the total number of
packets expected, multiplying the result of the division by 256, and packets expected, multiplying the result of the division by 256, and
taking the integer part. The numbers of duplicated packets and disˇ taking the integer part. The numbers of duplicated packets and dis-
carded packets do not enter into this calculation. Since receivers carded packets do not enter into this calculation. Since receivers
cannot be required to maintain unlimited buffers, a receiver MAY cannot be required to maintain unlimited buffers, a receiver MAY cat-
categorize late-arriving packets as lost. The degree of lateness egorize late-arriving packets as lost. The degree of lateness that
that triggers a loss SHOULD be significantly greater than that which triggers a loss SHOULD be significantly greater than that which trig-
triggers a discard. gers 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 dis
carded since the beginning of reception, due to late or early carded 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. This
value is expressed as a fixed point number with the binary point at 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 the left edge of the field. It is calculated by dividing the total
number of packets discarded (excluding duplicate packet discards) by number of packets discarded (excluding duplicate packet discards) by
the total number of packets expected, multiplying the result of the the total number of packets expected, multiplying the result of the
division by 256, and taking the integer part. division by 256, and taking the integer part.
burst metrics: burst metrics:
A burst is defined as a longest sequence of packets bounded by lost 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ˇ or discarded packets with the constraint that within a burst the num-
ber of successive packets that were received, and not discarded due ber of successive packets that were received, and not discarded due
to delay variation, is less than some value Gmin. A gap is defined 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 as the interval between bursts, and has the property that any lost or
discarded packets must be preceded and followed by at least Gmin discarded packets must be preceded and followed by at least Gmin
packets that were received and not discarded. This gives a maximum packets that were received and not discarded. This gives a maximum
loss/discard density within a gap of 1 / (Gmin + 1). loss/discard density within a gap of: 1 / (Gmin + 1).
burst duration: 16 bits burst duration: 16 bits
The mean duration, expressed in milliseconds, of the burst intervals The mean duration, expressed in milliseconds, of the burst intervals
that have occurred since the beginning of reception. The duration of that have occurred since the beginning of reception. The duration of
each interval is calculated based upon the packets that mark the each interval is calculated based upon the packets that mark the
beginning and end of that interval. It is equal to the timestamp of beginning and end of that interval. It is equal to the timestamp of
the end packet, plus the duration of the end packet, minus the times the end packet, plus the duration of the end packet, minus the times
tamp of the beginning packet. If the actual values are not avail tamp of the beginning packet. If the actual values are not avail
able, estimated values MUST be used. If there have been no burst able, estimated values MUST be used. If there have been no burst
intervals, the burst duration value MUST be zero. intervals, the burst duration value MUST be zero.
burst density: 8 bits burst density: 8 bits
The fraction of RTP data packets within burst intervals since the The fraction of RTP data packets within burst intervals since the
beginning of reception that were either lost or discarded. This beginning of reception that were either lost or discarded. This
value is expressed as a fixed point number with the binary point at 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 the left edge of the field. It is calculated by dividing the total
number of packets lost or discarded (excluding duplicate packet disˇ number of packets lost or discarded (excluding duplicate packet dis-
cards) within burst intervals by the total number of packets expected cards) within burst intervals by the total number of packets expected
within the burst intervals, multiplying the result of the division by within the burst intervals, multiplying the result of the division by
256, and taking the integer part. 256, and taking the integer part.
gap duration: 16 bits gap duration: 16 bits
The mean duration, expressed in milliseconds, of the gap intervals The mean duration, expressed in milliseconds, of the gap intervals
that have occurred since the beginning of reception. The duration of that have occurred since the beginning of reception. The duration of
each interval is calculated based upon the packet that marks the end each interval is calculated based upon the packet that marks the end
of the prior burst and the packet that marks the beginning of the of the prior burst and the packet that marks the beginning of the
subsequent burst. It is equal to the timestamp of the subsequent subsequent burst. It is equal to the timestamp of the subsequent
skipping to change at page 19, line 20 skipping to change at page 21, line 21
prior burst packet and the duration of the prior burst packet are 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 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 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 packet is replaced by the reception end time. If there have been no
gap intervals, the gap duration value MUST be zero. gap intervals, the gap duration value MUST be zero.
gap density: 8 bits gap density: 8 bits
The fraction of RTP data packets within inter-burst gaps since the The fraction of RTP data packets within inter-burst gaps since the
beginning of reception that were either lost or discarded. The value beginning of reception that were either lost or discarded. The value
is expressed as a fixed point number with the binary point at the 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 numˇ left edge of the field. It is calculated by dividing the total num-
ber of packets lost or discarded (excluding duplicate packet dis ber of packets lost or discarded (excluding duplicate packet dis
cards) within gap intervals by the total number of packets expected cards) within gap intervals by the total number of packets expected
within the gap intervals, multiplying the result of the division by within the gap intervals, multiplying the result of the division by
256, and taking the integer part. 256, and taking the integer part.
For example, if the packet spacing is 10mS and a 1 denotes a received For example, if the packet spacing is 10mS and a 1 denotes a received
packet and 0, a lost, and X, a discarded, packet then the following packet and 0, a lost, and X, a discarded, packet then the following
pattern: pattern:
11110111111111111111111X111X1011110111111111111111111X111111111 11110111111111111111111X111X1011110111111111111111111X111111111
|--burst---| |--burst---|
would have a burst duration of 120mS, a burst density of 0.33, a gap would have a burst duration of 120mS, a burst density of 0.33, a gap
duration of 510mS and a gap density of 0.04, for a GMIN value of 4 or duration of 510mS and a gap density of 0.04, for a GMIN value of 4 or
larger. larger.
4.8.4 Delay metrics 4.7.4 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 con-
sidered to be part of the voice application or end-system delay sidered 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 interfaces,
expressed in milliseconds. This value is the time of receipt of the expressed in milliseconds. This value is the time of receipt of the
most recent RTCP packet from source SSRC, minus the LSR (last SR) most recent RTCP packet from source SSRC, minus the LSR (last SR)
time reported in its SR (sender report), minus the DLSR (delay since time reported in its SR (sender report), minus the DLSR (delay since
last SR) reported in its SR. A non-zero LSR value is REQUIRED in last SR) reported in its SR. A non-zero LSR value is REQUIRED in
order to calculate round trip delay. A value of 0 is permissible durˇ order to calculate round trip delay. A value of 0 is permissible dur-
ing the first 2-3 RTCP exchanges as insufficient data may be availˇ ing the first 2-3 RTCP exchanges as insufficient data may be avail-
able to determine delay however MUST be populated as soon as a delay able to determine delay however MUST be populated as soon as a delay
estimate is available. 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 millisec-
onds. End system delay is defined as the total encoding, decoding onds. End system delay is defined as the total encoding, decoding
and jitter buffer delay determined at the reporting endpoint. This and jitter buffer delay determined at the reporting endpoint. This
is the time required for an RTP frame to be buffered, decoded, conˇ is the time required for an RTP frame to be buffered, decoded, con-
verted to analog form, looped back at the local analog interface, verted to analog form, looped back at the local analog interface,
encoded, and made available for transmission as an RTP frame. The encoded, and made available for transmission as an RTP frame. The
manner in which this value is estimated is implementation dependent. manner in which this value is estimated is implementation dependent.
This parameter MUST be provided in all VoIP metrics reports. 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.8.5 Signal related metrics 4.7.5 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 level: 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 signal
level to overflow signal level, expressed in decibels as a signed level to overflow signal level, expressed in decibels as a signed
integer in two's complement form. This is measured only for packets integer in two's complement form. This is measured only for packets
containing speech energy. The intent of this metric is not to proˇ containing speech energy. The intent of this metric is not to pro-
vide a precise measurement of the signal level but to provide a real vide a precise measurement of the signal level but to provide a real
time indication that the signal level may be excessively high or low. time indication that the signal level may be excessively high or low.
If the full range (overflow level) of the Vocoder's Digital to Analog 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 conversion function is +/- L and the value of a decoded sample during
a talkspurt is V then the signal level is given by 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 doubletalk level: 8 bits
The doubletalk level is defined as the proportion of voice frame The doubletalk level is defined as the proportion of voice frame
intervals during which speech energy was present in both sending and intervals during which speech energy was present in both sending and
receiving directions. High levels of doubletalk can provide an indiˇ receiving directions. High levels of doubletalk can provide an indi-
cation of delay or echo related problems. The value is expressed as a cation of delay or echo related problems. The value is expressed as a
fixed point number with the binary point at the left edge of the fixed point number with the binary point at the left edge of the
field. It is calculated by dividing the total number of voice frame field. It is calculated by dividing the total number of voice frame
intervals by the number of voice frame intervals during which energy intervals by the number of voice frame intervals during which energy
was present in both sending and receiving directions, multiplying was present in both sending and receiving directions, multiplying
the result of the division by 256, and taking the integer part. the result of the division by 256, and taking the integer part.
A value of 255 indicates that this value is unavailable A value of 255 indicates that this value is unavailable
noise level: 8 bits noise level: 8 bits
The noise level is defined as the ratio of the silent period back The noise level is defined as the ratio of the silent period back
ground noise level to overflow signal power, expressed in decibels as ground noise level to overflow signal power, expressed in decibels as
a signed integer in two's complement form. If the full range (overˇ a signed integer in two's complement form. If the full range (over-
flow level) of the Vocoder's Digital to Analog conversion function is flow 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 +/- L and the value of a decoded sample during a silence period is V
then the noise level is given by then the noise level is given by
Noise level = 10 log10 ( mean( abs(V) / L ) ) 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.8.6 Call quality/ transmission quality metrics 4.7.6 Call quality/ transmission quality metrics
The following metrics are direct measures of the transmission quality The following metrics are direct measures of the transmission quality
or call quality, and incorporate the effects of CODEC type, packet or call quality, and incorporate the effects of CODEC type, packet
loss, discard, burstiness, delay etc. These metrics may not be loss, discard, burstiness, delay etc. These metrics may not be
available in all systems however SHOULD be provided in order to supˇ available in all systems however SHOULD be provided in order to sup-
port problem diagnosis. port 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 the
call that is carried over this RTP session. It is expressed as an call that is carried over this RTP session. It is expressed as an
integer in the range 0 to 100, with a value of 94 corresponding to integer in the range 0 to 100, with a value of 94 corresponding to
"toll quality" and values of 50 or less regarded as unusable. This "toll quality" and values of 50 or less regarded as unusable. This
metric is defined as including the effects of delay, consistent with metric is defined as including the effects of delay, consistent with
ITU-T G.107 [6] and ETSI TS 101 329-5 [5]. ITU-T G.107 [6] and ETSI TS 101 329-5 [5].
skipping to change at page 22, line 30 skipping to change at page 24, line 32
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. 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) is a
voice quality metric on a scale from 1 to 5, in which 5 represents voice quality metric on a scale from 1 to 5, in which 5 represents
excellent and 1 represents unacceptable. This metric is defined as excellent and 1 represents unacceptable. This metric is defined as
not including the effects of delay and can be compared to MOS scores not including the effects of delay and can be compared to MOS scores
obtained from listening quality (ACR) tests. It is expressed as an obtained from listening quality (ACR) tests. It is expressed as an
integer in the range 10 to 50, corresponding to MOS x 10. For examˇ integer in the range 10 to 50, corresponding to MOS x 10. For exam-
ple, a value of 35 would correspond to an estimated MOS score of 3.5. ple, 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 (MOS-CQ)
is defined as including the effects of delay and other effects that is defined as including the effects of delay and other effects that
would affect conversational quality. The metric may be calculated by would affect conversational quality. The metric may be calculated by
converting an R factor determined according to ITU-T G.107 [6] or converting an R factor determined according to ITU-T G.107 [6] or
ETSI TS 101 329-5 [5] into an estimated MOS using the equation speciˇ ETSI TS 101 329-5 [5] into an estimated MOS using the equation speci-
fied in G.107 fied in G.107
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
4.8.7 Configuration parameters: 4.7.7 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 value of
16 = 0x10 corresponds to a burst interval having a minimum density of 16 (octal 0x10) corresponds to a burst interval having a minimum den-
6.25% of lost or discarded packets, which may cause noticeable degraˇ sity of 6.25% of lost or discarded packets, which may cause notice-
dation in call quality; during gap intervals, if packet loss or dis able degradation in call quality; during gap intervals, if packet
card occurs, each lost or discarded packet would be preceded by and loss or dis card occurs, each lost or discarded packet would be pre-
followed by a sequence of at least 16 received non-discarded packets. ceded by and followed by a sequence of at least 16 received non-dis-
Note that lost or discarded packets that occur within Gmin packets of carded packets. Note that lost or discarded packets that occur
a report being generated may be reclassified as being part of a burst within Gmin packets of a report being generated may be reclassified
or gap in later reports. ETSI TS 101 329-5 [5] defines a computaˇ as being part of a burst or gap in later reports. ETSI TS 101 329-5
tionally efficient algorithm for measuring burst and gap density [5] defines a computationally efficient algorithm for measuring burst
using a packet loss/discard event driven approach. Gmin MUST not be and gap density using a packet loss/discard event driven approach.
zero and MUST be provided. Gmin MUST not be zero and MUST be provided.
Receiver Configuration byte: Receiver Configuration byte:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|PLC|JBA|JB rate| |PLC|JBA|JB rate|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
PLC - packet loss concealment PLC - packet loss concealment
Standard (11) / enhanced (10) / disabled (01) / unspecified (00). Standard (11) / enhanced (10) / disabled (01) / unspecified (00).
When PLC=11 then a simple replay or interpolation algorithm is being When PLC=11 then a simple replay or interpolation algorithm is being
used to fill-in the missing packet - this is typically able to conˇ used to fill-in the missing packet - this is typically able to con-
ceal isolated lost packets with loss rates under 3%. When PLC=10 ceal isolated lost packets with loss rates under 3%. When PLC=10
then an enhanced interpolation algorithm is being used - this would then an enhanced interpolation algorithm is being used - this would
typically be able to conceal lost packets for loss rates of 10% or 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. 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 When PLC = 00 then no information is available concerning the use of
PLC however for some CODECs this may be inferred. PLC however for some CODECs this may be inferred.
JBA - Jitter Buffer Adaptive JBA - Jitter Buffer Adaptive
Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When
Jitter Buffer is adaptive then its size is being dynamically adjusted Jitter Buffer is adaptive then its size is being dynamically adjusted
to deal with varying levels of jitter. When non-adaptive then the to deal with varying levels of jitter. When non-adaptive then the
Jitter Buffer size is maintained at a fixed level. When either adapˇ Jitter Buffer size is maintained at a fixed level. When either adap-
tive or non-adaptive modes are specified then the Jitter Buffer Size 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 JB Rate - Jitter Buffer Rate
J = adjustment rate (0-15). This represents the implementation speˇ J = adjustment rate (0-15). This represents the implementation spe-
cific adjustment rate of a Jitter Buffer in adaptive mode. This cific adjustment rate of a Jitter Buffer in adaptive mode. This
parameter is defined in terms of the approximate time taken to fully parameter is defined in terms of the approximate time taken to fully
adjust to a step change in peak to peak jitter from 30mS to 100mS adjust to a step change in peak to peak jitter from 30mS to 100mS
such that: 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 degree of
"aggressiveness" of a an adaptive jitter buffer and may be estimated. "aggressiveness" of a an adaptive jitter buffer and may be estimated.
A value of 0 indicates that the adjustment time is unknown for this A value of 0 indicates that the adjustment time is unknown for this
implementation. implementation.
4.8.7 Jitter Buffer Parameters 4.7.7 Jitter Buffer Parameters
Jitter Buffer - nominal size in frames (8 bit) Jitter Buffer - nominal size in frames (8 bit)
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 that
arrive exactly on time. This parameter MUST be provided for both arrive exactly on time. This parameter MUST be provided for both
fixed and adaptive jitter buffer implementations. fixed and adaptive jitter buffer implementations.
Jitter Buffer Maximum - size in frames (8 bit) Jitter Buffer Maximum - size in frames (8 bit)
This is the current maximum jitter buffer level corresponding to the This is the current maximum jitter buffer level corresponding to the
earliest arriving packet that would not be discarded. In simple earliest arriving packet that would not be discarded. In simple
skipping to change at page 25, line 31 skipping to change at page 27, line 31
lost++; lost++;
if (pkt == 0) if (pkt == 0)
c33++; c33++;
else else
{ {
c23++; c23++;
c22 += (pkt - 1); c22 += (pkt - 1);
} }
} }
At each reporting interval the burst and gap metrics can be calcuˇ At each reporting interval the burst and gap metrics can be calcu-
lated as follows. lated 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)
skipping to change at page 26, line 28 skipping to change at page 28, line 28
/* 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. Acknowledgements 5. IANA Considerations
We thank the following people: Colin Perkins, Steve Casner, and Henˇ 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 ning Schulzrinne for their considered guidance; Nick Duffield for
extensive ongoing contributions; Sue Moon for helping foster collaboˇ extensive ongoing contributions; Sue Moon for helping foster collabo-
ration between the authors of this document; and Mounir Benzaid for ration between the authors of this document; and Mounir Benzaid for
drawing our attention to the reporting needs of MLDA. drawing our attention to the reporting needs of MLDA.
6. Intellectual Property 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 per-
tain to the implementation or use of the technology described in this tain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might document or the extent to which any license under such rights might
or might not be available; neither does it represent that it has made or might not be available; neither does it represent that it has made
any effort to identify any such rights. Information on the IETF's any effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards- procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP 11 [7]. Copies of claims related documentation can be found in BCP 11 [7]. Copies of claims
of rights made available for publication and any assurances of of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to 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 propri-
etary rights by implementors or users of this specification can be etary rights by implementors or users of this specification can be
obtained from the IETF Secretariat. 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.
7. References 9. References
[1] A. Adams, T. Bu, R. Caceres, N.G. Duffield, T. Friedman, J. [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 Horowitz, F. Lo Presti, S.B. Moon, V. Paxson, and D. Towsley, "The
Use of End-to-End Multicast Measurements for Characterizing Internal Use of End-to-End Multicast Measurements for Characterizing Internal
Network Behavior," IEEE Communications Magazine, May 2000. Network Behavior," IEEE Communications Magazine, May 2000.
[2] S. Bradner, "Key words for use in RFCs to indicate requirement [2] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," BCP 14, RFC 2119, IETF, March 1997. levels," BCP 14, RFC 2119, IETF, March 1997.
[3] R. Caceres, N.G. Duffield, and T. Friedman, "Impromptu measureˇ [3] R. Caceres, N.G. Duffield, and T. Friedman, "Impromptu measure-
ment infrastructures using RTP," Proc. IEEE Infocom 2002. ment infrastructures using RTP," Proc. IEEE Infocom 2002.
[4] A. D. Clark, "Modeling the Effects of Burst Packet Loss and [4] A. D. Clark, "Modeling the Effects of Burst Packet Loss and
Recency on Subjective Voice Quality," Proc. IP Telephony Workshop Recency on Subjective Voice Quality," Proc. IP Telephony Workshop
2001. 2001.
[5] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI [5] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI
TS 101 329-5 V1.1.1 (2000-11), November 2000. TS 101 329-5 V1.1.1 (2000-11), November 2000.
[6] ITU-T, "The E-Model, a computational model for use in transmisˇ [6] ITU-T, "The E-Model, a computational model for use in transmis-
sion planning," Recommendation G.107 (05/00), May 2000. sion planning," Recommendation G.107 (05/00), May 2000.
[7] J. Reynolds and J. Postel, "Assigned Numbers," STD 2, RFC 1700, [7] J. Reynolds and J. Postel, "Assigned Numbers," STD 2, RFC 1700,
IETF, October 1994. IETF, October 1994.
[8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A [8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
transport protocol for real-time applications," RFC 1889, IETF, transport protocol for real-time applications," RFC 1889, IETF,
February 1996. February 1996.
[9] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Conˇ [9] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Con-
trol Framework for Heterogeneous Multicast Environments", Proc. IWQoS trol Framework for Heterogeneous Multicast Environments", Proc. IWQoS
2000. 2000.
8. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). 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 doc-
ument itself may not be modified in any way, such as by removing the ument itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other 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 develop-
ing Internet standards in which case the procedures for copyrights ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English. 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 MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
9. Authors' Addresses 9. Authors' Addresses
Timur Friedman <timur.friedman@lip6.fr> Timur Friedman <timur.friedman@lip6.fr>
University of Paris 6 University of Paris 6
Laboratoire LiP6-CNRS Laboratoire LiP6-CNRS
8, rue du Capitaine Scott 8, rue du Capitaine Scott
75015 PARIS, FRANCE 75015 PARIS, FRANCE
Ramon Caceres <ramon@shieldip.com> Ramon Caceres <ramon@shieldip.com>
ShieldIP, Inc. ShieldIP, Inc.
11 West 42nd Street, 31st Floor 11 West 42nd Street, 31st Floor
New York, NY 10036, USA New York, NY 10036, USA
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
skipping to change at page 29, line 25 skipping to change at line 1419
Havre de Grace, MD, USA 21078 Havre de Grace, MD, USA 21078
Tel: +1 410 939-8732 Tel: +1 410 939-8732
Fax: +1 410 939-8732 Fax: +1 410 939-8732
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
Tel: +1 978 367-5600 Tel: +1 978 367-5600
Fax: +1 978 367-5700 Fax: +1 978 367-5700
10. Expiry
This draft expires 18 January 2003.
 End of changes. 

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