draft-ietf-avt-rtcp-report-extns-06.txt   rfc3611.txt 
Internet Engineering Task Force Expires: 19 November 2003 Network Working Group T. Friedman, Ed.
Audio/Video Transport Working Group Request for Comments: 3611 Paris 6
Category: Standards Track R. Caceres, Ed.
Timur Friedman, Paris 6 IBM Research
Ramon Caceres, ShieldIP A. Clark, Ed.
Alan Clark, Telchemy Telchemy
Editors November 2003
RTP Control Protocol Extended Reports (RTCP XR) RTP Control Protocol Extended Reports (RTCP XR)
draft-ietf-avt-rtcp-report-extns-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document specifies an Internet standards track protocol for the
of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
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), and defines how the use of XR packets RTP Control Protocol (RTCP), and defines how the use of XR packets
can be signaled by an application if it employs the Session can be signaled by an application if it employs the Session
skipping to change at page 2, line 13 skipping to change at page 2, line 7
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 .............................................. 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Applicability ............................................. 4 1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 4
1.2 Terminology ............................................... 7 1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 7
2. XR Packet Format .......................................... 7 2. XR Packet Format . . . . . . . . . . . . . . . . . . . . . . . 7
3. Extended Report Block Framework ........................... 8 3. Extended Report Block Framework. . . . . . . . . . . . . . . . 8
4. Extended Report Blocks .................................... 9 4. Extended Report Blocks . . . . . . . . . . . . . . . . . . . . 9
4.1 Loss RLE Report Block ..................................... 9 4.1. Loss RLE Report Block. . . . . . . . . . . . . . . . . . 9
4.1.1 Run Length Chunk .......................................... 15 4.1.1. Run Length Chunk . . . . . . . . . . . . . . . . 15
4.1.2 Bit Vector Chunk .......................................... 15 4.1.2. Bit Vector Chunk . . . . . . . . . . . . . . . . 15
4.1.3 Terminating Null Chunk .................................... 15 4.1.3. Terminating Null Chunk . . . . . . . . . . . . . 16
4.2 Duplicate RLE Report Block ................................ 16 4.2. Duplicate RLE Report Block . . . . . . . . . . . . . . . 16
4.3 Packet Receipt Times Report Block ......................... 17 4.3. Packet Receipt Times Report Block. . . . . . . . . . . . 18
4.4 Receiver Reference Time Report Block ...................... 20 4.4. Receiver Reference Time Report Block . . . . . . . . . . 20
4.5 DLRR Report Block ......................................... 21 4.5. DLRR Report Block. . . . . . . . . . . . . . . . . . . . 21
4.6 Statistics Summary Report Block ........................... 22 4.6. Statistics Summary Report Block. . . . . . . . . . . . . 22
4.7 VoIP Metrics Report Block ................................. 25 4.7. VoIP Metrics Report Block. . . . . . . . . . . . . . . . 25
4.7.1 Packet Loss and Discard Metrics ........................... 26 4.7.1. Packet Loss and Discard Metrics. . . . . . . . . 27
4.7.2 Burst Metrics ............................................. 27 4.7.2. Burst Metrics. . . . . . . . . . . . . . . . . . 27
4.7.3 Delay Metrics ............................................. 30 4.7.3. Delay Metrics. . . . . . . . . . . . . . . . . . 30
4.7.4 Signal Related Metrics .................................... 30 4.7.4. Signal Related Metrics . . . . . . . . . . . . . 31
4.7.5 Call Quality or Transmission Quality Metrics .............. 33 4.7.5. Call Quality or Transmission Quality Metrics . . 33
4.7.6 Configuration Parameters .................................. 34 4.7.6. Configuration Parameters . . . . . . . . . . . . 34
4.7.7 Jitter Buffer Parameters .................................. 35 4.7.7. Jitter Buffer Parameters . . . . . . . . . . . . 36
5. SDP Signaling ............................................. 36 5. SDP Signaling. . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1 The SDP Attribute ......................................... 37 5.1. The SDP Attribute. . . . . . . . . . . . . . . . . . . . 37
5.2 Usage in Offer/Answer ..................................... 40 5.2. Usage in Offer/Answer. . . . . . . . . . . . . . . . . . 40
5.3 Usage Outside of Offer/Answer ............................. 41 5.3. Usage Outside of Offer/Answer. . . . . . . . . . . . . . 42
6. IANA Considerations ....................................... 42 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 42
6.1 XR Packet Type ............................................ 42 6.1. XR Packet Type . . . . . . . . . . . . . . . . . . . . . 42
6.2 RTCP XR Block Type Registry ............................... 42 6.2. RTCP XR Block Type Registry. . . . . . . . . . . . . . . 42
6.3 The "rtcp-xr" SDP Attribute ............................... 43 6.3. The "rtcp-xr" SDP Attribute. . . . . . . . . . . . . . . 43
7. Security Considerations ................................... 44 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 44
A. Algorithms ................................................ 45 A. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.1 Sequence Number Interpretation ............................ 45 A.1. Sequence Number Interpretation . . . . . . . . . . . . . 46
A.2 Example Burst Packet Loss Calculation ..................... 46 A.2. Example Burst Packet Loss Calculation. . . . . . . . . . 47
Intellectual Property ..................................... 48 Intellectual Property Notice . . . . . . . . . . . . . . . . . . . 49
Full Copyright Statement .................................. 49 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 50
Acknowledgments ........................................... 49 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Contributors .............................................. 50 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses ........................................ 50 Normative References . . . . . . . . . . . . . . . . . . . . . . . 51
References ................................................ 52 Informative References . . . . . . . . . . . . . . . . . . . . . . 51
Normative References ...................................... 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
Non-Normative References .................................. 53 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 55
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) [9], and defines how the use of XR RTP Control Protocol (RTCP) [9], and defines how the use of XR
packets can be signaled by an application if it employs the Session packets can be signaled by an application if it employs the Session
Description Protocol (SDP) [4]. XR packets convey information beyond Description Protocol (SDP) [4]. XR packets convey information beyond
that already contained in the reception report blocks of RTCP's that already contained in the reception report blocks of RTCP's
sender report (SR) or Receiver Report (RR) packets. The information sender report (SR) or Receiver Report (RR) packets. The information
is of use across RTP profiles, and so is not appropriately carried in is of use across RTP profiles, and so is not appropriately carried in
skipping to change at page 3, line 41 skipping to change at page 3, line 37
categories. The first category consists of packet-by-packet reports categories. The first category consists of packet-by-packet reports
on received or lost RTP packets. Reports in the second category on received or lost RTP packets. Reports in the second category
convey reference time information between RTP participants. In the convey reference time information between RTP participants. In the
third category, reports convey metrics relating to packet receipts, third category, reports convey metrics relating to packet receipts,
that are summary in nature but that are more detailed, or of a that are summary in nature but that are more detailed, or of a
different type, than that conveyed in existing RTCP packets. different type, than that conveyed in existing RTCP packets.
All told, seven report block formats are defined by this document. All told, seven report block formats are defined by this document.
Of these, three are packet-by-packet block types: Of these, three are packet-by-packet block types:
- Loss RLE Report Block (Section 4.1): Run length encoding of reports - Loss RLE Report Block (Section 4.1): Run length encoding of
concerning the losses and receipts of RTP packets. 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 concerning duplicates of received RTP packets. reports concerning duplicates of received RTP packets.
- Packet Receipt Times Report Block (Section 4.3): A list of - Packet Receipt Times Report Block (Section 4.3): A list of
reception timestamps of RTP packets. reception timestamps of RTP packets.
There are two reference time related block types: There are two reference time related block types:
- Receiver Reference Time Report Block (Section 4.4): Receiver-end - Receiver Reference Time Report Block (Section 4.4): Receiver-end
wallclock timestamps. Together with the DLRR Report Block mentioned wallclock timestamps. Together with the DLRR Report Block
next, these allow non-senders to calculate round-trip times. mentioned next, these allow non-senders to calculate round-trip
times.
- DLRR Report Block (Section 4.5): The delay since the last Receiver - DLRR Report Block (Section 4.5): The delay since the last Receiver
Reference Time Report Block was received. An RTP data sender that Reference Time Report Block was received. An RTP data sender that
receives a Receiver Reference Time Report Block can respond with a receives a Receiver Reference Time Report Block can respond with a
DLRR Report Block, in much the same way as, in the mechanism already DLRR Report Block, in much the same way as, in the mechanism
defined for RTCP [9, Section 6.3.1], an RTP data receiver that already defined for RTCP [9, Section 6.3.1], an RTP data receiver
receives a sender's NTP timestamp can respond by filling in the DLSR that receives a sender's NTP timestamp can respond by filling in
field of an RTCP reception report block. the DLSR field of an RTCP reception report block.
Finally, this document defines two summary metric block types: Finally, this document defines two summary metric block types:
- Statistics Summary Report Block (Section 4.6): Statistics on RTP - Statistics Summary Report Block (Section 4.6): Statistics on RTP
packet sequence numbers, losses, duplicates, jitter, and TTL or Hop packet sequence numbers, losses, duplicates, jitter, and TTL or
Limit values. 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.
Before proceeding to the XR packet and report block definitions, this Before proceeding to the XR packet and report block definitions, this
document provides an applicability statement (Section 1.1) that document provides an applicability statement (Section 1.1) that
describes the contexts in which these report blocks can be used. It describes the contexts in which these report blocks can be used. It
also defines (Section 1.2) the normative use of key words, such as also defines (Section 1.2) the normative use of key words, such as
MUST and SHOULD, as they are employed in this document. MUST and SHOULD, as they are employed in this document.
Following the definitions of the various report blocks, this document Following the definitions of the various report blocks, this document
describes how applications that employ SDP can signal their use describes how applications that employ SDP can signal their use
(Section 5). The document concludes with a discussion (Section 6) of (Section 5). The document concludes with a discussion (Section 6) of
numbering considerations for the Internet Assigned Numbers Authority numbering considerations for the Internet Assigned Numbers Authority
(IANA), of security considerations (Section 7), and with appendices (IANA), of security considerations (Section 7), and with appendices
that provide examples of how to implement algorithms discussed in the that provide examples of how to implement algorithms discussed in the
text. text.
1.1 Applicability 1.1. Applicability
The XR packets are useful across multiple applications, and for that The XR packets are useful across multiple applications, and for that
reason are not defined as profile-specific extensions to RTCP sender reason are not defined as profile-specific extensions to RTCP sender
or Receiver Reports [9, Section 6.4.3]. Nonetheless, they are not of or Receiver Reports [9, Section 6.4.3]. Nonetheless, they are not of
use in all contexts. In particular, the VoIP metrics report block use in all contexts. In particular, the VoIP metrics report block
(Section 4.7) is specific to voice applications, though it can be (Section 4.7) is specific to voice applications, though it can be
employed over a wide variety of such applications. employed over a wide variety of such applications.
The VoIP metrics report block can be applied to any one-to-one or The VoIP metrics report block can be applied to any one-to-one or
one-to-many voice application for which the use of RTP and RTCP is one-to-many voice application for which the use of RTP and RTCP is
specified. The use of conversational metrics (Section 4.7.5), specified. The use of conversational metrics (Section 4.7.5),
including the R factor (as described by the E Model defined in [3]) including the R factor (as described by the E Model defined in [3])
and the mean opinion score for conversational quality (MOS-CQ), in and the mean opinion score for conversational quality (MOS-CQ), in
applications other than simple two party calls is not defined, and applications other than simple two party calls is not defined; hence,
hence these metrics should be identified as unavailable in multicast these metrics should be identified as unavailable in multicast
conferencing applications. conferencing applications.
The packet-by-packet report block types, Loss RLE (Section 4.1), The packet-by-packet report block types, Loss RLE (Section 4.1),
Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3), Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3),
have been defined with network tomography applications, such as have been defined with network tomography applications, such as
multicast inference of network characteristics (MINC) [11], in mind. multicast inference of network characteristics (MINC) [11], in mind.
MINC requires detailed packet receipt traces from multicast session MINC requires detailed packet receipt traces from multicast session
receivers in order to infer the gross structure of the multicast receivers in order to infer the gross structure of the multicast
distribution tree and the parameters, such as loss rates and delays, distribution tree and the parameters, such as loss rates and delays,
that apply to paths between the branching points of that tree. that apply to paths between the branching points of that tree.
Any real time multicast multimedia application can use the packet-by- Any real time multicast multimedia application can use the packet-
packet report block types. Such an application could employ a MINC by-packet report block types. Such an application could employ a
inference subsystem that would provide it with multicast tree MINC inference subsystem that would provide it with multicast tree
topology information. One potential use of such a subsystem would be topology information. One potential use of such a subsystem would be
for the identification of high loss regions in the multicast tree and for the identification of high loss regions in the multicast tree and
the identification of multicast session participants well situated to the identification of multicast session participants well situated to
provide retransmissions of lost packets. provide retransmissions of lost packets.
Detailed packet-by-packet reports do not necessarily have to consume Detailed packet-by-packet reports do not necessarily have to consume
disproportionate bandwidth with respect to other RTCP packets. An disproportionate bandwidth with respect to other RTCP packets. An
application can cap the size of these blocks. A mechanism called application can cap the size of these blocks. A mechanism called
"thinning" is provided for these report blocks, and can be used to "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 ensure that they adhere to a size limit by restricting the number of
skipping to change at page 5, line 48 skipping to change at page 5, line 44
bandwidth that they consume. bandwidth that they consume.
The packet-by-packet report blocks can also be used by dedicated The packet-by-packet report blocks can also be used by dedicated
network monitoring applications. For such an application, it might network monitoring applications. For such an application, it might
be appropriate to allow more than 5% of RTP data bandwidth to be used be appropriate to allow more than 5% of RTP data bandwidth to be used
for RTCP packets, thus allowing proportionately larger and more for RTCP packets, thus allowing proportionately larger and more
detailed report blocks. detailed report blocks.
Nothing in the packet-by-packet block types restricts their use to Nothing in the packet-by-packet block types restricts their use to
multicast applications. In particular, they could be used for multicast applications. In particular, they could be used for
network tomography similar to MINC, but using striped unicast network tomography similar to MINC, but using striped unicast packets
packets. In addition, if it were found useful, they could be used instead. In addition, if it were found useful, they could be used
for applications limited to two participants. for applications limited to two participants.
One use to which the packet-by-packet reports are not immediately One use to which the packet-by-packet reports are not immediately
suited is for data packet acknowledgments as part of a packet suited is for data packet acknowledgments as part of a packet
retransmission mechanism. The reason is that the packet accounting retransmission mechanism. The reason is that the packet accounting
technique suggested for these blocks differs from the packet technique suggested for these blocks differs from the packet
accounting normally employed by RTP. In order to favor measurement accounting normally employed by RTP. In order to favor measurement
applications, an effort is made to interpret as little as possible at applications, an effort is made to interpret as little as possible at
the data receiver, and leave the interpretation as much as possible the data receiver, and leave the interpretation as much as possible
to participants that receive the report blocks. Thus, for example, a to participants that receive the report blocks. Thus, for example, a
skipping to change at page 7, line 5 skipping to change at page 7, line 5
The SDP signaling defined for XR packets in this document (Section 5) 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 was done so with three use scenarios in mind: a Real Time Streaming
Protocol (RTSP) controlled streaming application, a one-to-many Protocol (RTSP) controlled streaming application, a one-to-many
multicast multimedia application such as a course lecture with multicast multimedia application such as a course lecture with
enhanced feedback, and a Session Initiation Protocol (SIP) controlled enhanced feedback, and a Session Initiation Protocol (SIP) controlled
conversational session involving two parties. Applications that conversational session involving two parties. Applications that
employ SDP are free to use additional SDP signaling for cases not employ SDP are free to use additional SDP signaling for cases not
covered here. In addition, applications are free to use signaling covered here. In addition, applications are free to use signaling
mechanisms other than SDP. mechanisms other than SDP.
1.2 Terminology 1.2. 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 BCP 14, RFC 2119 [1]
indicate requirement levels for compliance with this specification. and indicate requirement levels for compliance with this
specification.
2. XR Packet Format 2. XR Packet Format
An 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. This type of number, possibly zero, of extended report blocks. This type of
packet is laid out in a manner consistent with other RTCP packets, as packet is laid out in a manner consistent with other RTCP packets, as
concerns the essential version, packet type, and length information. concerns the essential version, packet type, and length information.
XR packets are thus backwards compatible with RTCP receiver XR packets are thus backwards compatible with RTCP receiver
implementations that do not recognize them, but that ought to be able implementations that do not recognize them, but that ought to be able
to parse past them using the length information. A padding field and to parse past them using the length information. A padding field and
skipping to change at page 7, line 42 skipping to change at page 7, line 43
: 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.
padding (P): 1 bit padding (P): 1 bit
If the padding bit is set, this XR packet contains some If the padding bit is set, this XR packet contains some
additional padding octets at the end. The semantics of this additional padding octets at the end. The semantics of this
field are identical to the semantics of the padding field in the field are identical to the semantics of the padding field in
SR packet, as defined by the RTP specification. the SR packet, as defined by the RTP specification.
reserved: 5 bits reserved: 5 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence
such definition, the bits in this field MUST be set to zero and of such definition, the bits in this field MUST be set to zero
MUST be ignored by the receiver. and 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
This value is registered with the Internet Assigned Numbers packet. This value is registered with the Internet Assigned
Authority (IANA), as described in Section 5.1. Numbers Authority (IANA), as described in Section 6.1.
length: 16 bits length: 16 bits
As described for the RTCP Sender Report (SR) packet (see Section As described for the RTCP Sender Report (SR) packet (see
6.3.1 of the RTP specification [9]). Briefly, the length of Section 6.4.1 of the RTP specification [9]). Briefly, the
this XR packet in 32-bit words minus one, including the header length of this XR packet in 32-bit words minus one, including
and any padding. the header and any padding.
SSRC: 32 bits SSRC: 32 bits
The synchronization source identifier for the originator of this The synchronization source identifier for the originator of
XR packet. this 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
Extended report blocks are stacked, one after the other, at the end Extended report blocks are stacked, one after the other, at the end
of an XR packet. An individual block's length is a multiple of 4 of an XR packet. An individual block's length is a multiple of 4
skipping to change at page 9, line 4 skipping to change at page 8, line 52
| BT | type-specific | block length | | BT | type-specific | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: type-specific block contents : : 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 6.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-
words minus one. If the block type definition permits, zero is bit words minus one. If the block type definition permits,
an acceptable value, signifying a block that consists of only zero is an acceptable value, signifying a block that consists
the BT, type-specific, and block length fields, with a null of only the BT, type-specific, and block length fields, with a
type-specific block contents field. null type-specific block contents field.
type-specific block contents: 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
long. bits 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
reporting upon received packet losses and duplicates, packet reporting upon received packet losses and duplicates, packet
reception times, receiver reference time information, receiver inter- reception times, receiver reference time information, receiver
report delays, detailed reception statistics, and voice over IP inter-report delays, detailed reception statistics, and voice over IP
(VoIP) metrics. An implementation SHOULD ignore incoming blocks with (VoIP) metrics. An implementation SHOULD ignore incoming blocks with
types either not relevant or unknown to it. Additional block types types not relevant or unknown to it. Additional block types MUST be
MUST be registered with the Internet Assigned Numbers Authority registered with the Internet Assigned Numbers Authority (IANA) [16],
(IANA) [16], as described in Section 5.2. as described in Section 6.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) [11]. 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 [13]. 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
skipping to change at page 10, line 37 skipping to change at page 10, line 35
for example, of excluding the stray old packet from an unrelated for example, of excluding the stray old packet from an unrelated
session from having an effect upon the calculation of the RTCP session from having an effect upon the calculation of the RTCP
transmission interval. The presence of stray packets might, on the transmission interval. The presence of stray packets might, on the
other hand, be of interest to a network monitoring application. other hand, be of interest to a network monitoring application.
One accounting interpretation that is still necessary is for a One accounting interpretation that is still necessary is for a
participant to decide whether the 16 bit sequence number has rolled participant to decide whether the 16 bit sequence number has rolled
over. Under ordinary circumstances this is not a difficult task. over. Under ordinary circumstances this is not a difficult task.
For example, if packet number 65,535 (the highest possible sequence For example, if packet number 65,535 (the highest possible sequence
number) is followed shortly by packet number 0, it is reasonable to number) is followed shortly by packet number 0, it is reasonable to
assume that there has been a rollover. However it is possible that assume that there has been a rollover. However, it is possible that
the packet is an earlier one (from 65,535 packets earlier). It is the packet is an earlier one (from 65,535 packets earlier). It is
also possible that the sequence numbers have rolled over multiple also possible that the sequence numbers have rolled over multiple
times, either forward or backward. The interpretation becomes more times, either forward or backward. The interpretation becomes more
difficult when there are large gaps between the sequence numbers, difficult when there are large gaps between the sequence numbers,
even accounting for rollover, and when there are long intervals even accounting for rollover, and when there are long intervals
between received packets. between received packets.
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
skipping to change at page 11, line 16 skipping to change at page 11, line 14
Each block reports on a single RTP data packet source, identified by Each block reports on a single RTP data packet source, identified by
its SSRC. The receiver that is supplying the report is identified in its SSRC. The receiver that is supplying the report is identified in
the header of 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 of
identify multiple wraparounds. identifying multiple wraparounds.
The trace described by a Loss RLE report consists of a sequence of The trace described by a Loss RLE report consists of a sequence of
Boolean values, one for each sequence number of the trace. A value Boolean values, one for each sequence number of the trace. A value
of one represents a packet receipt, meaning that one or more packets of one represents a packet receipt, meaning that one or more packets
having that sequence number have been received since the most recent having that sequence number have been received since the most recent
wraparound of sequence numbers (or since the beginning of the RTP wraparound of sequence numbers (or since the beginning of the RTP
session if no wraparound has been judged to have occurred). A value session if no wraparound has been judged to have occurred). A value
of zero represents a packet loss, meaning that there has been no of zero represents a packet loss, meaning that there has been no
packet receipt for that sequence number as of the time of the report. packet receipt for that sequence number as of the time of the report.
If a packet with a given sequence number is received after a report If a packet with a given sequence number is received after a report
skipping to change at page 12, line 22 skipping to change at page 12, line 22
run of 21 receipts run of 21 receipts
bit vector 0101 1111 1111 111 bit vector 0101 1111 1111 111
run of 9 receipts run of 9 receipts
null chunk null chunk
The choice of encoding is left to the application. As part of this The choice of encoding is left to the application. As part of this
freedom of choice, applications MAY terminate a series of run length freedom of choice, applications MAY terminate a series of run length
and bit vector chunks with a bit vector chunk that runs beyond the and bit vector chunks with a bit vector chunk that runs beyond the
sequence number space described by the report block. For example, if sequence number space described by the report block. For example, if
the 44th packet in the same sequence were lost: the 44th packet in the same sequence was lost:
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
This could be encoded as: This could be encoded as:
run of 21 receipts run of 21 receipts
bit vector 0101 1111 1111 111 bit vector 0101 1111 1111 111
bit vector 1111 1110 1000 000 bit vector 1111 1110 1000 000
null chunk null chunk
skipping to change at page 13, line 14 skipping to change at page 13, line 8
Caution should be used in sending Loss RLE Report Blocks because, Caution should be used in sending Loss RLE Report Blocks because,
even with the compression provided by run length encoding, they can even with the compression provided by run length encoding, they can
easily consume bandwidth out of proportion with normal RTCP packets. easily consume bandwidth out of proportion with normal RTCP packets.
The block type includes a mechanism, called thinning, that allows an The block type includes a mechanism, called thinning, that allows an
application to limit report sizes. application to limit report sizes.
A thinning value, T, selects a subset of packets within the sequence A thinning value, T, selects a subset of packets within the sequence
number space: those with sequence numbers that are multiples of 2^T. number space: those with sequence numbers that are multiples of 2^T.
Packet reception and loss reports apply only to those packets. T can Packet reception and loss reports apply only to those packets. T can
vary between 0 and 15. If T is zero then every packet in the vary between 0 and 15. If T is zero, then every packet in the
sequence number space is reported upon. If T is fifteen then one in sequence number space is reported upon. If T is fifteen, then one in
every 32,768 packets is reported upon. every 32,768 packets is reported upon.
Suppose that the trace just described begins at sequence number Suppose that the trace just described begins at sequence number
13,821. The last sequence number in the trace is 13,865. If the 13,821. The last sequence number in the trace is 13,865. If the
trace were to be thinned with a thinning value of T=2, then the trace were to be thinned with a thinning value of T=2, then the
following sequence numbers would be reported upon: 13,824, 13,828, following sequence numbers would be reported upon: 13,824, 13,828,
13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860,
13,864. The thinned trace would be as follows: 13,864. The thinned trace would be as follows:
1 1 1 1 1 0 1 1 1 1 0 1 1 1 1 1 0 1 1 1 1 0
skipping to change at page 14, line 25 skipping to change at page 14, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n | | chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Loss RLE Report Block is identified by the constant 1. A Loss RLE Report Block is identified by the constant 1.
rsvd.: 4 bits rsvd.: 4 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence
such definition, the bits in this field MUST be set to zero and of such definition, the bits in this field MUST be set to zero
MUST be ignored by the receiver. and MUST be ignored by the receiver.
thinning (T): 4 bits thinning (T): 4 bits
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
is one packet in every 32,768 (amounting to two packets within thinning is one packet in every 32,768 (amounting to two
each 16-bit sequence space). packets within 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 SSRC of source: 32 bits
The SSRC of the RTP data packet source being reported upon by The SSRC of the RTP data packet source being reported upon by
this report block. 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.
Otherwise, the leftmost bit of the chunk determines its type: 0 Otherwise, the left most bit of the chunk determines its type:
for run length and 1 for bit vector. 0 for run length and 1 for bit vector.
4.1.1 Run Length Chunk 4.1.1. Run Length Chunk
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R| run length | |C|R| run length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
chunk type (C): 1 bit chunk type (C): 1 bit
A zero identifies this as a run length chunk. A zero identifies this as a run length chunk.
skipping to change at page 15, line 31 skipping to change at page 15, line 34
Zero indicates a run of 0s. One indicates a run of 1s. Zero indicates a run of 0s. One indicates a run of 1s.
run length: 14 bits run length: 14 bits
A value between 1 and 16,383. The value MUST not be zero for a A value between 1 and 16,383. The value MUST not be zero for a
run length chunk (zeroes in both the run type and run length run length chunk (zeroes in both the run type and run length
fields would make the chunk a terminating null chunk). Run fields would make the chunk a terminating null chunk). Run
lengths of 15 or less MAY be described with a run length chunk lengths of 15 or less MAY be described with a run length chunk
despite the fact that they could also be described as part of a despite the fact that they could also be described as part of a
bit vector chunk. bit vector chunk.
4.1.2 Bit Vector Chunk 4.1.2. Bit Vector Chunk
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| bit vector | |C| bit vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
chunk type (C): 1 bit chunk type (C): 1 bit
A one identifies this as a bit vector chunk. A one identifies this as a bit vector chunk.
bit vector: 15 bits bit vector: 15 bits
The vector is read from left to right, in order of increasing The vector is read from left to right, in order of increasing
sequence number (with the appropriate allowance for wraparound). sequence number (with the appropriate allowance for
wraparound).
4.1.3. Terminating Null Chunk
4.1.3 Terminating Null Chunk
This chunk is all zeroes. This chunk is all zeroes.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2 Duplicate RLE Report Block 4.2. Duplicate RLE Report Block
This block type permits per-sequence-number reports on duplicates in This block type permits per-sequence-number reports on duplicates in
a source's RTP packet stream. Such information can be used for a source's RTP packet stream. Such information can be used for
network diagnosis, and provide an alternative to packet losses as a network diagnosis, and provide an alternative to packet losses as a
basis for multicast tree topology inference. basis for multicast tree topology inference.
The Duplicate RLE Report Block format is identical to the Loss RLE The Duplicate RLE Report Block format is identical to the Loss RLE
Report Block format. Only the interpretation is different, in that Report Block format. Only the interpretation is different, in that
the information concerns packet duplicates rather than packet losses. the information concerns packet duplicates rather than packet losses.
The trace to be encoded in this case also consists of zeros and ones, The trace to be encoded in this case also consists of zeros and ones,
skipping to change at page 17, line 25 skipping to change at page 17, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n | | chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Duplicate RLE Report Block is identified by the constant 2. A Duplicate RLE Report Block is identified by the constant 2.
rsvd.: 4 bits rsvd.: 4 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence
such definition, the bits in this field MUST be set to zero and of such a definition, the bits in this field MUST be set to
MUST be ignored by the receiver. zero and 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 SSRC of source: 32 bits
As defined in Section 4.1. 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 Packet Receipt Times 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
times for a given source's RTP packet stream. Such information can times for a given source's RTP packet stream. Such information can
be used for MINC inference of the topology of the multicast tree used be used for MINC inference of the topology of the multicast tree used
to distribute the source's RTP packets, and of the delays along the to distribute the source's RTP packets, and of the delays along the
links within that tree. It can also be used to measure partial path links within that tree. It can also be used to measure partial 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 Packet receipt times are expressed in the same units as in the RTP
RTP timestamps of data packets. This is so that, for each packet, timestamps of data packets. This is so that, for each packet, one
one can establish both the send time and the receipt time in can establish both the send time and the receipt time in comparable
comparable terms. Note, however, that as an RTP sender ordinarily terms. Note, however, that as an RTP sender ordinarily initializes
initializes its time to a value chosen at random, there can be no its time to a value chosen at random, there can be no expectation
expectation that reported send and receipt times will differ by an that reported send and receipt times will differ by an amount equal
amount equal to the one-way delay between sender and receiver. The to the one-way delay between sender and receiver. The reported times
reported times can nonetheless be useful for the purposes mentioned can nonetheless be useful for the purposes mentioned above.
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
receipt times 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 receipt times, any time other than the earliest MUST NOT be their receipt times, any time other than the earliest MUST NOT be
reported. This is to ensure consistency among reports. reported. This is to ensure consistency among reports.
Times reported in RTP timestamp format consume more bits than loss or Times reported in RTP timestamp format consume more bits than loss or
skipping to change at page 19, line 28 skipping to change at page 19, line 30
: ... : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet (end_seq - 1) mod 65536 | | Receipt time of packet (end_seq - 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Packet Receipt Times Report Block is identified by the A Packet Receipt Times Report Block is identified by the
constant 3. 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
such definition, the bits in this field MUST be set to zero and of such a definition, the bits in this field MUST be set to
MUST be ignored by the receiver. zero and 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 SSRC of source: 32 bits
As defined in Section 4.1. As defined in Section 4.1.
skipping to change at page 20, line 4 skipping to change at page 20, line 10
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.
Packet i receipt time: 32 bits Packet i receipt time: 32 bits
The receipt time of the packet with sequence number i at the The receipt time of the packet with sequence number i at the
receiver. The modular arithmetic shown in the packet format receiver. The modular arithmetic shown in the packet format
diagram is to allow for sequence number rollover. It is diagram is to allow for sequence number rollover. It is
preferable for the time value to be established at the link 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
arrival time. Units and format are the same as for the wire 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 receipt times should reflect the actual periodic playout, the receipt times should reflect the actual
time as closely as possible. For a session, if the RTP time as closely as possible. For a session, if the RTP
timestamp is chosen at random, the first receipt time value timestamp is chosen at random, the first receipt time value
SHOULD also be chosen at random, and subsequent timestamps SHOULD also be chosen at random, and subsequent timestamps
offset from this value. On the other hand, if the RTP timestamp offset from this value. On the other hand, if the RTP
is meant to reflect the reference time at the sender, then the timestamp is meant to reflect the reference time at the sender,
receipt time SHOULD be as close as possible to the reference then the receipt time SHOULD be as close as possible to the
time at the receiver. reference time at the receiver.
4.4 Receiver Reference Time Report Block 4.4. Receiver Reference Time Report Block
This block extends RTCP's timestamp reporting so that non-senders may This block extends RTCP's timestamp reporting so that non-senders may
also send timestamps. It recapitulates the NTP timestamp fields from also send timestamps. It recapitulates the NTP timestamp fields from
the RTCP Sender Report [9, Sec. 6.3.1]. A non-sender may estimate the RTCP Sender Report [9, Sec. 6.3.1]. A non-sender may estimate
its round trip time (RTT) to other participants, as proposed in [18], its round trip time (RTT) to other participants, as proposed in [18],
by sending this report block and receiving DLRR Report Blocks (see by sending this report block and receiving DLRR Report Blocks (see
next section) in reply. next section) in reply.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 20, line 42 skipping to change at page 20, line 48
| NTP timestamp, most significant word | | NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word | | NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Receiver Reference Time Report Block is identified by the A Receiver Reference Time Report Block is identified by the
constant 4. constant 4.
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
such definition, the bits in this field MUST be set to zero and of such definition, the bits in this field MUST be set to zero
MUST be ignored by the receiver. and MUST be ignored by the receiver.
block length: 16 bits block length: 16 bits
The constant 2, in accordance with the definition of this field The constant 2, in accordance with the definition of this field
in Section 3. in Section 3.
NTP timestamp: 64 bits NTP timestamp: 64 bits
Indicates the wallclock time when this block was sent so that it Indicates the wallclock time when this block was sent so that
may be used in combination with timestamps returned in DLRR it may be used in combination with timestamps returned in DLRR
Report Blocks (see next section) from other receivers to measure Report Blocks (see next section) from other receivers to
round-trip propagation to those receivers. Receivers should measure round-trip propagation to those receivers. Receivers
expect that the measurement accuracy of the timestamp may be should expect that the measurement accuracy of the timestamp
limited to far less than the resolution of the NTP timestamp. may be limited to far less than the resolution of the NTP
The measurement uncertainty of the timestamp is not indicated as timestamp. The measurement uncertainty of the timestamp is not
it may not be known. A report block sender that can keep track indicated as it may not be known. A report block sender that
of elapsed time but has no notion of wallclock time may use the can keep track of elapsed time but has no notion of wallclock
elapsed time since joining the session instead. This is assumed time may use the elapsed time since joining the session
to be less than 68 years, so the high bit will be zero. It is instead. This is assumed to be less than 68 years, so the high
permissible to use the sampling clock to estimate elapsed bit will be zero. It is permissible to use the sampling clock
wallclock time. A report sender that has no notion of wallclock to estimate elapsed wallclock time. A report sender that has
or elapsed time may set the NTP timestamp to zero. no notion of wallclock or elapsed time may set the NTP
timestamp to zero.
4.5 DLRR Report Block 4.5. DLRR Report Block
This block extends RTCP's delay since last Sender Report (DLSR) This block extends RTCP's delay since the last Sender Report (DLSR)
mechanism [9, Sec. 6.3.1] so that non-senders may also calculate mechanism [9, Sec. 6.3.1] so that non-senders may also calculate
round trip times, as proposed in [18]. It is termed DLRR for delay round trip times, as proposed in [18]. It is termed DLRR for delay
since last Receiver Report, and may be sent in response to a Receiver since the last Receiver Report, and may be sent in response to a
Timestamp Report Block (see previous section) from a receiver to Receiver Timestamp Report Block (see previous section) from a
allow that receiver to calculate its round trip time to the receiver to allow that receiver to calculate its round trip time to
respondent. The report consists of one or more 3 word sub-blocks: the respondent. The report consists of one or more 3 word sub-
one sub-block per Receiver Report. blocks: one sub-block per Receiver Report.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=5 | reserved | block length | | BT=5 | reserved | block length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first receiver) | sub- | SSRC_1 (SSRC of first receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| last RR (LRR) | 1 | last RR (LRR) | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 47 skipping to change at page 22, line 4
| SSRC_1 (SSRC of first receiver) | sub- | SSRC_1 (SSRC of first receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| last RR (LRR) | 1 | last RR (LRR) | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last RR (DLRR) | | delay since last RR (DLRR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second receiver) | sub- | SSRC_2 (SSRC of second receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2 : ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
block type (BT): 8 bits block type (BT): 8 bits
A DLRR Report Block is identified by the constant 5. A DLRR Report Block is identified by the constant 5.
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
such definition, the bits in this field MUST be set to zero and of such definition, the bits in this field MUST be set to zero
MUST be ignored by the receiver. and MUST be ignored by the receiver.
block length: 16 bits block length: 16 bits
Defined in Section 3. Defined in Section 3.
last RR timestamp (LRR): 32 bits last RR timestamp (LRR): 32 bits
The middle 32 bits out of 64 in the NTP timestamp (as explained The middle 32 bits out of 64 in the NTP timestamp (as explained
in the previous section) received as part of a Receiver in the previous section), received as part of a Receiver
Reference Time Report Block from participant SSRC_n. If no such Reference Time Report Block from participant SSRC_n. If no
block has been received, the field is set to zero. such block has been received, the field is set to zero.
delay since last RR (DLRR): 32 bits delay since last RR (DLRR): 32 bits
The delay, expressed in units of 1/65536 seconds, between The delay, expressed in units of 1/65536 seconds, between
receiving the last Receiver Reference Time Report Block from receiving the last Receiver Reference Time Report Block from
participant SSRC_n and sending this DLRR Report Block. If no participant SSRC_n and sending this DLRR Report Block. If a
Receiver Reference Time Report Block has been received yet from Receiver Reference Time Report Block has yet to be received
SSRC_n, the DLRR field is set to zero (or the DLRR is omitted from SSRC_n, the DLRR field is set to zero (or the DLRR is
entirely). Let SSRC_r denote the receiver issuing this DLRR omitted entirely). Let SSRC_r denote the receiver issuing this
Report Block. Participant SSRC_n can compute the round-trip DLRR Report Block. Participant SSRC_n can compute the round-
propagation delay to SSRC_r by recording the time A when this trip propagation delay to SSRC_r by recording the time A when
Receiver Timestamp Report Block is received. It calculates the this Receiver Timestamp Report Block is received. It
total round-trip time A-LRR using the last RR timestamp (LRR) calculates the total round-trip time A-LRR using the last RR
field, and then subtracting this field to leave the round-trip timestamp (LRR) field, and then subtracting this field to leave
propagation delay as A-LRR-DLRR. This is illustrated in [9, Fig. the round-trip propagation delay as A-LRR-DLRR. This is
2]. illustrated in [9, Fig. 2].
4.6 Statistics Summary Report Block 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 is not as finely grained as that
in the report blocks previously described. Information is recorded carried in the report blocks previously described. Information is
about lost packets, duplicate packets, jitter measurements, and TTL recorded about lost packets, duplicate packets, jitter measurements,
or Hop Limit values. Such information can be useful for network and TTL or Hop Limit values. Such information can be useful for
management. network management.
The report block contents are dependent upon a series of flags bit The report block contents are dependent upon a series of flag bits
carried in the first part of the header. Not all parameters need to carried in the first part of the header. Not all parameters need to
be reported in each block. Flags indicate which are and which are be reported in each block. Flags indicate which are and which are
not reported. The fields corresponding to unreported parameters MUST not reported. The fields corresponding to unreported parameters MUST
be present, but are set to zero. The receiver MUST ignore any be present, but are set to zero. The receiver MUST ignore any
Statistics Summary Report Block with a non-zero value in any field Statistics Summary Report Block with a non-zero value in any field
flagged as unreported. 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
skipping to change at page 23, line 47 skipping to change at page 23, line 49
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, mean_jitter, and Bit set to 1 if the min_jitter, max_jitter, mean_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 or Hop Limit flag (ToH): 2 bits TTL or Hop Limit flag (ToH): 2 bits
This field is set to 0 if none of the fields min_ttl_or_hl, This field is set to 0 if none of the fields min_ttl_or_hl,
max_ttl_or_hl, mean_ttl_or_hl, or dev_ttl_or_hl contain reports. max_ttl_or_hl, mean_ttl_or_hl, or dev_ttl_or_hl contain
If the field is non-zero then all of these fields contain reports. If the field is non-zero, then all of these fields
reports. The value 1 signifies that they report on IPv4 TTL contain reports. The value 1 signifies that they report on
values. The value 2 signifies that they report on IPv6 Hop IPv4 TTL values. The value 2 signifies that they report on
Limit values. This value 3 is undefined and MUST NOT be used. IPv6 Hop Limit values. The value 3 is undefined and MUST NOT
be used.
rsvd.: 3 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
such definition, the bits in this field MUST be set to zero and of such a definition, the bits in this field MUST be set to
MUST be ignored by the receiver. zero and 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 SSRC of source: 32 bits
As defined in Section 4.1. 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.
skipping to change at page 24, line 42 skipping to change at page 24, line 44
above sequence number interval. All jitter values are measured above sequence number interval. All jitter values are measured
as the difference between a packet's RTP timestamp and the as the difference between a packet's RTP timestamp and the
reporter's clock at the time of arrival, measured in the same reporter's clock at the time of arrival, measured in the same
units. units.
max_jitter: 32 bits max_jitter: 32 bits
The maximum relative transit time between two packets in the The maximum relative transit time between two packets in the
above sequence number interval. above sequence number interval.
mean_jitter: 32 bits mean_jitter: 32 bits
The mean relative transit time between each two packet series in The mean relative transit time between each two packet series
the above sequence number interval, rounded to the nearest value in the above sequence number interval, rounded to the nearest
expressible as an RTP timestamp. value expressible as an RTP timestamp.
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
two packet series in the above sequence number interval. each two packet series in the above sequence number interval.
min_ttl_or_hl: 8 bits min_ttl_or_hl: 8 bits
The minimum TTL or Hop Limit value of data packets in the The minimum TTL or Hop Limit value of data packets in the
sequence number range. sequence number range.
max_ttl_or_hl: 8 bits max_ttl_or_hl: 8 bits
The maximum TTL or Hop Limit value of data packets in the The maximum TTL or Hop Limit value of data packets in the
sequence number range. sequence number range.
mean_ttl_or_hl: 8 bits mean_ttl_or_hl: 8 bits
The mean TTL or Hop Limit value of data packets in the sequence The mean TTL or Hop Limit value of data packets in the sequence
number range, rounded to the nearest integer. number range, rounded to the nearest integer.
dev_ttl_or_hl: 8 bits dev_ttl_or_hl: 8 bits
The standard deviation of TTL or Hop Limit values of data The standard deviation of TTL or Hop Limit values of data
packets in the sequence number range. packets in the sequence number range.
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
desirable to consider the degree of burstiness of packet loss [14]. is desirable to consider the degree of burstiness of packet loss
Following a Gilbert-Elliott model [3], a period of time, bounded by [14]. Following a Gilbert-Elliott model [3], a period of time,
lost and/or discarded packets, with a high rate of losses and/or bounded by lost and/or discarded packets with a high rate of losses
discards is a "burst," and a period of time between two bursts is a and/or discards, is a "burst", and a period of time between two
"gap." Bursts correspond to periods of time during which the packet bursts is a "gap". Bursts correspond to periods of time during which
loss rate is high enough to produce noticeable degradation in audio the packet loss rate is high enough to produce noticeable degradation
quality. Gaps correspond to periods of time during which only in audio quality. Gaps correspond to periods of time during which
isolated lost packets may occur, and in general these can be masked only isolated lost packets may occur, and in general these can be
by packet loss concealment. Delay reports include the transit delay masked by packet loss concealment. Delay reports include the transit
between RTP end points and the VoIP end system processing delays, delay between RTP end points and the VoIP end system processing
both of which contribute to the user perceived delay. Additional delays, both of which contribute to the user perceived delay.
metrics include signal, echo, noise, and distortion levels. Call Additional metrics include signal, echo, noise, and distortion
quality metrics include R factors (as described by the E Model levels. Call quality metrics include R factors (as described by the
defined in [6,3]) and mean opinion scores (MOS scores). E Model defined in [6,3]) and mean opinion scores (MOS scores).
Implementations MUST provide values for all the fields defined here. Implementations MUST provide values for all the fields defined here.
For certain metrics, if the value is undefined or unknown, then the For certain metrics, if the value is undefined or unknown, then the
specified default or unknown field value MUST be provided. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 31 skipping to change at page 26, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RX config | reserved | JB nominal | | RX config | reserved | JB nominal |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JB maximum | JB abs max | | 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
such definition, the bits in this field MUST be set to zero and of such a definition, the bits in this field MUST be set to
MUST be ignored by the receiver. zero and MUST be ignored by the receiver.
block length: 16 bits block length: 16 bits
The constant 8, 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 SSRC of source: 32 bits
As defined in Section 4.1. 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
identify the source of quality degradation. These fields MUST be identify the source of quality degradation. These fields MUST be
populated, and MUST be set to zero if no packets have been received. populated, and MUST be set to zero if no packets have been received.
loss rate: 8 bits loss rate: 8 bits
The fraction of RTP data packets from the source lost since the The fraction of RTP data packets from the source lost since the
beginning of reception, expressed as a fixed point number with beginning of reception, expressed as a fixed point number with
the binary point at the left edge of the field. This value is the binary point at the left edge of the field. This value is
calculated by dividing the total number of packets lost (after calculated by dividing the total number of packets lost (after
the effects of applying any error protection such as FEC) by the the effects of applying any error protection such as FEC) by
total number of packets expected, multiplying the result of the the total number of packets expected, multiplying the result of
division by 256, limiting the maximum value to 255 (to avoid the division by 256, limiting the maximum value to 255 (to
overflow), and taking the integer part. The numbers of avoid overflow), and taking the integer part. The numbers of
duplicated packets and discarded packets do not enter into this duplicated packets and discarded packets do not enter into this
calculation. Since receivers cannot be required to maintain calculation. Since receivers cannot be required to maintain
unlimited buffers, a receiver MAY categorize late-arriving unlimited buffers, a receiver MAY categorize late-arriving
packets as lost. The degree of lateness that triggers a loss packets as lost. The degree of lateness that triggers a loss
SHOULD be significantly greater than that which triggers a SHOULD be significantly greater than that which triggers a
discard. discard.
discard rate: 8 bits discard rate: 8 bits
The fraction of RTP data packets from the source that have been The fraction of RTP data packets from the source that have been
discarded since the beginning of reception, due to late or early discarded since the beginning of reception, due to late or
arrival, under-run or overflow at the receiving jitter buffer. early arrival, under-run or overflow at the receiving jitter
This value is expressed as a fixed point number with the binary buffer. This value is expressed as a fixed point number with
point at the left edge of the field. It is calculated by the binary point at the left edge of the field. It is
dividing the total number of packets discarded (excluding calculated by dividing the total number of packets discarded
duplicate packet discards) by the total number of packets (excluding duplicate packet discards) by the total number of
expected, multiplying the result of the division by 256, packets expected, multiplying the result of the division by
limiting the maximum value to 255 (to avoid overflow), and 256, limiting the maximum value to 255 (to avoid overflow), and
taking the integer part. taking the integer part.
4.7.2 Burst Metrics 4.7.2. Burst Metrics
A burst is a period during which a high proportion of packets are A burst is a period during which a high proportion of packets are
either lost or discarded due to late arrival. A burst is defined, in either lost or discarded due to late arrival. A burst is defined, in
terms of a value Gmin, as a longest sequence that (a) starts with a terms of a value Gmin, as the longest sequence that (a) starts with a
lost or discarded packet, (b) does not contain any occurrences of lost or discarded packet, (b) does not contain any occurrences of
Gmin or more consecutive received (and not discarded) packets, and Gmin or more consecutively received (and not discarded) packets, and
(c) ends with a lost or discarded packet. (c) ends with a lost or discarded packet.
A gap, informally, is a period of low packet losses and/or discards. A gap, informally, is a period of low packet losses and/or discards.
Formally, a gap is defined as any of the following: (a) the period Formally, a gap is defined as any of the following: (a) the period
from the start of an RTP session to the receipt time of the last from the start of an RTP session to the receipt time of the last
received packet before the first burst, (b) the period from the end received packet before the first burst, (b) the period from the end
of the last burst to either the time of the report or the end of the of the last burst to either the time of the report or the end of the
RTP session, whichever comes first, or (c) the period of time between RTP session, whichever comes first, or (c) the period of time between
two bursts. two bursts.
For the purpose of determining if a lost or discarded packet near the For the purpose of determining if a lost or discarded packet near the
start or end of an RTP session is within a gap or a burst it is start or end of an RTP session is within a gap or a burst, it is
assumed that the RTP session is preceded and followed by at least assumed that the RTP session is preceded and followed by at least
Gmin received packets, and that the time of the report is followed by Gmin received packets, and that the time of the report is followed by
at least Gmin received packets. at least Gmin received packets.
A gap has the property that any lost or discarded packets within the A gap has the property that any lost or discarded packets within the
gap must be preceded and followed by at least Gmin packets that were gap must be preceded and followed by at least Gmin packets that were
received and not discarded. This gives a maximum loss/discard rate received and not discarded. This gives a maximum loss/discard rate
within a gap of: 1 / (Gmin + 1). within a gap of: 1 / (Gmin + 1).
A Gmin value of 16 is RECOMMENDED as it results in gap A Gmin value of 16 is RECOMMENDED, as it results in gap
characteristics that correspond to good quality (i.e. low packet loss characteristics that correspond to good quality (i.e., low packet
rate, a minimum distance of 16 received packets between lost packets) loss rate, a minimum distance of 16 received packets between lost
and hence differentiates nicely between good and poor quality packets), and hence differentiates nicely between good and poor
periods. quality periods.
For example, a 1 denotes a received, 0 a lost, and X a discarded For example, a 1 denotes a received packet, 0 a lost packet, and X a
packet in the following pattern covering 64 packets: discarded packet in the following pattern covering 64 packets:
11110111111111111111111X111X1011110111111111111111111X111111111 11110111111111111111111X111X1011110111111111111111111X111111111
|---------gap----------|--burst---|------------gap------------| |---------gap----------|--burst---|------------gap------------|
The burst consists of the twelve packets indicated above, starting at The burst consists of the twelve packets indicated above, starting at
a discarded packet and ending at a lost packet. The first gap starts a discarded packet and ending at a lost packet. The first gap starts
at the beginning of the session and the second gap ends at the time at the beginning of the session and the second gap ends at the time
of the report. of the report.
If the packet spacing is 10 ms and the Gmin value is the recommended If the packet spacing is 10 ms and the Gmin value is the recommended
skipping to change at page 28, line 46 skipping to change at page 29, line 4
This would result in reported values as follows (see field This would result in reported values as follows (see field
descriptions for semantics and details on how these are calculated): descriptions for semantics and details on how these are calculated):
loss rate 12, which corresponds to 5% loss rate 12, which corresponds to 5%
discard rate 12, which corresponds to 5% discard rate 12, which corresponds to 5%
burst density 84, which corresponds to 33% burst density 84, which corresponds to 33%
gap density 10, which corresponds to 4% gap density 10, which corresponds to 4%
burst duration 120, value in milliseconds burst duration 120, value in milliseconds
gap duration 520, value in milliseconds gap duration 520, value in milliseconds
burst density: 8 bits burst density: 8 bits
The fraction of RTP data packets within burst periods since the The fraction of RTP data packets within burst periods since the
beginning of reception that were either lost or discarded. This beginning of reception that were either lost or discarded.
value is expressed as a fixed point number with the binary point This value is expressed as a fixed point number with the binary
at the left edge of the field. It is calculated by dividing the point at the left edge of the field. It is calculated by
total number of packets lost or discarded (excluding duplicate dividing the total number of packets lost or discarded
packet discards) within burst periods by the total number of (excluding duplicate packet discards) within burst periods by
packets expected within the burst periods, multiplying the the total number of packets expected within the burst periods,
result of the division by 256, limiting the maximum value to 255 multiplying the result of the division by 256, limiting the
(to avoid overflow), and taking the integer part. This field maximum value to 255 (to avoid overflow), and taking the
MUST be populated and MUST be set to zero if no packets have integer part. This field MUST be populated and MUST be set to
been received. zero if no packets have been received.
gap density: 8 bits gap density: 8 bits
The fraction of RTP data packets within inter-burst gaps since The fraction of RTP data packets within inter-burst gaps since
the beginning of reception that were either lost or discarded. the beginning of reception that were either lost or discarded.
The value is expressed as a fixed point number with the binary The value is expressed as a fixed point number with the binary
point at the left edge of the field. It is calculated by point at the left edge of the field. It is calculated by
dividing the total number of packets lost or discarded dividing the total number of packets lost or discarded
(excluding duplicate packet discards) within gap periods by the (excluding duplicate packet discards) within gap periods by the
total number of packets expected within the gap periods, total number of packets expected within the gap periods,
multiplying the result of the division by 256, limiting the multiplying the result of the division by 256, limiting the
maximum value to 255 (to avoid overflow), and taking the integer maximum value to 255 (to avoid overflow), and taking the
part. This field MUST be populated and MUST be set to zero if integer part. This field MUST be populated and MUST be set to
no packets have been received. zero if no packets have been received.
burst duration: 16 bits burst duration: 16 bits
The mean duration, expressed in milliseconds, of the burst The mean duration, expressed in milliseconds, of the burst
periods that have occurred since the beginning of reception. periods that have occurred since the beginning of reception.
The duration of each period is calculated based upon the packets The duration of each period is calculated based upon the
that mark the beginning and end of that period. It is equal to packets that mark the beginning and end of that period. It is
the timestamp of the end packet, plus the duration of the end equal to the timestamp of the end packet, plus the duration of
packet, minus the timestamp of the beginning packet. If the the end packet, minus the timestamp of the beginning packet.
actual values are not available, estimated values MUST be used. If the actual values are not available, estimated values MUST
If there have been no burst periods, the burst duration value be used. If there have been no burst periods, the burst
MUST be zero. duration value MUST be zero.
gap duration: 16 bits gap duration: 16 bits
The mean duration, expressed in milliseconds, of the gap periods The mean duration, expressed in milliseconds, of the gap
that have occurred since the beginning of reception. The periods that have occurred since the beginning of reception.
duration of each period is calculated based upon the packet that The duration of each period is calculated based upon the packet
marks the end of the prior burst and the packet that marks the that marks the end of the prior burst and the packet that marks
beginning of the subsequent burst. It is equal to the timestamp the beginning of the subsequent burst. It is equal to the
of the subsequent burst packet, minus the timestamp of the prior timestamp of the subsequent burst packet, minus the timestamp
burst packet, plus the duration of the prior burst packet. If of the prior burst packet, plus the duration of the prior burst
the actual values are not available, estimated values MUST be packet. If the actual values are not available, estimated
used. In the case of a gap that occurs at the beginning of values MUST be used. In the case of a gap that occurs at the
reception, the sum of the timestamp of the prior burst packet beginning of reception, the sum of the timestamp of the prior
and the duration of the prior burst packet are replaced by the burst packet and the duration of the prior burst packet are
reception start time. In the case of a gap that occurs at the replaced by the reception start time. In the case of a gap
end of reception, the timestamp of the subsequent burst packet that occurs at the end of reception, the timestamp of the
is replaced by the reception end time. If there have been no subsequent burst packet is replaced by the reception end time.
gap periods, the gap duration value MUST be zero. If there have been no gap periods, the gap duration value MUST
be zero.
4.7.3 Delay Metrics 4.7.3. Delay Metrics
For the purpose of the following definitions, the RTP interface is For the purpose of the following definitions, the RTP interface is
the interface between the RTP instance and the voice application the interface between the RTP instance and the voice application
(i.e. FEC, de-interleaving, de-multiplexing, jitter buffer). For (i.e., FEC, de-interleaving, de-multiplexing, jitter buffer). For
example, the time delay due to RTP payload multiplexing would be example, the time delay due to RTP payload multiplexing would be
considered to be part of the voice application or end-system delay considered part of the voice application or end-system delay, whereas
whereas delay due to multiplexing RTP frames within a UDP frame would delay due to multiplexing RTP frames within a UDP frame would be
be considered part of the RTP reported delay. This distinction is 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 MAY be interfaces, expressed in milliseconds. This value MAY be
measured using RTCP, the DLRR method defined in Section 4.5 of measured using RTCP, the DLRR method defined in Section 4.5 of
this document, in which case it is necessary to convert the this document, where it is necessary to convert the units of
units of measurement from NTP timestamp values to milliseconds, measurement from NTP timestamp values to milliseconds, or other
or other approaches. If RTCP is used then the reported delay approaches. If RTCP is used, then the reported delay value is
value is the time of receipt of the most recent RTCP packet from the time of receipt of the most recent RTCP packet from source
source SSRC, minus the LSR (last SR) time reported in its SR SSRC, minus the LSR (last SR) time reported in its SR (Sender
(Sender Report), minus the DLSR (delay since last SR) reported Report), minus the DLSR (delay since last SR) reported in its
in its SR. A non-zero LSR value is required in order to SR. A non-zero LSR value is required in order to calculate
calculate round trip delay. A value of 0 is permissible, however round trip delay. A value of 0 is permissible; however, this
this field MUST be populated as soon as a delay estimate is field MUST be populated as soon as a delay estimate is
available. 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 sum of the milliseconds. End system delay is defined as the sum of the
total sample accumulation and encoding delay associated with the total sample accumulation and encoding delay associated with
sending direction and the jitter buffer, decoding, and playout the sending direction and the jitter buffer, decoding, and
buffer delay associated with the receiving direction. This playout buffer delay associated with the receiving direction.
delay MAY be estimated or measured. This value SHOULD be This delay MAY be estimated or measured. This value SHOULD be
provided in all VoIP metrics reports. If an implementation is provided in all VoIP metrics reports. If an implementation is
unable to provide the data, the value 0 MUST be used. unable to provide the data, the value 0 MUST be used.
Note that the one way symmetric VoIP segment delay may be calculated Note that the one way symmetric VoIP segment delay may be calculated
from the round trip and end system delays as follows. If the round from the round trip and end system delays is as follows; if the round
trip delay is denoted RTD and the end system delays associated with trip delay is denoted, RTD and the end system delays associated with
the two endpoints are ESD(A) and ESD(B) then: the two endpoints are ESD(A) and ESD(B) then:
one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2 one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2
4.7.4 Signal Related Metrics 4.7.4. Signal Related Metrics
The following metrics are intended to provide real time information The following metrics are intended to provide real time information
related to the non-packet elements of the voice over IP system to related to the non-packet elements of the voice over IP system to
assist with the identification of problems affecting call quality. assist with the identification of problems affecting call quality.
The values identified below must be determined for the received audio The values identified below must be determined for the received audio
signal. The information required to populate these fields may not be signal. The information required to populate these fields may not be
available in all systems, although it is strongly recommended that available in all systems, although it is strongly recommended that
this data SHOULD be provided to support problem diagnosis. this data SHOULD be provided to support problem diagnosis.
signal level: 8 bits signal 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 0 dBm0 reference [10], expressed in decibels signal level to a 0 dBm0 reference [10], expressed in decibels
as a signed integer in two's complement form. This is measured as a signed integer in two's complement form. This is measured
only for packets containing speech energy. The intent of this only for packets containing speech energy. The intent of this
metric is not to provide a precise measurement of the signal 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. level may be excessively high or low.
signal level = 10 Log10 ( 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 generally be 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 0 dBm0 reference, expressed in background noise level to a 0 dBm0 reference, expressed in
decibels as a signed integer in two's complement form. decibels as a signed integer in two's complement 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 value may be measured directly by The residual echo return loss value may be measured directly by
the VoIP end system's echo canceller or may be estimated by the VoIP end system's echo canceller or may be estimated by
adding the echo return loss (ERL) and echo return loss adding the echo return loss (ERL) and echo return loss
enhancement (ERLE) values reported by the echo canceller. enhancement (ERLE) values reported by the echo canceller.
RERL(dB) = ERL (dB) + ERLE (dB) RERL(dB) = ERL (dB) + ERLE (dB)
In the case of a VoIP gateway, the source of echo is typically
In the case of a VoIP gateway the source of echo is typically
line echo that occurs at 2-4 wire conversion points in the line echo that occurs at 2-4 wire conversion points in the
network. This can be in the 8-12 dB range. A line echo network. This can be in the 8-12 dB range. A line echo
canceler can provide an ERLE of 30 dB or more and hence reduce canceler can provide an ERLE of 30 dB or more and hence reduce
this to 40-50 dB. In the case of an IP phone this could be this to 40-50 dB. In the case of an IP phone, this could be
acoustic coupling between handset speaker and microphone or acoustic coupling between handset speaker and microphone or
residual acoustic echo from speakerphone operation, and may more residual acoustic echo from speakerphone operation, and may
correctly be termed terminal coupling loss (TCL). A typical more correctly be termed terminal coupling loss (TCL). A
handset would result in 40-50 dB of echo loss due to acoustic typical handset would result in 40-50 dB of echo loss due to
feedback. acoustic feedback.
Examples: Examples:
- IP gateway connected to circuit switched network with 2 wire - IP gateway connected to circuit switched network with 2 wire
loop. Without echo cancellation, typical 2-4 wire converter ERL loop. Without echo cancellation, typical 2-4 wire converter
of 12 dB. RERL = ERL + ERLE = 12 + 0 = 12 dB. ERL of 12 dB. RERL = ERL + ERLE = 12 + 0 = 12 dB.
- IP gateway connected to circuit switched network with 2 wire - IP gateway connected to circuit switched network with 2 wire
loop. With echo canceler that improves echo by 30 dB. RERL = loop. With echo canceler that improves echo by 30 dB.
ERL + ERLE = 12 + 30 = 42 dB. RERL = ERL + ERLE = 12 + 30 = 42 dB.
- IP phone with conventional handset. Acoustic coupling from - IP phone with conventional handset. Acoustic coupling from
handset speaker to microphone (terminal coupling loss) is handset speaker to microphone (terminal coupling loss) is
typically 40 dB. RERL = TCL = 40 dB. typically 40 dB. RERL = TCL = 40 dB.
If we denote the local end of the VoIP path as A and the remote If we denote the local end of the VoIP path as A and the remote
end as B and if the sender loudness rating (SLR) and receiver end as B, and if the sender loudness rating (SLR) and receiver
loudness rating (RLR) are known for A (default values 8 dB and 2 loudness rating (RLR) are known for A (default values 8 dB and
dB respectively), then the echo loudness level at end A (talker 2 dB respectively), then the echo loudness level at end A
echo loudness rating or TELR) is given by: (talker echo loudness rating or TELR) is given by:
TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A) TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)
TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B) TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)
Hence in order to incorporate echo into a voice quality estimate Hence, in order to incorporate echo into a voice quality
at the A end of a VoIP connection it is desirable to send the estimate at the A end of a VoIP connection, it is desirable to
ERL + ERLE value from B to A using a format such as RTCP XR. send the ERL + ERLE value from B to A using a format such as
RTCP XR.
Echo related information may not be available in all VoIP end Echo related information may not be available in all VoIP end
systems. As echo does have a significant effect on systems. As echo does have a significant effect on
conversational quality it is recommended that estimated values conversational quality, it is recommended that estimated values
for echo return loss and terminal coupling loss be provided (if for echo return loss and terminal coupling loss be provided (if
sensible estimates can be reasonably determined). sensible estimates can be reasonably determined).
Typical values for end systems are given below to provide Typical values for end systems are given below to provide
guidance: guidance:
- IP Phone with handset: typically 45 dB. - IP Phone with handset: typically 45 dB.
- PC softphone or speakerphone: extremely variable, consider - PC softphone or speakerphone: extremely variable, consider
reporting "undefined" (127). reporting "undefined" (127).
- IP gateway with line echo canceller: typically has ERL and - IP gateway with line echo canceller: typically has ERL and
ERLE available. ERLE available.
- IP gateway without line echo canceller: frequently a source of - IP gateway without line echo canceller: frequently a source
echo related problems, consider reporting either a low value (12 of echo related problems, consider reporting either a low
dB) or "undefined" (127). value (12 dB) or "undefined" (127).
Gmin Gmin
See Configuration Parameters (Section 4.7.6, below). See Configuration Parameters (Section 4.7.6, below).
4.7.5 Call Quality or Transmission Quality Metrics 4.7.5. Call Quality or Transmission Quality Metrics
The following metrics are direct measures of the call quality or The following metrics are direct measures of the call quality or
transmission quality, and incorporate the effects of codec type, transmission quality, and incorporate the effects of codec type,
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, they SHOULD be provided in
support problem diagnosis. order to support problem diagnosis.
R factor: 8 bits R factor: 8 bits
The R factor is a voice quality metric describing the segment of The R factor is a voice quality metric describing the segment
the call that is carried over this RTP session. It is expressed of the call that is carried over this RTP session. It is
as an integer in the range 0 to 100, with a value of 94 expressed as an integer in the range 0 to 100, with a value of
corresponding to "toll quality" and values of 50 or less 94 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 [6] and ETSI TS effects of delay, consistent with ITU-T G.107 [6] and ETSI TS
101 329-5 [3]. 101 329-5 [3].
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
Values other than 127 and the valid range defined above MUST not Values other than 127 and the valid range defined above MUST
be sent and MUST be ignored by the receiving system. not be sent and MUST be ignored by the receiving system.
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.
values are interpreted in the same manner as for the RTP R Its 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 [6] and ETSI TS 101 329-5 delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5
[3], 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.
Values other than 127 and the valid range defined above MUST not Values other than 127 and the valid range defined above MUST
be sent and MUST be ignored by the receiving system. not be sent and MUST be ignored by the receiving system.
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
The estimated mean opinion score for listening quality (MOS-LQ) The estimated mean opinion score for listening quality (MOS-LQ)
is a voice quality metric on a scale from 1 to 5, in which 5 is a voice quality metric on a scale from 1 to 5, in which 5
represents excellent and 1 represents unacceptable. This metric represents excellent and 1 represents unacceptable. This
is defined as not including the effects of delay and can be metric is defined as not including the effects of delay and can
compared to MOS scores obtained from listening quality (ACR) be compared to MOS scores obtained from listening quality (ACR)
tests. It is expressed as an integer in the range 10 to 50, tests. It is expressed as an integer in the range 10 to 50,
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.
Values other than 127 and the valid range defined above MUST not Values other than 127 and the valid range defined above MUST
be sent and MUST be ignored by the receiving system. not be sent and MUST be ignored by the receiving system.
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
to ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an estimated according to ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an
MOS using the equation specified in G.107. It is expressed as estimated MOS using the equation specified in G.107. It is
an integer in the range 10 to 50, corresponding to MOS x 10, as expressed as an integer in the range 10 to 50, corresponding to
for MOS-LQ. MOS x 10, as for MOS-LQ.
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
Values other than 127 and the valid range defined above MUST not Values other than 127 and the valid range defined above MUST
be sent and MUST be ignored by the receiving system. not be sent and MUST be ignored by the receiving system.
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 part of a burst or gap in
later reports. ETSI TS 101 329-5 [3] 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 and MUST remain constant across not be zero, MUST be provided, and MUST remain constant across
VoIP Metrics report blocks for the duration of the RTP session. VoIP Metrics report blocks for the duration of the RTP session.
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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|PLC|JBA|JB rate| |PLC|JBA|JB rate|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
packet loss concealment (PLC): 2 bits packet loss concealment (PLC): 2 bits
Standard (11) / enhanced (10) / disabled (01) / unspecified Standard (11) / enhanced (10) / disabled (01) / unspecified
(00). When PLC = 11 then a simple replay or interpolation (00). When PLC = 11, then a simple replay or interpolation
algorithm is being used to fill-in the missing packet; this algorithm is being used to fill-in the missing packet; this
approach is typically able to conceal isolated lost packets approach is typically able to conceal isolated lost packets at
at low packet loss rates. When PLC = 10 then an enhanced low packet loss rates. When PLC = 10, then an enhanced
interpolation algorithm is being used; algorithms of this interpolation algorithm is being used; algorithms of this type
type are able to conceal high packet loss rates are able to conceal high packet loss rates effectively. When
effectively. When PLC = 01 then silence is being inserted PLC = 01, then silence is being inserted in place of lost
in place of lost packets. When PLC = 00 then no packets. When PLC = 00, then no information is available
information is available concerning the use of PLC, however concerning the use of PLC; however, for some codecs this may be
for some codecs this may be inferred. inferred.
jitter buffer adaptive (JBA): 2 bits jitter buffer adaptive (JBA): 2 bits
Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown
(00). When the jitter buffer is adaptive then its size is (00). When the jitter buffer is adaptive, then its size is
being dynamically adjusted to deal with varying levels of being dynamically adjusted to deal with varying levels of
jitter. When non-adaptive, the jitter buffer size is jitter. When non-adaptive, the jitter buffer size is
maintained at a fixed level. When either adaptive or non- maintained at a fixed level. When either adaptive or non-
adaptive modes are specified then the jitter buffer size adaptive modes are specified, then the jitter buffer size
parameters below MUST be specified. parameters below MUST be specified.
jitter buffer rate (JB rate): 4 bits jitter buffer rate (JB rate): 4 bits
J = adjustment rate (0-15). This represents the J = adjustment rate (0-15). This represents the implementation
implementation specific adjustment rate of a jitter buffer specific adjustment rate of a jitter buffer in adaptive mode.
in adaptive mode. This parameter is defined in terms of the This parameter is defined in terms of the approximate time
approximate time taken to fully adjust to a step change in taken to fully adjust to a step change in peak to peak jitter
peak to peak jitter from 30 ms to 100 ms such that: 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 an adaptive jitter buffer and may
and may be estimated. A value of 0 indicates that the be estimated. A value of 0 indicates that the adjustment time
adjustment time is unknown for this implementation. is unknown for this implementation.
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
such definition, the bits in this field MUST be set to zero and of such a definition, the bits in this field MUST be set to
MUST be ignored by the receiver. zero and MUST be ignored by the receiver.
4.7.7. Jitter Buffer Parameters
4.7.7 Jitter Buffer Parameters
The values reported in these fields SHOULD be the most recently The values reported in these fields SHOULD be the most recently
obtained values at the time of reporting. obtained values at the time of reporting.
jitter buffer nominal delay (JB nominal): 16 bits jitter buffer nominal delay (JB nominal): 16 bits
This is the current nominal jitter buffer delay in milliseconds, This is the current nominal jitter buffer delay in
which corresponds to the nominal jitter buffer delay for packets milliseconds, which corresponds to the nominal jitter buffer
that arrive exactly on time. This parameter MUST be provided delay for packets that arrive exactly on time. This parameter
for both fixed and adaptive jitter buffer implementations. MUST be provided for both fixed and adaptive jitter buffer
implementations.
jitter buffer maximum delay (JB maximum): 16 bits jitter buffer maximum delay (JB maximum): 16 bits
This is the current maximum jitter buffer delay in milliseconds This is the current maximum jitter buffer delay in milliseconds
which corresponds to the earliest arriving packet that would not which corresponds to the earliest arriving packet that would
be discarded. In simple queue implementations this may not be discarded. In simple queue implementations this may
correspond to the nominal size. In adaptive jitter buffer correspond to the nominal size. In adaptive jitter buffer
implementations this value may dynamically vary up to JB abs max implementations, this value may dynamically vary up to JB abs
(see below). This parameter MUST be provided for both fixed and max (see below). This parameter MUST be provided for both
adaptive jitter buffer implementations. fixed and adaptive jitter buffer implementations.
jitter buffer absolute maximum delay (JB abs max): 16 bits jitter buffer absolute maximum delay (JB abs max): 16 bits
This is the absolute maximum delay in milliseconds that the This is the absolute maximum delay in milliseconds that the
adaptive jitter buffer can reach under worst case conditions. adaptive jitter buffer can reach under worst case conditions.
If this value exceeds 65535 milliseconds then this field SHALL If this value exceeds 65535 milliseconds, then this field SHALL
convey the value 65535. This parameter MUST be provided for convey the value 65535. This parameter MUST be provided for
adaptive jitter buffer implementations and its value MUST be set adaptive jitter buffer implementations and its value MUST be
to JB maximum for fixed jitter buffer implementations. set to JB maximum for fixed jitter buffer implementations.
5. SDP Signaling 5. SDP Signaling
This section defines Session Description Protocol (SDP) [4] signaling This section defines Session Description Protocol (SDP) [4] signaling
for XR blocks that can be employed by applications that utilize SDP. for XR blocks that can be employed by applications that utilize SDP.
This signaling is defined to be used either by applications that This signaling is defined to be used either by applications that
implement the SDP Offer/Answer model [8] or by applications that use implement the SDP Offer/Answer model [8] or by applications that use
SDP to describe media and transport configurations in connection with SDP to describe media and transport configurations in connection
such protocols as the Session Announcement Protocol (SAP) [15] or the with such protocols as the Session Announcement Protocol (SAP) [15]
Real Time Streaming Protocol (RTSP) [17]. There exist other or the Real Time Streaming Protocol (RTSP) [17]. There exist other
potential signaling methods, which are not defined here. potential signaling methods that are not defined here.
The XR blocks MAY be used without prior signaling. This is The XR blocks MAY be used without prior signaling. This is
consistent with the rules governing other RTCP packet types, as consistent with the rules governing other RTCP packet types, as
described in [9]. An example in which signaling would not be used is described in [9]. An example in which signaling would not be used is
an application that always requires the use of one or more XR blocks. an application that always requires the use of one or more XR blocks.
However for applications that are configured at session initiation, However, for applications that are configured at session initiation,
the use of some type of signaling is recommended. the use of some type of signaling is recommended.
Note that, although the use of SDP signaling for XR blocks may be 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 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 is used in an environment where XR blocks are only implemented by
some fraction of the participants, the ones not implementing the XR some fraction of the participants, the ones not implementing the XR
blocks will ignore the SDP attribute. blocks will ignore the SDP attribute.
5.1 The SDP Attribute 5.1. The SDP Attribute
This section defines one new SDP attribute "rtcp-xr" that can be used 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 to signal participants in a media session that they should use the
specified XR blocks. This attribute can be easily extended in the specified XR blocks. This attribute can be easily extended in the
future with new parameters to cover any new report blocks. future with new parameters to cover any new report blocks.
The RTCP XR blocks SDP attribute is defined below in Augmented 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 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 attribute. When specified at session level, it applies to all media
level blocks in the session. Any media level specification MUST level blocks in the session. Any media level specification MUST
skipping to change at page 38, line 49 skipping to change at page 39, line 15
MAY specify an integer value. This value indicates the largest size MAY specify an integer value. This value indicates the largest size
the whole report block SHOULD have in octets. This shall be seen as 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 an indication that thinning shall be applied if necessary to meet the
target size. target size.
The "stat-summary" parameter contains a list indicating which fields The "stat-summary" parameter contains a list indicating which fields
SHOULD be included in the Statistics Summary report blocks that are SHOULD be included in the Statistics Summary report blocks that are
sent. The list is a comma separated list, containing one or more sent. The list is a comma separated list, containing one or more
field indicators. The space character (0x20) SHALL NOT be present field indicators. The space character (0x20) SHALL NOT be present
within the list. Field indicators represent the flags defined in within the list. Field indicators represent the flags defined in
section 4.6. The field indicators and their respective flags are as Section 4.6. The field indicators and their respective flags are as
follows: follows:
Indicator Flag Indicator Flag
--------- --------------------------- --------- ---------------------------
loss loss report flag (L) loss loss report flag (L)
dup duplicate report flag (D) dup duplicate report flag (D)
jitt jitter flag (J) jitt jitter flag (J)
TTL TTL or Hop Limit flag (ToH) TTL TTL or Hop Limit flag (ToH)
HL TTL or Hop Limit flag (ToH) HL TTL or Hop Limit flag (ToH)
skipping to change at page 39, line 34 skipping to change at page 39, line 47
trigger this by sending an initiator block. trigger this by sending an initiator block.
The collaborative category currently consists only of one The collaborative category currently consists only of one
functionality, namely the RTT measurement mechanism for RTP data functionality, namely the RTT measurement mechanism for RTP data
receivers. The collective functionality of the Receiver Reference receivers. The collective functionality of the Receiver Reference
Time Report Block and DLRR Report Block is represented by the "rcvr- Time Report Block and DLRR Report Block is represented by the "rcvr-
rtt" parameter. This parameter takes as its arguments a mode value rtt" parameter. This parameter takes as its arguments a mode value
and, optionally, a maximum size for the DLRR report block. The mode and, optionally, a maximum size for the DLRR report block. The mode
value "all" indicates that both RTP data senders and data receivers value "all" indicates that both RTP data senders and data receivers
MAY send DLRR blocks, while the mode value "sender" indicates that MAY send DLRR blocks, while the mode value "sender" indicates that
only active RTP senders MAY send DLRR blocks, i.e. non RTP senders 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, 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 any DLRR Report Blocks that are sent SHALL NOT exceed the specified
size. If size limitations mean that a DLRR Report Block sender size. If size limitations mean that a DLRR Report Block sender
cannot report in one block upon all participants from which it has cannot report in one block upon all participants from which it has
received a Receiver Reference Time Report Block then it SHOULD report received a Receiver Reference Time Report Block then it SHOULD report
on participants in a round robin fashion across several report on participants in a round robin fashion across several report
intervals. intervals.
The "rtcp-xr" attributes parameter list MAY be empty. This is useful The "rtcp-xr" attributes parameter list MAY be empty. This is useful
in cases in which an application needs to signal that it understands in cases in which an application needs to signal that it understands
skipping to change at page 40, line 18 skipping to change at page 40, line 31
tells a participant that it SHOULD NOT send any XR blocks at all. tells a participant that it SHOULD NOT send any XR blocks at all.
The purpose is to conserve bandwidth. This is especially important The purpose is to conserve bandwidth. This is especially important
when collaborative parameters are applied to a large multicast group: when collaborative parameters are applied to a large multicast group:
the sending of an initiator block could potentially trigger responses the sending of an initiator block could potentially trigger responses
from all participants. There are, however, contexts in which it from all participants. There are, however, contexts in which it
makes sense to send an XR block in the absence of a parameter makes sense to send an XR block in the absence of a parameter
signaling its use. For instance, an application might be designed so signaling its use. For instance, an application might be designed so
as to send certain report blocks without negotiation, while using SDP as to send certain report blocks without negotiation, while using SDP
signaling to negotiate the use of other blocks. signaling to negotiate the use of other blocks.
5.2 Usage in Offer/Answer 5.2. Usage in Offer/Answer
In the Offer/Answer context [8], the interpretation of SDP signaling In the Offer/Answer context [8], the interpretation of SDP signaling
for XR packets depends upon the direction attribute that is signaled: for XR packets depends upon the direction attribute that is signaled:
"recvonly", "sendrecv", or "sendonly" [4]. If no direction attribute "recvonly", "sendrecv", or "sendonly" [4]. If no direction attribute
is supplied then "sendrecv" is assumed. This section applies only to is supplied, then "sendrecv" is assumed. This section applies only
unicast media streams, except where noted. Discussion of unilateral to unicast media streams, except where noted. Discussion of
parameters is followed by discussion of collaborative parameters in unilateral parameters is followed by discussion of collaborative
this section. parameters in this section.
For "sendonly" and "sendrecv" media stream offers that specify For "sendonly" and "sendrecv" media stream offers that specify
unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send
the corresponding XR blocks. For "sendrecv" offers, the answerer MAY the corresponding XR blocks. For "sendrecv" offers, the answerer MAY
include the "rtcp-xr" attribute in its response, and specify any include the "rtcp-xr" attribute in its response, and specify any
unilateral parameters in order to request that the offerer send the unilateral parameters in order to request that the offerer send the
corresponding XR blocks. The offerer SHOULD send these blocks. corresponding XR blocks. The offerer SHOULD send these blocks.
For "recvonly" media stream offers, the offerer's use of the "rtcp- For "recvonly" media stream offers, the offerer's use of the "rtcp-
xr" attribute in connection with unilateral parameters indicates that xr" attribute in connection with unilateral parameters indicates that
skipping to change at page 41, line 8 skipping to change at page 41, line 23
capable of receiving the corresponding initiator and replying with capable of receiving the corresponding initiator and replying with
the appropriate responses. For example, an offer that specifies the the appropriate responses. For example, an offer that specifies the
"rcvr-rtt" parameter means that the offerer is prepared to receive "rcvr-rtt" parameter means that the offerer is prepared to receive
Receiver Reference Time Report Blocks and to send DLRR Report Blocks. Receiver Reference Time Report Blocks and to send DLRR Report Blocks.
An offer of a collaborative parameter means that the answerer MAY An offer of a collaborative parameter means that the answerer MAY
send the initiator, and, having received the initiator, the offerer send the initiator, and, having received the initiator, the offerer
SHOULD send the responses. SHOULD send the responses.
There are exceptions to the rule that an offerer of a collaborative There are exceptions to the rule that an offerer of a collaborative
parameter should send responses. For instance, the collaborative parameter should send responses. For instance, the collaborative
parameter might specify a mode that excludes the offerer. Or parameter might specify a mode that excludes the offerer; or
congestion control or maximum transmission unit considerations might congestion control or maximum transmission unit considerations might
militate against the offerer's response. militate against the offerer's response.
By including a collaborative parameter in its answer, the answerer By including a collaborative parameter in its answer, the answerer
declares its ability to receive initiators and to send responses. declares its ability to receive initiators and to send responses.
The offerer MAY then send initiators, to which the answerer SHOULD The offerer MAY then send initiators, to which the answerer SHOULD
reply with responses. As for the offer of a collaborative parameter, reply with responses. As for the offer of a collaborative parameter,
there are exceptions to the rule that the answerer should reply. there are exceptions to the rule that the answerer should reply.
When making an SDP offer of a collaborative parameter for a multicast When making an SDP offer of a collaborative parameter for a multicast
skipping to change at page 41, line 34 skipping to change at page 41, line 49
indicates that a specified participant MAY send an initiator block. indicates that a specified participant MAY send an initiator block.
An SDP answer for a multicast media stream SHOULD include all An SDP answer for a multicast media stream SHOULD include all
collaborative parameters that are present in the offer and that are collaborative parameters that are present in the offer and that are
supported by the answerer. It SHOULD NOT include any collaborative supported by the answerer. It SHOULD NOT include any collaborative
parameter that is absent from the offer. parameter that is absent from the offer.
If a participant receives an SDP offer and understands the "rtcp-xr" If a participant receives an SDP offer and understands the "rtcp-xr"
attribute but does not wish to implement XR functionality offered, attribute but does not wish to implement XR functionality offered,
its answer SHOULD include an "rtcp-xr" attribute without parameters. its answer SHOULD include an "rtcp-xr" attribute without parameters.
By doing so, the party declares that at a minimum that it is capable By doing so, the party declares that, at a minimum, is capable of
of understanding the signaling. understanding the signaling.
5.3 Usage Outside of Offer/Answer 5.3. Usage Outside of Offer/Answer
SDP can be employed outside of the Offer/Answer context, for instance SDP can be employed outside of the Offer/Answer context, for instance
for multimedia sessions that are announced through the Session for multimedia sessions that are announced through the Session
Announcement Protocol (SAP) [15], or streamed through the Real Time Announcement Protocol (SAP) [15], or streamed through the Real Time
Streaming Protocol (RTSP) [17]. The signaling model is simpler, as Streaming Protocol (RTSP) [17]. The signaling model is simpler, as
the sender does not negotiate parameters, but the functionality that the sender does not negotiate parameters, but the functionality
is expected from specifying the "rtcp-xr" attribute is the same as in expected from specifying the "rtcp-xr" attribute is the same as in
Offer/Answer. Offer/Answer.
When a unilateral parameter is specified for the "rtcp-xr" attribute When a unilateral parameter is specified for the "rtcp-xr" attribute
associated with a media stream, the receiver of that stream SHOULD associated with a media stream, the receiver of that stream SHOULD
send the corresponding XR block. When a collaborative parameter is send the corresponding XR block. When a collaborative parameter is
specified, only the participants indicated by the mode value in the specified, only the participants indicated by the mode value in the
collaborative parameter are concerned. Each such participant that collaborative parameter are concerned. Each such participant that
receives an initiator block SHOULD send the corresponding response receives an initiator block SHOULD send the corresponding response
block. Each such participant MAY also send initiator blocks. block. Each such participant MAY also send initiator blocks.
skipping to change at page 42, line 23 skipping to change at page 42, line 39
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.
Further, this document defines a new SDP attribute, "rtcp-xr", within Further, this document defines a new SDP attribute, "rtcp-xr", within
the existing IANA registry of SDP Parameters. It defines a new IANA the existing IANA registry of SDP Parameters. It defines a new IANA
registry, the registry of RTCP XR SDP Parameters, and an initial set registry, the registry of RTCP XR SDP Parameters, and an initial set
of six parameters, and describes how additional parameters are to be of six parameters, and describes how additional parameters are to be
allocated. allocated.
6.1 XR Packet Type 6.1. XR Packet Type
The XR packet type defined by this document is registered with the 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 IANA as packet type 207 in the registry of RTP RTCP Control Packet
types (PT). types (PT).
6.2 RTCP XR Block Type Registry 6.2. RTCP XR Block Type Registry
This document creates an IANA registry called the RTCP XR Block Type This document creates an IANA registry called the RTCP XR Block Type
Registry to cover the name space of the Extended Report block type Registry to cover the name space of the Extended Report block type
(BT) field specified in Section 3. The BT field contains eight bits, (BT) field specified in Section 3. The BT field contains eight bits,
allowing 256 values. The RTCP XR Block Type Registry is to be allowing 256 values. The RTCP XR Block Type Registry is to be
managed by the IANA according to the Specification Required policy of managed by the IANA according to the Specification Required policy of
RFC 2434 [7]. Future specifications SHOULD attribute block type RFC 2434 [7]. Future specifications SHOULD attribute block type
values in strict numeric order following the values attributed in values in strict numeric order following the values attributed in
this document: this document:
skipping to change at page 43, line 4 skipping to change at page 43, line 17
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 Packet Receipt Times Report Block 3 Packet Receipt Times Report Block
4 Receiver Reference Time Report Block 4 Receiver Reference Time Report Block
5 DLRR Report Block 5 DLRR Report Block
6 Statistics Summary Report Block 6 Statistics Summary Report Block
7 VoIP Metrics Report Block 7 VoIP Metrics Report Block
The BT value 255 is reserved for future extensions. The BT value 255 is reserved for future extensions.
Furthermore, future specifications SHOULD avoid the value 0. Doing Furthermore, future specifications SHOULD avoid the value 0. Doing
so facilitates packet validity checking, since an all-zeros field so facilitates packet validity checking, since an all-zeros field
might commonly be found in an ill-formed packet. might commonly be found in an ill-formed packet.
Any registration MUST contain the following information: Any registration MUST contain the following information:
- Contact information of the one doing the registration, including at - Contact information of the one doing the registration, including
least name, address, and email. at least name, address, and email.
- The format of the block type being registered, consistent with the - The format of the block type being registered, consistent with the
extended report block format described in Section 3. extended report block format described in Section 3.
- A description of what the block type represents and how it shall be - A description of what the block type represents and how it shall
interpreted, detailing this information for each of its fields. be interpreted, detailing this information for each of its fields.
6.3 The "rtcp-xr" SDP Attribute 6.3. The "rtcp-xr" SDP Attribute
This SDP attribute "rtcp-xr" defined by this document is registered The SDP attribute "rtcp-xr" defined by this document is registered
with the IANA registry of SDP Parameters as follows: with the IANA registry of SDP Parameters as follows:
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: rtcp-xr Attribute name: rtcp-xr
Long form: RTP Control Protocol Extended Report Parameters Long form: RTP Control Protocol Extended Report Parameters
Type of name: att-field Type of name: att-field
Type of attribute: session and media level Type of attribute: session and media level
Subject to charset: no Subject to charset: no
Purpose: see Section 5 of this document Purpose: see Section 5 of this document
skipping to change at page 43, line 48 skipping to change at page 44, line 15
registry for these parameters is required. This document creates an registry for these parameters is required. This document creates an
IANA registry called the RTCP XR SDP Parameters Registry. It IANA registry called the RTCP XR SDP Parameters Registry. It
contains the six parameters defined in Section 5.1: "pkt-loss-rle", contains the six parameters defined in Section 5.1: "pkt-loss-rle",
"pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and "pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and
"recv-rtt". "recv-rtt".
Additional parameters are to be added to this registry in accordance Additional parameters are to be added to this registry in accordance
with the Specification Required policy of RFC 2434 [7]. Any with the Specification Required policy of RFC 2434 [7]. Any
registration MUST contain the following information: registration MUST contain the following information:
- Contact information of the one doing the registration, including at - Contact information of the one doing the registration, including
least name, address, and email. at least name, address, and email.
- An Augmented Backus-Naur Form (ABNF) [2] definition of the - An Augmented Backus-Naur Form (ABNF) [2] definition of the
parameter, in accordance with the "format-ext" definition of parameter, in accordance with the "format-ext" definition of
Section 5.1. Section 5.1.
- A description of what the parameter represents and how it shall be - A description of what the parameter represents and how it shall be
interpreted, both normally and in Offer/Answer. interpreted, both normally and in Offer/Answer.
7. Security Considerations 7. Security Considerations
skipping to change at page 44, line 33 skipping to change at page 44, line 48
The per-packet information contained in Loss RLE, Duplicate RLE, and The per-packet information contained in Loss RLE, Duplicate RLE, and
Packet Receipt Times Report Blocks facilitates multicast inference of Packet Receipt Times Report Blocks facilitates multicast inference of
network characteristics (MINC) [11]. Such inference can reveal the network characteristics (MINC) [11]. Such inference can reveal the
gross topology of a multicast distribution tree, as well as gross topology of a multicast distribution tree, as well as
parameters, such as the loss rates and delays, along paths between parameters, such as the loss rates and delays, along paths between
branching points in that tree. Such information might be considered branching points in that tree. Such information might be considered
sensitive to autonomous system administrators. sensitive to autonomous system administrators.
The VoIP Metrics Report Block provides information on the quality of The VoIP Metrics Report Block provides information on the quality of
ongoing voice calls. Though such information might be carried in ongoing voice calls. Though such information might be carried in an
application specific format in standard RTP sessions, making it application specific format in standard RTP sessions, making it
available in a standard format here makes it more available to available in a standard format here makes it more available to
potential eavesdroppers. potential eavesdroppers.
No new mechanisms are introduced in this document to ensure No new mechanisms are introduced in this document to ensure
confidentiality. Encryption procedures, such as those being confidentiality. Encryption procedures, such as those being
suggested for a Secure RTCP (SRTCP) [12] at the time that this suggested for a Secure RTCP (SRTCP) [12] at the time that this
document was written, can be used when confidentiality is a concern document was written, can be used when confidentiality is a concern
to end hosts. Given that RTCP traffic can be encrypted by the end to end hosts. Given that RTCP traffic can be encrypted by the end
hosts, autonomous systems must be prepared for the fact that certain hosts, autonomous systems must be prepared for the fact that certain
skipping to change at page 45, line 23 skipping to change at page 46, line 7
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 place an upper limit on the size of the XR report applications SHOULD place an upper limit on the size of the XR report
blocks they employ. The "thinning" techniques described in Section blocks they employ. The "thinning" techniques described in Section
4.1 permit the packet-by-packet report blocks to adhere to a 4.1 permit the packet-by-packet report blocks to adhere to a
predefined size limit. 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 is the algorithm suggested by Section 4.1 for keeping track of
sequence numbers from a given sender. It implements the accounting the sequence numbers from a given sender. It implements the
practice required for the generation of Loss RLE Report Blocks. accounting 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
them into a 32 bit sequence number space. The first packet received them into a 32 bit sequence number space. The first packet received
from a source is considered to have arrived roughly in the middle of from a source is considered to have arrived roughly in the middle of
that space. Each packet that follows is placed either ahead or that space. Each packet that follows is placed either ahead of or
behind the prior one in this 32 bit space, depending upon which behind the prior one in this 32 bit space, depending upon which
choice would place it closer (or, in the event of a tie, which choice choice would place it closer (or, in the event of a tie, which choice
would not require a rollover in the 16 bit sequence number). would not require a rollover in the 16 bit sequence number).
// The reference sequence number is an extended sequence number // The reference sequence number is an extended sequence number
// that serves as the basis for determining whether a new 16 bit // that serves as the basis for determining whether a new 16 bit
// sequence number comes earlier or later in the 32 bit sequence // sequence number comes earlier or later in the 32 bit sequence
// space. // space.
u_int32 _src_ref_seq; u_int32 _src_ref_seq;
bool _uninitialized_src_ref_seq; bool _uninitialized_src_ref_seq;
skipping to change at page 46, line 48 skipping to change at page 47, line 32
// Set the reference sequence number to be this most // Set the reference sequence number to be this most
// recently-received sequence number. // recently-received sequence number.
_src_ref_seq = extended_seq; _src_ref_seq = extended_seq;
} }
// 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). The algorithm, which has VoIP Metrics Report Block (Section 4.7). The algorithm, which has
been verified against a working implementation for correctness, is been verified against a working implementation for correctness, is
reproduced from ETSI TS 101 329-5 [3]. The algorithm as described reproduced from ETSI TS 101 329-5 [3]. The algorithm, as described
here takes precedence over any change that might eventually be made here, takes precedence over any change that might eventually be made
to the algorithm in future ETSI documents. to the algorithm in future ETSI documents.
This algorithm is event driven and hence extremely computationally This algorithm is event driven and hence extremely computationally
efficient. efficient.
Given the following definition of states: Given the following definition of states:
state 1 = received a packet during a gap state 1 = received a packet during a gap
state 2 = received a packet during a burst state 2 = received a packet during a burst
state 3 = lost a packet during a burst state 3 = lost a packet during a burst
state 4 = lost an isolated packet during a gap state 4 = lost an isolated packet during a gap
The "c" variables below correspond to state transition counts, i.e.,
The "c" variables below correspond to state transition counts, i.e.
c14 is the transition from state 1 to state 4. It is possible to c14 is the transition from state 1 to state 4. It is possible to
infer one of a pair of state transition counts to an accuracy of 1 infer one of a pair of state transition counts to an accuracy of 1
which is generally sufficient for this application. which is generally sufficient for this application.
"pkt" is the count of packets received since the last packet was "pkt" is the count of packets received since the last packet was
declared lost or discarded and "lost" is the number of packets lost declared lost or discarded, and "lost" is the number of packets lost
within the current burst. "packet_lost" and "packet_discarded" are within the current burst. "packet_lost" and "packet_discarded" are
Boolean variables that indicate if the event that resulted in this Boolean variables that indicate if the event that resulted in this
function being invoked was a lost or discarded packet. function being invoked was a lost or discarded packet.
if(packet_lost) { if(packet_lost) {
loss_count++; loss_count++;
} }
if(packet_discarded) { if(packet_discarded) {
discard_count++; discard_count++;
} }
skipping to change at page 48, line 45 skipping to change at page 49, line 30
// Calculate burst and gap durations in ms // Calculate burst and gap durations in ms
m = frameDuration_in_ms * framesPerRTPPkt; m = frameDuration_in_ms * framesPerRTPPkt;
gap_length = (c11 + c14 + c13) * m / c13; gap_length = (c11 + c14 + c13) * m / c13;
burst_length = ctotal * m / c13 - lgap; burst_length = ctotal * m / c13 - lgap;
/* calculate loss and discard rates */ /* calculate loss and discard rates */
loss_rate = 256 * loss_count / ctotal; loss_rate = 256 * loss_count / ctotal;
discard_rate = 256 * discard_count / ctotal; discard_rate = 256 * discard_count / ctotal;
Intellectual Property Intellectual Property Notice
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 [5]. 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
skipping to change at page 49, line 19 skipping to change at page 50, line 5
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
Director. Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
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; Mounir Benzaid for helping foster collaboration between the authors; Mounir Benzaid for
drawing our attention to the reporting needs of MLDA; Dorgham Sisalem drawing our attention to the reporting needs of MLDA; Dorgham Sisalem
and Adam Wolisz for encouraging us to incorporate MLDA block types; and Adam Wolisz for encouraging us to incorporate MLDA block types;
and Jose Rey for valuable review of the SDP Signaling section. 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, IBM Research
Alan Clark, Telchemy Alan Clark, Telchemy
Robert Cole, AT&T Labs Robert G. Cole, JHU Applied Physics Laboratory
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 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
skipping to change at page 50, line 38 skipping to change at page 51, line 5
4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield 4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield
4.3 Packet Receipt Times Report Block Friedman, Caceres, Duffield 4.3 Packet Receipt Times Report Block Friedman, Caceres, Duffield
4.4 Receiver Reference Time Report Block Friedman 4.4 Receiver Reference Time Report Block Friedman
4.5 DLRR Report Block Friedman 4.5 DLRR Report Block Friedman
4.6 Statistics Summary Report Block Almeroth, Sarac 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 The principal person to contact regarding the SDP signaling described
in this document is Magnus Westerlund. in this document is Magnus Westerlund.
References
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] ETSI, "Quality of Service (QoS) measurement methodologies", ETSI
TS 101 329-5 V1.1.1 (2000-11), November 2000.
[4] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[5] Hovey, R. and S. Bradner, "The Organizations Involved in the
IETF Standards Process", BCP 11, RFC 2028, October 1996.
[6] ITU-T, "The E-Model, a computational model for use in
transmission planning", Recommendation G.107, January 2003.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2002.
[9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003.
[10] TIA/EIA-810-A Transmission Requirements for Narrowband Voice
over IP and Voice over PCM Digital Wireline Telephones, December
2000.
Informative References
[11] Adams, A., Bu, T., Caceres, R., Duffield, N.G., Friedman, T.,
Horowitz, J., Lo Presti, F., Moon, S.B., Paxson, V. and D.
Towsley, "The Use of End-to-End Multicast Measurements for
Characterizing Internal Network Behavior", IEEE Communications
Magazine, May 2000.
[12] Baugher, McGrew, Oran, Blom, Carrara, Naslund and Norrman, "The
Secure Real-time Transport Protocol", Work in Progress.
[13] Caceres, R., Duffield, N.G. and T. Friedman, "Impromptu
measurement infrastructures using RTP", Proc. IEEE Infocom 2002.
[14] Clark, A.D., "Modeling the Effects of Burst Packet Loss and
Recency on Subjective Voice Quality", Proc. IP Telephony
Workshop 2001.
[15] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[16] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an
On-line Database", RFC 3232, January 2002.
[17] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[18] Sisalem D. and A. Wolisz, "MLDA: A TCP-friendly Congestion
Control Framework for Heterogeneous Multicast Environments",
Proc. IWQoS 2000.
Authors' Addresses Authors' Addresses
Kevin Almeroth <almeroth@cs.ucsb.edu> Kevin Almeroth
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> EMail: almeroth@cs.ucsb.edu
ShieldIP, Inc.
11 West 42nd Street, 31st Floor Ramon Caceres
New York, NY 10036 USA IBM Research
Alan Clark <alan@telchemy.com> 19 Skyline Drive
Hawthorne, NY 10532 USA
EMail: caceres@watson.ibm.com
Alan Clark
Telchemy Incorporated Telchemy Incorporated
3360 Martins Farm Road, Suite 200 3360 Martins Farm Road, Suite 200
Suwanee, GA 30024 USA Suwanee, GA 30024 USA
Tel: +1 770 614 6944
Phone: +1 770 614 6944
Fax: +1 770 614 3951 Fax: +1 770 614 3951
EMail: alan@telchemy.com
Robert Cole <rgcole@att.com> Robert G. Cole
AT&T Labs Johns Hopkins University Applied Physics Laboratory
330 Saint Johns Street, MP2-S170
2nd Floor 11100 Johns Hopkins Road
Havre de Grace, MD 21078 USA Laurel, MD 20723-6099 USA
Tel: +1 410 939 8732
Fax: +1 410 939 8732
Nick Duffield <duffield@research.att.com> Phone: +1 443 778 6951
EMail: robert.cole@jhuapl.edu
Nick Duffield
AT&T Labs-Research AT&T Labs-Research
180 Park Avenue, P.O. Box 971 180 Park Avenue, P.O. Box 971
Florham Park, NJ 07932-0971 USA Florham Park, NJ 07932-0971 USA
Tel: +1 973 360 8726
Fax: +1 973 360 8050
Timur Friedman <timur.friedman@lip6.fr> Phone: +1 973 360 8726
Fax: +1 973 360 8050
EMail: duffield@research.att.com
Timur Friedman
Universite Pierre et Marie Curie (Paris 6) Universite Pierre et Marie Curie (Paris 6)
Laboratoire LiP6-CNRS Laboratoire LiP6-CNRS
8, rue du Capitaine Scott 8, rue du Capitaine Scott
75015 PARIS France 75015 PARIS France
Tel: +33 1 44 27 71 06
Phone: +33 1 44 27 71 06
Fax: +33 1 44 27 74 95 Fax: +33 1 44 27 74 95
EMail: timur.friedman@lip6.fr
Kaynam Hedayat <khedayat@brixnet.com> Kaynam Hedayat
Brix Networks Brix Networks
285 Mill Road 285 Mill Road
Chelmsford, MA 01824 USA Chelmsford, MA 01824 USA
Tel: +1 978 367 5600
Phone: +1 978 367 5600
Fax: +1 978 367 5700 Fax: +1 978 367 5700
EMail: khedayat@brixnet.com
Kamil Sarac <ksarac@utdallas.edu> Kamil Sarac
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
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
The references are divided into normative references and non-
normative references.
Normative References
[1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," BCP 14, RFC 2119, IETF, March 1997.
[2] 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.
[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,
October 1996.
[6] ITU-T, "The E-Model, a computational model for use in
transmission planning," Recommendation G.107 (05/00), May 2000.
[7] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs," best current practice BCP 26, RFC
2434, IETF, October 1998.
[8] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the
Session Description Protocol (SDP)", RFC 3264, Internet Engineering
Task Force, June 2002.
[9] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Phone: +1 972 883 2337
transport protocol for real-time applications," RFC 1889, IETF, Fax: +1 972 883 2349
February 1996. EMail: ksarac@utdallas.edu
[10] TIA/EIA-810-A Transmission Requirements for Narrowband Voice
over IP and Voice over PCM Digital Wireline Telephones, December
2000.
Non-Normative References Magnus Westerlund
Ericsson Research
Ericsson AB
SE-164 80 Stockholm Sweden
[11] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. Phone: +46 8 404 82 87
Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The Fax: +46 8 757 55 50
Use of End-to-End Multicast Measurements for Characterizing Internal EMail: magnus.westerlund@ericsson.com
Network Behavior," IEEE Communications Magazine, May 2000.
[12] Baugher, McGrew, Oran, Blom, Carrara, Naslund, and Norrman, "The Full Copyright Statement
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 Copyright (C) The Internet Society (2003). All Rights Reserved.
measurement infrastructures using RTP," Proc. IEEE Infocom 2002.
[14] A. D. Clark, "Modeling the Effects of Burst Packet Loss and This document and translations of it may be copied and furnished to
Recency on Subjective Voice Quality," Proc. IP Telephony Workshop others, and derivative works that comment on or otherwise explain it
2001. or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
[15] M. Handley, C. Perkins, E. Whelan, "Session Announcement The limited permissions granted above are perpetual and will not be
Protocol", RFC 2974, Internet Engineering Task Force, October 2000. revoked by the Internet Society or its successors or assignees.
[16] J. Reynolds, "Assigned Numbers: RFC 1700 is Replaced by an On- This document and the information contained herein is provided on an
line Database", RFC 3232, IETF, January 2002. "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
[17] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming Acknowledgement
protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr.
1998.
[18] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Funding for the RFC Editor function is currently provided by the
Control Framework for Heterogeneous Multicast Environments", Proc. Internet Society.
IWQoS 2000.
 End of changes. 

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