GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3611

Network Working Group T. Friedman, Ed. Request for Comments: 3611 Paris 6 Category: Standards Track R. Caceres, Ed.

                                                          IBM Research
                                                         A. Clark, Ed.
                                                              Telchemy
                                                         November 2003
          RTP Control Protocol Extended Reports (RTCP XR)

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

 This document defines the Extended Report (XR) packet type for the
 RTP Control Protocol (RTCP), and defines how the use of XR packets
 can be signaled by an application if it employs the Session
 Description Protocol (SDP).  XR packets are composed of report
 blocks, and seven block types are defined here.  The purpose of the
 extended reporting format is to convey information that supplements
 the six statistics that are contained in the report blocks used by
 RTCP's Sender Report (SR) and Receiver Report (RR) packets.  Some
 applications, such as multicast inference of network characteristics
 (MINC) or voice over IP (VoIP) monitoring, require other and more
 detailed statistics.  In addition to the block types defined here,
 additional block types may be defined in the future by adhering to
 the framework that this document provides.

Friedman, et al. Standards Track [Page 1] RFC 3611 RTCP XR November 2003

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Applicability. . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  7
 2.  XR Packet Format . . . . . . . . . . . . . . . . . . . . . . .  7
 3.  Extended Report Block Framework. . . . . . . . . . . . . . . .  8
 4.  Extended Report Blocks . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Loss RLE Report Block. . . . . . . . . . . . . . . . . .  9
           4.1.1.  Run Length Chunk . . . . . . . . . . . . . . . . 15
           4.1.2.  Bit Vector Chunk . . . . . . . . . . . . . . . . 15
           4.1.3.  Terminating Null Chunk . . . . . . . . . . . . . 16
     4.2.  Duplicate RLE Report Block . . . . . . . . . . . . . . . 16
     4.3.  Packet Receipt Times Report Block. . . . . . . . . . . . 18
     4.4.  Receiver Reference Time Report Block . . . . . . . . . . 20
     4.5.  DLRR Report Block. . . . . . . . . . . . . . . . . . . . 21
     4.6.  Statistics Summary Report Block. . . . . . . . . . . . . 22
     4.7.  VoIP Metrics Report Block. . . . . . . . . . . . . . . . 25
           4.7.1.  Packet Loss and Discard Metrics. . . . . . . . . 27
           4.7.2.  Burst Metrics. . . . . . . . . . . . . . . . . . 27
           4.7.3.  Delay Metrics. . . . . . . . . . . . . . . . . . 30
           4.7.4.  Signal Related Metrics . . . . . . . . . . . . . 31
           4.7.5.  Call Quality or Transmission Quality Metrics . . 33
           4.7.6.  Configuration Parameters . . . . . . . . . . . . 34
           4.7.7.  Jitter Buffer Parameters . . . . . . . . . . . . 36
 5.  SDP Signaling. . . . . . . . . . . . . . . . . . . . . . . . . 36
     5.1.  The SDP Attribute. . . . . . . . . . . . . . . . . . . . 37
     5.2.  Usage in Offer/Answer. . . . . . . . . . . . . . . . . . 40
     5.3.  Usage Outside of Offer/Answer. . . . . . . . . . . . . . 42
 6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 42
     6.1.  XR Packet Type . . . . . . . . . . . . . . . . . . . . . 42
     6.2.  RTCP XR Block Type Registry. . . . . . . . . . . . . . . 42
     6.3.  The "rtcp-xr" SDP Attribute. . . . . . . . . . . . . . . 43
 7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 44
 A.  Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 46
     A.1.  Sequence Number Interpretation . . . . . . . . . . . . . 46
     A.2.  Example Burst Packet Loss Calculation. . . . . . . . . . 47
 Intellectual Property Notice . . . . . . . . . . . . . . . . . . . 49
 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 50
 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
 Normative References . . . . . . . . . . . . . . . . . . . . . . . 51
 Informative References . . . . . . . . . . . . . . . . . . . . . . 51
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 55

Friedman, et al. Standards Track [Page 2] RFC 3611 RTCP XR November 2003

1. Introduction

 This document defines the Extended Report (XR) packet type for the
 RTP Control Protocol (RTCP) [9], and defines how the use of XR
 packets can be signaled by an application if it employs the Session
 Description Protocol (SDP) [4].  XR packets convey information beyond
 that already contained in the reception report blocks of RTCP's
 sender report (SR) or Receiver Report (RR) packets.  The information
 is of use across RTP profiles, and so is not appropriately carried in
 SR or RR profile-specific extensions.  Information used for network
 management falls into this category, for instance.
 The definition is broken out over the three sections that follow the
 Introduction.  Section 2 defines the XR packet as consisting of an
 eight octet header followed by a series of components called report
 blocks.  Section 3 defines the common format, or framework,
 consisting of a type and a length field, required for all report
 blocks.  Section 4 defines several specific report block types.
 Other block types can be defined in future documents as the need
 arises.
 The report block types defined in this document fall into three
 categories.  The first category consists of packet-by-packet reports
 on received or lost RTP packets.  Reports in the second category
 convey reference time information between RTP participants.  In the
 third category, reports convey metrics relating to packet receipts,
 that are summary in nature but that are more detailed, or of a
 different type, than that conveyed in existing RTCP packets.
 All told, seven report block formats are defined by this document.
 Of these, three are packet-by-packet block types:
  1. Loss RLE Report Block (Section 4.1): Run length encoding of

reports concerning the losses and receipts of RTP packets.

  1. Duplicate RLE Report Block (Section 4.2): Run length encoding of

reports concerning duplicates of received RTP packets.

  1. Packet Receipt Times Report Block (Section 4.3): A list of

reception timestamps of RTP packets.

 There are two reference time related block types:
  1. Receiver Reference Time Report Block (Section 4.4): Receiver-end

wallclock timestamps. Together with the DLRR Report Block

    mentioned next, these allow non-senders to calculate round-trip
    times.

Friedman, et al. Standards Track [Page 3] RFC 3611 RTCP XR November 2003

  1. DLRR Report Block (Section 4.5): The delay since the last Receiver

Reference Time Report Block was received. An RTP data sender that

    receives a Receiver Reference Time Report Block can respond with a
    DLRR Report Block, in much the same way as, in the mechanism
    already defined for RTCP [9, Section 6.3.1], an RTP data receiver
    that receives a sender's NTP timestamp can respond by filling in
    the DLSR field of an RTCP reception report block.
 Finally, this document defines two summary metric block types:
  1. Statistics Summary Report Block (Section 4.6): Statistics on RTP

packet sequence numbers, losses, duplicates, jitter, and TTL or

    Hop Limit values.
  1. VoIP Metrics Report Block (Section 4.7): Metrics for monitoring

Voice over IP (VoIP) calls.

 Before proceeding to the XR packet and report block definitions, this
 document provides an applicability statement (Section 1.1) that
 describes the contexts in which these report blocks can be used.  It
 also defines (Section 1.2) the normative use of key words, such as
 MUST and SHOULD, as they are employed in this document.
 Following the definitions of the various report blocks, this document
 describes how applications that employ SDP can signal their use
 (Section 5).  The document concludes with a discussion (Section 6) of
 numbering considerations for the Internet Assigned Numbers Authority
 (IANA), of security considerations (Section 7), and with appendices
 that provide examples of how to implement algorithms discussed in the
 text.

1.1. Applicability

 The XR packets are useful across multiple applications, and for that
 reason are not defined as profile-specific extensions to RTCP sender
 or Receiver Reports [9, Section 6.4.3].  Nonetheless, they are not of
 use in all contexts.  In particular, the VoIP metrics report block
 (Section 4.7) is specific to voice applications, though it can be
 employed over a wide variety of such applications.
 The VoIP metrics report block can be applied to any one-to-one or
 one-to-many voice application for which the use of RTP and RTCP is
 specified.  The use of conversational metrics (Section 4.7.5),
 including the R factor (as described by the E Model defined in [3])
 and the mean opinion score for conversational quality (MOS-CQ), in
 applications other than simple two party calls is not defined; hence,
 these metrics should be identified as unavailable in multicast
 conferencing applications.

Friedman, et al. Standards Track [Page 4] RFC 3611 RTCP XR November 2003

 The packet-by-packet report block types, Loss RLE (Section 4.1),
 Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3),
 have been defined with network tomography applications, such as
 multicast inference of network characteristics (MINC) [11], in mind.
 MINC requires detailed packet receipt traces from multicast session
 receivers in order to infer the gross structure of the multicast
 distribution tree and the parameters, such as loss rates and delays,
 that apply to paths between the branching points of that tree.
 Any real time multicast multimedia application can use the packet-
 by-packet report block types.  Such an application could employ a
 MINC inference subsystem that would provide it with multicast tree
 topology information.  One potential use of such a subsystem would be
 for the identification of high loss regions in the multicast tree and
 the identification of multicast session participants well situated to
 provide retransmissions of lost packets.
 Detailed packet-by-packet reports do not necessarily have to consume
 disproportionate bandwidth with respect to other RTCP packets.  An
 application can cap the size of these blocks.  A mechanism called
 "thinning" is provided for these report blocks, and can be used to
 ensure that they adhere to a size limit by restricting the number of
 packets reported upon within any sequence number interval.  The
 rationale for, and use of this mechanism is described in [13].
 Furthermore, applications might not require report blocks from all
 receivers in order to answer such important questions as where in the
 multicast tree there are paths that exceed a defined loss rate
 threshold.  Intelligent decisions regarding which receivers send
 these report blocks can further restrict the portion of RTCP
 bandwidth that they consume.
 The packet-by-packet report blocks can also be used by dedicated
 network monitoring applications.  For such an application, it might
 be appropriate to allow more than 5% of RTP data bandwidth to be used
 for RTCP packets, thus allowing proportionately larger and more
 detailed report blocks.
 Nothing in the packet-by-packet block types restricts their use to
 multicast applications.  In particular, they could be used for
 network tomography similar to MINC, but using striped unicast packets
 instead.  In addition, if it were found useful, they could be used
 for applications limited to two participants.
 One use to which the packet-by-packet reports are not immediately
 suited is for data packet acknowledgments as part of a packet
 retransmission mechanism.  The reason is that the packet accounting
 technique suggested for these blocks differs from the packet
 accounting normally employed by RTP.  In order to favor measurement

Friedman, et al. Standards Track [Page 5] RFC 3611 RTCP XR November 2003

 applications, an effort is made to interpret as little as possible at
 the data receiver, and leave the interpretation as much as possible
 to participants that receive the report blocks.  Thus, for example, a
 packet with an anomalous SSRC ID or an anomalous sequence number
 might be excluded by normal RTP accounting, but would be reported
 upon for network monitoring purposes.
 The Statistics Summary Report Block (Section 4.6) has also been
 defined with network monitoring in mind.  This block type can be used
 equally well for reporting on unicast and multicast packet reception.
 The reference time related block types were conceived for receiver-
 based TCP-friendly multicast congestion control [18].  By allowing
 data receivers to calculate their round trip times to senders, they
 help the receivers estimate the downstream bandwidth they should
 request.  Note that if every receiver is to send Receiver Reference
 Time Report Blocks (Section 4.4), a sender might potentially send a
 number of DLRR Report Blocks (Section 4.5) equal to the number of
 receivers whose RTCP packets have arrived at the sender within its
 reporting interval.  As the number of participants in a multicast
 session increases, an application should use discretion regarding
 which participants send these blocks, and how frequently.
 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)
 was done so with three use scenarios in mind: a Real Time Streaming
 Protocol (RTSP) controlled streaming application, a one-to-many
 multicast multimedia application such as a course lecture with
 enhanced feedback, and a Session Initiation Protocol (SIP) controlled
 conversational session involving two parties.  Applications that
 employ SDP are free to use additional SDP signaling for cases not
 covered here.  In addition, applications are free to use signaling
 mechanisms other than SDP.

