draft-ietf-avt-rtcp-report-extns-03.txt   draft-ietf-avt-rtcp-report-extns-04.txt 
Internet Engineering Task Force Expires: 2 September 2003 Internet Engineering Task Force Expires: 16 October 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
Alan Clark, Telchemy Alan Clark, Telchemy
Editors Editors
RTP Extended Reports (RTP XR) RTP Control Protocol Extended Reports (RTCP XR)
draft-ietf-avt-rtcp-report-extns-03.txt draft-ietf-avt-rtcp-report-extns-04.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 42 skipping to change at page 1, line 42
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 (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document defines the extended report (XR) packet type for the This document defines the Extended Report (XR) packet type for the
RTP control protocol (RTCP). XR packets are composed of report RTP Control Protocol (RTCP), and defines how the use of XR packets
can be signaled by an application if it employs the Session
Description Protocol (SDP). XR packets are composed of report
blocks, and seven block types are defined here. The purpose of the blocks, and seven block types are defined here. The purpose of the
extended reporting format is to convey information that supplements extended reporting format is to convey information that supplements
the six statistics that are contained in the report blocks used by the six statistics that are contained in the report blocks used by
RTCP's sender report (SR) and receiver report (RR) packets. Some RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some
applications, such as multicast inference of network characteristics applications, such as multicast inference of network characteristics
(MINC) or voice over IP (VoIP) monitoring, require other and more (MINC) or voice over IP (VoIP) monitoring, require other and more
detailed statistics. In addition to the block types defined here, detailed statistics. In addition to the block types defined here,
additional block types may be defined in the future by adhering to additional block types may be defined in the future by adhering to
the framework that this document provides. the framework that this document provides.
Table of Contents Table of Contents
1. Introduction .............................................. 2 1. Introduction .............................................. 3
1.1 Terminology ............................................... 3 1.1 Applicability ............................................. 4
2. XR Packet Format .......................................... 4 1.2 Terminology ............................................... 6
3. Extended Report Block Framework ........................... 5 2. XR Packet Format .......................................... 6
4. Extended Report Blocks .................................... 6 3. Extended Report Block Framework ........................... 8
4.1 Loss RLE Report Block ..................................... 6 4. Extended Report Blocks .................................... 9
4.1.1 Run Length Chunk .......................................... 12 4.1 Loss RLE Report Block ..................................... 9
4.1.2 Bit Vector Chunk .......................................... 12 4.1.1 Run Length Chunk .......................................... 15
4.1.3 Terminating Null Chunk .................................... 12 4.1.2 Bit Vector Chunk .......................................... 15
4.2 Duplicate RLE Report Block ................................ 13 4.1.3 Terminating Null Chunk .................................... 15
4.3 Timestamp Report Block .................................... 14 4.2 Duplicate RLE Report Block ................................ 16
4.4 Statistics Summary Report Block ........................... 16 4.3 Packet Receipt Times Report Block ......................... 17
4.5 Receiver Timestamp Report Block ........................... 19 4.4 Receiver Reference Time Report Block ...................... 20
4.6 DLRR Report Block ......................................... 20 4.5 DLRR Report Block ......................................... 21
4.7 VoIP Metrics Report Block ................................. 21 4.6 Statistics Summary Report Block ........................... 22
4.7.1 Packet Loss and Discard Metrics ........................... 22 4.7 VoIP Metrics Report Block ................................. 25
4.7.2 Burst Metrics ............................................. 23 4.7.1 Packet Loss and Discard Metrics ........................... 26
4.7.3 Delay Metrics ............................................. 25 4.7.2 Burst Metrics ............................................. 27
4.7.4 Signal Related Metrics .................................... 26 4.7.3 Delay Metrics ............................................. 29
4.7.5 Call Quality or Transmission Quality Metrics .............. 29 4.7.4 Signal Related Metrics .................................... 30
4.7.6 Configuration Parameters .................................. 30 4.7.5 Call Quality or Transmission Quality Metrics .............. 33
4.7.7 Jitter Buffer Parameters .................................. 31 4.7.6 Configuration Parameters .................................. 34
5. IANA Considerations ....................................... 32 4.7.7 Jitter Buffer Parameters .................................. 35
5.1 XR Packet Type ............................................ 32 5. SDP Signaling ............................................. 36
5.2 RTP XR Block Type Registry ................................ 32 5.1 The SDP Attribute ......................................... 36
6. Security Considerations ................................... 33 5.2 Usage in Offer/Answer ..................................... 39
A. Algorithms ................................................ 34 5.3 Usage Outside of Offer/Answer ............................. 40
A.1 Sequence Number Interpretation ............................ 34 6. IANA Considerations ....................................... 41
A.2 Example Burst Packet Loss Calculation ..................... 35 6.1 XR Packet Type ............................................ 41
Intellectual Property ..................................... 37 6.2 RTCP XR Block Type Registry ............................... 41
Full Copyright Statement .................................. 37 6.3 The "rtcp-xr" SDP Attribute ............................... 42
Acknowledgments ........................................... 38 7. Security Considerations ................................... 43
Contributors .............................................. 38 A. Algorithms ................................................ 44
Authors' Addresses ........................................ 39 A.1 Sequence Number Interpretation ............................ 44
References ................................................ 40 A.2 Example Burst Packet Loss Calculation ..................... 45
Normative References ...................................... 40 Intellectual Property ..................................... 47
Non-Normative References .................................. 41 Full Copyright Statement .................................. 48
Acknowledgments ........................................... 48
Contributors .............................................. 48
Authors' Addresses ........................................ 49
References ................................................ 51
Normative References ...................................... 51
Non-Normative References .................................. 52
1. Introduction 1. Introduction
This document defines the extended report (XR) packet type for the This document defines the Extended Report (XR) packet type for the
RTP control protocol (RTCP) [7]. XR packets convey information RTP Control Protocol (RTCP) [10], and defines how the use of XR
beyond that already contained in the reception report blocks of packets can be signaled by an application if it employs the Session
RTCP's sender report (SR) or receiver report (RR) packets. The Description Protocol (SDP) [4]. XR packets convey information beyond
information is of use across RTP profiles, and so is not that already contained in the reception report blocks of RTCP's
appropriately carried in SR or RR profile-specific extensions. sender report (SR) or Receiver Report (RR) packets. The information
Information used for network management falls into this category, for is of use across RTP profiles, and so is not appropriately carried in
instance. SR or RR profile-specific extensions. Information used for network
management falls into this category, for instance.
The definition is broken out over the three following sections of The definition is broken out over the three sections that follow the
this document, starting with a general framework and finishing with Introduction. Section 2 defines the XR packet as consisting of an
the specific information conveyed. The framework defined by Section eight octet header followed by a series of components called report
2 contains common header information followed by a series of blocks. Section 3 defines the common format, or framework,
components called report blocks. Section 3 defines the format common consisting of a type and a length field, required for all report
to such blocks. Section 4 defines seven block types. blocks. Section 4 defines several specific report block types.
Other block types can be defined in future documents as the need
arises.
Seven report block formats are defined by this document: The report block types defined in this document fall into three
categories. The first category consists of packet-by-packet reports
on received or lost RTP packets. Reports in the second category
convey reference time information between RTP participants. In the
third category, reports convey metrics relating to packet receipts,
that are summary in nature but that are more detailed, or of a
different type, than that conveyed in existing RTCP packets.
- Loss RLE Report Block (Section 4.1): Run length encoding of RTP All told, seven report block formats are defined by this document.
packet loss reports. Of these, three are packet-by-packet block types:
- Loss RLE Report Block (Section 4.1): Run length encoding of reports
concerning the losses and receipts of RTP packets.
- Duplicate RLE Report Block (Section 4.2): Run length encoding of - Duplicate RLE Report Block (Section 4.2): Run length encoding of
reports of RTP packet duplicates. reports concerning duplicates of received RTP packets.
- Timestamp Report Block (Section 4.3): A list of timestamps of - Packet Receipt Times Report Block (Section 4.3): A list of
received RTP packets. reception timestamps of RTP packets.
- Statistics Summary Report Block (Section 4.4): Statistics on RTP There are two reference time related block types:
packet sequence numbers, losses, duplicates, jitter, and TTL values.
- Receiver Timestamp Report Block (Section 4.5): Receiver-end - Receiver Reference Time Report Block (Section 4.4): Receiver-end
timestamps that complement the sender-end timestamps already defined wallclock timestamps. Together with the DLRR Report Block mentioned
for RTCP. next, these allow non-senders to calculate round-trip times.
- DLRR Report Block (Section 4.6): The delay since the last Receiver - DLRR Report Block (Section 4.5): The delay since the last Receiver
Timestamp Report Block was received, allowing non-senders to Reference Time Report Block was received. An RTP data sender that
calculate round-trip times. receives a Receiver Reference Time Report Block can respond with a
DLRR Report Block, in much the same way as, in the mechanism already
defined for RTCP [10, Section 6.3.1], an RTP data receiver that
receives a sender's NTP timestamp can respond by filling in the DLSR
field of an RTCP reception report block.
Finally, this document defines two summary metric block types:
- Statistics Summary Report Block (Section 4.6): Statistics on RTP
packet sequence numbers, losses, duplicates, jitter, and TTL or Hop
Limit values.
- VoIP Metrics Report Block (Section 4.7): Metrics for monitoring - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring
Voice over IP (VoIP) calls. Voice over IP (VoIP) calls.
These blocks are defined within a minimal framework: a type field and Before proceeding to the XR packet and report block definitions, this
a length field are common to all XR blocks. The purpose is to document provides an applicability statement (Section 1.1) that
maintain flexibility and to keep overhead low. Other block formats, describes the contexts in which these report blocks can be used. It
beyond the seven defined here, may be defined within this framework also defines (Section 1.2) the normative use of key words, such as
as the need arises. MUST and SHOULD, as they are employed in this document.
Following the definitions of the various report blocks, this document
describes how applications that employ SDP can signal their use
(Section 5). The document concludes with a discussion (Section 6) of
numbering considerations for the Internet Assigned Numbers Authority
(IANA), of security considerations (Section 7), and with appendices
that provide examples of how to implement algorithms discussed in the
text.
1.1 Applicability
The XR packets are useful across multiple applications, and for that
reason are not defined as profile-specific extensions to RTCP sender
or Receiver Reports [10, Section 6.4.3]. Nonetheless, they are not
of use in all contexts. In particular, the VoIP metrics report block
(Section 4.7) is specific to voice applications, though it can be
employed over a wide variety of such applications.
The VoIP metrics report block can be applied to any conversational,
multicast or broadcast application for which the use of RTP and RTCP
is specified. The use of conversational metrics (Section 4.7.5),
including the R factor (as described by the E Model defined in [3])
and the mean opinion score for conversational quality (MOS-CQ), in
applications other than simple two party calls is not defined, and
hence these metrics should be identified as unavailable in
conferencing, multicast and broadcast applications.
The packet-by-packet report block types, Loss RLE (Section 4.1),
Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3),
have been defined with network tomography applications, such as
multicast inference of network characteristics (MINC) [11], in mind.
MINC requires detailed packet receipt traces from multicast session
receivers in order to infer the gross structure of the multicast
distribution tree and the parameters, such as loss rates and delays,
that apply to paths between the branching points of that tree.
Any real time multicast multimedia application can use the packet-by-
packet report block types. Such an application could employ a MINC
inference subsystem that would provide it with multicast tree
topology information. One potential use of such a subsystem would be
for the identification of high loss regions in the multicast tree and
the identification of multicast session participants well situated to
provide retransmissions of lost packets.
Detailed packet-by-packet reports do not necessarily have to consume
disproportionate bandwidth with respect to other RTCP packets. An
application can cap the size of these blocks. A mechanism called
"thinning" is provided for these report blocks, and can be used to
ensure that they adhere to a size limit by restricting the number of
packets reported upon within any sequence number interval. The
rationale for, and use of this mechanism is described in [13].
Furthermore, applications might not require report blocks from all
receivers in order to answer such important questions as where in the
multicast tree there are paths that exceed a defined loss rate
threshold. Intelligent decisions regarding which receivers send
these report blocks can further restrict the portion of RTCP
bandwidth that they consume.
The packet-by-packet report blocks can also be used by dedicated
network monitoring applications. For such an application, it might
be appropriate to allow more than 5% of RTP data bandwidth to be used
for RTCP packets, thus allowing proportionately larger and more
detailed report blocks.
Nothing in the packet-by-packet block types restricts their use to
multicast applications. In particular, they could be used for
network tomography similar to MINC, but using striped unicast
packets. In addition, if it were found useful, they could be used
for applications limited to two participants.
One use to which the packet-by-packet reports are not immediately
suited is for data packet acknowledgments as part of a packet
retransmission mechanism. The reason is that the packet accounting
technique suggested for these blocks differs from the packet
accounting normally employed by RTP. In order to favor measurement
applications, an effort is made to interpret as little as possible at
the data receiver, and leave the interpretation as much as possible
to participants that receive the report blocks. Thus, for example, a
packet with an anomalous SSRC ID or an anomalous sequence number
might be excluded by normal RTP accounting, but would be reported
upon for network monitoring purposes.
The Statistics Summary Report Block (Section 4.6) has also been
defined with network monitoring in mind. This block type can be used
equally well for reporting on unicast and multicast packet reception.
The reference time related block types were conceived for receiver-
based TCP-friendly multicast congestion control [17]. By allowing
data receivers to calculate their round trip times to senders, they
help the receivers estimate the downstream bandwidth they should
request. Note that if every receiver is to send Receiver Reference
Time Report Blocks (Section 4.4), a sender might potentially send a
number of DLRR Report Blocks (Section 4.5) equal to the number of
receivers whose RTCP packets have arrived at the sender within its
reporting interval. As the number of participants in a multicast
session increases, an application should use discretion regarding
which participants send these blocks, and how frequently.
The SDP signaling defined for XR packets in this document (Section 5)
was done so with three use scenarios in mind: a Real Time Streaming
Protocol (RTSP) controlled streaming application, a one-to-many
multicast multimedia application such as a course lecture with
enhanced feedback, and a Session Initiation Protocol (SIP) controlled
conversational session involving two parties. Applications that
employ SDP are free to use additional SDP signaling for cases not
covered here. In addition, applications are free to use signaling
mechanisms other than SDP.
1.2 Terminology
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 [1] and document are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliance with this specification. indicate requirement levels for compliance with this specification.
2. XR Packet Format 2. XR Packet Format
The XR packet consists of a header of two 32-bit words, followed by a An 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 type of
packet is laid out in a manner consistent with other RTCP packets, as
concerns the essential version, packet type, and length information.
XR packets are thus backwards compatibility with RTCP receiver
implementations that do not recognize them, but that ought to be able
to parse past them using the length information. A padding field and
an SSRC/CSRC field are also provided in the same locations that they
appear in other RTCP packets, for simplicity. The format is as
follows:
0 1 2 3 0 1 2 3
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=207 | length | |V=2|P|reserved | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC | | SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: report blocks : : report blocks :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
version (V): 2 bits version (V): 2 bits
Identifies the version of RTP. This specification applies to Identifies the version of RTP. This specification applies to
RTP version two. RTP version two.
skipping to change at page 4, line 45 skipping to change at page 7, line 45
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver. MUST be ignored by the receiver.
packet type (PT): 8 bits packet type (PT): 8 bits
Contains the constant 207 to identify this as an RTCP XR packet. Contains the constant 207 to identify this as an RTCP XR packet.
This value is registered with the Internet Assigned Numbers This value is registered with the Internet Assigned Numbers
Authority (IANA), as described in Section 5.1. Authority (IANA), as described in Section 5.1.
length: 16 bits length: 16 bits
As described for the RTP sender report (SR) packet (see Section As described for the RTCP Sender Report (SR) packet (see Section
6.3.1 of the RTP specification [7]). Briefly, the length of 6.3.1 of the RTP specification [10]). Briefly, the length of
this XR packet in 32-bit words minus one, including the header this XR packet in 32-bit words minus one, including the header
and any padding. and any padding.
SSRC: 32 bits SSRC/CSRC: 32 bits
The synchronization source identifier for the originator of this The synchronization source identifier for the originator of this
XR packet. XR packet.
report blocks: variable length. report blocks: variable length.
Zero or more extended report blocks. In keeping with the Zero or more extended report blocks. In keeping with the
extended report block framework defined below, each block MUST extended report block framework defined below, each block MUST
consist of one or more 32-bit words. consist of one or more 32-bit words.
3. Extended Report Block Framework 3. Extended Report Block Framework
skipping to change at page 5, line 33 skipping to change at page 8, line 33
type, and can use the length information to locate each successive type, and can use the length information to locate each successive
block, even in the presence of block types it does not recognize. block, even in the presence of block types it does not recognize.
An extended report block has the following format: An extended report block has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT | type-specific | block length | | BT | type-specific | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: type-specific data : : type-specific block contents :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
Identifies the block format. Seven block types are defined in Identifies the block format. Seven block types are defined in
Section 4. Additional block types may be defined in future Section 4. Additional block types may be defined in future
specifications. This field's name space is managed by the specifications. This field's name space is managed by the
Internet Assigned Numbers Authority (IANA), as described in Internet Assigned Numbers Authority (IANA), as described in
Section 5.2. Section 5.2.
type-specific: 8 bits type-specific: 8 bits
The use of these bits is determined by the block type The use of these bits is determined by the block type
definition. definition.
block length: 16 bits block length: 16 bits
The length of this report block including the header, in 32-bit The length of this report block including the header, in 32-bit
words minus one. If the block type definition permits, zero is words minus one. If the block type definition permits, zero is
an acceptable value, signifying a block that consists of only an acceptable value, signifying a block that consists of only
the BT, type-specific, and block length fields, with a null the BT, type-specific, and block length fields, with a null
type-specific data field. type-specific block contents field.
type-specific data: variable length type-specific block contents: variable length
The use of this field is defined by the particular block type, The use of this field is defined by the particular block type,
subject to the constraint that it MUST be a multiple of 32 bits subject to the constraint that it MUST be a multiple of 32 bits
long. If the block type definition permits, It MAY be zero bits long. If the block type definition permits, It MAY be zero bits
long. long.
4. Extended Report Blocks 4. Extended Report Blocks
This section defines seven extended report blocks: block types for This section defines seven extended report blocks: block types for
losses, duplicates, packet reception timestamps, detailed reception reporting upon received packet losses and duplicates, packet
statistics, receiver timestamps, receiver inter-report delays, and reception times, receiver reference time information, receiver inter-
voice over IP (VoIP) metrics. An implementation SHOULD ignore report delays, detailed reception statistics, and voice over IP
incoming blocks with types either not relevant or unknown to it. (VoIP) metrics. An implementation SHOULD ignore incoming blocks with
Additional block types MUST be registered with the Internet Assigned types either not relevant or unknown to it. Additional block types
Numbers Authority (IANA) [5], as described in Section 5.2. MUST be registered with the Internet Assigned Numbers Authority
(IANA) [7], as described in Section 5.2.
4.1 Loss RLE Report Block 4.1 Loss RLE Report Block
This block type permits detailed reporting upon individual packet This block type permits detailed reporting upon individual packet
receipt and loss events. Such reports can be used, for example, for receipt and loss events. Such reports can be used, for example, for
multicast inference of network characteristics (MINC) [8]. With multicast inference of network characteristics (MINC) [11]. With
MINC, one can discover the topology of the multicast tree used for MINC, one can discover the topology of the multicast tree used for
distributing a source's RTP packets, and of the loss rates along distributing a source's RTP packets, and of the loss rates along
links within that tree. Or they could be used to provide raw data to links within that tree. Or they could be used to provide raw data to
a network management application. a network management application.
Since a Boolean trace of lost and received RTP packets is potentially Since a Boolean trace of lost and received RTP packets is potentially
lengthy, this block type permits the trace to be compressed through lengthy, this block type permits the trace to be compressed through
run length encoding. To further reduce block size, loss event run length encoding. To further reduce block size, loss event
reports can be systematically dropped from the trace in a mechanism reports can be systematically dropped from the trace in a mechanism
called thinning that is described below and that is studied in [9]. called thinning that is described below and that is studied in [13].
A participant that generates a Loss RLE Report Block should favor A participant that generates a Loss RLE Report Block should favor
accuracy in reporting on observed events over interpretation of those accuracy in reporting on observed events over interpretation of those
events whenever possible. Interpretation should be left to those who events whenever possible. Interpretation should be left to those who
observe the report blocks. Following this approach implies that observe the report blocks. Following this approach implies that
accounting for Loss RLE Report Blocks will differ from the accounting accounting for Loss RLE Report Blocks will differ from the accounting
for the generation of the SR and RR packets described in the RTP for the generation of the SR and RR packets described in the RTP
specification [7] in the following two areas: per-sender accounting specification [10] in the following two areas: per-sender accounting
and per-packet accounting. and per-packet accounting.
In its per-sender accounting, an RTP session participant SHOULD NOT In its per-sender accounting, an RTP session participant SHOULD NOT
make the receipt of a threshold minimum number of RTP packets a make the receipt of a threshold minimum number of RTP packets a
condition for reporting upon the sender of those packets. This condition for reporting upon the sender of those packets. This
accounting technique differs from the technique described in Section accounting technique differs from the technique described in Section
6.2.1 and Appendix A.1 of the RTP specification that allows a 6.2.1 and Appendix A.1 of the RTP specification that allows a
threshold to determine whether a sender is considered valid. threshold to determine whether a sender is considered valid.
In its per-packet accounting, an RTP session participant SHOULD treat In its per-packet accounting, an RTP session participant SHOULD treat
skipping to change at page 7, line 44 skipping to change at page 10, line 45
The per-packet accounting technique mandated here is for a The per-packet accounting technique mandated here is for a
participant to keep track of the sequence number of the packet most participant to keep track of the sequence number of the packet most
recently received from a sender. For the next packet that arrives recently received from a sender. For the next packet that arrives
from that sender, the sequence number MUST be judged to fall no more from that sender, the sequence number MUST be judged to fall no more
than 32,768 packets ahead or behind the most recent one, whichever than 32,768 packets ahead or behind the most recent one, whichever
choice places it closer. In the event that both choices are equally choice places it closer. In the event that both choices are equally
distant (only possible when the distance is 32,768), the choice MUST distant (only possible when the distance is 32,768), the choice MUST
be the one that does not require a rollover. Appendix A.1 presents be the one that does not require a rollover. Appendix A.1 presents
an algorithm that implements this technique. an algorithm that implements this technique.
Each block reports on a single source, identified by its SSRC. The Each block reports on a single RTP data packet source, identified by
receiver that is supplying the report is identified in the header of its SSRC. The receiver that is supplying the report is identified in
the RTCP packet. the header of the RTCP packet.
Choice of beginning and ending RTP packet sequence numbers for the Choice of beginning and ending RTP packet sequence numbers for the
trace is left to the application. These values are reported in the trace is left to the application. These values are reported in the
block. The last sequence number in the trace MAY differ from the block. The last sequence number in the trace MAY differ from the
sequence number reported on in any accompanying SR or RR report. sequence number reported on in any accompanying SR or RR report.
Note that because of sequence number wraparound the ending sequence Note that because of sequence number wraparound the ending sequence
number MAY be less than the beginning sequence number. A Loss RLE number MAY be less than the beginning sequence number. A Loss RLE
Report Block MUST NOT be used to report upon a range of 65,534 or Report 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 greater in the sequence number space, as there is no means to
skipping to change at page 11, line 40 skipping to change at page 14, line 40
The amount of thinning performed on the sequence number space. The amount of thinning performed on the sequence number space.
Only those packets with sequence numbers 0 mod 2^T are reported Only those packets with sequence numbers 0 mod 2^T are reported
on by this block. A value of 0 indicates that there is no on by this block. A value of 0 indicates that there is no
thinning, and all packets are reported on. The maximum thinning thinning, and all packets are reported on. The maximum thinning
is one packet in every 32,768 (amounting to two packets within is one packet in every 32,768 (amounting to two packets within
each 16-bit sequence space). each 16-bit sequence space).
block length: 16 bits block length: 16 bits
Defined in Section 3. Defined in Section 3.
SSRC of source: 32 bits
The SSRC of the RTP data packet source being reported upon by
this report block.
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 There are three chunk types: run length, bit vector, and
terminating null, defined in the following sections. If the terminating null, defined in the following sections. If the
chunk is all zeroes then it is a terminating null chunk. chunk is all zeroes then it is a terminating null chunk.
skipping to change at page 14, line 35 skipping to change at page 17, line 35
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver. MUST be ignored by the receiver.
thinning (T): 4 bits thinning (T): 4 bits
As defined in Section 4.1. As defined in Section 4.1.
block length: 16 bits block length: 16 bits
Defined in Section 3. Defined in Section 3.
SSRC of source: 32 bits
As defined in Section 4.1.
begin_seq: 16 bits begin_seq: 16 bits
As defined in Section 4.1. As defined in Section 4.1.
end_seq: 16 bits end_seq: 16 bits
As defined in Section 4.1. As defined in Section 4.1.
chunk i: 16 bits chunk i: 16 bits
As defined in Section 4.1. As defined in Section 4.1.
4.3 Timestamp Report Block 4.3 Packet Receipt Times Report Block
This block type permits per-sequence-number reports on packet receipt This block type permits per-sequence-number reports on packet receipt
timestamps for a given source's RTP packet stream. Such information times for a given source's RTP packet stream. Such information can
can be used for MINC inference of the topology of the multicast tree be used for MINC inference of the topology of the multicast tree used
used to distribute the source's RTP packets, and of the delays along to distribute the source's RTP packets, and of the delays along the
the links within that tree. It can also be used to measure partial links within that tree. It can also be used to measure partial path
path characteristics and to model distributions for packet jitter. characteristics and to model distributions for packet jitter.
Packet receipt times are expressed in the same units as used in the
RTP timestamps of data packets. This is so that, for each packet,
one can establish both the send time and the receipt time in
comparable terms. Note, however, that as an RTP sender ordinarily
initializes its time to a value chosen at random, there can be no
expectation that reported send and receipt times will differ by an
amount equal to the one-way delay between sender and receiver. The
reported times can nonetheless be useful for the purposes mentioned
above.
At least one packet MUST have been received for each sequence number At least one packet MUST have been received for each sequence number
reported upon in this block. If this block type is used to report reported upon in this block. If this block type is used to report
timestamps for a series of sequence numbers that includes lost receipt times for a series of sequence numbers that includes lost
packets, several blocks are required. If duplicate packets have been packets, several blocks are required. If duplicate packets have been
received for a given sequence number, and those packets differ in received for a given sequence number, and those packets differ in
their receiver timestamps, any timestamp other than the earliest MUST their receipt times, any time other than the earliest MUST NOT be
NOT be reported. This is to ensure consistency among reports. reported. This is to ensure consistency among reports.
Timestamps consume more bits than loss or duplicate information, and Times reported in RTP timestamp format consume more bits than loss or
do not lend themselves to run length encoding. The use of thinning duplicate information, and do not lend themselves to run length
is encouraged to limit the size of Timestamp Report Blocks. encoding. The use of thinning is encouraged to limit the size of
Packet Receipt Times Report Blocks.
The Timestamp Report Block has the following format: The Packet Receipt Times 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=3 | rsvd. | T | block length | | BT=3 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp 1 | | Receipt time of packet begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp 2 | | Receipt time of packet (begin_seq + 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp n | | Receipt time of packet (end_seq - 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Timestamp Report Block is identified by the constant 3. A Packet Receipt Times Report Block is identified by the
constant 3.
rsvd.: 4 bits rsvd.: 4 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver. MUST be ignored by the receiver.
thinning (T): 4 bits thinning (T): 4 bits
As defined in Section 4.1. As defined in Section 4.1.
block length: 16 bits block length: 16 bits
Defined in Section 3. Defined in Section 3.
SSRC of source: 32 bits
As defined in Section 4.1.
begin_seq: 16 bits begin_seq: 16 bits
As defined in Section 4.1. As defined in Section 4.1.
end_seq: 16 bits end_seq: 16 bits
As defined in Section 4.1. As defined in Section 4.1.
RTP timestamp i: 32 bits Receipt time of packet i: 32 bits
The timestamp reflects the packet arrival time at the receiver. The receipt time of the packet with sequence number i at the
It is preferable for the timestamp to be established at the link receiver. The modular arithmetic shown in the packet format
diagram is to allow for sequence number rollover. It is
preferable for the time value to be established at the link
layer interface, or in any case as close as possible to the wire layer interface, or in any case as close as possible to the wire
arrival time. Units and format are the same as for the arrival time. Units and format are the same as for the
timestamp in RTP data packets. As opposed to RTP data packet timestamp in RTP data packets. As opposed to RTP data packet
timestamps, in which nominal values may be used instead of timestamps, in which nominal values may be used instead of
system clock values in order to convey information useful for system clock values in order to convey information useful for
periodic playout, the receiver timestamps should reflect the periodic playout, the receipt times should reflect the actual
actual time as closely as possible. The initial value of the time as closely as possible. For a session, if the RTP
timestamp is random, and subsequent timestamps are offset from timestamp is chosen at random, the first receipt time value
this value. SHOULD also be chosen at random, and subsequent timestamps
offset from this value. On the other hand, if the RTP timestamp
is meant to reflect the reference time at the sender, then the
receipt time SHOULD be as close as possible to the reference
time at the receiver.
4.4 Statistics Summary Report Block 4.4 Receiver Reference Time Report Block
This block extends RTCP's timestamp reporting so that non-senders may
also send timestamps. It recapitulates the NTP timestamp fields from
the RTCP Sender Report [10, Sec. 6.3.1]. A non-sender may estimate
its round trip time (RTT) to other participants, as proposed in [17],
by sending this report block and receiving DLRR Report Blocks (see
next section) in reply.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=4 | reserved | block length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
A Receiver Reference Time Report Block is identified by the
constant 4.
reserved: 8 bits
This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver.
block length: 16 bits
The constant 2, in accordance with the definition of this field
in Section 3.
NTP timestamp: 64 bits
Indicates the wallclock time when this block was sent so that it
may be used in combination with timestamps returned in DLRR
Report Blocks (see next section) from other receivers to measure
round-trip propagation to those receivers. Receivers should
expect that the measurement accuracy of the timestamp may be
limited to far less than the resolution of the NTP timestamp.
The measurement uncertainty of the timestamp is not 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
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 to use the sampling clock to estimate elapsed
wallclock time. A report sender that has no notion of wallclock
or elapsed time may set the NTP timestamp to zero.
4.5 DLRR Report Block
This block extends RTCP's delay since last Sender Report (DLSR)
mechanism [10, Sec. 6.3.1] so that non-senders may also calculate
round trip times, as proposed in [17]. It is termed DLRR for delay
since last Receiver Report, and may be sent in response to a Receiver
Timestamp Report Block (see previous section) from a receiver to
allow that receiver to calculate its round trip time to the
respondent. The report consists of one or more 3 word sub-blocks:
one sub-block per Receiver Report.
0 1 2 3
0 1 2 3 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=5 | reserved | block length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| last RR (LRR) | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last RR (DLRR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
block type (BT): 8 bits
A DLRR Report Block is identified by the constant 5.
reserved: 8 bits
This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver.
block length: 16 bits
Defined in Section 3.
last RR timestamp (LRR): 32 bits
The middle 32 bits out of 64 in the NTP timestamp (as explained
in the previous section) received as part of a Receiver
Reference Time Report Block from participant SSRC_n. If no such
block has been received, the field is set to zero.
delay since last RR (DLRR): 32 bits
The delay, expressed in units of 1/65536 seconds, between
receiving the last Receiver Reference Time Report Block from
participant SSRC_n and sending this DLRR Report Block. If no
Receiver Reference Time Report 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 receiver issuing this DLRR
Report Block. Participant SSRC_n can compute the round-trip
propagation delay to SSRC_r by recording the time A when this
Receiver Timestamp Report Block is received. It calculates the
total round-trip time A-LSR using the last SR timestamp (LSR)
field, and then subtracting this field to leave the round-trip
propagation delay as A-LSR-DLSR. This is illustrated in [10,
Fig. 2].
4.6 Statistics Summary Report Block
This block reports statistics beyond the information carried in the This block reports statistics beyond the information carried in the
standard RTCP packet format, but not as fine grained as that carried standard RTCP packet format, but not as fine grained as that carried
in the report blocks previously described. Information is recorded in the report blocks previously described. Information is recorded
about lost packets, duplicate packets, jitter measurements, and TTL about lost packets, duplicate packets, jitter measurements, and TTL
values (TTL values being taken from the TTL field of IPv4 packets, if or Hop Limit values. Such information can be useful for network
the data packets are carried over IPv4). Such information can be management.
useful for network management.
The report block contents are dependent upon a bit vector carried in The report block contents are dependent upon a series of flags bit
the first part of the header. Not all parameters need to be reported carried in the first part of the header. Not all parameters need to
in each block. Flags indicate which are and which are not reported. be reported in each block. Flags indicate which are and which are
The fields corresponding to unreported parameters MUST be set to not reported. The fields corresponding to unreported parameters MUST
zero. The receiver MUST ignore any Statistics Summary Report Block be set to zero. The receiver MUST ignore any Statistics Summary
with a non-zero value in any field flagged as unreported. Report Block with a non-zero value in any field flagged as
unreported.
The Statistics Summary Report Block has the following format: The Statistics Summary Report Block has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=4 |L|D|J|T| rsvd. | block length = 9 | | BT=6 |L|D|J|ToH|rsvd.| block length = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lost_packets | | lost_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dup_packets | | dup_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_jitter | | min_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max_jitter | | max_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| avg_jitter | | avg_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dev_jitter | | dev_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_ttl | max_ttl | avg_ttl | dev_ttl | | min_ttl_or_hl | max_ttl_or_hl | avg_ttl_or_hl | dev_ttl_or_hl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Statistics Summary Report Block is identified by the constant A Statistics Summary Report Block is identified by the constant
4. 6.
loss report flag (L): 1 bit loss report flag (L): 1 bit
Bit set to 1 if the lost_packets field contains a report, 0 Bit set to 1 if the lost_packets field contains a report, 0
otherwise. otherwise.
duplicate report flag (D): 1 bit duplicate report flag (D): 1 bit
Bit set to 1 if the dup_packets field contains a report, 0 Bit set to 1 if the dup_packets field contains a report, 0
otherwise. otherwise.
jitter flag (J): 1 bit jitter flag (J): 1 bit
Bit set to 1 if the min_jitter, max_jitter, avg_jitter, and Bit set to 1 if the min_jitter, max_jitter, avg_jitter, and
dev_jitter fields all contain reports, 0 if none of them do. dev_jitter fields all contain reports, 0 if none of them do.
TTL flag (T): 1 bit TTL or Hop Limit flag (ToH): 2 bits
Bit set to 1 if the min_ttl, max_ttl, avg_ttl, and dev_ttl This field is set to 0 if none of the fields min_ttl_or_hl,
fields all contain reports, 0 if none of them do. max_ttl_or_hl, avg_ttl_or_hl, or dev_ttl_or_hl contain reports.
If the field is non-zero then all of these fields contain
reports. The value 1 signifies that they report on IPv4 TTL
values. The value 2 signifies that they report on IPv6 Hop
Limit values. This value 3 is undefined and MUST NOT be used.
rsvd.: 4 bits rsvd.: 3 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver. MUST be ignored by the receiver.
block length: 16 bits block length: 16 bits
The constant 9, in accordance with the definition of this field The constant 9, in accordance with the definition of this field
in Section 3. in Section 3.
SSRC of source: 32 bits
As defined in Section 4.1.
begin_seq: 16 bits begin_seq: 16 bits
As defined in Section 4.1. As defined in Section 4.1.
end_seq: 16 bits end_seq: 16 bits
As defined in Section 4.1. As defined in Section 4.1.
lost_packets: 32 bits lost_packets: 32 bits
Number of lost packets in the above sequence number interval. Number of lost packets in the above sequence number interval.
dup_packets: 32 bits dup_packets: 32 bits
skipping to change at page 18, line 42 skipping to change at page 24, line 49
above sequence number interval. above sequence number interval.
avg_jitter: 32 bits avg_jitter: 32 bits
The average relative transit time between each two packet series The average relative transit time between each two packet series
in the above sequence number interval. in the above sequence number interval.
dev_jitter: 32 bits dev_jitter: 32 bits
The standard deviation of the relative transit time between each The standard deviation of the relative transit time between each
two packet series in the above sequence number interval. two packet series in the above sequence number interval.
min_ttl: 8 bits min_ttl_or_hl: 8 bits
The minimum TTL value of data packets in sequence number range. The minimum TTL or Hop Limit value of data packets in the
sequence number range.
max_ttl: 8 bits
The maximum TTL value of data packets in sequence number range.
avg_ttl: 8 bits
The average TTL value of data packets in sequence number range.
dev_ttl: 8 bits
The standard deviation of TTL values of data packets in sequence
number range.
4.5 Receiver Timestamp Report Block
This block extends RTCP's timestamp reporting so that non-senders may
also send timestamps. It recapitulates the NTP timestamp fields from
the RTCP Sender Report [7, Sec. 6.3.1]. A non-sender may estimate
its RTT to other participants, as proposed in [11], by sending this
report block and receiving DLRR Report Blocks (see next section) in
reply.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=5 | reserved | block length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
A Receiver Timestamp Report Block is identified by the constant
5.
reserved: 8 bits
This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver.
block length: 16 bits
The constant 2, in accordance with the definition of this field
in Section 3.
NTP timestamp: 64 bits
Indicates the wallclock time when this block was sent so that it
may be used in combination with timestamps returned in DLRR
Report Blocks (see next section) from other receivers to measure
round-trip propagation to those receivers. Receivers should
expect that the measurement accuracy of the timestamp may be
limited to far less than the resolution of the NTP timestamp.
The measurement uncertainty of the timestamp is not 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
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 to use the sampling clock to estimate elapsed
wallclock time. A report sender that has no notion of wallclock
or elapsed time may set the NTP timestamp to zero.
4.6 DLRR Report Block
This block extends RTCP's delay since last sender report (DLSR)
mechanism [7, Sec. 6.3.1] so that non-senders may also calculate
round trip times, as proposed in [11]. It is termed DLRR for delay
since last receiver report, and may be sent in response to a Receiver
Timestamp Report Block (see previous section) from a receiver to
allow that receiver to calculate its round trip time to the
respondent. The report consists of one or more 3 word sub-blocks:
one sub-block per receiver report.
0 1 2 3
0 1 2 3 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=6 | reserved | block length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| last RR (LRR) | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last RR (DLRR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
block type (BT): 8 bits
A DLRR Report Block is identified by the constant 6.
reserved: 8 bits
This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver.
block length: 16 bits max_ttl_or_hl: 8 bits
Defined in Section 3. The maximum TTL or Hop Limit value of data packets in the
sequence number range.
last RR timestamp (LRR): 32 bits avg_ttl_or_hl: 8 bits
The middle 32 bits out of 64 in the NTP timestamp (as explained The average TTL or Hop Limit value of data packets in the
in the previous section) received as part of a Receiver sequence number range.
Timestamp Report Block from participant SSRC_n. If no such block
has been received, the field is set to zero.
delay since last RR (DLRR): 32 bits dev_ttl_or_hl: 8 bits
The delay, expressed in units of 1/65536 seconds, between The standard deviation of TTL or Hop Limit values of data
receiving the last Receiver Timestamp Report Block from packets in the sequence number range.
participant SSRC_n and sending this DLRR Report Block. If no
Receiver Timestamp Report 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 receiver issuing this DLRR
Report Block. Participant SSRC_n can compute the round-trip
propagation delay to SSRC_r by recording the time A when this
Receiver Timestamp Report Block is received. It calculates the
total round-trip time A-LSR using the last SR timestamp (LSR)
field, and then subtracting this field to leave the round-trip
propagation delay as A-LSR-DLSR. This is illustrated in [7, Fig.
2].
4.7 VoIP Metrics Report Block 4.7 VoIP Metrics Report Block
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 [10]. desirable to consider the degree of burstiness of packet loss [14].
Following a Gilbert-Elliott model [2], a period of time, bounded by Following a Gilbert-Elliott model [3], a period of time, bounded by
lost and/or discarded packets, with a high rate of losses and/or lost and/or discarded packets, with a high rate of losses and/or
discards is a "burst," and a period of time between two bursts is a discards is a "burst," and a period of time between two bursts is a
"gap." Bursts correspond to periods of time during which the packet "gap." Bursts correspond to periods of time during which the packet
loss rate is high enough to produce noticeable degradation in audio loss rate is high enough to produce noticeable degradation in audio
quality. Gaps correspond to periods of time during which only quality. Gaps correspond to periods of time during which only
isolated lost packets may occur, and in general these can be masked isolated lost packets may occur, and in general these can be masked
by packet loss concealment. Delay reports include the transit delay by packet loss concealment. Delay reports include the transit delay
between RTCP end points and the VoIP end system processing delays, between RTCP end points and the VoIP end system processing delays,
both of which contribute to the user perceived delay. Additional both of which contribute to the user perceived delay. Additional
metrics include signal, echo, noise, and distortion levels. Call metrics include signal, echo, noise, and distortion levels. Call
quality metrics include R factors (as described by the E Model quality metrics include R factors (as described by the E Model
defined in [2]) and mean opinion scores (MOS scores). defined in [3]) and mean opinion scores (MOS scores).
An implementation that sends these blocks SHOULD send at least one Implementations MUST provide values for all the fields defined here.
every ten seconds for the duration of the call, SHOULD send one For certain metrics, if the value is undefined or unknown, then the
whenever a codec type change or other significant change occurs, specified default or unknown field value MUST be provided.
SHOULD send one when significant call quality degradation is detected
and SHOULD send one upon call termination. Implementations MUST
provide values for all the fields defined here. For certain metrics,
if the value is undefined or unknown, then the specified default or
unknown field value MUST be provided.
The block is encoded as seven 32-bit words: The block is encoded as seven 32-bit words:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=7 | reserved | block length = 6 | | BT=7 | reserved | block length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| loss rate | discard rate | burst density | gap density | | loss rate | discard rate | burst density | gap density |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burst duration | gap duration | | burst duration | gap duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| round trip delay | end system delay | | round trip delay | end system delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signal level | noise level | RERL | Gmin | | signal level | noise level | RERL | 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 | reserved | JB nominal |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JB maximum | JB abs max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A VoIP Metrics Report Block is identified by the constant 7. A VoIP Metrics Report Block is identified by the constant 7.
reserved: 8 bits reserved: 8 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver. MUST be ignored by the receiver.
block length: 16 bits block length: 16 bits
The constant 6, in accordance with the definition of this field The constant 8, in accordance with the definition of this field
in Section 3. in Section 3.
SSRC of source: 32 bits
As defined in Section 4.1.
The remaining fields are described in the following six sections: The remaining fields are described in the following six sections:
Packet Loss and Discard Metrics, Delay Metrics, Signal Related Packet Loss and Discard Metrics, Delay Metrics, Signal Related
Metrics, Call Quality or Transmission Quality Metrics, Configuration Metrics, Call Quality or Transmission Quality Metrics, Configuration
Metrics, and Jitter Buffer Parameters. Metrics, and Jitter Buffer Parameters.
4.7.1 Packet Loss and Discard Metrics 4.7.1 Packet Loss and Discard Metrics
It is very useful to distinguish between packets lost by the network It is very useful to distinguish between packets lost by the network
and those discarded due to jitter. Both have equal effect on the and those discarded due to jitter. Both have equal effect on the
quality of the voice stream however having separate counts helps quality of the voice stream however having separate counts helps
skipping to change at page 26, line 15 skipping to change at page 30, line 15
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 example, the time delay due to RTP payload multiplexing would be
considered to be part of the voice application or end-system delay considered to be part of the voice application or end-system delay
whereas delay due to multiplexing RTP frames within a UDP frame would whereas delay due to multiplexing RTP frames within a UDP frame would
be considered part of the RTP reported delay. This distinction is be considered part of the RTP reported delay. This distinction is
consistent with the use of RTCP for delay measurements. consistent with the use of RTCP for delay measurements.
round trip delay: 16 bits round trip delay: 16 bits
The most recently calculated round trip time between RTP The most recently calculated round trip time between RTP
interfaces, expressed in milliseconds. This value is the time of interfaces, expressed in milliseconds. This value MAY be
receipt of the most recent RTCP packet from source SSRC, minus measured using RTCP, the DLRR method defined in Section 4.5 of
the LSR (last SR) time reported in its SR (sender report), minus this document or other approaches. If RTCP is used then the
the DLSR (delay since last SR) reported in its SR. A non-zero reported delay value is the time of receipt of the most recent
LSR value is REQUIRED in order to calculate round trip delay. A RTCP packet from source SSRC, minus the LSR (last SR) time
value of 0 is permissible during the first two or three RTCP reported in its SR (Sender Report), minus the DLSR (delay since
exchanges as insufficient data may be available to determine last SR) reported in its SR. A non-zero LSR value is required
delay however MUST be populated as soon as a delay estimate is in order to calculate round trip delay. A value of 0 is
available. permissible, however this field MUST be populated as soon as a
delay estimate is available.
end system delay: 16 bits end system delay: 16 bits
The most recently estimated end system delay, expressed in The most recently estimated end system delay, expressed in
milliseconds. End system delay is defined as the total milliseconds. End system delay is defined as the total
encoding, decoding and jitter buffer delay determined at the encoding, decoding and jitter buffer delay determined at the
reporting endpoint. This is the time required for an RTP frame reporting endpoint. This is the time required for an RTP frame
to be buffered, decoded, converted to analog form, looped back to be buffered, decoded, converted to analog form, looped back
at the local analog interface, encoded, and made available for at the local analog interface, encoded, and made available for
transmission as an RTP frame. The manner in which this value is transmission as an RTP frame. The manner in which this value is
estimated is implementation dependent. This parameter MUST be estimated is implementation dependent. This parameter MUST be
skipping to change at page 27, line 16 skipping to change at page 31, line 17
signal level: 8 bits signal level: 8 bits
The voice signal relative level is defined as the ratio of the The voice signal relative level is defined as the ratio of the
signal level to a reference digital milliwatt, expressed in signal level to a reference digital milliwatt, expressed in
decibels as a signed integer in two's complement form. This is decibels as a signed integer in two's complement form. This is
measured only for packets containing speech energy. The intent measured only for packets containing speech energy. The intent
of this metric is not to provide a precise measurement of the of this metric is not to provide a precise measurement of the
signal level but to provide a real time indication that the signal level but to provide a real time indication that the
signal level may be excessively high or low. signal level may be excessively high or low.
signal level = 10 log 10 ( rms talkspurt power (mW) ) signal level = 10 Log10 ( rms talkspurt power (mW) )
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
Typical values should be generally in the -15 to -20 dBm range. Typical values should be generally in the -15 to -20 dBm range.
noise level: 8 bits noise level: 8 bits
The noise level is defined as the ratio of the silent period The noise level is defined as the ratio of the silent period
background noise level to a reference digital milliwatt, background noise level to a reference digital milliwatt,
expressed in decibels as a signed integer in two's complement expressed in decibels as a signed integer in two's complement
form. form.
noise level = 10 log10 ( rms silence power (mW) ) noise level = 10 Log10 ( rms silence power (mW) )
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
residual echo return loss (RERL): 8 bits residual echo return loss (RERL): 8 bits
The residual echo return loss is defined as the sum of the The residual echo return loss is defined as the sum of the
measured echo return loss (ERL) and the echo return loss measured echo return loss (ERL) and the echo return loss
enhancement (ERLE) expressed in dB as a signed integer in two's enhancement (ERLE) expressed in dB as a signed integer in two's
complement form. It defines the ratio of a transmitted voice complement form. It defines the ratio of a transmitted voice
signal that is reflected back to the talker. A low level of signal that is reflected back to the talker. A low level of
echo return loss (say less than 20 dB) in conjunction with some echo return loss (say less than 20 dB) in conjunction with some
skipping to change at page 29, line 19 skipping to change at page 33, line 19
packet loss, discard, burstiness, delay etc. These metrics may not packet loss, discard, burstiness, delay etc. These metrics may not
be available in all systems however SHOULD be provided in order to be available in all systems however SHOULD be provided in order to
support problem diagnosis. support problem diagnosis.
R factor: 8 bits R factor: 8 bits
The R factor is a voice quality metric describing the segment of The R factor is a voice quality metric describing the segment of
the call that is carried over this RTP session. It is expressed the 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 as an integer in the range 0 to 100, with a value of 94
corresponding to "toll quality" and values of 50 or less corresponding to "toll quality" and values of 50 or less
regarded as unusable. This metric is defined as including the regarded as unusable. This metric is defined as including the
effects of delay, consistent with ITU-T G.107 [4] and ETSI TS effects of delay, consistent with ITU-T G.107 [6] and ETSI TS
101 329-5 [2]. 101 329-5 [3].
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
ext. R factor: 8 bits ext. R factor: 8 bits
The external R factor is a voice quality metric describing the The external R factor is a voice quality metric describing the
segment of the call that is carried over a network segment segment of the call that is carried over a network segment
external to the RTP segment, for example a cellular network. Its external to the RTP segment, for example a cellular network. Its
values are interpreted in the same manner as for the RTP R values are interpreted in the same manner as for the RTP R
factor. This metric is defined as including the effects of factor. This metric is defined as including the effects of
delay, consistent with ITU-T G.107 [4] and ETSI TS 101 329-5 delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5
[2], and relates to the outward voice path from the Voice over [3], and relates to the outward voice path from the Voice over
IP termination for which this metrics block applies. IP termination for which this metrics block applies.
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
Note that an overall R factor may be estimated from the RTP segment R Note that an overall R factor may be estimated from the RTP segment R
factor and the external R factor, as follows: factor and the external R factor, as follows:
R total = RTP R factor + ext. R factor - 94 R total = RTP R factor + ext. R factor - 94
MOS-LQ: 8 bits MOS-LQ: 8 bits
skipping to change at page 30, line 10 skipping to change at page 34, line 10
corresponding to MOS x 10. For example, a value of 35 would corresponding to MOS x 10. For example, a value of 35 would
correspond to an estimated MOS score of 3.5. 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 The estimated mean opinion score for conversational quality
(MOS-CQ) is defined as including the effects of delay and other (MOS-CQ) is defined as including the effects of delay and other
effects that would affect conversational quality. The metric effects that would affect conversational quality. The metric
may be calculated by converting an R factor determined according may be calculated by converting an R factor determined according
to ITU-T G.107 [4] or ETSI TS 101 329-5 [2] into an estimated to ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an estimated
MOS using the equation specified in G.107. It is expressed as MOS using the equation specified in G.107. It is expressed as
an integer in the range 10 to 50, corresponding to MOS x 10, as an integer in the range 10 to 50, corresponding to MOS x 10, as
for MOS-LQ. for MOS-LQ.
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
4.7.6 Configuration Parameters 4.7.6 Configuration Parameters
Gmin: 8 bits Gmin: 8 bits
The gap threshold. This field contains the value used for this The gap threshold. This field contains the value used for this
report block to determine if a gap exists. The recommended report block to determine if a gap exists. The recommended
value of 16 corresponds to a burst period having a minimum value of 16 corresponds to a burst period having a minimum
density of 6.25% of lost or discarded packets, which may cause density of 6.25% of lost or discarded packets, which may cause
noticeable degradation in call quality; during gap periods, if noticeable degradation in call quality; during gap periods, if
packet loss or discard occurs, each lost or discarded packet packet loss or discard occurs, each lost or discarded packet
would be preceded by and followed by a sequence of at least 16 would be preceded by and followed by a sequence of at least 16
received non-discarded packets. Note that lost or discarded received non-discarded packets. Note that lost or discarded
packets that occur within Gmin packets of a report being packets that occur within Gmin packets of a report being
generated may be reclassified as being part of a burst or gap in generated may be reclassified as being part of a burst or gap in
later reports. ETSI TS 101 329-5 [2] defines a computationally later reports. ETSI TS 101 329-5 [3] defines a computationally
efficient algorithm for measuring burst and gap density using a efficient algorithm for measuring burst and gap density using a
packet loss/discard event driven approach. This algorithm is packet loss/discard event driven approach. This algorithm is
reproduced in Appendix A.2 of the present document. Gmin MUST reproduced in Appendix A.2 of the present document. Gmin MUST
not be zero and MUST be provided. not be zero and MUST be provided.
receiver configuration byte (RX config): 8 bits receiver configuration byte (RX config): 8 bits
This byte consists of the following fields: This byte consists of the following fields:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 31, line 33 skipping to change at page 35, line 33
approximate time taken to fully adjust to a step change in approximate time taken to fully adjust to a step change in
peak to peak jitter from 30 ms to 100 ms such that: peak to peak jitter from 30 ms to 100 ms such that:
adjustment time = 2 * J * frame size (ms) adjustment time = 2 * J * frame size (ms)
This parameter is intended only to provide a guide to the This parameter is intended only to provide a guide to the
degree of "aggressiveness" of a an adaptive jitter buffer degree of "aggressiveness" of a an adaptive jitter buffer
and may be estimated. A value of 0 indicates that the and may be estimated. A value of 0 indicates that the
adjustment time is unknown for this implementation. adjustment time is unknown for this implementation.
reserved: 8 bits
This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver.
4.7.7 Jitter Buffer Parameters 4.7.7 Jitter Buffer Parameters
jitter buffer nominal size in frames (JB nominal): 8 bits jitter buffer nominal delay (JB nominal): 16 bits
This is the current nominal fill point within the jitter buffer, This is the current nominal jitter buffer delay in milliseconds,
which corresponds to the nominal jitter buffer delay for packets which corresponds to the nominal jitter buffer delay for packets
that arrive exactly on time. This parameter MUST be provided that arrive exactly on time. This parameter MUST be provided
for both fixed and adaptive jitter buffer implementations. for both fixed and adaptive jitter buffer implementations.
jitter buffer maximum size in frames (JB maximum): 8 bits jitter buffer maximum delay (JB maximum): 16 bits
This is the current maximum jitter buffer level corresponding to This is the current maximum jitter buffer delay corresponding to
the earliest arriving packet that would not be discarded. In the earliest arriving packet that would not be discarded. In
simple queue implementations this may correspond to the nominal simple queue implementations this may correspond to the nominal
size. In adaptive jitter buffer implementations this value may size. In adaptive jitter buffer implementations this value may
dynamically vary up to JB abs max (see below). This parameter dynamically vary up to JB abs max (see below). This parameter
MUST be provided for both fixed and adaptive jitter buffer MUST be provided for both fixed and adaptive jitter buffer
implementations. implementations.
jitter buffer absolute maximum size in frames (JB abs max): 8 bits jitter buffer absolute maximum delay (JB abs max): 16 bits
This is the absolute maximum size that the adaptive jitter This is the absolute maximum delay that the adaptive jitter
buffer can reach under worst case jitter conditions. This buffer can reach under worst case jitter conditions. This
parameter MUST be provided for adaptive jitter buffer parameter MUST be provided for adaptive jitter buffer
implementations and its value MUST be set to JB maximum for implementations and its value MUST be set to JB maximum for
fixed jitter buffer implementations. fixed jitter buffer implementations.
5. IANA Considerations 5. SDP Signaling
This document defines a new RTP packet type, the extended report (XR) This section defines Session Description Protocol (SDP) [4] signaling
type, within the existing Internet Assigned Numbers Authority (IANA) for XR blocks that can be employed by applications that utilize SDP.
registry of RTP RTCP Control Packet Types. This document also This signaling is defined to be used either by applications that
defines a new IANA registry: the registry of RTP XR Block Types. implement the SDP Offer/Answer model [9] or by applications that use
SDP to describe media and transport configurations in connection with
such protocols as the Session Announcement Protocol (SAP) [15] or the
Real Time Streaming Protocol (RTSP) [16]. There exist other
potential signaling methods, which are not defined here.
The XR blocks MAY be used without prior signaling. This is
consistent with the rules governing other RTCP packet types, as
described in [10]. An example in which signaling would not be used
is an application that always requires the use of one or more XR
blocks. However for applications that are configured at session
initiation, the use of some type of signaling is recommended.
Note that, although the use of SDP signaling for XR blocks may be
optional, if used it MUST be used as defined here. If SDP signaling
is used in an environment where XR blocks are only implemented by
some fraction of the participants, the ones not implementing the XR
blocks will ignore the SDP attribute.
5.1 The SDP Attribute
This section defines one new SDP attribute "rtcp-xr" that can be used
to signal participants in a media session that they should use the
specified XR blocks. This attribute can be easily extended in the
future with new parameters to cover any new report blocks.
The RTCP XR blocks SDP attribute is defined below in Augmented
Backus-Naur Form (ABNF) [2]. It is both a session and a media level
attribute. When specified at session level, it applies to all media
level blocks in the session. Any media level specification MUST
replace a session level specification, if one is present, for that
media block.
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
xr-format = pkt-loss-rle
/ pkt-dup-rle
/ pkt-rcpt-times
/ rcvr-rtt
/ stat-summary
/ voip-metrics
/ format-ext
pkt-loss-rle = "pkt-loss-rle" ["=" max-size]
pkt-dup-rle = "pkt-dup-rle" ["=" max-size]
pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size]
rcvr-rtt = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size]
stat-summary = "stat-summary"
voip-metrics = "voip-metrics"
max-size = 1*DIGIT ; maximum block size in octets
rcvr-rtt-mode = "all"
/ "sender"
format-ext = non-ws-string
non-ws-string = 1*(%x21-FF)
The "rtcp-xr" attribute contains zero, one, or more XR block related
parameters. Each parameter signals functionality for an XR block, or
a group of XR blocks. The attribute is extensible so that parameters
can be defined for any future XR block (and a parameter should be
defined for every future block).
Each "rtcp-xr" parameter belongs to one of two categories. The first
category, the unilateral parameters, are for report blocks that
simply report on the RTP stream and related metrics. The second
category, collaborative parameters, are for XR blocks that involve
actions by more than one party in order to carry out their functions.
Round trip time (RTT) measurement is an example of collaborative
functionality. An RTP data packet receiver sends a Receiver
Reference Time Report Block (Section 4.4). A participant that
receives this block sends a DLRR Report Block (Section 4.5) in
response, allowing the receiver to calculate its RTT to that
participant. As this example illustrates, collaborative
functionality may be implemented by two or more different XR blocks.
The collaborative functionality of several XR blocks may be governed
by a single "rtcp-xr" parameter.
For the unilateral category, this document defines the following
parameters. The parameter names and their corresponding XR formats
are as follows:
Parameter name XR block (block type and name)
-------------- ------------------------------------
pkt-loss-rle 1 Loss RLE Report Block
pkt-dup-rle 2 Duplicate RLE Report Block
pkt-rcpt-times 3 Packet Receipt Times Report Block
stat-summary 6 Statistics Summary Report Block
voip-metrics 7 VoIP Metrics Report Block
The "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters
MAY specify an integer value. This value indicates the largest size
the whole report block SHOULD have in octets. This shall be seen as
an indication that thinning shall be applied if necessary to meet the
target size.
Blocks in the collaborative category are classified as initiator
blocks or response blocks. Signaling SHOULD indicate which
participants are required to respond to the initiator block. A party
that wishes to receive response blocks from those participants can
trigger this by sending an initiator block.
The collaborative category currently consists only of one
functionality, namely the RTT measurement mechanism for RTP data
receivers. The collective functionality of the Receiver Reference
Time Report Block and DLRR Report Block is represented by the "rcvr-
rtt" parameter. This parameter takes as its arguments a mode value
and, optionally, a maximum size for the DLRR report block. The mode
value "all" indicates that both RTP data senders and data receivers
MAY send DLRR blocks, while the mode value "sender" indicates that
only active RTP senders MAY send DLRR blocks, i.e. non RTP senders
SHALL NOT send DLRR blocks. If a maximum size in octets is included,
any DLRR Report Blocks that are sent SHALL NOT exceed the specified
size. If size limitations mean that a DLRR Report Block sender
cannot report in one block upon all participants from which it has
received a Receiver Reference Time Report Block then it SHOULD report
on participants in a round robin fashion across several report
intervals.
The "rtcp-xr" attributes parameter list MAY be empty. This is useful
in cases in which an application needs to signal that it understands
the SDP signaling but does not wish to avail itself of XR
functionality. For example, an application in a SIP controlled
session could signal that it wishes to stop using all XR blocks by
removing all applicable SDP parameters in a re-INVITE message that it
sends. If XR blocks are not to be used at all from the beginning of
a session, it is RECOMMENDED that the "rtcp-xr" attribute not be
supplied at all.
When the "rtcp-xr" attribute is present, participants SHOULD NOT send
XR blocks other than the ones indicated by the parameters. This
means that inclusion of a "rtcp-xr" attribute without any parameters
tells a participant that it SHOULD NOT send any XR blocks at all.
The purpose is to conserve bandwidth. This is especially important
when collaborative parameters are applied to a large multicast group:
the sending of an initiator block could potentially trigger responses
from all participants. There are, however, contexts in which it
makes sense to send an XR block in the absence of a parameter
signaling its use. For instance, an application might be designed so
as to send certain report blocks without negotiation, while using SDP
signaling to negotiate the use of other blocks.
5.2 Usage in Offer/Answer
In the Offer/Answer context [9], the interpretation of SDP signaling
for XR packets depends upon the direction attribute that is signaled:
"recvonly", "sendrecv", or "sendonly" [4]. If no direction attribute
is supplied then "sendrecv" is assumed. This section applies only to
unicast media streams, except where noted. Discussion of unilateral
parameters is followed by discussion of collaborative parameters in
this section.
For "sendonly" and "sendrecv" media stream offers that specify
unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send
the corresponding XR blocks. For "sendrecv" offers, the answerer MAY
include the "rtcp-xr" attribute in its response, and specify any
unilateral parameters in order to request that the offerer send the
corresponding XR blocks. The offerer SHOULD send these blocks.
For "recvonly" media stream offers, the offerer's use of the "rtcp-
xr" attribute in connection with unilateral parameters indicates that
the offerer is capable of sending the corresponding XR blocks. If
the answerer responds with an "rtcp-xr" attribute, the offerer SHOULD
send XR blocks for each specified unilateral parameter that was in
its offer.
For multicast media streams, the inclusion of an "rtcp-xr" attribute
with unilateral parameters means that every media recipient SHOULD
send the corresponding XR blocks.
An SDP offer with a collaborative parameter declares the offerer
capable of receiving the corresponding initiator and replying with
the appropriate responses. For example, an offer that specifies the
"rcvr-rtt" parameter means that the offerer is prepared to receive
Receiver Reference Time Report Blocks and to send DLRR Report Blocks.
An offer of a collaborative parameter means that the answerer MAY
send the initiator, and, having received the initiator, the offerer
SHOULD send the responses.
There are exceptions to the rule that an offerer of a collaborative
parameter should send responses. For instance, the collaborative
parameter might specify a mode that excludes the offerer. Or
congestion control or maximum transmission unit considerations might
militate against the offerer's response.
By including a collaborative parameter in its answer, the answerer
declares its ability to receive initiators and to send responses.
The offerer MAY then send initiators, to which the answerer SHOULD
reply with responses. As for the offer of a collaborative parameter,
there are exceptions to the rule that the answerer should reply.
When making an SDP offer of a collaborative parameter for a multicast
media stream, the offerer SHOULD specify which participants are to
respond to a received initiator. A participant that is not specified
SHOULD NOT send responses. Otherwise, undue bandwidth might be
consumed. The offer indicates that each participant that is
specified SHOULD respond if it receives an initiator. It also
indicates that a specified participant MAY send an initiator block.
An SDP answer for a multicast media stream SHOULD include all
collaborative parameters that are present in the offer and that are
supported by the answerer. It SHOULD NOT include any collaborative
parameter that is absent from the offer.
If a participant receives an SDP offer and understands the "rtcp-xr"
attribute but does not wish to implement XR functionality offered,
its answer SHOULD include an "rtcp-xr" attribute without parameters.
By doing so, the party declares that at a minimum that it is capable
of understanding the signaling.
5.3 Usage Outside of Offer/Answer
SDP can be employed outside of the Offer/Answer context, for instance
for multimedia sessions that are announced through the Session
Announcement Protocol (SAP) [15], or streamed through the Real Time
Streaming Protocol (RTSP) [16]. The signaling model is simpler, as
the sender does not negotiate parameters, but the functionality that
is expected from specifying the "rtcp-xr" attribute is the same as in
Offer/Answer.
When a unilateral parameter is specified for the "rtcp-xr" attribute
associated with a media stream, the receiver of that stream SHOULD
send the corresponding XR block. When a collaborative parameter is
specified, only the participants indicated by the mode value in the
collaborative parameter are concerned. Each such participant that
receives an initiator block SHOULD send the corresponding response
block. Each such participant MAY also send initiator blocks.
6. IANA Considerations
This document defines a new RTCP packet type, the Extended Report
(XR) type, within the existing Internet Assigned Numbers Authority
(IANA) registry of RTP RTCP Control Packet Types. This document also
defines a new IANA registry: the registry of RTCP XR Block Types.
Within this new registry, this document defines an initial set of Within this new registry, this document defines an initial set of
seven block types and describes how the remaining types are to be seven block types and describes how the remaining types are to be
allocated. allocated.
5.1 XR Packet Type Further, this document defines a new SDP attribute, "rtcp-xr", within
the existing IANA registry of SDP Parameters. It defines a new IANA
registry, the registry of RTCP XR SDP Parameters, and an initial set
of six parameters, and describes how additional parameters are to be
allocated.
The IANA SHALL register the RTP extended report (XR) packet defined 6.1 XR Packet Type
by this document as packet type 207 in the registry of RTP RTCP
Control Packet types (PT).
5.2 RTP XR Block Type Registry The XR packet type defined by this document is registered with the
IANA as packet type 207 in the registry of RTP RTCP Control Packet
types (PT).
The IANA SHALL create the RTP XR Block Type Registry to cover the 6.2 RTCP XR Block Type Registry
name space of the extended report block type (BT) field specified in
Section 3 of this document. The BT field contains eight bits, This document creates an IANA registry called the RTCP XR Block Type
allowing 256 values. The IANA SHALL manage the RTP XR Block Type Registry to cover the name space of the Extended Report block type
Registry according to the Specification Required policy of RFC 2434 (BT) field specified in Section 3. The BT field contains eight bits,
[6]. Future specifications SHOULD attribute block type values in allowing 256 values. The RTCP XR Block Type Registry is to be
strict numeric order following the values attributed in this managed by the IANA according to the Specification Required policy of
document: RFC 2434 [8]. Future specifications SHOULD attribute block type
values in strict numeric order following the values attributed in
this document:
BT name BT name
-- ---- -- ----
1 Loss RLE Report Block 1 Loss RLE Report Block
2 Duplicate RLE Report Block 2 Duplicate RLE Report Block
3 Timestamp Report Block 3 Packet Receipt Times Report Block
4 Statistics Summary Report Block 4 Receiver Reference Time Report Block
5 Receiver Timestamp Report Block 5 DLRR Report Block
6 DLRR Report Block 6 Statistics Summary Report Block
7 VoIP Metrics Report Block 7 VoIP Metrics Report Block
Furthermore, future specifications SHOULD avoid the values 0 and 255. The BT value 255 is reserved for future extensions.
Doing so facilitates packet validity checking, since all-zeros and
all-ones are values that might commonly be found in ill-formed
packets.
6. Security Considerations Furthermore, future specifications SHOULD avoid the value 0. Doing
so facilitates packet validity checking, since an all-zeros field
might commonly be found in an ill-formed packet.
6.3 The "rtcp-xr" SDP Attribute
This SDP attribute "rtcp-xr" defined by this document is registered
with the IANA registry of SDP Parameters as follows:
SDP Attribute ("att-field"):
Attribute name: rtcp-xr
Long form: RTP Control Protocol Extended Report Parameters
Type of name: att-field
Type of attribute: session and media level
Subject to charset: no
Purpose: see Section 5 of this document
Reference: this document
Values: see this document and registrations below
The attribute has an extensible parameter field and therefore a
registry for these parameters is required. This document creates an
IANA registry called the RTCP XR SDP Parameters Registry. It
contains the six parameters defined in Section 5.1: "pkt-loss-rle",
"pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and
"recv-rtt".
Additional parameters are to be added to this registry in accordance
with the Specification Required policy of RFC 2434 [8]. Any
registration MUST contain the following information:
- Contact information of the one doing the registration, including at
least name, address, and email.
- An Augmented Backus-Naur Form (ABNF) [2] definition of the
parameter, in accordance with the "format-ext" definition.
- A description of what the parameter represents and how it shall be
interpreted, both normally and in Offer/Answer.
7. Security Considerations
This document extends the RTCP reporting mechanism. The security This document extends the RTCP reporting mechanism. The security
considerations that apply to RTCP reports also apply to XR reports. considerations that apply to RTCP reports also apply to XR reports.
This section details the additional security considerations that This section details the additional security considerations that
apply to the extensions. apply to the extensions.
The extensions introduce heightened confidentiality concerns. The extensions introduce heightened confidentiality concerns.
Standard RTCP reports contain a limited number of summary statistics. Standard RTCP reports contain a limited number of summary statistics.
The information contained in XR reports is both more detailed and The information contained in XR reports is both more detailed and
more extensive (covering a larger number of parameters). The per- more extensive (covering a larger number of parameters). The per-
packet information contained in Loss RLE, Duplicate RLE, and packet report blocks and the VoIP Metrics Report Block provide
Timestamp Report Blocks facilitates MINC inference of multicast examples.
distribution trees for RTP data packets, and inference of link
characteristics such as loss and delay. This inference reveals The per-packet information contained in Loss RLE, Duplicate RLE, and
information that might otherwise be considered confidential to Packet Receipt Times Report Blocks facilitates multicast inference of
autonomous system administrators. The VoIP Metrics Report Block network characteristics (MINC) [11]. Such inference can reveal the
provides information on the quality of ongoing voice calls. Though gross topology of a multicast distribution tree, as well as
such information might be carried in application specific format in parameters, such as the loss rates and delays, along paths between
standard RTP sessions, making it available in a standard format here branching points in that tree. Such information might be considered
makes it more available to potential eavesdroppers. sensitive 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 No new mechanisms are introduced in this document to ensure
confidentiality. Standard encryption procedures can be used when confidentiality. Encryption procedures, such as those being
confidentiality is a concern to end hosts. Autonomous system suggested for a Secure RTCP (SRTCP) [12] at the time that this
administrators concerned about the loss of confidentiality regarding document was written, can be used when confidentiality is a concern
their networks can encrypt traffic, or filter it to exclude RTCP to end hosts. Given that RTCP traffic can be encrypted by the end
packets containing the XR report blocks concerned. hosts, autonomous systems must be prepared for the fact that certain
aspects of their network topology can be revealed.
Any encryption or filtering of XR report blocks entails a loss of Any encryption or filtering of XR report blocks entails a loss of
monitoring information to third parties. For example, a network that monitoring information to third parties. For example, a network that
establishes a tunnel to encrypt VoIP Report Blocks denies that establishes a tunnel to encrypt VoIP Report Blocks denies that
information to the service providers traversed by the tunnel. The information to the service providers traversed by the tunnel. The
service providers cannot then monitor or respond to the quality of service providers cannot then monitor or respond to the quality of
the VoIP calls that they carry, potentially creating problems for the the VoIP calls that they carry, potentially creating problems for the
network's users. As a default, XR packets SHOULD NOT be encrypted or network's users. As a default, XR packets SHOULD NOT be encrypted or
filtered. filtered.
The extensions also make certain denial of service attacks easier. The extensions also make certain denial of service attacks easier.
This is because of the potential to create RTCP packets much larger This is because of the potential to create RTCP packets much larger
than average with the per packet reporting capabilities of the Loss than average with the per packet reporting capabilities of the Loss
RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the
automatic bandwidth adjustment mechanisms in RTCP, if some session automatic bandwidth adjustment mechanisms in RTCP, if some session
participants are sending large RTCP packets, all participants will participants are sending large RTCP packets, all participants will
see their RTCP reporting intervals lengthened, meaning they will be see their RTCP reporting intervals lengthened, meaning they will be
able to report less frequently. To limit the effects of large able to report less frequently. To limit the effects of large
packets, even in the absence of denial of service attacks, packets, even in the absence of denial of service attacks,
applications SHOULD limit the size of XR report blocks and employ the applications SHOULD place an upper limit on the size of the XR report
thinning techniques described in this document in order to fit blocks they employ. The "thinning" techniques described in Section
reports into the space available. 4.1 permit the packet-by-packet report blocks to adhere to a
predefined size limit.
A. Algorithms A. Algorithms
A.1 Sequence Number Interpretation A.1 Sequence Number Interpretation
This the algorithm suggested by Section 4.1 for keeping track of the This the algorithm suggested by Section 4.1 for keeping track of the
sequence numbers from a given sender. It implements the accounting sequence numbers from a given sender. It implements the accounting
practice required for the generation of Loss RLE Report Blocks. practice required for the generation of Loss RLE Report Blocks.
This algorithm keeps track of 16 bit sequence numbers by translating This algorithm keeps track of 16 bit sequence numbers by translating
skipping to change at page 35, line 38 skipping to change at page 45, line 51
// Return our best guess for a 32-bit sequence number that // Return our best guess for a 32-bit sequence number that
// corresponds to the 16-bit number we were given. // corresponds to the 16-bit number we were given.
return extended_seq; return extended_seq;
} }
A.2 Example Burst Packet Loss Calculation. A.2 Example Burst Packet Loss Calculation.
This is an algorithm for measuring the burst characteristics for the This is an algorithm for measuring the burst characteristics for the
VoIP Metrics Report Block (Section 4.7). It is reproduced from ETSI VoIP Metrics Report Block (Section 4.7). It is reproduced from ETSI
TS 101 329-5 [2]. The algorithm is event driven and hence extremely TS 101 329-5 [3]. The algorithm is event driven and hence extremely
computationally efficient. computationally efficient.
Given the following definition of states: Given the following definition of states:
state 1 = received a packet during a gap state 1 = received a packet during a gap
state 2 = received a packet during a burst state 2 = received a packet during a burst
state 3 = lost a packet during a burst state 3 = lost a packet during a burst
state 4 = lost an isolated packet during a gap state 4 = lost an isolated packet during a gap
The "c" variables below correspond to state transition counts, i.e. The "c" variables below correspond to state transition counts, i.e.
skipping to change at page 37, line 35 skipping to change at page 47, line 48
Intellectual Property 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 intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP 11 [3]. Copies standards-related documentation can be found in BCP 11 [5]. Copies
of claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made to of licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
skipping to change at page 38, line 33 skipping to change at page 48, line 45
"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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgments Acknowledgments
We thank the following people: Colin Perkins, Steve Casner, and We thank the following people: Colin Perkins, Steve Casner, and
Henning Schulzrinne for their considered guidance; Sue Moon for Henning Schulzrinne for their considered guidance; Sue Moon for
helping foster collaboration between the authors; Magnus Westerlund helping foster collaboration between the authors; Mounir Benzaid for
for his detailed comments; Mounir Benzaid for drawing our attention drawing our attention to the reporting needs of MLDA; Dorgham Sisalem
to the reporting needs of MLDA; and Dorgham Sisalem and Adam Wolisz and Adam Wolisz for encouraging us to incorporate MLDA block types;
for encouraging us to incorporate MLDA block types. and Jose Rey for valuable review of the SDP Signaling section.
Contributors Contributors
The following people are the authors of this document: The following people are the authors of this document:
Kevin Almeroth, UCSB Kevin Almeroth, UCSB
Ramon Caceres, ShieldIP Ramon Caceres, ShieldIP
Alan Clark, Telchemy Alan Clark, Telchemy
Robert Cole, AT&T Labs Robert Cole, AT&T Labs
Nick Duffield, AT&T Labs-Research Nick Duffield, AT&T Labs-Research
Timur Friedman, Paris 6 Timur Friedman, Paris 6
Kaynam Hedayat, Brix Networks Kaynam Hedayat, Brix Networks
Kamil Sarac, UT Dallas Kamil Sarac, UT Dallas
skipping to change at page 38, line 50 skipping to change at page 49, line 14
The following people are the authors of this document: The following people are the authors of this document:
Kevin Almeroth, UCSB Kevin Almeroth, UCSB
Ramon Caceres, ShieldIP Ramon Caceres, ShieldIP
Alan Clark, Telchemy Alan Clark, Telchemy
Robert Cole, AT&T Labs Robert Cole, AT&T Labs
Nick Duffield, AT&T Labs-Research Nick Duffield, AT&T Labs-Research
Timur Friedman, Paris 6 Timur Friedman, Paris 6
Kaynam Hedayat, Brix Networks Kaynam Hedayat, Brix Networks
Kamil Sarac, UT Dallas Kamil Sarac, UT Dallas
Magnus Westerlund, Ericsson
The principal people to contact regarding the individual report The principal people to contact regarding the individual report
blocks described in this document are as follows: blocks described in this document are as follows:
sec. report block principal contributors sec. report block principal contributors
---- ------------ ---------------------- ---- ------------ ----------------------
4.1 Loss RLE Report Block Friedman, Caceres, Duffield 4.1 Loss RLE Report Block Friedman, Caceres, Duffield
4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield 4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield
4.3 Timestamp Report Block Friedman, Caceres, Duffield 4.3 Packet Receipt Times Report Block Friedman, Caceres, Duffield
4.4 Statistics Summary Report Block Almeroth, Sarac 4.4 Receiver Reference Time Report Block Friedman
4.5 Receiver Timestamp Report Block Friedman 4.5 DLRR Report Block Friedman
4.6 DLRR Report Block Friedman 4.6 Statistics Summary Report Block Almeroth, Sarac
4.7 VoIP Metrics Report Block Clark, Cole, Hedayat 4.7 VoIP Metrics Report Block Clark, Cole, Hedayat
The principal person to contact regarding the SDP signaling described
in this document is Magnus Westerlund.
Authors' Addresses Authors' Addresses
Kevin Almeroth <almeroth@cs.ucsb.edu> Kevin Almeroth <almeroth@cs.ucsb.edu>
Department of Computer Science Department of Computer Science
University of California University of California
Santa Barbara, CA 93106 USA Santa Barbara, CA 93106 USA
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
skipping to change at page 40, line 26 skipping to change at page 51, line 4
Tel: +1 978 367 5600 Tel: +1 978 367 5600
Fax: +1 978 367 5700 Fax: +1 978 367 5700
Kamil Sarac <ksarac@utdallas.edu> Kamil Sarac <ksarac@utdallas.edu>
Department of Computer Science (ES 4.207) Department of Computer Science (ES 4.207)
Eric Jonsson School of Engineering & Computer Science Eric Jonsson School of Engineering & Computer Science
University of Texas at Dallas University of Texas at Dallas
Richardson, TX 75083-0688 USA Richardson, TX 75083-0688 USA
Tel: +1 972 883 2337 Tel: +1 972 883 2337
Fax: +1 972 883 2349 Fax: +1 972 883 2349
Magnus Westerlund <magnus.westerlund@era.ericsson.se>
Ericsson Research, Corporate Unit
Ericsson Radio Systems AB
SE-164 80 Stockholm
Sweden
Tel: +46 8 404 82 87
Fax: +46 8 757 55 50
References References
The references are divided into normative references and non- The references are divided into normative references and non-
normative references. normative references.
Normative References Normative References
[1] S. Bradner, "Key words for use in RFCs to indicate requirement [1] 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.
[2] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI [2] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, Internet Engineering Task Force, November 1997.
[3] 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.
[3] R. Hovey and S. Bradner, "The Organizations Involved in the IETF [4] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC
2327, Internet Engineering Task Force, April 1998.
[5] R. Hovey and S. Bradner, "The Organizations Involved in the IETF
Standards Process," best current practice BCP 11, RFC 2028, IETF, Standards Process," best current practice BCP 11, RFC 2028, IETF,
October 1996. October 1996.
[4] ITU-T, "The E-Model, a computational model for use in [6] ITU-T, "The E-Model, a computational model for use in
transmission planning," Recommendation G.107 (05/00), May 2000. transmission planning," Recommendation G.107 (05/00), May 2000.
[5] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2, [7] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2,
RFC 1700, IETF, October 1994. RFC 1700, IETF, October 1994.
[6] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA [8] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs," best current practice BCP 26, RFC Considerations Section in RFCs," best current practice BCP 26, RFC
2434, IETF, October 1998. 2434, IETF, October 1998.
[7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A [9] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the
transport protocol for real-time applications," RFC 1889, IETF, Session Description Protocol (SDP)", RFC 3264, Internet Engineering
Task Force, June 2002.
[10] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:
A transport protocol for real-time applications," RFC 1889, IETF,
February 1996. February 1996.
Non-Normative References Non-Normative References
[8] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. [11] 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.
[9] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu [12] Baugher, McGrew, Oran, Blom, Carrara, Naslund, and Norrman, "The
Secure Real-time Transport Protocol," Internet-Draft draft-ietf-avt-
srtp-05.txt, June 2002. Note: this is is a work in progress.
[13] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu
measurement infrastructures using RTP," Proc. IEEE Infocom 2002. measurement infrastructures using RTP," Proc. IEEE Infocom 2002.
[10] A. D. Clark, "Modeling the Effects of Burst Packet Loss and [14] 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.
[11] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion [15] M. Handley, C. Perkins, E. Whelan, "Session Announcement
Protocol", RFC 2974, Internet Engineering Task Force, October 2000.
[16] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming
protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr.
1998.
[17] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion
Control Framework for Heterogeneous Multicast Environments", Proc. Control Framework for Heterogeneous Multicast Environments", Proc.
IWQoS 2000. IWQoS 2000.
 End of changes. 

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