draft-ietf-avt-rtcp-report-extns-04.txt   draft-ietf-avt-rtcp-report-extns-05.txt 
Internet Engineering Task Force Expires: 16 October 2003 Internet Engineering Task Force Expires: 30 October 2003
Audio/Video Transport Working Group Audio/Video Transport Working Group
Timur Friedman, Paris 6 Timur Friedman, Paris 6
Ramon Caceres, ShieldIP Ramon Caceres, ShieldIP
Alan Clark, Telchemy Alan Clark, Telchemy
Editors Editors
RTP Control Protocol Extended Reports (RTCP XR) RTP Control Protocol Extended Reports (RTCP XR)
draft-ietf-avt-rtcp-report-extns-04.txt draft-ietf-avt-rtcp-report-extns-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 ............................................... 6 1.2 Terminology ............................................... 7
2. XR Packet Format .......................................... 6 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 .................................... 15
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 ......................... 17
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 ........................... 26
4.7.2 Burst Metrics ............................................. 27 4.7.2 Burst Metrics ............................................. 27
4.7.3 Delay Metrics ............................................. 29 4.7.3 Delay Metrics ............................................. 29
4.7.4 Signal Related Metrics .................................... 30 4.7.4 Signal Related Metrics .................................... 30
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 .................................. 35
5. SDP Signaling ............................................. 36 5. SDP Signaling ............................................. 36
5.1 The SDP Attribute ......................................... 36 5.1 The SDP Attribute ......................................... 37
5.2 Usage in Offer/Answer ..................................... 39 5.2 Usage in Offer/Answer ..................................... 39
5.3 Usage Outside of Offer/Answer ............................. 40 5.3 Usage Outside of Offer/Answer ............................. 41
6. IANA Considerations ....................................... 41 6. IANA Considerations ....................................... 41
6.1 XR Packet Type ............................................ 41 6.1 XR Packet Type ............................................ 41
6.2 RTCP XR Block Type Registry ............................... 41 6.2 RTCP XR Block Type Registry ............................... 42
6.3 The "rtcp-xr" SDP Attribute ............................... 42 6.3 The "rtcp-xr" SDP Attribute ............................... 42
7. Security Considerations ................................... 43 7. Security Considerations ................................... 43
A. Algorithms ................................................ 44 A. Algorithms ................................................ 44
A.1 Sequence Number Interpretation ............................ 44 A.1 Sequence Number Interpretation ............................ 44
A.2 Example Burst Packet Loss Calculation ..................... 45 A.2 Example Burst Packet Loss Calculation ..................... 46
Intellectual Property ..................................... 47 Intellectual Property ..................................... 48
Full Copyright Statement .................................. 48 Full Copyright Statement .................................. 48
Acknowledgments ........................................... 48 Acknowledgments ........................................... 49
Contributors .............................................. 48 Contributors .............................................. 49
Authors' Addresses ........................................ 49 Authors' Addresses ........................................ 50
References ................................................ 51 References ................................................ 51
Normative References ...................................... 51 Normative References ...................................... 51
Non-Normative References .................................. 52 Non-Normative References .................................. 52
1. Introduction 1. Introduction
This document defines the Extended Report (XR) packet type for the This document defines the Extended Report (XR) packet type for the
RTP Control Protocol (RTCP) [10], 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
SR or RR profile-specific extensions. Information used for network SR or RR profile-specific extensions. Information used for network
management falls into this category, for instance. management falls into this category, for instance.
The definition is broken out over the three sections that follow the The definition is broken out over the three sections that follow the
Introduction. Section 2 defines the XR packet as consisting of an Introduction. Section 2 defines the XR packet as consisting of an
skipping to change at page 4, line 13 skipping to change at page 4, line 13
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 mentioned
next, these allow non-senders to calculate round-trip times. 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 already
defined for RTCP [10, Section 6.3.1], an RTP data receiver that defined for RTCP [9, Section 6.3.1], an RTP data receiver that
receives a sender's NTP timestamp can respond by filling in the DLSR receives a sender's NTP timestamp can respond by filling in the DLSR
field of an RTCP reception report block. 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 Hop
Limit values. Limit values.
- VoIP Metrics Report Block (Section 4.7): Metrics for monitoring - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring
skipping to change at page 4, line 44 skipping to change at page 4, line 44
(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 [10, Section 6.4.3]. Nonetheless, they are not or Receiver Reports [9, Section 6.4.3]. Nonetheless, they are not of
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 conversational, The VoIP metrics report block can be applied to any one-to-one or
multicast or broadcast application for which the use of RTP and RTCP one-to-many voice application for which the use of RTP and RTCP is
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, and
hence these metrics should be identified as unavailable in hence these metrics should be identified as unavailable in multicast
conferencing, multicast and broadcast 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.
skipping to change at page 6, line 22 skipping to change at page 6, line 22
to participants that receive the report blocks. Thus, for example, a to participants that receive the report blocks. Thus, for example, a
packet with an anomalous SSRC ID or an anomalous sequence number packet with an anomalous SSRC ID or an anomalous sequence number
might be excluded by normal RTP accounting, but would be reported might be excluded by normal RTP accounting, but would be reported
upon for network monitoring purposes. upon for network monitoring purposes.
The Statistics Summary Report Block (Section 4.6) has also been The Statistics Summary Report Block (Section 4.6) has also been
defined with network monitoring in mind. This block type can be used defined with network monitoring in mind. This block type can be used
equally well for reporting on unicast and multicast packet reception. equally well for reporting on unicast and multicast packet reception.
The reference time related block types were conceived for receiver- The reference time related block types were conceived for receiver-
based TCP-friendly multicast congestion control [17]. By allowing based TCP-friendly multicast congestion control [18]. By allowing
data receivers to calculate their round trip times to senders, they data receivers to calculate their round trip times to senders, they
help the receivers estimate the downstream bandwidth they should help the receivers estimate the downstream bandwidth they should
request. Note that if every receiver is to send Receiver Reference request. Note that if every receiver is to send Receiver Reference
Time Report Blocks (Section 4.4), a sender might potentially send a Time Report Blocks (Section 4.4), a sender might potentially send a
number of DLRR Report Blocks (Section 4.5) equal to the number of number of DLRR Report Blocks (Section 4.5) equal to the number of
receivers whose RTCP packets have arrived at the sender within its receivers whose RTCP packets have arrived at the sender within its
reporting interval. As the number of participants in a multicast reporting interval. As the number of participants in a multicast
session increases, an application should use discretion regarding session increases, an application should use discretion regarding
which participants send these blocks, and how frequently. which participants send these blocks, and how frequently.
XR packets supplement the existing RTCP packets, and may be stacked
with other RTCP packets to form compound RTCP packets [9, Section 6].
The introduction of XR packets into a session in no way changes the
rules governing the calculation of the RTCP reporting interval [9,
Section 6.2]. As XR packets are RTCP packets, they count as such for
bandwidth calculations. As a result, the addition of extended
reporting information may tend to increase the average RTCP packet
size, and thus the average reporting interval. This increase may be
limited by limiting the size of XR packets.
The SDP signaling defined for XR packets in this document (Section 5) 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.
skipping to change at page 7, line 7 skipping to change at page 7, line 18
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1] and document are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliance with this specification. indicate requirement levels for compliance with this specification.
2. XR Packet Format 2. XR Packet Format
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 compatibility 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
an SSRC/CSRC field are also provided in the same locations that they an SSRC field are also provided in the same locations that they
appear in other RTCP packets, for simplicity. The format is as appear in other RTCP packets, for simplicity. The format is as
follows: follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=XR=207 | length | |V=2|P|reserved | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC | | SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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
skipping to change at page 7, line 46 skipping to change at page 8, line 10
such definition, the bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver. MUST be ignored by the receiver.
packet type (PT): 8 bits packet type (PT): 8 bits
Contains the constant 207 to identify this as an RTCP XR packet. Contains the constant 207 to identify this as an RTCP XR packet.
This value is registered with the Internet Assigned Numbers This value is registered with the Internet Assigned Numbers
Authority (IANA), as described in Section 5.1. Authority (IANA), as described in Section 5.1.
length: 16 bits length: 16 bits
As described for the RTCP Sender Report (SR) packet (see Section As described for the RTCP Sender Report (SR) packet (see Section
6.3.1 of the RTP specification [10]). Briefly, the length of 6.3.1 of the RTP specification [9]). Briefly, the length of
this XR packet in 32-bit words minus one, including the header this XR packet in 32-bit words minus one, including the header
and any padding. and any padding.
SSRC/CSRC: 32 bits SSRC: 32 bits
The synchronization source identifier for the originator of this The synchronization source identifier for the originator of this
XR packet. XR packet.
report blocks: variable length. report blocks: variable length.
Zero or more extended report blocks. In keeping with the Zero or more extended report blocks. In keeping with the
extended report block framework defined below, each block MUST extended report block framework defined below, each block MUST
consist of one or more 32-bit words. consist of one or more 32-bit words.
3. Extended Report Block Framework 3. Extended Report Block Framework
skipping to change at page 9, line 22 skipping to change at page 9, line 32
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 inter-
report delays, detailed reception statistics, and voice over IP 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 either not relevant or unknown to it. Additional block types
MUST be registered with the Internet Assigned Numbers Authority MUST be registered with the Internet Assigned Numbers Authority
(IANA) [7], as described in Section 5.2. (IANA) [16], as described in Section 5.2.
4.1 Loss RLE Report Block 4.1 Loss RLE Report Block
This block type permits detailed reporting upon individual packet This block type permits detailed reporting upon individual packet
receipt and loss events. Such reports can be used, for example, for receipt and loss events. Such reports can be used, for example, for
multicast inference of network characteristics (MINC) [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.
skipping to change at page 9, line 46 skipping to change at page 10, line 8
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
events whenever possible. Interpretation should be left to those who events whenever possible. Interpretation should be left to those who
observe the report blocks. Following this approach implies that observe the report blocks. Following this approach implies that
accounting for Loss RLE Report Blocks will differ from the accounting accounting for Loss RLE Report Blocks will differ from the accounting
for the generation of the SR and RR packets described in the RTP for the generation of the SR and RR packets described in the RTP
specification [10] in the following two areas: per-sender accounting specification [9] in the following two areas: per-sender accounting
and per-packet accounting. and per-packet accounting.
In its per-sender accounting, an RTP session participant SHOULD NOT In its per-sender accounting, an RTP session participant SHOULD NOT
make the receipt of a threshold minimum number of RTP packets a make the receipt of a threshold minimum number of RTP packets a
condition for reporting upon the sender of those packets. This condition for reporting upon the sender of those packets. This
accounting technique differs from the technique described in Section accounting technique differs from the technique described in Section
6.2.1 and Appendix A.1 of the RTP specification that allows a 6.2.1 and Appendix A.1 of the RTP specification that allows a
threshold to determine whether a sender is considered valid. threshold to determine whether a sender is considered valid.
In its per-packet accounting, an RTP session participant SHOULD treat In its per-packet accounting, an RTP session participant SHOULD treat
skipping to change at page 19, line 47 skipping to change at page 19, line 47
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.
Receipt time of packet i: 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 wire
arrival time. Units and format are the same as for the arrival time. Units and format are the same as for the
timestamp in RTP data packets. As opposed to RTP data packet timestamp in RTP data packets. As opposed to RTP data packet
timestamps, in which nominal values may be used instead of timestamps, in which nominal values may be used instead of
system clock values in order to convey information useful for system clock values in order to convey information useful for
periodic playout, the receipt times should reflect the actual periodic playout, the receipt times should reflect the actual
skipping to change at page 20, line 22 skipping to change at page 20, line 22
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 timestamp
is meant to reflect the reference time at the sender, then the is meant to reflect the reference time at the sender, then the
receipt time SHOULD be as close as possible to the reference receipt time SHOULD be as close as possible to the reference
time at the receiver. 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 [10, 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 [17], 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=4 | reserved | block length = 2 | | BT=4 | reserved | block length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, most significant word | | NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 24 skipping to change at page 21, line 24
of elapsed time but has no notion of wallclock time may use the of elapsed time but has no notion of wallclock time may use the
elapsed time since joining the session instead. This is assumed elapsed time since joining the session instead. This is assumed
to be less than 68 years, so the high bit will be zero. It is to be less than 68 years, so the high bit will be zero. It is
permissible to use the sampling clock to estimate elapsed permissible to use the sampling clock to estimate elapsed
wallclock time. A report sender that has no notion of wallclock wallclock time. A report sender that has no notion of wallclock
or elapsed time may set the NTP timestamp to zero. 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 last Sender Report (DLSR)
mechanism [10, 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 [17]. 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 last Receiver Report, and may be sent in response to a Receiver
Timestamp Report Block (see previous section) from a receiver to Timestamp Report Block (see previous section) from a receiver to
allow that receiver to calculate its round trip time to the allow that receiver to calculate its round trip time to the
respondent. The report consists of one or more 3 word sub-blocks: respondent. The report consists of one or more 3 word sub-blocks:
one sub-block per Receiver Report. 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 |
skipping to change at page 22, line 29 skipping to change at page 22, line 29
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 no
Receiver Reference Time Report Block has been received yet from Receiver Reference Time Report Block has been received yet from
SSRC_n, the DLRR field is set to zero (or the DLRR is omitted SSRC_n, the DLRR field is set to zero (or the DLRR is omitted
entirely). Let SSRC_r denote the receiver issuing this DLRR entirely). Let SSRC_r denote the receiver issuing this DLRR
Report Block. Participant SSRC_n can compute the round-trip Report Block. Participant SSRC_n can compute the round-trip
propagation delay to SSRC_r by recording the time A when this propagation delay to SSRC_r by recording the time A when this
Receiver Timestamp Report Block is received. It calculates the Receiver Timestamp Report Block is received. It calculates the
total round-trip time A-LSR using the last SR timestamp (LSR) total round-trip time A-LRR using the last RR timestamp (LRR)
field, and then subtracting this field to leave the round-trip field, and then subtracting this field to leave the round-trip
propagation delay as A-LSR-DLSR. This is illustrated in [10, propagation delay as A-LRR-DLRR. This is illustrated in [9, Fig.
Fig. 2]. 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 not as fine grained as that carried
in the report blocks previously described. Information is recorded in the report blocks previously described. Information is recorded
about lost packets, duplicate packets, jitter measurements, and TTL about lost packets, duplicate packets, jitter measurements, and TTL
or Hop Limit values. Such information can be useful for network or Hop Limit values. Such information can be useful for network
management. management.
The report block contents are dependent upon a series of flags bit The report block contents are dependent upon a series of flags bit
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 set to zero. The receiver MUST ignore any Statistics Summary be present, but are set to zero. The receiver MUST ignore any
Report Block with a non-zero value in any field flagged as Statistics Summary Report Block with a non-zero value in any field
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
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=6 |L|D|J|ToH|rsvd.| block length = 9 | | BT=6 |L|D|J|ToH|rsvd.| block length = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lost_packets | | lost_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dup_packets | | dup_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_jitter | | min_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max_jitter | | max_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| avg_jitter | | mean_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dev_jitter | | dev_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_ttl_or_hl | max_ttl_or_hl | avg_ttl_or_hl | dev_ttl_or_hl | | min_ttl_or_hl | max_ttl_or_hl |mean_ttl_or_hl | dev_ttl_or_hl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Statistics Summary Report Block is identified by the constant A Statistics Summary Report Block is identified by the constant
6. 6.
loss report flag (L): 1 bit loss report flag (L): 1 bit
Bit set to 1 if the lost_packets field contains a report, 0 Bit set to 1 if the lost_packets field contains a report, 0
otherwise. otherwise.
duplicate report flag (D): 1 bit duplicate report flag (D): 1 bit
Bit set to 1 if the dup_packets field contains a report, 0 Bit set to 1 if the dup_packets field contains a report, 0
otherwise. otherwise.
jitter flag (J): 1 bit jitter flag (J): 1 bit
Bit set to 1 if the min_jitter, max_jitter, avg_jitter, and Bit set to 1 if the min_jitter, max_jitter, 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, avg_ttl_or_hl, or dev_ttl_or_hl contain reports. max_ttl_or_hl, mean_ttl_or_hl, or dev_ttl_or_hl contain reports.
If the field is non-zero then all of these fields contain If the field is non-zero then all of these fields contain
reports. The value 1 signifies that they report on IPv4 TTL reports. The value 1 signifies that they report on IPv4 TTL
values. The value 2 signifies that they report on IPv6 Hop values. The value 2 signifies that they report on IPv6 Hop
Limit values. This value 3 is undefined and MUST NOT be used. Limit values. This 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 of
such definition, the bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver. MUST be ignored by the receiver.
skipping to change at page 24, line 41 skipping to change at page 24, line 41
The minimum relative transit time between two packets in the The minimum relative transit time between two packets in the
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.
avg_jitter: 32 bits mean_jitter: 32 bits
The average relative transit time between each two packet series The mean relative transit time between each two packet series in
in the above sequence number interval. the above sequence number interval, rounded to the nearest 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 each
two packet series in the above sequence number interval. 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.
avg_ttl_or_hl: 8 bits mean_ttl_or_hl: 8 bits
The average TTL or Hop Limit value of data packets in the The mean TTL or Hop Limit value of data packets in the sequence
sequence number range. 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.
skipping to change at page 25, line 37 skipping to change at page 25, line 37
In order to properly assess the quality of a Voice over IP call it is In order to properly assess the quality of a Voice over IP call it is
desirable to consider the degree of burstiness of packet loss [14]. desirable to consider the degree of burstiness of packet loss [14].
Following a Gilbert-Elliott model [3], a period of time, bounded by Following a Gilbert-Elliott model [3], a period of time, bounded by
lost and/or discarded packets, with a high rate of losses and/or lost and/or discarded packets, with a high rate of losses and/or
discards is a "burst," and a period of time between two bursts is a discards is a "burst," and a period of time between two bursts is a
"gap." Bursts correspond to periods of time during which the packet "gap." Bursts correspond to periods of time during which the packet
loss rate is high enough to produce noticeable degradation in audio loss rate is high enough to produce noticeable degradation in audio
quality. Gaps correspond to periods of time during which only quality. Gaps correspond to periods of time during which only
isolated lost packets may occur, and in general these can be masked isolated lost packets may occur, and in general these can be masked
by packet loss concealment. Delay reports include the transit delay by packet loss concealment. Delay reports include the transit delay
between RTCP end points and the VoIP end system processing delays, between RTP end points and the VoIP end system processing delays,
both of which contribute to the user perceived delay. Additional both of which contribute to the user perceived delay. Additional
metrics include signal, echo, noise, and distortion levels. Call metrics include signal, echo, noise, and distortion levels. Call
quality metrics include R factors (as described by the E Model quality metrics include R factors (as described by the E Model
defined in [3]) and mean opinion scores (MOS scores). 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 27, line 37 skipping to change at page 27, line 37
This value is expressed as a fixed point number with the binary This 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 discarded (excluding dividing the total number of packets discarded (excluding
duplicate packet discards) by the total number of packets duplicate packet discards) by the total number of packets
expected, multiplying the result of the division by 256, expected, multiplying the result of the division by 256,
limiting the maximum value to 255 (to avoid overflow), and 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, informally, is a period of high packet losses and/or A burst is a period during which a high proportion of packets are
discards. Formally, a burst is defined as a longest sequence of either lost or discarded due to late arrival. A burst is defined, in
packets bounded by lost or discarded packets with the constraint that terms of a value Gmin, as a longest sequence that (a) starts with a
within a burst any sequence of successive packets that were received, lost or discarded packet, (b) does not contain any occurrences of
and not discarded due to delay variation, is of length less than a Gmin or more consecutive received (and not discarded) packets, and
value Gmin. (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 received and not discarded. This gives a maximum loss/discard rate
density 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 loss
rate, a minimum distance of 16 received packets between lost packets) rate, a minimum distance of 16 received packets between lost packets)
and hence differentiates nicely between good and poor quality and hence differentiates nicely between good and poor quality
periods. periods.
For example, a 1 denotes a received, 0 a lost, and X a discarded For example, a 1 denotes a received, 0 a lost, and X a discarded
packet in the following pattern covering 64 packets: packet in the following pattern covering 64 packets:
skipping to change at page 28, line 40 skipping to change at page 28, line 40
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
value of 16, the burst duration is 120 ms, the burst density 0.33, value of 16, the burst duration is 120 ms, the burst density 0.33,
the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04. the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04.
This would result in reported values as follows (see field 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 density 12, which corresponds to 5% loss rate 12, which corresponds to 5%
discard density 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. This
value is expressed as a fixed point number with the binary point value is expressed as a fixed point number with the binary point
at the left edge of the field. It is calculated by dividing the at the left edge of the field. It is calculated by dividing the
skipping to change at page 30, line 17 skipping to change at page 30, line 17
example, the time delay due to RTP payload multiplexing would be example, the time delay due to RTP payload multiplexing would be
considered to be part of the voice application or end-system delay considered to be part of the voice application or end-system delay
whereas delay due to multiplexing RTP frames within a UDP frame would whereas delay due to multiplexing RTP frames within a UDP frame would
be considered part of the RTP reported delay. This distinction is be considered part of the RTP reported delay. This distinction is
consistent with the use of RTCP for delay measurements. consistent with the use of RTCP for delay measurements.
round trip delay: 16 bits round trip delay: 16 bits
The most recently calculated round trip time between RTP The most recently calculated round trip time between RTP
interfaces, expressed in milliseconds. This value 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 or other approaches. If RTCP is used then the this document, in which case it is necessary to convert the
reported delay value is the time of receipt of the most recent units of measurement from NTP timestamp values to milliseconds,
RTCP packet from source SSRC, minus the LSR (last SR) time or other approaches. If RTCP is used then the reported delay
reported in its SR (Sender Report), minus the DLSR (delay since value is the time of receipt of the most recent RTCP packet from
last SR) reported in its SR. A non-zero LSR value is required source SSRC, minus the LSR (last SR) time reported in its SR
in order to calculate round trip delay. A value of 0 is (Sender Report), minus the DLSR (delay since last SR) reported
permissible, however this field MUST be populated as soon as a in its SR. A non-zero LSR value is required in order to
delay estimate is available. calculate round trip delay. A value of 0 is permissible, however
this field MUST be populated as soon as a delay estimate is
available.
end system delay: 16 bits end system delay: 16 bits
The most recently estimated end system delay, expressed in The most recently estimated end system delay, expressed in
milliseconds. End system delay is defined as the total milliseconds. End system delay is defined as the sum of the
encoding, decoding and jitter buffer delay determined at the total sample accumulation and encoding delay associated with the
reporting endpoint. This is the time required for an RTP frame sending direction and the jitter buffer, decoding, and playout
to be buffered, decoded, converted to analog form, looped back buffer delay associated with the receiving direction. This
at the local analog interface, encoded, and made available for delay MAY be estimated or measured. This value MUST be provided
transmission as an RTP frame. The manner in which this value is in all VoIP metrics reports.
estimated is implementation dependent. This parameter MUST be
provided in all VoIP metrics reports.
Note that the one way symmetric VoIP segment delay may be calculated Note that the one way symmetric VoIP segment delay may be calculated
from the round trip and end system delays as follows. If the round from the round trip and end system delays as follows. If the round
trip delay is denoted RTD and the end system delays associated with trip delay is denoted RTD and the end system delays associated with
the two endpoints are ESD(A) and ESD(B) then: the two endpoints are ESD(A) and ESD(B) then:
one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2 one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2
4.7.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 reference digital milliwatt, expressed in signal level to a 0dBm0 reference [10], expressed in decibels as
decibels as a signed integer in two's complement form. This is a signed integer in two's complement form. This is measured
measured only for packets containing speech energy. The intent only for packets containing speech energy. The intent of this
of this metric is not to provide a precise measurement of the metric is not to provide a precise measurement of the signal
signal level but to provide a real time indication that the level but to provide a real time indication that the signal
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 be generally in the -15 to -20 dBm range.
noise level: 8 bits noise level: 8 bits
The noise level is defined as the ratio of the silent period The noise level is defined as the ratio of the silent period
background noise level to a reference digital milliwatt, background noise level to a 0 dBm0 reference, expressed in
expressed in decibels as a signed integer in two's complement decibels as a signed integer in two's complement form.
form.
noise level = 10 Log10 ( rms silence power (mW) ) noise level = 10 Log10 ( rms silence power (mW) )
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
residual echo return loss (RERL): 8 bits residual echo return loss (RERL): 8 bits
The residual echo return loss is defined as the sum of the The residual echo return loss is defined as the sum of the
measured echo return loss (ERL) and the echo return loss measured echo return loss (ERL) and the echo return loss
enhancement (ERLE) expressed in dB as a signed integer in two's enhancement (ERLE) of the echo canceller (if present), expressed
complement form. It defines the ratio of a transmitted voice in dB as a signed integer in two's complement form.
signal that is reflected back to the talker. A low level of
echo return loss (say less than 20 dB) in conjunction with some The residual echo return loss relates to the effective echo
delay can lead to hollowness or audible echo. A high level of level that a user would hear. The amount of echo that can occur
echo return loss (say over 40 dB) is preferable. in analog loops can be significant, and therefore echo
cancellers are typically used to try and eliminate or reduce the
audible echo. The amount of echo is typically described as an
"echo return loss" (i.e. ratio between the transmitted signal
level and the received echo level) expressed in dB. The
effectiveness of an echo canceller is normally described in
terms of "echo return loss enhancement", i.e. an echo canceller
increases the effective echo return loss and makes the audible
echo smaller. Hence the residual echo return loss (RERL) is the
sum of the echo return loss (ERL) and the echo return loss
enhancement (ERLE) expressed in dB.
A low level of echo return loss (say less than 20 dB) in
conjunction with some delay can lead to hollowness or audible
echo. A high level of echo return loss (say over 40 dB) is
preferable.
The ERL and ERLE parameters are often available directly from the The ERL and ERLE parameters are often available directly from the
echo canceler contained within the VoIP end system. They relate to echo canceler contained within the VoIP end system. They relate to
the echo on the external network attached to the end point. the echo on the external network attached to the end point.
In the case of a VoIP gateway this would be line echo that typically In the case of a VoIP gateway this would be line echo that typically
occurs at 2-4 wire conversion points in the network. Echo return occurs at 2-4 wire conversion points in the network. Echo return
loss from typical 2-4 wire conversions can be in the 8-12 dB range. loss from typical 2-4 wire conversions can be in the 8-12 dB range.
A line echo canceler can provide an ERLE of 30 dB or more and hence A line echo 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 reduce this to 40-50 dB. In the case of an IP phone this could be
skipping to change at page 33, line 23 skipping to change at page 33, line 37
R factor: 8 bits R factor: 8 bits
The R factor is a voice quality metric describing the segment of The R factor is a voice quality metric describing the segment of
the call that is carried over this RTP session. It is expressed the call that is carried over this RTP session. It is expressed
as an integer in the range 0 to 100, with a value of 94 as an integer in the range 0 to 100, with a value of 94
corresponding to "toll quality" and values of 50 or less corresponding to "toll quality" and values of 50 or less
regarded as unusable. This metric is defined as including the regarded as unusable. This metric is defined as including the
effects of delay, consistent with ITU-T G.107 [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
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. Its
values are interpreted in the same manner as for the RTP R values are interpreted in the same manner as for the RTP R
factor. This metric is defined as including the effects of factor. This metric is defined as including the effects of
delay, consistent with ITU-T G.107 [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
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 metric
is defined as not including the effects of delay and can be is defined as not including the effects of delay and can be
compared to MOS scores obtained from listening quality (ACR) 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
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 according
to ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an estimated to ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an estimated
MOS using the equation specified in G.107. It is expressed as MOS using the equation specified in G.107. It is expressed as
an integer in the range 10 to 50, corresponding to MOS x 10, as an integer in the range 10 to 50, corresponding to MOS x 10, as
for MOS-LQ. for MOS-LQ.
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
Values other than 127 and the valid range defined above MUST 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
skipping to change at page 35, line 47 skipping to change at page 36, line 20
4.7.7 Jitter Buffer Parameters 4.7.7 Jitter Buffer Parameters
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 milliseconds,
which corresponds to the nominal jitter buffer delay for packets which corresponds to the nominal jitter buffer delay for packets
that arrive exactly on time. This parameter MUST be provided that arrive exactly on time. This parameter MUST be provided
for both fixed and adaptive jitter buffer implementations. for both fixed and adaptive jitter buffer implementations.
jitter buffer maximum delay (JB maximum): 16 bits jitter buffer maximum delay (JB maximum): 16 bits
This is the current maximum jitter buffer delay corresponding to This is the current maximum jitter buffer delay in milliseconds
the earliest arriving packet that would not be discarded. In which corresponds to the earliest arriving packet that would not
simple queue implementations this may correspond to the nominal be discarded. In simple queue implementations this may
size. In adaptive jitter buffer implementations this value may correspond to the nominal size. In adaptive jitter buffer
dynamically vary up to JB abs max (see below). This parameter implementations this value may dynamically vary up to JB abs max
MUST be provided for both fixed and adaptive jitter buffer (see below). This parameter MUST be provided for both fixed and
implementations. 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 that the adaptive jitter This is the absolute maximum delay in milliseconds that the
buffer can reach under worst case jitter conditions. This adaptive jitter buffer can reach under worst case conditions.
parameter MUST be provided for adaptive jitter buffer If this value exceeds 65535 milliseconds then this field SHALL
implementations and its value MUST be set to JB maximum for convey the value 65535. This parameter MUST be provided for
fixed jitter buffer implementations. adaptive jitter buffer implementations and its value MUST be 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 [9] 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 with
such protocols as the Session Announcement Protocol (SAP) [15] or the such protocols as the Session Announcement Protocol (SAP) [15] or the
Real Time Streaming Protocol (RTSP) [16]. There exist other Real Time Streaming Protocol (RTSP) [17]. There exist other
potential signaling methods, which are not defined here. potential signaling methods, which 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 [10]. An example in which signaling would not be used described in [9]. An example in which signaling would not be used is
is an application that always requires the use of one or more XR an application that always requires the use of one or more XR blocks.
blocks. However for applications that are configured at session However for applications that are configured at session initiation,
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
skipping to change at page 37, line 22 skipping to change at page 37, line 43
/ voip-metrics / voip-metrics
/ format-ext / format-ext
pkt-loss-rle = "pkt-loss-rle" ["=" max-size] pkt-loss-rle = "pkt-loss-rle" ["=" max-size]
pkt-dup-rle = "pkt-dup-rle" ["=" max-size] pkt-dup-rle = "pkt-dup-rle" ["=" max-size]
pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size] pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size]
rcvr-rtt = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size] rcvr-rtt = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size]
stat-summary = "stat-summary" stat-summary = "stat-summary"
voip-metrics = "voip-metrics" voip-metrics = "voip-metrics"
max-size = 1*DIGIT ; maximum block size in octets max-size = 1*DIGIT ; maximum block size in octets
DIGIT = %x30-39
rcvr-rtt-mode = "all" rcvr-rtt-mode = "all"
/ "sender" / "sender"
format-ext = non-ws-string format-ext = non-ws-string
non-ws-string = 1*(%x21-FF) non-ws-string = 1*(%x21-FF)
CRLF = %d13.10
The "rtcp-xr" attribute contains zero, one, or more XR block related The "rtcp-xr" attribute contains zero, one, or more XR block related
parameters. Each parameter signals functionality for an XR block, or parameters. Each parameter signals functionality for an XR block, or
a group of XR blocks. The attribute is extensible so that parameters a group of XR blocks. The attribute is extensible so that parameters
can be defined for any future XR block (and a parameter should be can be defined for any future XR block (and a parameter should be
defined for every future block). defined for every future block).
Each "rtcp-xr" parameter belongs to one of two categories. The first Each "rtcp-xr" parameter belongs to one of two categories. The first
category, the unilateral parameters, are for report blocks that category, the unilateral parameters, are for report blocks that
simply report on the RTP stream and related metrics. The second simply report on the RTP stream and related metrics. The second
category, collaborative parameters, are for XR blocks that involve category, collaborative parameters, are for XR blocks that involve
skipping to change at page 39, line 22 skipping to change at page 39, line 45
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 [9], 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 to
unicast media streams, except where noted. Discussion of unilateral unicast media streams, except where noted. Discussion of unilateral
parameters is followed by discussion of collaborative parameters in parameters is followed by discussion of collaborative parameters in
this section. 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
skipping to change at page 40, line 45 skipping to change at page 41, line 19
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 that it is capable
of understanding the signaling. of 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) [16]. 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 that
is expected from specifying the "rtcp-xr" attribute is the same as in is 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
skipping to change at page 41, line 39 skipping to change at page 42, line 13
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 [8]. 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:
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:
- Contact information of the one doing the registration, including at
least name, address, and email.
- The format of the block type being registered, consistent with the
extended report block format described in Section 3.
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 This 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
skipping to change at page 42, line 45 skipping to change at page 43, line 19
Values: see this document and registrations below Values: see this document and registrations below
The attribute has an extensible parameter field and therefore a The attribute has an extensible parameter field and therefore a
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 [8]. 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 at
least name, address, and email. 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. parameter, in accordance with the "format-ext" definition of
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
This document extends the RTCP reporting mechanism. The security This document extends the RTCP reporting mechanism. The security
considerations that apply to RTCP reports also apply to XR reports. considerations that apply to RTCP reports [9, Appendix B] also apply
This section details the additional security considerations that to XR reports. This section details the additional security
apply to the extensions. considerations that apply to the extensions.
The extensions introduce heightened confidentiality concerns. The extensions introduce heightened confidentiality concerns.
Standard RTCP reports contain a limited number of summary statistics. Standard RTCP reports contain a limited number of summary statistics.
The information contained in XR reports is both more detailed and The information contained in XR reports is both more detailed and
more extensive (covering a larger number of parameters). The per- more extensive (covering a larger number of parameters). The per-
packet report blocks and the VoIP Metrics Report Block provide packet report blocks and the VoIP Metrics Report Block provide
examples. examples.
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
skipping to change at page 43, line 51 skipping to change at page 44, line 26
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
aspects of their network topology can be revealed. aspects of their network topology can be revealed.
Any encryption or filtering of XR report blocks entails a loss of Any encryption or filtering of XR report blocks entails a loss of
monitoring information to third parties. For example, a network that monitoring information to third parties. For example, a network that
establishes a tunnel to encrypt VoIP Report Blocks denies that establishes a tunnel to encrypt VoIP Report Blocks denies that
information to the service providers traversed by the tunnel. The information to the service providers traversed by the tunnel. The
service providers cannot then monitor or respond to the quality of service providers cannot then monitor or respond to the quality of
the VoIP calls that they carry, potentially creating problems for the the VoIP calls that they carry, potentially creating problems for the
network's users. As a default, XR packets SHOULD NOT be encrypted or network's users. As a default, XR packets should not be encrypted or
filtered. filtered.
The extensions also make certain denial of service attacks easier. The extensions also make certain denial of service attacks easier.
This is because of the potential to create RTCP packets much larger This is because of the potential to create RTCP packets much larger
than average with the per packet reporting capabilities of the Loss than average with the per packet reporting capabilities of the Loss
RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the
automatic bandwidth adjustment mechanisms in RTCP, if some session automatic bandwidth adjustment mechanisms in RTCP, if some session
participants are sending large RTCP packets, all participants will participants are sending large RTCP packets, all participants will
see their RTCP reporting intervals lengthened, meaning they will be see their RTCP reporting intervals lengthened, meaning they will be
able to report less frequently. To limit the effects of large able to report less frequently. To limit the effects of large
skipping to change at page 47, line 29 skipping to change at page 48, line 4
// Calculate burst and densities. // Calculate burst and densities.
p32 = c32 / (c31 + c32 + c33); p32 = c32 / (c31 + c32 + c33);
if((c22 + c23) < 1) { if((c22 + c23) < 1) {
p23 = 1; p23 = 1;
} }
else { else {
p23 = 1 - c22/(c22 + c23); p23 = 1 - c22/(c22 + c23);
} }
burst_density = 256 * p23 / (p23 + p32); burst_density = 256 * p23 / (p23 + p32);
gap_density = 256 * c14 / (c11 + c14); gap_density = 256 * c14 / (c11 + c14);
// Calculate burst and gap durations in ms // Calculate burst and gap durations in ms
m = frameDuration_in_ms * framesPerRTPPkt; m = frameDuration_in_ms * framesPerRTPPkt;
gap_length = (c11 + c14 + c13) * m / c13; gap_length = (c11 + c14 + c13) * m / c13;
burst_length = ctotal * m / c13 - lgap; burst_length = ctotal * m / c13 - lgap;
/* calculate loss and discard densities */ /* calculate loss and discard rates */
loss_density = 256 * loss_count / ctotal; loss_rate = 256 * loss_count / ctotal;
discard_density = 256 * discard_count / ctotal; discard_rate = 256 * discard_count / ctotal;
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at page 51, line 38 skipping to change at page 52, line 5
[4] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC [4] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC
2327, Internet Engineering Task Force, April 1998. 2327, Internet Engineering Task Force, April 1998.
[5] R. Hovey and S. Bradner, "The Organizations Involved in the IETF [5] R. Hovey and S. Bradner, "The Organizations Involved in the IETF
Standards Process," best current practice BCP 11, RFC 2028, IETF, Standards Process," best current practice BCP 11, RFC 2028, IETF,
October 1996. October 1996.
[6] ITU-T, "The E-Model, a computational model for use in [6] ITU-T, "The E-Model, a computational model for use in
transmission planning," Recommendation G.107 (05/00), May 2000. transmission planning," Recommendation G.107 (05/00), May 2000.
[7] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2, [7] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
RFC 1700, IETF, October 1994.
[8] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs," best current practice BCP 26, RFC Considerations Section in RFCs," best current practice BCP 26, RFC
2434, IETF, October 1998. 2434, IETF, October 1998.
[9] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the [8] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the
Session Description Protocol (SDP)", RFC 3264, Internet Engineering Session Description Protocol (SDP)", RFC 3264, Internet Engineering
Task Force, June 2002. Task Force, June 2002.
[10] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: [9] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
A transport protocol for real-time applications," RFC 1889, IETF, transport protocol for real-time applications," RFC 1889, IETF,
February 1996. February 1996.
[10] TIA/EIA-810-A Transmission Requirements for Narrowband Voice
over IP and Voice over PCM Digital Wireline Telephones, December
2000.
Non-Normative References Non-Normative References
[11] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. [11] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J.
Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The
Use of End-to-End Multicast Measurements for Characterizing Internal Use of End-to-End Multicast Measurements for Characterizing Internal
Network Behavior," IEEE Communications Magazine, May 2000. Network Behavior," IEEE Communications Magazine, May 2000.
[12] Baugher, McGrew, Oran, Blom, Carrara, Naslund, and Norrman, "The [12] Baugher, McGrew, Oran, Blom, Carrara, Naslund, and Norrman, "The
Secure Real-time Transport Protocol," Internet-Draft draft-ietf-avt- Secure Real-time Transport Protocol," Internet-Draft draft-ietf-avt-
srtp-05.txt, June 2002. Note: this is is a work in progress. srtp-05.txt, June 2002. Note: this is is a work in progress.
skipping to change at page 52, line 26 skipping to change at page 52, line 42
[13] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu [13] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu
measurement infrastructures using RTP," Proc. IEEE Infocom 2002. measurement infrastructures using RTP," Proc. IEEE Infocom 2002.
[14] A. D. Clark, "Modeling the Effects of Burst Packet Loss and [14] A. D. Clark, "Modeling the Effects of Burst Packet Loss and
Recency on Subjective Voice Quality," Proc. IP Telephony Workshop Recency on Subjective Voice Quality," Proc. IP Telephony Workshop
2001. 2001.
[15] M. Handley, C. Perkins, E. Whelan, "Session Announcement [15] M. Handley, C. Perkins, E. Whelan, "Session Announcement
Protocol", RFC 2974, Internet Engineering Task Force, October 2000. Protocol", RFC 2974, Internet Engineering Task Force, October 2000.
[16] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming [16] J. Reynolds, "Assigned Numbers: RFC 1700 is Replaced by an On-
line Database", RFC 3232, IETF, January 2002.
[17] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming
protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr.
1998. 1998.
[17] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion [18] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion
Control Framework for Heterogeneous Multicast Environments", Proc. Control Framework for Heterogeneous Multicast Environments", Proc.
IWQoS 2000. IWQoS 2000.
 End of changes. 

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