Friedman, et al. Standards Track [Page 6] RFC 3611 RTCP XR November 2003

1.2. Terminology

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in BCP 14, RFC 2119 [1]
 and indicate requirement levels for compliance with this
 specification.

2. XR Packet Format

 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
 packet is laid out in a manner consistent with other RTCP packets, as
 concerns the essential version, packet type, and length information.
 XR packets are thus backwards compatible with RTCP receiver
 implementations that do not recognize them, but that ought to be able
 to parse past them using the length information.  A padding field and
 an SSRC field are also provided in the same locations that they
 appear in other RTCP packets, for simplicity.  The format is as
 follows:
  0                   1                   2                   3
  0 1 2 3 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            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              SSRC                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                         report blocks                         :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 version (V): 2 bits
       Identifies the version of RTP.  This specification applies to
       RTP version two.
 padding (P): 1 bit
       If the padding bit is set, this XR packet contains some
       additional padding octets at the end.  The semantics of this
       field are identical to the semantics of the padding field in
       the SR packet, as defined by the RTP specification.
 reserved: 5 bits
       This field is reserved for future definition.  In the absence
       of such definition, the bits in this field MUST be set to zero
       and MUST be ignored by the receiver.

Friedman, et al. Standards Track [Page 7] RFC 3611 RTCP XR November 2003

 packet type (PT): 8 bits
       Contains the constant 207 to identify this as an RTCP XR
       packet.  This value is registered with the Internet Assigned
       Numbers Authority (IANA), as described in Section 6.1.
 length: 16 bits
       As described for the RTCP Sender Report (SR) packet (see
       Section 6.4.1 of the RTP specification [9]).  Briefly, the
       length of this XR packet in 32-bit words minus one, including
       the header and any padding.
 SSRC: 32 bits
       The synchronization source identifier for the originator of
       this XR packet.
 report blocks: variable length.
       Zero or more extended report blocks.  In keeping with the
       extended report block framework defined below, each block MUST
       consist of one or more 32-bit words.

3. Extended Report Block Framework

 Extended report blocks are stacked, one after the other, at the end
 of an XR packet.  An individual block's length is a multiple of 4
 octets.  The XR header's length field describes the total length of
 the packet, including these extended report blocks.
 Each block has block type and length fields that facilitate parsing.
 A receiving application can demultiplex the blocks based upon their
 type, and can use the length information to locate each successive
 block, even in the presence of block types it does not recognize.
 An extended report block has the following format:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      BT       | type-specific |         block length          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :             type-specific block contents                      :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 block type (BT): 8 bits
       Identifies the block format.  Seven block types are defined in
       Section 4.  Additional block types may be defined in future
       specifications.  This field's name space is managed by the
       Internet Assigned Numbers Authority (IANA), as described in
       Section 6.2.

Friedman, et al. Standards Track [Page 8] RFC 3611 RTCP XR November 2003

 type-specific: 8 bits
       The use of these bits is determined by the block type
       definition.
 block length: 16 bits
       The length of this report block, including the header, in 32-
       bit words minus one.  If the block type definition permits,
       zero is an acceptable value, signifying a block that consists
       of only the BT, type-specific, and block length fields, with a
       null type-specific block contents field.
 type-specific block contents: variable length
       The use of this field is defined by the particular block type,
       subject to the constraint that it MUST be a multiple of 32 bits
       long.  If the block type definition permits, It MAY be zero
       bits long.

4. Extended Report Blocks

 This section defines seven extended report blocks: block types for
 reporting upon received packet losses and duplicates, packet
 reception times, receiver reference time information, receiver
 inter-report delays, detailed reception statistics, and voice over IP
 (VoIP) metrics.  An implementation SHOULD ignore incoming blocks with
 types not relevant or unknown to it.  Additional block types MUST be
 registered with the Internet Assigned Numbers Authority (IANA) [16],
 as described in Section 6.2.

4.1. Loss RLE Report Block

 This block type permits detailed reporting upon individual packet
 receipt and loss events.  Such reports can be used, for example, for
 multicast inference of network characteristics (MINC) [11].  With
 MINC, one can discover the topology of the multicast tree used for
 distributing a source's RTP packets, and of the loss rates along
 links within that tree, or they could be used to provide raw data to
 a network management application.
 Since a Boolean trace of lost and received RTP packets is potentially
 lengthy, this block type permits the trace to be compressed through
 run length encoding.  To further reduce block size, loss event
 reports can be systematically dropped from the trace in a mechanism
 called thinning that is described below and that is studied in [13].
 A participant that generates a Loss RLE Report Block should favor
 accuracy in reporting on observed events over interpretation of those
 events whenever possible.  Interpretation should be left to those who
 observe the report blocks.  Following this approach implies that

Friedman, et al. Standards Track [Page 9] RFC 3611 RTCP XR November 2003

 accounting for Loss RLE Report Blocks will differ from the accounting
 for the generation of the SR and RR packets described in the RTP
 specification [9] in the following two areas: per-sender accounting
 and per-packet accounting.
 In its per-sender accounting, an RTP session participant SHOULD NOT
 make the receipt of a threshold minimum number of RTP packets a
 condition for reporting upon the sender of those packets.  This
 accounting technique differs from the technique described in Section
 6.2.1 and Appendix A.1 of the RTP specification that allows a
 threshold to determine whether a sender is considered valid.
 In its per-packet accounting, an RTP session participant SHOULD treat
 all sequence numbers as valid.  This accounting technique differs
 from the technique described in Appendix A.1 of the RTP specification
 that suggests ruling a sequence number valid or invalid on the basis
 of its contiguity with the sequence numbers of previously received
 packets.
 Sender validity and sequence number validity are interpretations of
 the raw data.  Such interpretations are justified in the interest,
 for example, of excluding the stray old packet from an unrelated
 session from having an effect upon the calculation of the RTCP
 transmission interval.  The presence of stray packets might, on the
 other hand, be of interest to a network monitoring application.
 One accounting interpretation that is still necessary is for a
 participant to decide whether the 16 bit sequence number has rolled
 over.  Under ordinary circumstances this is not a difficult task.
 For example, if packet number 65,535 (the highest possible sequence
 number) is followed shortly by packet number 0, it is reasonable to
 assume that there has been a rollover.  However, it is possible that
 the packet is an earlier one (from 65,535 packets earlier).  It is
 also possible that the sequence numbers have rolled over multiple
 times, either forward or backward.  The interpretation becomes more
 difficult when there are large gaps between the sequence numbers,
 even accounting for rollover, and when there are long intervals
 between received packets.
 The per-packet accounting technique mandated here is for a
 participant to keep track of the sequence number of the packet most
 recently received from a sender.  For the next packet that arrives
 from that sender, the sequence number MUST be judged to fall no more
 than 32,768 packets ahead or behind the most recent one, whichever
 choice places it closer.  In the event that both choices are equally
 distant (only possible when the distance is 32,768), the choice MUST
 be the one that does not require a rollover.  Appendix A.1 presents
 an algorithm that implements this technique.

Friedman, et al. Standards Track [Page 10] RFC 3611 RTCP XR November 2003

 Each block reports on a single RTP data packet source, identified by
 its SSRC.  The receiver that is supplying the report is identified in
 the header of the RTCP packet.
 Choice of beginning and ending RTP packet sequence numbers for the
 trace is left to the application.  These values are reported in the
 block.  The last sequence number in the trace MAY differ from the
 sequence number reported on in any accompanying SR or RR report.
 Note that because of sequence number wraparound, the ending sequence
 number MAY be less than the beginning sequence number.  A Loss RLE
 Report Block MUST NOT be used to report upon a range of 65,534 or
 greater in the sequence number space, as there is no means of
 identifying multiple wraparounds.
 The trace described by a Loss RLE report consists of a sequence of
 Boolean values, one for each sequence number of the trace.  A value
 of one represents a packet receipt, meaning that one or more packets
 having that sequence number have been received since the most recent
 wraparound of sequence numbers (or since the beginning of the RTP
 session if no wraparound has been judged to have occurred).  A value
 of zero represents a packet loss, meaning that there has been no
 packet receipt for that sequence number as of the time of the report.
 If a packet with a given sequence number is received after a report
 of a loss for that sequence number, a later Loss RLE report MAY
 report a packet receipt for that sequence number.
 The encoding itself consists of a series of 16 bit units called
 chunks that describe sequences of packet receipts or losses in the
 trace.  Each chunk either specifies a run length or a bit vector, or
 is a null chunk.  A run length describes between 1 and 16,383 events
 that are all the same (either all receipts or all losses).  A bit
 vector describes 15 events that may be mixed receipts and losses.  A
 null chunk describes no events, and is used to round out the block to
 a 32 bit word boundary.
 The mapping from a sequence of lost and received packets into a
 sequence of chunks is not necessarily unique.  For example, the
 following trace covers 45 packets, of which the 22nd and 24th have
 been lost and the others received:
    1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1

Friedman, et al. Standards Track [Page 11] RFC 3611 RTCP XR November 2003

 One way to encode this would be:
    bit vector 1111 1111 1111 111
    bit vector 1111 1101 0111 111
    bit vector 1111 1111 1111 111
    null chunk
 Another way to encode this would be:
    run of 21 receipts
    bit vector 0101 1111 1111 111
    run of 9 receipts
    null chunk
 The choice of encoding is left to the application.  As part of this
 freedom of choice, applications MAY terminate a series of run length
 and bit vector chunks with a bit vector chunk that runs beyond the
 sequence number space described by the report block.  For example, if
 the 44th packet in the same sequence was lost:
    1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
 This could be encoded as:
    run of 21 receipts
    bit vector 0101 1111 1111 111
    bit vector 1111 1110 1000 000
    null chunk
 In this example, the last five bits of the second bit vector describe
 a part of the sequence number space that extends beyond the last
 sequence number in the trace.  These bits have been set to zero.
 All bits in a bit vector chunk that describe a part of the sequence
 number space that extends beyond the last sequence number in the
 trace MUST be set to zero, and MUST be ignored by the receiver.
 A null packet MUST appear at the end of a Loss RLE Report Block if
 the number of run length plus bit vector chunks is odd.  The null
 chunk MUST NOT appear in any other context.
 Caution should be used in sending Loss RLE Report Blocks because,
 even with the compression provided by run length encoding, they can
 easily consume bandwidth out of proportion with normal RTCP packets.
 The block type includes a mechanism, called thinning, that allows an
 application to limit report sizes.

Friedman, et al. Standards Track [Page 12] RFC 3611 RTCP XR November 2003

 A thinning value, T, selects a subset of packets within the sequence
 number space: those with sequence numbers that are multiples of 2^T.
 Packet reception and loss reports apply only to those packets.  T can
 vary between 0 and 15.  If T is zero, then every packet in the
 sequence number space is reported upon.  If T is fifteen, then one in
 every 32,768 packets is reported upon.
 Suppose that the trace just described begins at sequence number
 13,821.  The last sequence number in the trace is 13,865.  If the
 trace were to be thinned with a thinning value of T=2, then the
 following sequence numbers would be reported upon: 13,824, 13,828,
 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860,
 13,864.  The thinned trace would be as follows:
    1    1    1    1    1    0    1    1    1    1    0
 This could be encoded as follows:
    bit vector 1111 1011 1100 000
    null chunk
 The last four bits in the bit vector, representing sequence numbers
 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are
 thus set to zero and are ignored by the receiver.  With thinning, the
 loss of the 22nd packet goes unreported because its sequence number,
 13,842, is not a multiple of four.  Packet receipts for all sequence
 numbers that are not multiples of four also go unreported.  However,
 in this example thinning has permitted the Loss RLE Report Block to
 be shortened by one 32 bit word.
 Choice of the thinning value is left to the application.

Friedman, et al. Standards Track [Page 13] RFC 3611 RTCP XR November 2003

 The Loss RLE Report Block has the following format:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     BT=1      | rsvd. |   T   |         block length          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        SSRC of source                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          begin_seq            |             end_seq           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          chunk 1              |             chunk 2           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                              ...                              :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          chunk n-1            |             chunk n           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 block type (BT): 8 bits
       A Loss RLE Report Block is identified by the constant 1.
 rsvd.: 4 bits
       This field is reserved for future definition.  In the absence
       of such definition, the bits in this field MUST be set to zero
       and MUST be ignored by the receiver.
 thinning (T): 4 bits
       The amount of thinning performed on the sequence number space.
       Only those packets with sequence numbers 0 mod 2^T are reported
       on by this block.  A value of 0 indicates that there is no
       thinning, and all packets are reported on.  The maximum
       thinning is one packet in every 32,768 (amounting to two
       packets within each 16-bit sequence space).
 block length: 16 bits
       Defined in Section 3.
 SSRC of source: 32 bits
       The SSRC of the RTP data packet source being reported upon by
       this report block.
 begin_seq: 16 bits
       The first sequence number that this block reports on.
 end_seq: 16 bits
       The last sequence number that this block reports on plus one.

Friedman, et al. Standards Track [Page 14] RFC 3611 RTCP XR November 2003

 chunk i: 16 bits
       There are three chunk types: run length, bit vector, and
       terminating null, defined in the following sections.  If the
       chunk is all zeroes, then it is a terminating null chunk.
       Otherwise, the left most bit of the chunk determines its type:
       0 for run length and 1 for bit vector.

4.1.1. Run Length Chunk

  0                   1
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |C|R|        run length         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 chunk type (C): 1 bit
       A zero identifies this as a run length chunk.
 run type (R): 1 bit
       Zero indicates a run of 0s.  One indicates a run of 1s.
 run length: 14 bits
       A value between 1 and 16,383.  The value MUST not be zero for a
       run length chunk (zeroes in both the run type and run length
       fields would make the chunk a terminating null chunk).  Run
       lengths of 15 or less MAY be described with a run length chunk
       despite the fact that they could also be described as part of a
       bit vector chunk.

4.1.2. Bit Vector Chunk

  0                   1
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |C|        bit vector           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 chunk type (C): 1 bit
       A one identifies this as a bit vector chunk.
 bit vector: 15 bits
       The vector is read from left to right, in order of increasing
       sequence number (with the appropriate allowance for
       wraparound).

Friedman, et al. Standards Track [Page 15] RFC 3611 RTCP XR November 2003

4.1.3. Terminating Null Chunk

 This chunk is all zeroes.
  0                   1
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2. Duplicate RLE Report Block

 This block type permits per-sequence-number reports on duplicates in
 a source's RTP packet stream.  Such information can be used for
 network diagnosis, and provide an alternative to packet losses as a
 basis for multicast tree topology inference.
 The Duplicate RLE Report Block format is identical to the Loss RLE
 Report Block format.  Only the interpretation is different, in that
 the information concerns packet duplicates rather than packet losses.
 The trace to be encoded in this case also consists of zeros and ones,
 but a zero here indicates the presence of duplicate packets for a
 given sequence number, whereas a one indicates that no duplicates
 were received.
 The existence of a duplicate for a given sequence number is
 determined over the entire reporting period.  For example, if packet
 number 12,593 arrives, followed by other packets with other sequence
 numbers, the arrival later in the reporting period of another packet
 numbered 12,593 counts as a duplicate for that sequence number.  The
 duplicate does not need to follow immediately upon the first packet
 of that number.  Care must be taken that a report does not cover a
 range of 65,534 or greater in the sequence number space.
 No distinction is made between the existence of a single duplicate
 packet and multiple duplicate packets for a given sequence number.
 Note also that since there is no duplicate for a lost packet, a loss
 is encoded as a one in a Duplicate RLE Report Block.

Friedman, et al. Standards Track [Page 16] RFC 3611 RTCP XR November 2003

 The Duplicate RLE Report Block has the following format:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     BT=2      | rsvd. |   T   |         block length          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        SSRC of source                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          begin_seq            |             end_seq           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          chunk 1              |             chunk 2           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                              ...                              :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          chunk n-1            |             chunk n           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 block type (BT): 8 bits
       A Duplicate RLE Report Block is identified by the constant 2.
 rsvd.: 4 bits
       This field is reserved for future definition.  In the absence
       of such a definition, the bits in this field MUST be set to
       zero and MUST be ignored by the receiver.
 thinning (T): 4 bits
       As defined in Section 4.1.
 block length: 16 bits
       Defined in Section 3.
 SSRC of source: 32 bits
       As defined in Section 4.1.
 begin_seq: 16 bits
       As defined in Section 4.1.
 end_seq: 16 bits
       As defined in Section 4.1.
 chunk i: 16 bits
       As defined in Section 4.1.

Friedman, et al. Standards Track [Page 17] RFC 3611 RTCP XR November 2003

4.3. Packet Receipt Times Report Block

 This block type permits per-sequence-number reports on packet receipt
 times for a given source's RTP packet stream.  Such information can
 be used for MINC inference of the topology of the multicast tree used
 to distribute the source's RTP packets, and of the delays along the
 links within that tree.  It can also be used to measure partial path
 characteristics and to model distributions for packet jitter.
 Packet receipt times are expressed in the same units as in the RTP
 timestamps of data packets.  This is so that, for each packet, one
 can establish both the send time and the receipt time in comparable
 terms.  Note, however, that as an RTP sender ordinarily initializes
 its time to a value chosen at random, there can be no expectation
 that reported send and receipt times will differ by an amount equal
 to the one-way delay between sender and receiver.  The reported times
 can nonetheless be useful for the purposes mentioned above.
 At least one packet MUST have been received for each sequence number
 reported upon in this block.  If this block type is used to report
 receipt times for a series of sequence numbers that includes lost
 packets, several blocks are required.  If duplicate packets have been
 received for a given sequence number, and those packets differ in
 their receipt times, any time other than the earliest MUST NOT be
 reported.  This is to ensure consistency among reports.
 Times reported in RTP timestamp format consume more bits than loss or
 duplicate information, and do not lend themselves to run length
 encoding.  The use of thinning is encouraged to limit the size of
 Packet Receipt Times Report Blocks.

Friedman, et al. Standards Track [Page 18] RFC 3611 RTCP XR November 2003

 The Packet Receipt Times Report Block has the following format:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     BT=3      | rsvd. |   T   |         block length          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        SSRC of source                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          begin_seq            |             end_seq           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       Receipt time of packet begin_seq                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       Receipt time of packet (begin_seq + 1) mod 65536        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                              ...                              :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       Receipt time of packet (end_seq - 1) mod 65536          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 block type (BT): 8 bits
       A Packet Receipt Times Report Block is identified by the
       constant 3.
 rsvd.: 4 bits
       This field is reserved for future definition.  In the absence
       of such a definition, the bits in this field MUST be set to
       zero and MUST be ignored by the receiver.
 thinning (T): 4 bits
       As defined in Section 4.1.
 block length: 16 bits
       Defined in Section 3.
 SSRC of source: 32 bits
       As defined in Section 4.1.
 begin_seq: 16 bits
       As defined in Section 4.1.
 end_seq: 16 bits
       As defined in Section 4.1.

Friedman, et al. Standards Track [Page 19] RFC 3611 RTCP XR November 2003

 Packet i receipt time: 32 bits
       The receipt time of the packet with sequence number i at the
       receiver.  The modular arithmetic shown in the packet format
       diagram is to allow for sequence number rollover.  It is
       preferable for the time value to be established at the link
       layer interface, or in any case as close as possible to the
       wire arrival time.  Units and format are the same as for the
       timestamp in RTP data packets.  As opposed to RTP data packet
       timestamps, in which nominal values may be used instead of
       system clock values in order to convey information useful for
       periodic playout, the receipt times should reflect the actual
       time as closely as possible.  For a session, if the RTP
       timestamp is chosen at random, the first receipt time value
       SHOULD also be chosen at random, and subsequent timestamps
       offset from this value.  On the other hand, if the RTP
       timestamp is meant to reflect the reference time at the sender,
       then the receipt time SHOULD be as close as possible to the
       reference time at the receiver.

4.4. Receiver Reference Time Report Block

 This block extends RTCP's timestamp reporting so that non-senders may
 also send timestamps.  It recapitulates the NTP timestamp fields from
 the RTCP Sender Report [9, Sec. 6.3.1].  A non-sender may estimate
 its round trip time (RTT) to other participants, as proposed in [18],
 by sending this report block and receiving DLRR Report Blocks (see
 next section) in reply.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     BT=4      |   reserved    |       block length = 2        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              NTP timestamp, most significant word             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             NTP timestamp, least significant word             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 block type (BT): 8 bits
       A Receiver Reference Time Report Block is identified by the
       constant 4.
 reserved: 8 bits
       This field is reserved for future definition.  In the absence
       of such definition, the bits in this field MUST be set to zero
       and MUST be ignored by the receiver.

Friedman, et al. Standards Track [Page 20] RFC 3611 RTCP XR November 2003

 block length: 16 bits
       The constant 2, in accordance with the definition of this field
       in Section 3.
 NTP timestamp: 64 bits
       Indicates the wallclock time when this block was sent so that
       it may be used in combination with timestamps returned in DLRR
       Report Blocks (see next section) from other receivers to
       measure round-trip propagation to those receivers.  Receivers
       should expect that the measurement accuracy of the timestamp
       may be limited to far less than the resolution of the NTP
       timestamp.  The measurement uncertainty of the timestamp is not
       indicated as it may not be known.  A report block sender that
       can keep track of elapsed time but has no notion of wallclock
       time may use the elapsed time since joining the session
       instead.  This is assumed to be less than 68 years, so the high
       bit will be zero.  It is permissible to use the sampling clock
       to estimate elapsed wallclock time.  A report sender that has
       no notion of wallclock or elapsed time may set the NTP
       timestamp to zero.

4.5. DLRR Report Block

 This block extends RTCP's delay since the last Sender Report (DLSR)
 mechanism [9, Sec. 6.3.1] so that non-senders may also calculate
 round trip times, as proposed in [18].  It is termed DLRR for delay
 since the last Receiver Report, and may be sent in response to a
 Receiver Timestamp Report Block (see previous section) from a
 receiver to allow that receiver to calculate its round trip time to
 the respondent.  The report consists of one or more 3 word sub-
 blocks: one sub-block per Receiver Report.
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=5 | reserved | block length | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block | last RR (LRR) | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last RR (DLRR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 (SSRC of second receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block : … : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Friedman, et al. Standards Track [Page 21] RFC 3611 RTCP XR November 2003

 block type (BT): 8 bits
       A DLRR Report Block is identified by the constant 5.
 reserved: 8 bits
       This field is reserved for future definition.  In the absence
       of such definition, the bits in this field MUST be set to zero
       and MUST be ignored by the receiver.
 block length: 16 bits
       Defined in Section 3.
 last RR timestamp (LRR): 32 bits
       The middle 32 bits out of 64 in the NTP timestamp (as explained
       in the previous section), received as part of a Receiver
       Reference Time Report Block from participant SSRC_n.  If no
       such block has been received, the field is set to zero.
 delay since last RR (DLRR): 32 bits
       The delay, expressed in units of 1/65536 seconds, between
       receiving the last Receiver Reference Time Report Block from
       participant SSRC_n and sending this DLRR Report Block.  If a
       Receiver Reference Time Report Block has yet to be received
       from SSRC_n, the DLRR field is set to zero (or the DLRR is
       omitted entirely).  Let SSRC_r denote the receiver issuing this
       DLRR Report Block.  Participant SSRC_n can compute the round-
       trip propagation delay to SSRC_r by recording the time A when
       this Receiver Timestamp Report Block is received.  It
       calculates the total round-trip time A-LRR using the last RR
       timestamp (LRR) field, and then subtracting this field to leave
       the round-trip propagation delay as A-LRR-DLRR.  This is
       illustrated in [9, Fig. 2].

4.6. Statistics Summary Report Block

 This block reports statistics beyond the information carried in the
 standard RTCP packet format, but is not as finely grained as that
 carried in the report blocks previously described.  Information is
 recorded about lost packets, duplicate packets, jitter measurements,
 and TTL or Hop Limit values.  Such information can be useful for
 network management.
 The report block contents are dependent upon a series of flag bits
 carried in the first part of the header.  Not all parameters need to
 be reported in each block.  Flags indicate which are and which are
 not reported.  The fields corresponding to unreported parameters MUST
 be present, but are set to zero.  The receiver MUST ignore any
 Statistics Summary Report Block with a non-zero value in any field
 flagged as unreported.

Friedman, et al. Standards Track [Page 22] RFC 3611 RTCP XR November 2003

 The Statistics Summary Report Block has the following format:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     BT=6      |L|D|J|ToH|rsvd.|       block length = 9        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        SSRC of source                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          begin_seq            |             end_seq           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        lost_packets                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        dup_packets                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         min_jitter                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         max_jitter                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         mean_jitter                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         dev_jitter                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | min_ttl_or_hl | max_ttl_or_hl |mean_ttl_or_hl | dev_ttl_or_hl |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 block type (BT): 8 bits
       A Statistics Summary Report Block is identified by the constant
       6.
 loss report flag (L): 1 bit
       Bit set to 1 if the lost_packets field contains a report, 0
       otherwise.
 duplicate report flag (D): 1 bit
       Bit set to 1 if the dup_packets field contains a report, 0
       otherwise.
 jitter flag (J): 1 bit
       Bit set to 1 if the min_jitter, max_jitter, mean_jitter, and
       dev_jitter fields all contain reports, 0 if none of them do.
 TTL or Hop Limit flag (ToH): 2 bits
       This field is set to 0 if none of the fields min_ttl_or_hl,
       max_ttl_or_hl, mean_ttl_or_hl, or dev_ttl_or_hl contain
       reports.  If the field is non-zero, then all of these fields
       contain reports.  The value 1 signifies that they report on
       IPv4 TTL values.  The value 2 signifies that they report on

Friedman, et al. Standards Track [Page 23] RFC 3611 RTCP XR November 2003

       IPv6 Hop Limit values.  The value 3 is undefined and MUST NOT
       be used.
 rsvd.: 3 bits
       This field is reserved for future definition.  In the absence
       of such a definition, the bits in this field MUST be set to
       zero and MUST be ignored by the receiver.
 block length: 16 bits
       The constant 9, in accordance with the definition of this field
       in Section 3.
 SSRC of source: 32 bits
       As defined in Section 4.1.
 begin_seq: 16 bits
       As defined in Section 4.1.
 end_seq: 16 bits
       As defined in Section 4.1.
 lost_packets: 32 bits
       Number of lost packets in the above sequence number interval.
 dup_packets: 32 bits
       Number of duplicate packets in the above sequence number
       interval.
 min_jitter: 32 bits
       The minimum relative transit time between two packets in the
       above sequence number interval.  All jitter values are measured
       as the difference between a packet's RTP timestamp and the
       reporter's clock at the time of arrival, measured in the same
       units.
 max_jitter: 32 bits
       The maximum relative transit time between two packets in the
       above sequence number interval.
 mean_jitter: 32 bits
       The mean relative transit time between each two packet series
       in the above sequence number interval, rounded to the nearest
       value expressible as an RTP timestamp.
 dev_jitter: 32 bits
       The standard deviation of the relative transit time between
       each two packet series in the above sequence number interval.

Friedman, et al. Standards Track [Page 24] RFC 3611 RTCP XR November 2003

 min_ttl_or_hl: 8 bits
       The minimum TTL or Hop Limit value of data packets in the
       sequence number range.
 max_ttl_or_hl: 8 bits
       The maximum TTL or Hop Limit value of data packets in the
       sequence number range.
 mean_ttl_or_hl: 8 bits
       The mean TTL or Hop Limit value of data packets in the sequence
       number range, rounded to the nearest integer.
 dev_ttl_or_hl: 8 bits
       The standard deviation of TTL or Hop Limit values of data
       packets in the sequence number range.

4.7. VoIP Metrics Report Block

 The VoIP Metrics Report Block provides metrics for monitoring voice
 over IP (VoIP) calls.  These metrics include packet loss and discard
 metrics, delay metrics, analog metrics, and voice quality metrics.
 The block reports separately on packets lost on the IP channel, and
 those that have been received but then discarded by the receiving
 jitter buffer.  It also reports on the combined effect of losses and
 discards, as both have equal effect on call quality.
 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].  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 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 loss rate is high enough to produce noticeable degradation
 in audio quality.  Gaps correspond to periods of time during which
 only isolated lost packets may occur, and in general these can be
 masked by packet loss concealment.  Delay reports include the transit
 delay between RTP end points and the VoIP end system processing
 delays, both of which contribute to the user perceived delay.
 Additional metrics include signal, echo, noise, and distortion
 levels.  Call quality metrics include R factors (as described by the
 E Model defined in [6,3]) and mean opinion scores (MOS scores).
 Implementations MUST provide values for all the fields defined here.
 For certain metrics, if the value is undefined or unknown, then the
 specified default or unknown field value MUST be provided.

Friedman, et al. Standards Track [Page 25] RFC 3611 RTCP XR November 2003

 The block is encoded as seven 32-bit words:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     BT=7      |   reserved    |       block length = 8        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        SSRC of source                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   loss rate   | discard rate  | burst density |  gap density  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       burst duration          |         gap duration          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     round trip delay          |       end system delay        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | signal level  |  noise level  |     RERL      |     Gmin      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   R factor    | ext. R factor |    MOS-LQ     |    MOS-CQ     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   RX config   |   reserved    |          JB nominal           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          JB maximum           |          JB abs max           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 block type (BT): 8 bits
       A VoIP Metrics Report Block is identified by the constant 7.
 reserved: 8 bits
       This field is reserved for future definition.  In the absence
       of such a definition, the bits in this field MUST be set to
       zero and MUST be ignored by the receiver.
 block length: 16 bits
       The constant 8, in accordance with the definition of this field
       in Section 3.
 SSRC of source: 32 bits
       As defined in Section 4.1.
 The remaining fields are described in the following six sections:
 Packet Loss and Discard Metrics, Delay Metrics, Signal Related
 Metrics, Call Quality or Transmission Quality Metrics, Configuration
 Metrics, and Jitter Buffer Parameters.

Friedman, et al. Standards Track [Page 26] RFC 3611 RTCP XR November 2003

4.7.1. Packet Loss and Discard Metrics

 It is very useful to distinguish between packets lost by the network
 and those discarded due to jitter.  Both have equal effect on the
 quality of the voice stream, however, having separate counts helps
 identify the source of quality degradation.  These fields MUST be
 populated, and MUST be set to zero if no packets have been received.
 loss rate: 8 bits
       The fraction of RTP data packets from the source lost since the
       beginning of reception, expressed as a fixed point number with
       the binary point at the left edge of the field.  This value is
       calculated by dividing the total number of packets lost (after
       the effects of applying any error protection such as FEC) by
       the total number of packets expected, multiplying the result of
       the division by 256, limiting the maximum value to 255 (to
       avoid overflow), and taking the integer part.  The numbers of
       duplicated packets and discarded packets do not enter into this
       calculation.  Since receivers cannot be required to maintain
       unlimited buffers, a receiver MAY categorize late-arriving
       packets as lost.  The degree of lateness that triggers a loss
       SHOULD be significantly greater than that which triggers a
       discard.
 discard rate: 8 bits
       The fraction of RTP data packets from the source that have been
       discarded since the beginning of reception, due to late or
       early arrival, under-run or overflow at the receiving jitter
       buffer.  This value is expressed as a fixed point number with
       the binary point at the left edge of the field.  It is
       calculated by dividing the total number of packets discarded
       (excluding duplicate packet discards) by the total number of
       packets expected, multiplying the result of the division by
       256, limiting the maximum value to 255 (to avoid overflow), and
       taking the integer part.

4.7.2. Burst Metrics

 A burst is a period during which a high proportion of packets are
 either lost or discarded due to late arrival.  A burst is defined, in
 terms of a value Gmin, as the longest sequence that (a) starts with a
 lost or discarded packet, (b) does not contain any occurrences of
 Gmin or more consecutively received (and not discarded) packets, and
 (c) ends with a lost or discarded packet.
 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
 from the start of an RTP session to the receipt time of the last

Friedman, et al. Standards Track [Page 27] RFC 3611 RTCP XR November 2003

 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
 RTP session, whichever comes first, or (c) the period of time between
 two bursts.
 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
 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
 at least Gmin received packets.
 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
 received and not discarded.  This gives a maximum loss/discard rate
 within a gap of: 1 / (Gmin + 1).
 A Gmin value of 16 is RECOMMENDED, as it results in gap
 characteristics that correspond to good quality (i.e., low packet
 loss rate, a minimum distance of 16 received packets between lost
 packets), and hence differentiates nicely between good and poor
 quality periods.
 For example, a 1 denotes a received packet, 0 a lost packet, and X a
 discarded packet in the following pattern covering 64 packets:
    11110111111111111111111X111X1011110111111111111111111X111111111
    |---------gap----------|--burst---|------------gap------------|
 The burst consists of the twelve packets indicated above, starting at
 a discarded packet and ending at a lost packet.  The first gap starts
 at the beginning of the session and the second gap ends at the time
 of the report.
 If the packet spacing is 10 ms and the Gmin value is the recommended
 value of 16, the burst duration is 120 ms, the burst density 0.33,
 the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04.
 This would result in reported values as follows (see field
 descriptions for semantics and details on how these are calculated):
    loss rate             12, which corresponds to 5%
    discard rate          12, which corresponds to 5%
    burst density         84, which corresponds to 33%
    gap density           10, which corresponds to 4%
    burst duration       120, value in milliseconds
    gap duration         520, value in milliseconds

Friedman, et al. Standards Track [Page 28] RFC 3611 RTCP XR November 2003

 burst density: 8 bits
       The fraction of RTP data packets within burst periods since the
       beginning of reception that were either lost or discarded.
       This value is expressed as a fixed point number with the binary
       point at the left edge of the field.  It is calculated by
       dividing the total number of packets lost or discarded
       (excluding duplicate packet discards) within burst periods by
       the total number of packets expected within the burst periods,
       multiplying the result of the division by 256, limiting the
       maximum value to 255 (to avoid overflow), and taking the
       integer part.  This field MUST be populated and MUST be set to
       zero if no packets have been received.
 gap density: 8 bits
       The fraction of RTP data packets within inter-burst gaps since
       the beginning of reception that were either lost or discarded.
       The value is expressed as a fixed point number with the binary
       point at the left edge of the field.  It is calculated by
       dividing the total number of packets lost or discarded
       (excluding duplicate packet discards) within gap periods by the
       total number of packets expected within the gap periods,
       multiplying the result of the division by 256, limiting the
       maximum value to 255 (to avoid overflow), and taking the
       integer part.  This field MUST be populated and MUST be set to
       zero if no packets have been received.
 burst duration: 16 bits
       The mean duration, expressed in milliseconds, of the burst
       periods that have occurred since the beginning of reception.
       The duration of each period is calculated based upon the
       packets that mark the beginning and end of that period.  It is
       equal to the timestamp of the end packet, plus the duration of
       the end packet, minus the timestamp of the beginning packet.
       If the actual values are not available, estimated values MUST
       be used.  If there have been no burst periods, the burst
       duration value MUST be zero.
 gap duration: 16 bits
       The mean duration, expressed in milliseconds, of the gap
       periods that have occurred since the beginning of reception.
       The duration of each period is calculated based upon the packet
       that marks the end of the prior burst and the packet that marks
       the beginning of the subsequent burst.  It is equal to the
       timestamp of the subsequent burst packet, minus the timestamp
       of the prior burst packet, plus the duration of the prior burst
       packet.  If the actual values are not available, estimated
       values MUST be used.  In the case of a gap that occurs at the
       beginning of reception, the sum of the timestamp of the prior

Friedman, et al. Standards Track [Page 29] RFC 3611 RTCP XR November 2003

       burst packet and the duration of the prior burst packet are
       replaced by the reception start time.  In the case of a gap
       that occurs at the end of reception, the timestamp of the
       subsequent burst packet is replaced by the reception end time.
       If there have been no gap periods, the gap duration value MUST
       be zero.

4.7.3. Delay Metrics

 For the purpose of the following definitions, the RTP interface is
 the interface between the RTP instance and the voice application
 (i.e., FEC, de-interleaving, de-multiplexing, jitter buffer).  For
 example, the time delay due to RTP payload multiplexing would be
 considered part of the voice application or end-system delay, whereas
 delay due to multiplexing RTP frames within a UDP frame would be
 considered part of the RTP reported delay.  This distinction is
 consistent with the use of RTCP for delay measurements.
 round trip delay: 16 bits
       The most recently calculated round trip time between RTP
       interfaces, expressed in milliseconds.  This value MAY be
       measured using RTCP, the DLRR method defined in Section 4.5 of
       this document, where it is necessary to convert the units of
       measurement from NTP timestamp values to milliseconds, or other
       approaches.  If RTCP is used, then the reported delay value is
       the time of receipt of the most recent RTCP packet from source
       SSRC, minus the LSR (last SR) time reported in its SR (Sender
       Report), minus the DLSR (delay since last SR) reported in its
       SR.  A non-zero LSR value is required in order to 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
       The most recently estimated end system delay, expressed in
       milliseconds.  End system delay is defined as the sum of the
       total sample accumulation and encoding delay associated with
       the sending direction and the jitter buffer, decoding, and
       playout buffer delay associated with the receiving direction.
       This delay MAY be estimated or measured.  This value SHOULD be
       provided in all VoIP metrics reports.  If an implementation is
       unable to provide the data, the value 0 MUST be used.

Friedman, et al. Standards Track [Page 30] RFC 3611 RTCP XR November 2003

 Note that the one way symmetric VoIP segment delay may be calculated
 from the round trip and end system delays is as follows; if the round
 trip delay is denoted, RTD and the end system delays associated with
 the two endpoints are ESD(A) and ESD(B) then:
  one way symmetric voice path delay  =  ( RTD + ESD(A) + ESD(B) ) / 2

4.7.4. Signal Related Metrics

 The following metrics are intended to provide real time information
 related to the non-packet elements of the voice over IP system to
 assist with the identification of problems affecting call quality.
 The values identified below must be determined for the received audio
 signal.  The information required to populate these fields may not be
 available in all systems, although it is strongly recommended that
 this data SHOULD be provided to support problem diagnosis.
 signal level: 8 bits
       The voice signal relative level is defined as the ratio of the
       signal level to a 0 dBm0 reference [10], expressed in decibels
       as a signed integer in two's complement form.  This is measured
       only for packets containing speech energy.  The intent of this
       metric is not to provide a precise measurement of the signal
       level but to provide a real time indication that the signal
       level may be excessively high or low.
       signal level = 10 Log10 ( rms talkspurt power (mW) )
       A value of 127 indicates that this parameter is unavailable.
       Typical values should generally be in the -15 to -20 dBm range.
 noise level: 8 bits
       The noise level is defined as the ratio of the silent period
       background noise level to a 0 dBm0 reference, expressed in
       decibels as a signed integer in two's complement form.
       noise level = 10 Log10 ( rms silence power (mW) )
       A value of 127 indicates that this parameter is unavailable.
 residual echo return loss (RERL): 8 bits
       The residual echo return loss value may be measured directly by
       the VoIP end system's echo canceller or may be estimated by
       adding the echo return loss (ERL) and echo return loss
       enhancement (ERLE) values reported by the echo canceller.
       RERL(dB) = ERL (dB) + ERLE (dB)

Friedman, et al. Standards Track [Page 31] RFC 3611 RTCP XR November 2003

       In the case of a VoIP gateway, the source of echo is typically
       line echo that occurs at 2-4 wire conversion points in the
       network.  This can be in the 8-12 dB range.  A line echo
       canceler can provide an ERLE of 30 dB or more and hence reduce
       this to 40-50 dB.  In the case of an IP phone, this could be
       acoustic coupling between handset speaker and microphone or
       residual acoustic echo from speakerphone operation, and may
       more correctly be termed terminal coupling loss (TCL).  A
       typical handset would result in 40-50 dB of echo loss due to
       acoustic feedback.
       Examples:
  1. IP gateway connected to circuit switched network with 2 wire

loop. Without echo cancellation, typical 2-4 wire converter

          ERL of 12 dB.  RERL = ERL + ERLE = 12 + 0 = 12 dB.
  1. IP gateway connected to circuit switched network with 2 wire

loop. With echo canceler that improves echo by 30 dB.

          RERL = ERL + ERLE = 12 + 30 = 42 dB.
  1. IP phone with conventional handset. Acoustic coupling from

handset speaker to microphone (terminal coupling loss) is

          typically 40 dB.  RERL = TCL = 40 dB.
       If we denote the local end of the VoIP path as A and the remote
       end as B, and if the sender loudness rating (SLR) and receiver
       loudness rating (RLR) are known for A (default values 8 dB and
       2 dB respectively), then the echo loudness level at end A
       (talker echo loudness rating or TELR) is given by:
       TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)
       TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)
       Hence, in order to incorporate echo into a voice quality
       estimate at the A end of a VoIP connection, it is desirable to
       send the ERL + ERLE value from B to A using a format such as
       RTCP XR.
       Echo related information may not be available in all VoIP end
       systems.  As echo does have a significant effect on
       conversational quality, it is recommended that estimated values
       for echo return loss and terminal coupling loss be provided (if
       sensible estimates can be reasonably determined).

Friedman, et al. Standards Track [Page 32] RFC 3611 RTCP XR November 2003

       Typical values for end systems are given below to provide
       guidance:
  1. IP Phone with handset: typically 45 dB.
  1. PC softphone or speakerphone: extremely variable, consider

reporting "undefined" (127).

  1. IP gateway with line echo canceller: typically has ERL and

ERLE available.

  1. IP gateway without line echo canceller: frequently a source

of echo related problems, consider reporting either a low

          value (12 dB) or "undefined" (127).
 Gmin
       See Configuration Parameters (Section 4.7.6, below).

4.7.5. Call Quality or Transmission Quality Metrics

 The following metrics are direct measures of the call quality or
 transmission quality, and incorporate the effects of codec type,
 packet loss, discard, burstiness, delay etc.  These metrics may not
 be available in all systems, however, they SHOULD be provided in
 order to support problem diagnosis.
 R factor: 8 bits
       The R factor is a voice quality metric describing the segment
       of the call that is carried over this RTP session.  It is
       expressed as an integer in the range 0 to 100, with a value of
       94 corresponding to "toll quality" and values of 50 or less
       regarded as unusable.  This metric is defined as including the
       effects of delay, consistent with ITU-T G.107 [6] and ETSI TS
       101 329-5 [3].
       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
       The external R factor is a voice quality metric describing the
       segment of the call that is carried over a network segment
       external to the RTP segment, for example a cellular network.
       Its values are interpreted in the same manner as for the RTP R
       factor.  This metric is defined as including the effects of
       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
       IP termination for which this metrics block applies.

Friedman, et al. Standards Track [Page 33] RFC 3611 RTCP XR November 2003

       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
 factor and the external R factor, as follows:
 R total = RTP R factor + ext. R factor - 94
 MOS-LQ: 8 bits
       The estimated mean opinion score for listening quality (MOS-LQ)
       is a voice quality metric on a scale from 1 to 5, in which 5
       represents excellent and 1 represents unacceptable.  This
       metric is defined as not including the effects of delay and can
       be compared to MOS scores obtained from listening quality (ACR)
       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
       correspond to an estimated MOS score of 3.5.
       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
       The estimated mean opinion score for conversational quality
       (MOS-CQ) is defined as including the effects of delay and other
       effects that would affect conversational quality.  The metric
       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 MOS using the equation specified in G.107.  It is
       expressed as an integer in the range 10 to 50, corresponding to
       MOS x 10, as for MOS-LQ.
       A value of 127 indicates that this parameter is unavailable.
       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

 Gmin: 8 bits
       The gap threshold.  This field contains the value used for this
       report block to determine if a gap exists.  The recommended
       value of 16 corresponds to a burst period having a minimum
       density of 6.25% of lost or discarded packets, which may cause
       noticeable degradation in call quality; during gap periods, if
       packet loss or discard occurs, each lost or discarded packet
       would be preceded by and followed by a sequence of at least 16
       received non-discarded packets.  Note that lost or discarded

Friedman, et al. Standards Track [Page 34] RFC 3611 RTCP XR November 2003

       packets that occur within Gmin packets of a report being
       generated may be reclassified as part of a burst or gap in
       later reports.  ETSI TS 101 329-5 [3] defines a computationally
       efficient algorithm for measuring burst and gap density using a
       packet loss/discard event driven approach.  This algorithm is
       reproduced in Appendix A.2 of the present document.  Gmin MUST
       not be zero, MUST be provided, and MUST remain constant across
       VoIP Metrics report blocks for the duration of the RTP session.
 receiver configuration byte (RX config): 8 bits
       This byte consists of the following fields:
           0 1 2 3 4 5 6 7
          +-+-+-+-+-+-+-+-+
          |PLC|JBA|JB rate|
          +-+-+-+-+-+-+-+-+
 packet loss concealment (PLC): 2 bits
       Standard (11) / enhanced (10) / disabled (01) / unspecified
       (00).  When PLC = 11, then a simple replay or interpolation
       algorithm is being used to fill-in the missing packet; this
       approach is typically able to conceal isolated lost packets at
       low packet loss rates.  When PLC = 10, then an enhanced
       interpolation algorithm is being used; algorithms of this type
       are able to conceal high packet loss rates effectively.  When
       PLC = 01, then silence is being inserted in place of lost
       packets.  When PLC = 00, then no information is available
       concerning the use of PLC; however, for some codecs this may be
       inferred.
 jitter buffer adaptive (JBA): 2 bits
       Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown
       (00).  When the jitter buffer is adaptive, then its size is
       being dynamically adjusted to deal with varying levels of
       jitter.  When non-adaptive, the jitter buffer size is
       maintained at a fixed level.  When either adaptive or non-
       adaptive modes are specified, then the jitter buffer size
       parameters below MUST be specified.
 jitter buffer rate (JB rate): 4 bits
       J = adjustment rate (0-15).  This represents the implementation
       specific adjustment rate of a jitter buffer in adaptive mode.
       This parameter is defined in terms of the approximate time
       taken to fully adjust to a step change in peak to peak jitter
       from 30 ms to 100 ms such that:
       adjustment time = 2 * J * frame size (ms)

Friedman, et al. Standards Track [Page 35] RFC 3611 RTCP XR November 2003

       This parameter is intended only to provide a guide to the
       degree of "aggressiveness" of an adaptive jitter buffer and may
       be estimated.  A value of 0 indicates that the adjustment time
       is unknown for this implementation.
 reserved: 8 bits
       This field is reserved for future definition.  In the absence
       of such a definition, the bits in this field MUST be set to
       zero and MUST be ignored by the receiver.

4.7.7. Jitter Buffer Parameters

 The values reported in these fields SHOULD be the most recently
 obtained values at the time of reporting.
 jitter buffer nominal delay (JB nominal): 16 bits
       This is the current nominal jitter buffer delay in
       milliseconds, which corresponds to the nominal jitter buffer
       delay for packets that arrive exactly on time.  This parameter
       MUST be provided for both fixed and adaptive jitter buffer
       implementations.
 jitter buffer maximum delay (JB maximum): 16 bits
       This is the current maximum jitter buffer delay in milliseconds
       which corresponds to the earliest arriving packet that would
       not be discarded.  In simple queue implementations this may
       correspond to the nominal size.  In adaptive jitter buffer
       implementations, this value may dynamically vary up to JB abs
       max (see below).  This parameter MUST be provided for both
       fixed and adaptive jitter buffer implementations.
 jitter buffer absolute maximum delay (JB abs max): 16 bits
       This is the absolute maximum delay in milliseconds that the
       adaptive jitter buffer can reach under worst case conditions.
       If this value exceeds 65535 milliseconds, then this field SHALL
       convey the value 65535.  This parameter MUST be provided for
       adaptive jitter buffer implementations and its value MUST be
       set to JB maximum for fixed jitter buffer implementations.

5. SDP Signaling

 This section defines Session Description Protocol (SDP) [4] signaling
 for XR blocks that can be employed by applications that utilize SDP.
 This signaling is defined to be used either by applications that
 implement the SDP Offer/Answer model [8] or by applications that use
 SDP to describe media and transport configurations in connection

Friedman, et al. Standards Track [Page 36] RFC 3611 RTCP XR November 2003

 with such protocols as the Session Announcement Protocol (SAP) [15]
 or the Real Time Streaming Protocol (RTSP) [17].  There exist other
 potential signaling methods that are not defined here.
 The XR blocks MAY be used without prior signaling.  This is
 consistent with the rules governing other RTCP packet types, as
 described in [9].  An example in which signaling would not be used is
 an application that always requires the use of one or more XR blocks.
 However, for applications that are configured at session initiation,
 the use of some type of signaling is recommended.
 Note that, although the use of SDP signaling for XR blocks may be
 optional, if used, it MUST be used as defined here.  If SDP signaling
 is used in an environment where XR blocks are only implemented by
 some fraction of the participants, the ones not implementing the XR
 blocks will ignore the SDP attribute.

5.1. The SDP Attribute

 This section defines one new SDP attribute "rtcp-xr" that can be used
 to signal participants in a media session that they should use the
 specified XR blocks.  This attribute can be easily extended in the
 future with new parameters to cover any new report blocks.
 The RTCP XR blocks SDP attribute is defined below in Augmented
 Backus-Naur Form (ABNF) [2].  It is both a session and a media level
 attribute.  When specified at session level, it applies to all media
 level blocks in the session.  Any media level specification MUST
 replace a session level specification, if one is present, for that
 media block.
  rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
   xr-format = pkt-loss-rle
             / pkt-dup-rle
             / pkt-rcpt-times
             / rcvr-rtt
             / stat-summary
             / voip-metrics
             / format-ext
   pkt-loss-rle   = "pkt-loss-rle" ["=" max-size]
   pkt-dup-rle    = "pkt-dup-rle" ["=" max-size]
   pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size]
   rcvr-rtt       = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size]
   rcvr-rtt-mode  = "all"
                  / "sender"
   stat-summary   = "stat-summary" ["=" stat-flag *("," stat-flag)]

Friedman, et al. Standards Track [Page 37] RFC 3611 RTCP XR November 2003

   stat-flag      = "loss"
                  / "dup"
                  / "jitt"
                  / "TTL"
                  / "HL"
   voip-metrics   = "voip-metrics"
   max-size       = 1*DIGIT ; maximum block size in octets
   DIGIT          = %x30-39
   format-ext     = non-ws-string
   non-ws-string  = 1*(%x21-FF)
   CRLF           = %d13.10
 The "rtcp-xr" attribute contains zero, one, or more XR block related
 parameters.  Each parameter signals functionality for an XR block, or
 a group of XR blocks.  The attribute is extensible so that parameters
 can be defined for any future XR block (and a parameter should be
 defined for every future block).
 Each "rtcp-xr" parameter belongs to one of two categories.  The first
 category, the unilateral parameters, are for report blocks that
 simply report on the RTP stream and related metrics.  The second
 category, collaborative parameters, are for XR blocks that involve
 actions by more than one party in order to carry out their functions.
 Round trip time (RTT) measurement is an example of collaborative
 functionality.  An RTP data packet receiver sends a Receiver
 Reference Time Report Block (Section 4.4).  A participant that
 receives this block sends a DLRR Report Block (Section 4.5) in
 response, allowing the receiver to calculate its RTT to that
 participant.  As this example illustrates, collaborative
 functionality may be implemented by two or more different XR blocks.
 The collaborative functionality of several XR blocks may be governed
 by a single "rtcp-xr" parameter.
 For the unilateral category, this document defines the following
 parameters.  The parameter names and their corresponding XR formats
 are as follows:
    Parameter name    XR block (block type and name)
    --------------    ------------------------------------
    pkt-loss-rle      1  Loss RLE Report Block
    pkt-dup-rle       2  Duplicate RLE Report Block
    pkt-rcpt-times    3  Packet Receipt Times Report Block
    stat-summary      6  Statistics Summary Report Block
    voip-metrics      7  VoIP Metrics Report Block

Friedman, et al. Standards Track [Page 38] RFC 3611 RTCP XR November 2003

 The "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters
 MAY specify an integer value.  This value indicates the largest size
 the whole report block SHOULD have in octets.  This shall be seen as
 an indication that thinning shall be applied if necessary to meet the
 target size.
 The "stat-summary" parameter contains a list indicating which fields
 SHOULD be included in the Statistics Summary report blocks that are
 sent.  The list is a comma separated list, containing one or more
 field indicators.  The space character (0x20) SHALL NOT be present
 within the list.  Field indicators represent the flags defined in
 Section 4.6.  The field indicators and their respective flags are as
 follows:
    Indicator    Flag
    ---------    ---------------------------
    loss         loss report flag (L)
    dup          duplicate report flag (D)
    jitt         jitter flag (J)
    TTL          TTL or Hop Limit flag (ToH)
    HL           TTL or Hop Limit flag (ToH)
 For "loss", "dup", and "jitt", the presence of the indicator
 indicates that the corresponding flag should be set to 1 in the
 Statistics Summary report blocks that are sent.  The presence of
 "TTL" indicates that the corresponding flag should be set to 1.  The
 presence of "HL" indicates that the corresponding flag should be set
 to 2.  The indicators "TTL" and "HL" MUST NOT be signaled together.
 Blocks in the collaborative category are classified as initiator
 blocks or response blocks.  Signaling SHOULD indicate which
 participants are required to respond to the initiator block.  A party
 that wishes to receive response blocks from those participants can
 trigger this by sending an initiator block.
 The collaborative category currently consists only of one
 functionality, namely the RTT measurement mechanism for RTP data
 receivers.  The collective functionality of the Receiver Reference
 Time Report Block and DLRR Report Block is represented by the "rcvr-
 rtt" parameter.  This parameter takes as its arguments a mode value
 and, optionally, a maximum size for the DLRR report block.  The mode
 value "all" indicates that both RTP data senders and data receivers
 MAY send DLRR blocks, while the mode value "sender" indicates that
 only active RTP senders MAY send DLRR blocks, i.e., non RTP senders
 SHALL NOT send DLRR blocks.  If a maximum size in octets is included,
 any DLRR Report Blocks that are sent SHALL NOT exceed the specified
 size.  If size limitations mean that a DLRR Report Block sender
 cannot report in one block upon all participants from which it has

Friedman, et al. Standards Track [Page 39] RFC 3611 RTCP XR November 2003

 received a Receiver Reference Time Report Block then it SHOULD report
 on participants in a round robin fashion across several report
 intervals.
 The "rtcp-xr" attributes parameter list MAY be empty.  This is useful
 in cases in which an application needs to signal that it understands
 the SDP signaling but does not wish to avail itself of XR
 functionality.  For example, an application in a SIP controlled
 session could signal that it wishes to stop using all XR blocks by
 removing all applicable SDP parameters in a re-INVITE message that it
 sends.  If XR blocks are not to be used at all from the beginning of
 a session, it is RECOMMENDED that the "rtcp-xr" attribute not be
 supplied at all.
 When the "rtcp-xr" attribute is present, participants SHOULD NOT send
 XR blocks other than the ones indicated by the parameters.  This
 means that inclusion of a "rtcp-xr" attribute without any parameters
 tells a participant that it SHOULD NOT send any XR blocks at all.
 The purpose is to conserve bandwidth.  This is especially important
 when collaborative parameters are applied to a large multicast group:
 the sending of an initiator block could potentially trigger responses
 from all participants.  There are, however, contexts in which it
 makes sense to send an XR block in the absence of a parameter
 signaling its use.  For instance, an application might be designed so
 as to send certain report blocks without negotiation, while using SDP
 signaling to negotiate the use of other blocks.

5.2. Usage in Offer/Answer

 In the Offer/Answer context [8], the interpretation of SDP signaling
 for XR packets depends upon the direction attribute that is signaled:
 "recvonly", "sendrecv", or "sendonly" [4].  If no direction attribute
 is supplied, then "sendrecv" is assumed.  This section applies only
 to unicast media streams, except where noted.  Discussion of
 unilateral parameters is followed by discussion of collaborative
 parameters in this section.
 For "sendonly" and "sendrecv" media stream offers that specify
 unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send
 the corresponding XR blocks.  For "sendrecv" offers, the answerer MAY
 include the "rtcp-xr" attribute in its response, and specify any
 unilateral parameters in order to request that the offerer send the
 corresponding XR blocks.  The offerer SHOULD send these blocks.
 For "recvonly" media stream offers, the offerer's use of the "rtcp-
 xr" attribute in connection with unilateral parameters indicates that
 the offerer is capable of sending the corresponding XR blocks.  If

Friedman, et al. Standards Track [Page 40] RFC 3611 RTCP XR November 2003

 the answerer responds with an "rtcp-xr" attribute, the offerer SHOULD
 send XR blocks for each specified unilateral parameter that was in
 its offer.
 For multicast media streams, the inclusion of an "rtcp-xr" attribute
 with unilateral parameters means that every media recipient SHOULD
 send the corresponding XR blocks.
 An SDP offer with a collaborative parameter declares the offerer
 capable of receiving the corresponding initiator and replying with
 the appropriate responses.  For example, an offer that specifies the
 "rcvr-rtt" parameter means that the offerer is prepared to receive
 Receiver Reference Time Report Blocks and to send DLRR Report Blocks.
 An offer of a collaborative parameter means that the answerer MAY
 send the initiator, and, having received the initiator, the offerer
 SHOULD send the responses.
 There are exceptions to the rule that an offerer of a collaborative
 parameter should send responses.  For instance, the collaborative
 parameter might specify a mode that excludes the offerer; or
 congestion control or maximum transmission unit considerations might
 militate against the offerer's response.
 By including a collaborative parameter in its answer, the answerer
 declares its ability to receive initiators and to send responses.
 The offerer MAY then send initiators, to which the answerer SHOULD
 reply with responses.  As for the offer of a collaborative parameter,
 there are exceptions to the rule that the answerer should reply.
 When making an SDP offer of a collaborative parameter for a multicast
 media stream, the offerer SHOULD specify which participants are to
 respond to a received initiator.  A participant that is not specified
 SHOULD NOT send responses.  Otherwise, undue bandwidth might be
 consumed.  The offer indicates that each participant that is
 specified SHOULD respond if it receives an initiator.  It also
 indicates that a specified participant MAY send an initiator block.
 An SDP answer for a multicast media stream SHOULD include all
 collaborative parameters that are present in the offer and that are
 supported by the answerer.  It SHOULD NOT include any collaborative
 parameter that is absent from the offer.
 If a participant receives an SDP offer and understands the "rtcp-xr"
 attribute but does not wish to implement XR functionality offered,
 its answer SHOULD include an "rtcp-xr" attribute without parameters.
 By doing so, the party declares that, at a minimum, is capable of
 understanding the signaling.

Friedman, et al. Standards Track [Page 41] RFC 3611 RTCP XR November 2003

5.3. Usage Outside of Offer/Answer

 SDP can be employed outside of the Offer/Answer context, for instance
 for multimedia sessions that are announced through the Session
 Announcement Protocol (SAP) [15], or streamed through the Real Time
 Streaming Protocol (RTSP) [17].  The signaling model is simpler, as
 the sender does not negotiate parameters, but the functionality
 expected from specifying the "rtcp-xr" attribute is the same as in
 Offer/Answer.
 When a unilateral parameter is specified for the "rtcp-xr" attribute
 associated with a media stream, the receiver of that stream SHOULD
 send the corresponding XR block.  When a collaborative parameter is
 specified, only the participants indicated by the mode value in the
 collaborative parameter are concerned.  Each such participant that
 receives an initiator block SHOULD send the corresponding response
 block.  Each such participant MAY also send initiator blocks.

6. IANA Considerations

 This document defines a new RTCP packet type, the Extended Report
 (XR) type, within the existing Internet Assigned Numbers Authority
 (IANA) registry of RTP RTCP Control Packet Types.  This document also
 defines a new IANA registry: the registry of RTCP XR Block Types.
 Within this new registry, this document defines an initial set of
 seven block types and describes how the remaining types are to be
 allocated.
 Further, this document defines a new SDP attribute, "rtcp-xr", within
 the existing IANA registry of SDP Parameters.  It defines a new IANA
 registry, the registry of RTCP XR SDP Parameters, and an initial set
 of six parameters, and describes how additional parameters are to be
 allocated.

6.1. XR Packet Type

 The XR packet type defined by this document is registered with the
 IANA as packet type 207 in the registry of RTP RTCP Control Packet
 types (PT).

6.2. RTCP XR Block Type Registry

 This document creates an IANA registry called the RTCP XR 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,
 allowing 256 values.  The RTCP XR Block Type Registry is to be
 managed by the IANA according to the Specification Required policy of

Friedman, et al. Standards Track [Page 42] RFC 3611 RTCP XR November 2003

 RFC 2434 [7].  Future specifications SHOULD attribute block type
 values in strict numeric order following the values attributed in
 this document:
    BT  name
    --  ----
     1  Loss RLE Report Block
     2  Duplicate RLE Report Block
     3  Packet Receipt Times Report Block
     4  Receiver Reference Time Report Block
     5  DLRR Report Block
     6  Statistics Summary Report Block
     7  VoIP Metrics Report Block
    The BT value 255 is reserved for future extensions.
 Furthermore, future specifications SHOULD avoid the value 0.  Doing
 so facilitates packet validity checking, since an all-zeros field
 might commonly be found in an ill-formed packet.
 Any registration MUST contain the following information:
  1. Contact information of the one doing the registration, including

at least name, address, and email.

  1. The format of the block type being registered, consistent with the

extended report block format described in Section 3.

  1. A description of what the block type represents and how it shall

be interpreted, detailing this information for each of its fields.

6.3. The "rtcp-xr" SDP Attribute

 The SDP attribute "rtcp-xr" defined by this document is registered
 with the IANA registry of SDP Parameters as follows:
 SDP Attribute ("att-field"):
   Attribute name:     rtcp-xr
   Long form:          RTP Control Protocol Extended Report Parameters
   Type of name:       att-field
   Type of attribute:  session and media level
   Subject to charset: no
   Purpose:            see Section 5 of this document
   Reference:          this document
   Values:             see this document and registrations below

Friedman, et al. Standards Track [Page 43] RFC 3611 RTCP XR November 2003

 The attribute has an extensible parameter field and therefore a
 registry for these parameters is required.  This document creates an
 IANA registry called the RTCP XR SDP Parameters Registry.  It
 contains the six parameters defined in Section 5.1: "pkt-loss-rle",
 "pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and
 "recv-rtt".
 Additional parameters are to be added to this registry in accordance
 with the Specification Required policy of RFC 2434 [7].  Any
 registration MUST contain the following information:
  1. Contact information of the one doing the registration, including

at least name, address, and email.

  1. An Augmented Backus-Naur Form (ABNF) [2] definition of the

parameter, in accordance with the "format-ext" definition of

    Section 5.1.
  1. A description of what the parameter represents and how it shall be

interpreted, both normally and in Offer/Answer.

7. Security Considerations

 This document extends the RTCP reporting mechanism.  The security
 considerations that apply to RTCP reports [9, Appendix B] also apply
 to XR reports.  This section details the additional security
 considerations that apply to the extensions.
 The extensions introduce heightened confidentiality concerns.
 Standard RTCP reports contain a limited number of summary statistics.
 The information contained in XR reports is both more detailed and
 more extensive (covering a larger number of parameters).  The per-
 packet report blocks and the VoIP Metrics Report Block provide
 examples.
 The per-packet information contained in Loss RLE, Duplicate RLE, and
 Packet Receipt Times Report Blocks facilitates multicast inference of
 network characteristics (MINC) [11].  Such inference can reveal the
 gross topology of a multicast distribution tree, as well as
 parameters, such as the loss rates and delays, along paths between
 branching points in that tree.  Such information might be considered
 sensitive to autonomous system administrators.
 The VoIP Metrics Report Block provides information on the quality of
 ongoing voice calls.  Though such information might be carried in an
 application specific format in standard RTP sessions, making it
 available in a standard format here makes it more available to
 potential eavesdroppers.

Friedman, et al. Standards Track [Page 44] RFC 3611 RTCP XR November 2003

 No new mechanisms are introduced in this document to ensure
 confidentiality.  Encryption procedures, such as those being
 suggested for a Secure RTCP (SRTCP) [12] at the time that this
 document was written, can be used when confidentiality is a concern
 to end hosts.  Given that RTCP traffic can be encrypted by the end
 hosts, autonomous systems must be prepared for the fact that certain
 aspects of their network topology can be revealed.
 Any encryption or filtering of XR report blocks entails a loss of
 monitoring information to third parties.  For example, a network that
 establishes a tunnel to encrypt VoIP Report Blocks denies that
 information to the service providers traversed by the tunnel.  The
 service providers cannot then monitor or respond to the quality of
 the VoIP calls that they carry, potentially creating problems for the
 network's users.  As a default, XR packets should not be encrypted or
 filtered.
 The extensions also make certain denial of service attacks easier.
 This is because of the potential to create RTCP packets much larger
 than average with the per packet reporting capabilities of the Loss
 RLE, Duplicate RLE, and Timestamp Report Blocks.  Because of the
 automatic bandwidth adjustment mechanisms in RTCP, if some session
 participants are sending large RTCP packets, all participants will
 see their RTCP reporting intervals lengthened, meaning they will be
 able to report less frequently.  To limit the effects of large
 packets, even in the absence of denial of service attacks,
 applications SHOULD place an upper limit on the size of the XR report
 blocks they employ.  The "thinning" techniques described in Section
 4.1 permit the packet-by-packet report blocks to adhere to a
 predefined size limit.

Friedman, et al. Standards Track [Page 45] RFC 3611 RTCP XR November 2003

A. Algorithms

A.1. Sequence Number Interpretation

 This is the algorithm suggested by Section 4.1 for keeping track of
 the sequence numbers from a given sender.  It implements the
 accounting practice required for the generation of Loss RLE Report
 Blocks.
 This algorithm keeps track of 16 bit sequence numbers by translating
 them into a 32 bit sequence number space.  The first packet received
 from a source is considered to have arrived roughly in the middle of
 that space.  Each packet that follows is placed either ahead of or
 behind the prior one in this 32 bit space, depending upon which
 choice would place it closer (or, in the event of a tie, which choice
 would not require a rollover in the 16 bit sequence number).
 // The reference sequence number is an extended sequence number
 // that serves as the basis for determining whether a new 16 bit
 // sequence number comes earlier or later in the 32 bit sequence
 // space.
 u_int32 _src_ref_seq;
 bool    _uninitialized_src_ref_seq;
 // Place seq into a 32-bit sequence number space based upon a
 // heuristic for its most likely location.
 u_int32 extend_seq(const u_int16 seq) {
         u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b;
         if(_uninitialized_src_ref_seq) {
                 // This is the first sequence number received.  Place
                 // it in the middle of the extended sequence number
                 // space.
                 _src_ref_seq                = seq | 0x80000000u;
                 _uninitialized_src_ref_seq  = false;
                 extended_seq                = _src_ref_seq;
         }
         else {
                 // Prior sequence numbers have been received.
                 // Propose two candidates for the extended sequence
                 // number: seq_a is without wraparound, seq_b with
                 // wraparound.
                 seq_a = seq | (_src_ref_seq & 0xFFFF0000u);
                 if(_src_ref_seq < seq_a) {
                         seq_b  = seq_a - 0x00010000u;
                         diff_a = seq_a - _src_ref_seq;

Friedman, et al. Standards Track [Page 46] RFC 3611 RTCP XR November 2003

                         diff_b = _src_ref_seq - seq_b;
                 }
                 else {
                         seq_b  = seq_a + 0x00010000u;
                         diff_a = _src_ref_seq - seq_a;
                         diff_b = seq_b - _src_ref_seq;
                 }
                 // Choose the closer candidate.  If they are equally
                 // close, the choice is somewhat arbitrary: we choose
                 // the candidate for which no rollover is necessary.
                 if(diff_a < diff_b) {
                         extended_seq = seq_a;
                 }
                 else {
                         extended_seq = seq_b;
                 }
                 // Set the reference sequence number to be this most
                 // recently-received sequence number.
                 _src_ref_seq = extended_seq;
         }
         // Return our best guess for a 32-bit sequence number that
         // corresponds to the 16-bit number we were given.
         return extended_seq;
 }

A.2. Example Burst Packet Loss Calculation.

 This is an algorithm for measuring the burst characteristics for the
 VoIP Metrics Report Block (Section 4.7).  The algorithm, which has
 been verified against a working implementation for correctness, is
 reproduced from ETSI TS 101 329-5 [3].  The algorithm, as described
 here, takes precedence over any change that might eventually be made
 to the algorithm in future ETSI documents.
 This algorithm is event driven and hence extremely computationally
 efficient.
 Given the following definition of states:
    state 1 = received a packet during a gap
    state 2 = received a packet during a burst
    state 3 = lost a packet during a burst
    state 4 = lost an isolated packet during a gap

Friedman, et al. Standards Track [Page 47] RFC 3611 RTCP XR November 2003

 The "c" variables below correspond to state transition counts, i.e.,
 c14 is the transition from state 1 to state 4.  It is possible to
 infer one of a pair of state transition counts to an accuracy of 1
 which is generally sufficient for this application.
 "pkt" is the count of packets received since the last packet was
 declared lost or discarded, and "lost" is the number of packets lost
 within the current burst.  "packet_lost" and "packet_discarded" are
 Boolean variables that indicate if the event that resulted in this
 function being invoked was a lost or discarded packet.
 if(packet_lost) {
         loss_count++;
 }
 if(packet_discarded) {
         discard_count++;
 }
 if(!packet_lost && !packet_discarded) {
         pkt++;
 }
 else {
         if(pkt >= gmin) {
                 if(lost == 1) {
                         c14++;
                 }
                 else {
                         c13++;
                 }
                 lost = 1;
                 c11 += pkt;
         }
         else {
                 lost++;
                 if(pkt == 0) {
                         c33++;
                 }
                 else {
                         c23++;
                         c22 += (pkt - 1);
                 }
         }
         pkt = 0;
 }
 At each reporting interval the burst and gap metrics can be
 calculated as follows.

Friedman, et al. Standards Track [Page 48] RFC 3611 RTCP XR November 2003

 // Calculate additional transition counts.
 c31 = c13;
 c32 = c23;
 ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33;
 // Calculate burst and densities.
 p32 = c32 / (c31 + c32 + c33);
 if((c22 + c23) < 1) {
         p23 = 1;
 }
 else {
         p23 = 1 - c22/(c22 + c23);
 }
 burst_density = 256 * p23 / (p23 + p32);
 gap_density = 256 * c14 / (c11 + c14);
 // Calculate burst and gap durations in ms
 m = frameDuration_in_ms * framesPerRTPPkt;
 gap_length = (c11 + c14 + c13) * m / c13;
 burst_length = ctotal * m / c13 - lgap;
 /* calculate loss and discard rates */
 loss_rate = 256 * loss_count / ctotal;
 discard_rate = 256 * discard_count / ctotal;

Intellectual Property Notice

 The IETF takes no position regarding the validity or scope of any
 intellectual property or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; neither does it represent that it
 has made any effort to identify any such rights.  Information on the
 IETF's procedures with respect to rights in standards-track and
 standards-related documentation can be found in BCP 11 [5].  Copies
 of claims of rights made available for publication and any assurances
 of licenses to be made available, or the result of an attempt made to
 obtain a general license or permission for the use of such
 proprietary rights by implementors or users of this specification can
 be obtained from the IETF Secretariat.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights which may cover technology that may be required to practice
 this standard.  Please address the information to the IETF Executive
 Director.

Friedman, et al. Standards Track [Page 49] RFC 3611 RTCP XR November 2003

Acknowledgments

 We thank the following people: Colin Perkins, Steve Casner, and
 Henning Schulzrinne for their considered guidance; Sue Moon for
 helping foster collaboration between the authors; Mounir Benzaid for
 drawing our attention to the reporting needs of MLDA; Dorgham Sisalem
 and Adam Wolisz for encouraging us to incorporate MLDA block types;
 and Jose Rey for valuable review of the SDP Signaling section.

Contributors

 The following people are the authors of this document:
   Kevin Almeroth, UCSB
   Ramon Caceres, IBM Research
   Alan Clark, Telchemy
   Robert G. Cole, JHU Applied Physics Laboratory
   Nick Duffield, AT&T Labs-Research
   Timur Friedman, Paris 6
   Kaynam Hedayat, Brix Networks
   Kamil Sarac, UT Dallas
   Magnus Westerlund, Ericsson
 The principal people to contact regarding the individual report
 blocks described in this document are as follows:
 sec. report block                         principal contributors
 ---- ------------                         ----------------------
 4.1  Loss RLE Report Block                Friedman, Caceres, Duffield
 4.2  Duplicate RLE Report Block           Friedman, Caceres, Duffield
 4.3  Packet Receipt Times Report Block    Friedman, Caceres, Duffield
 4.4  Receiver Reference Time Report Block Friedman
 4.5  DLRR Report Block                    Friedman
 4.6  Statistics Summary Report Block      Almeroth, Sarac
 4.7  VoIP Metrics Report Block            Clark, Cole, Hedayat
 The principal person to contact regarding the SDP signaling described
 in this document is Magnus Westerlund.

Friedman, et al. Standards Track [Page 50] RFC 3611 RTCP XR November 2003

References

Normative References

 [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [2]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
      Specifications: ABNF", RFC 2234, November 1997.
 [3]  ETSI, "Quality of Service (QoS) measurement methodologies", ETSI
      TS 101 329-5 V1.1.1 (2000-11), November 2000.
 [4]  Handley, M. and V. Jacobson, "SDP: Session Description
      Protocol", RFC 2327, April 1998.
 [5]  Hovey, R. and S. Bradner, "The Organizations Involved in the
      IETF Standards Process", BCP 11, RFC 2028, October 1996.
 [6]  ITU-T, "The E-Model, a computational model for use in
      transmission planning", Recommendation G.107, January 2003.
 [7]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 [8]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
      the Session Description Protocol (SDP)", RFC 3264, June 2002.
 [9]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
      "RTP: A Transport Protocol for Real-Time Applications", RFC
      3550, July 2003.
 [10] TIA/EIA-810-A Transmission Requirements for Narrowband Voice
      over IP and Voice over PCM Digital Wireline Telephones, December
      2000.

Informative References

 [11] Adams, A., Bu, T., Caceres, R., Duffield, N.G., Friedman, T.,
      Horowitz, J., Lo Presti, F., Moon, S.B., Paxson, V. and D.
      Towsley, "The Use of End-to-End Multicast Measurements for
      Characterizing Internal Network Behavior", IEEE Communications
      Magazine, May 2000.
 [12] Baugher, McGrew, Oran, Blom, Carrara, Naslund and Norrman, "The
      Secure Real-time Transport Protocol", Work in Progress.

Friedman, et al. Standards Track [Page 51] RFC 3611 RTCP XR November 2003

 [13] Caceres, R., Duffield, N.G. and T. Friedman, "Impromptu
      measurement infrastructures using RTP", Proc. IEEE Infocom 2002.
 [14] Clark, A.D., "Modeling the Effects of Burst Packet Loss and
      Recency on Subjective Voice Quality", Proc. IP Telephony
      Workshop 2001.
 [15] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
      Protocol", RFC 2974, October 2000.
 [16] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an
      On-line Database", RFC 3232, January 2002.
 [17] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
      Protocol (RTSP)", RFC 2326, April 1998.
 [18] Sisalem D. and A. Wolisz, "MLDA: A TCP-friendly Congestion
      Control Framework for Heterogeneous Multicast Environments",
      Proc. IWQoS 2000.

Friedman, et al. Standards Track [Page 52] RFC 3611 RTCP XR November 2003

Authors' Addresses

 Kevin Almeroth
 Department of Computer Science
 University of California
 Santa Barbara, CA 93106 USA
 EMail: almeroth@cs.ucsb.edu
 Ramon Caceres
 IBM Research
 19 Skyline Drive
 Hawthorne, NY 10532 USA
 EMail: caceres@watson.ibm.com
 Alan Clark
 Telchemy Incorporated
 3360 Martins Farm Road, Suite 200
 Suwanee, GA 30024 USA
 Phone: +1 770 614 6944
 Fax:   +1 770 614 3951
 EMail: alan@telchemy.com
 Robert G. Cole
 Johns Hopkins University Applied Physics Laboratory
 MP2-S170
 11100 Johns Hopkins Road
 Laurel, MD 20723-6099 USA
 Phone: +1 443 778 6951
 EMail: robert.cole@jhuapl.edu
 Nick Duffield
 AT&T Labs-Research
 180 Park Avenue, P.O. Box 971
 Florham Park, NJ 07932-0971 USA
 Phone: +1 973 360 8726
 Fax:   +1 973 360 8050
 EMail: duffield@research.att.com

Friedman, et al. Standards Track [Page 53] RFC 3611 RTCP XR November 2003

 Timur Friedman
 Universite Pierre et Marie Curie (Paris 6)
 Laboratoire LiP6-CNRS
 8, rue du Capitaine Scott
 75015 PARIS France
 Phone: +33 1 44 27 71 06
 Fax:   +33 1 44 27 74 95
 EMail: timur.friedman@lip6.fr
 Kaynam Hedayat
 Brix Networks
 285 Mill Road
 Chelmsford, MA 01824 USA
 Phone: +1 978 367 5600
 Fax:   +1 978 367 5700
 EMail: khedayat@brixnet.com
 Kamil Sarac
 Department of Computer Science (ES 4.207)
 Eric Jonsson School of Engineering & Computer Science
 University of Texas at Dallas
 Richardson, TX 75083-0688 USA
 Phone: +1 972 883 2337
 Fax:   +1 972 883 2349
 EMail: ksarac@utdallas.edu
 Magnus Westerlund
 Ericsson Research
 Ericsson AB
 SE-164 80 Stockholm Sweden
 Phone: +46 8 404 82 87
 Fax:   +46 8 757 55 50
 EMail: magnus.westerlund@ericsson.com

Friedman, et al. Standards Track [Page 54] RFC 3611 RTCP XR November 2003

Full Copyright Statement

 Copyright (C) The Internet Society (2003).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assignees.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Friedman, et al. Standards Track [Page 55]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3611.txt · Last modified: 2003/11/04 00:17 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki