Internet Engineering Task Force                 Expires: 2 September 16 October 2003
Audio/Video Transport Working Group

                                                 Timur Friedman, Paris 6
                                                 Ramon Caceres, ShieldIP
                                                 Alan Clark, Telchemy
                                                 Editors

            RTP Control Protocol Extended Reports (RTP (RTCP XR)

                draft-ietf-avt-rtcp-report-extns-03.txt

                draft-ietf-avt-rtcp-report-extns-04.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright Notice

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

Abstract

   This document defines the extended report Extended Report (XR) packet type for the
   RTP control protocol (RTCP). 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 Sender Report (SR) and receiver report 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.

Table of Contents

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

1. Introduction

   This document defines the extended report Extended Report (XR) packet type for the
   RTP control protocol Control Protocol (RTCP) [7]. [10], 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 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 following sections of
   this document, starting with a general framework and finishing with that follow the specific information conveyed.  The framework defined by
   Introduction.  Section 2 contains common defines the XR packet as consisting of an
   eight octet header information followed by a series of components called report
   blocks.  Section 3 defines the format common
   to such format, or framework,
   consisting of a type and a length field, required for all report
   blocks.  Section 4 defines seven several specific report block types.

   Seven
   Other block types can be defined in future documents as the need
   arises.

   The report block formats are types defined by in this document:

   - Loss RLE Report Block (Section 4.1): Run length encoding document fall into three
   categories.  The first category consists of packet-by-packet reports
   on received or lost RTP
   packet loss reports.

   - Duplicate RLE Report 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:

   - Loss RLE Report Block (Section 4.2): 4.1): Run length encoding of reports
   concerning the losses and receipts of RTP packet duplicates. packets.

   - Timestamp Duplicate RLE Report Block (Section 4.3): A list 4.2): Run length encoding of timestamps
   reports concerning duplicates of received RTP packets.

   - Statistics Summary Packet Receipt Times Report Block (Section 4.4): Statistics on 4.3): A list of
   reception timestamps of RTP
   packet sequence numbers, losses, duplicates, jitter, and TTL values. packets.

   There are two reference time related block types:

   - Receiver Timestamp Reference Time Report Block (Section 4.5): 4.4): Receiver-end
   timestamps that complement
   wallclock timestamps.  Together with the sender-end timestamps already defined
   for RTCP. DLRR Report Block mentioned
   next, these allow non-senders to calculate round-trip times.

   - DLRR Report Block (Section 4.6): 4.5): The delay since the last Receiver
   Timestamp
   Reference Time Report Block was received, allowing non-senders to
   calculate round-trip times. 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 [10, Section 6.3.1], an RTP data receiver that
   receives a sender's NTP timestamp can respond by filling in the DLSR
   field of an RTCP reception report block.

   Finally, this document defines two summary metric block types:

   - Statistics Summary Report Block (Section 4.6): Statistics on RTP
   packet sequence numbers, losses, duplicates, jitter, and TTL or Hop
   Limit values.

   - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring
   Voice over IP (VoIP) calls.

   These blocks are defined within a minimal framework: a type field and
   a length field are common

   Before proceeding to all the XR blocks.  The purpose is to
   maintain flexibility packet and to keep overhead low.  Other report block formats,
   beyond the seven defined here, may be defined within definitions, this framework
   as
   document provides an applicability statement (Section 1.1) that
   describes the need arises.

1.1 Terminology
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" contexts in this
   document are to which these report blocks can be interpreted used.  It
   also defines (Section 1.2) the normative use of key words, such as described in RFC 2119 [1]
   MUST and
   indicate requirement levels for compliance with SHOULD, as they are employed in this specification.

2. XR Packet Format

   The XR packet consists of a header document.

   Following the definitions of two 32-bit words, followed by the various report blocks, this document
   describes how applications that employ SDP can signal their use
   (Section 5).  The document concludes with a
   number, possibly zero, discussion (Section 6) of extended report blocks.

    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=XP=207   |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           SSRC/CSRC                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                         report blocks                         :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   version (V): 2 bits
        Identifies
   numbering considerations for the version Internet Assigned Numbers Authority
   (IANA), of RTP.  This specification applies security considerations (Section 7), and with appendices
   that provide examples of how to
        RTP version two.

   padding (P): 1 bit
        If the padding bit is set, this XR packet contains some
        additional padding octets at implement algorithms discussed in the end.
   text.

1.1 Applicability

   The semantics of this
        field XR packets are identical useful across multiple applications, and for that
   reason are not defined as profile-specific extensions to the semantics RTCP sender
   or Receiver Reports [10, Section 6.4.3].  Nonetheless, they are not
   of the padding field use in the
        SR packet, as defined by the RTP specification.

   reserved: 5 bits
        This field is reserved for future definition. all contexts.  In particular, the absence VoIP metrics report block
   (Section 4.7) is specific to voice applications, though it can be
   employed over a wide variety of such definition, the bits in this field MUST applications.

   The VoIP metrics report block can be set applied to zero and
        MUST be ignored by the receiver.

   packet type (PT): 8 bits
        Contains any conversational,
   multicast or broadcast application for which the constant 207 to identify this as an use of RTP and RTCP XR packet.
        This value
   is registered with specified.  The use of conversational metrics (Section 4.7.5),
   including the Internet Assigned Numbers
        Authority (IANA), as R factor (as described by the E Model defined in Section 5.1.

   length: 16 bits
        As described for [3])
   and the RTP sender mean opinion score for conversational quality (MOS-CQ), in
   applications other than simple two party calls is not defined, and
   hence these metrics should be identified as unavailable in
   conferencing, multicast and broadcast applications.

   The packet-by-packet report (SR) packet (see Section
        6.3.1 of the RTP specification [7]).  Briefly, the length 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
        this XR network characteristics (MINC) [11], in mind.
   MINC requires detailed packet receipt traces from multicast session
   receivers in 32-bit words minus one, including order to infer the header gross structure of the multicast
   distribution tree and any padding.

   SSRC: 32 bits
        The synchronization source identifier for the originator parameters, such as loss rates and delays,
   that apply to paths between the branching points of this
        XR packet.

   report blocks: variable length.
        Zero or more extended report blocks.  In keeping with that tree.

   Any real time multicast multimedia application can use the
        extended packet-by-
   packet report block framework defined below, each block MUST
        consist types.  Such an application could employ a MINC
   inference subsystem that would provide it with multicast tree
   topology information.  One potential use of one or more 32-bit words.

3. Extended Report Block Framework

   Extended report blocks are stacked, one after such a subsystem would be
   for the other, at identification of high loss regions in the end multicast tree and
   the identification of an XR packet. 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 individual block's length
   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 multiple size limit by restricting the number of 4
   octets.
   packets reported upon within any sequence number interval.  The XR header's length field describes the total length
   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 packet, including
   multicast tree there are paths that exceed a defined loss rate
   threshold.  Intelligent decisions regarding which receivers send
   these extended report blocks.

   Each block has block type and length fields that facilitate parsing.
   A receiving application blocks can demultiplex further restrict the portion of RTCP
   bandwidth that they consume.

   The packet-by-packet report blocks based upon their
   type, and can use the length information also be used by dedicated
   network monitoring applications.  For such an application, it might
   be appropriate to locate each successive
   block, even 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 presence of packet-by-packet 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 data                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   block type (BT): 8 bits
        Identifies restricts their use to
   multicast applications.  In particular, they could be used for
   network tomography similar to MINC, but using striped unicast
   packets.  In addition, if it were found useful, they could be used
   for applications limited to two participants.

   One use to which the block format.  Seven block types packet-by-packet reports are defined in
        Section 4.  Additional block types may be defined in future
        specifications.  This field's name space not immediately
   suited is managed by the
        Internet Assigned Numbers Authority (IANA), for data packet acknowledgments as described in
        Section 5.2.

   type-specific: 8 bits
        The use part of these bits is determined by the block type
        definition.

   block length: 16 bits a packet
   retransmission mechanism.  The length of this report block including reason is that the header, in 32-bit
        words minus one.  If packet accounting
   technique suggested for these blocks differs from the block type definition permits, zero is packet
   accounting normally employed by RTP.  In order to favor measurement
   applications, an acceptable value, signifying a block that consists of only effort is made to interpret as little as possible at
   the BT, type-specific, and block length fields, with a null
        type-specific data field.

   type-specific data: variable length
        The use of this field is defined by receiver, and leave the particular block type,
        subject interpretation as much as possible
   to the constraint participants that it MUST be a multiple of 32 bits
        long.  If receive the block type definition permits, It MAY be zero bits
        long.

4. Extended Report Blocks

   This section defines seven extended report blocks: block types blocks.  Thus, for
   losses, duplicates, example, a
   packet reception timestamps, detailed reception
   statistics, receiver timestamps, receiver inter-report delays, and
   voice over IP (VoIP) metrics.  An implementation SHOULD ignore
   incoming blocks with types either not relevant an anomalous SSRC ID or unknown to it.
   Additional block types MUST an anomalous sequence number
   might be registered with the Internet Assigned
   Numbers Authority (IANA) [5], as described in Section 5.2.

4.1 Loss RLE 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 permits detailed reporting upon individual packet
   receipt and loss events.  Such reports can be used, used
   equally well for example, reporting on unicast and multicast packet reception.

   The reference time related block types were conceived for receiver-
   based TCP-friendly multicast inference of network characteristics (MINC) [8].  With
   MINC, one can discover the topology of congestion control [17].  By allowing
   data receivers to calculate their round trip times to senders, they
   help the multicast tree used for
   distributing a source's RTP packets, and of receivers estimate the loss rates along
   links within that tree.  Or downstream bandwidth they could be used to provide raw data should
   request.  Note that if every receiver is to send Receiver Reference
   Time Report Blocks (Section 4.4), a network management application.

   Since sender might potentially send a Boolean trace
   number of lost and received RTP DLRR Report Blocks (Section 4.5) equal to the number of
   receivers whose RTCP packets is potentially
   lengthy, this block type permits have arrived at the trace to be compressed through
   run length encoding.  To further reduce block size, loss event
   reports can be systematically dropped from sender within its
   reporting interval.  As the trace in a mechanism
   called thinning that is described below and that is studied number of participants in [9].

   A participant that generates a Loss RLE Report Block multicast
   session increases, an application should favor
   accuracy use discretion regarding
   which participants send these blocks, and how frequently.

   The SDP signaling defined for XR packets 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 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
   accounting for Loss RLE Report Blocks will differ from the accounting
   employ SDP are free to use additional SDP signaling for the generation of the SR cases not
   covered here.  In addition, applications are free to use signaling
   mechanisms other than SDP.

1.2 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and RR packets described "OPTIONAL" in the RTP
   specification [7] this
   document are to be interpreted as described in the following two areas: per-sender accounting RFC 2119 [1] and per-packet accounting.

   In its per-sender accounting, an RTP session participant SHOULD NOT
   make the receipt
   indicate requirement levels for compliance with this specification.

2. XR Packet Format

   An XR packet consists of a threshold minimum number header of RTP packets two 32-bit words, followed by a
   condition for reporting upon the sender
   number, possibly zero, of those packets. extended report blocks.  This
   accounting technique differs from the technique described in Section
   6.2.1 and Appendix A.1 type of the RTP specification that allows a
   threshold to determine whether a sender
   packet 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 laid out in Appendix A.1 of the RTP specification
   that suggests ruling a sequence number valid or invalid on the basis
   of its contiguity manner consistent with other RTCP packets, as
   concerns the sequence numbers of previously received
   packets.

   Sender validity essential version, packet type, and sequence number validity length information.
   XR packets are interpretations of thus backwards compatibility with RTCP receiver
   implementations that do not recognize them, but that ought to be able
   to parse past them using the raw data.  Such interpretations length information.  A padding field and
   an SSRC/CSRC field are justified also provided in the interest, same locations that they
   appear in other RTCP packets, for example, 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/CSRC                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                         report blocks                         :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   version (V): 2 bits
        Identifies the version of excluding RTP.  This specification applies to
        RTP version two.

   padding (P): 1 bit
        If the stray old padding bit is set, this XR packet from an unrelated
   session from having an effect upon the calculation of contains some
        additional padding octets at the RTCP
   transmission interval. end.  The presence semantics of stray packets might, on this
        field are identical to the
   other hand, be semantics of interest to a network monitoring application.

   One accounting interpretation that is still necessary the padding field in the
        SR packet, as defined by the RTP specification.

   reserved: 5 bits
        This field is reserved for a
   participant to decide whether future definition.  In the 16 bit sequence number has rolled
   over.  Under ordinary circumstances absence of
        such definition, the bits in 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 field MUST be set to
   assume that there has been a rollover.  However it is possible that zero and
        MUST be ignored by the receiver.

   packet is type (PT): 8 bits
        Contains the constant 207 to identify this as an earlier one (from 65,535 packets earlier).  It RTCP XR packet.
        This value 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 registered with the sequence numbers,
   even accounting for rollover, and when there are long intervals
   between received packets.

   The per-packet accounting technique mandated here is Internet Assigned Numbers
        Authority (IANA), as described in Section 5.1.

   length: 16 bits
        As described for a
   participant to keep track of the sequence number RTCP Sender Report (SR) packet (see Section
        6.3.1 of the packet most
   recently received from a sender.  For RTP specification [10]).  Briefly, the next length of
        this XR 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 in 32-bit words minus one, whichever
   choice places it closer.  In including the event that both choices are equally
   distant (only possible when header
        and any padding.

   SSRC/CSRC: 32 bits
        The synchronization source identifier for the distance is 32,768), originator of this
        XR packet.

   report blocks: variable length.
        Zero or more extended report blocks.  In keeping with the choice
        extended report block framework defined below, each block MUST
   be the
        consist of one that does not require a rollover.  Appendix A.1 presents
   an algorithm that implements this technique.

   Each block reports on a single source, identified by its SSRC.  The
   receiver that is supplying the or more 32-bit words.

3. Extended Report Block Framework

   Extended report is identified in blocks are stacked, one after the header of other, at the RTCP packet.

   Choice end
   of beginning and ending RTP packet sequence numbers for the
   trace an XR packet.  An individual block's length is left to the application.  These values are reported in the
   block. a multiple of 4
   octets.  The last sequence number in XR header's length field describes the trace MAY differ from total length of
   the
   sequence number reported on in any accompanying SR or RR report.

   Note packet, including these extended report blocks.

   Each block has block type and length fields that because of sequence number wraparound facilitate parsing.
   A receiving application can demultiplex the ending sequence
   number MAY be less than blocks based upon their
   type, and can use the beginning sequence number.  A Loss RLE
   Report Block MUST NOT be used length information to report upon a range of 65,534 or
   greater locate each successive
   block, even in the sequence number space, as there is no means to
   identify 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 presence of one represents a packet receipt, meaning that one or more packets
   having that sequence number have been received since block types it does not recognize.

   An extended report block has the most recent
   wraparound of sequence numbers (or since 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 beginning of 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 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
        Internet Assigned Numbers Authority (IANA), as described in
        Section 5.2.

   type-specific: 8 bits
        The use of these bits is determined by the time block type
        definition.

   block length: 16 bits
        The length of this report block including the report. header, in 32-bit
        words minus one.  If a packet with a given sequence number the block type definition permits, zero is received after
        an acceptable value, signifying a report block that consists of only
        the BT, type-specific, and block length fields, with a loss for that sequence number, 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 later Loss RLE report 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 a 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 either not relevant or unknown to it. Additional block types
   MUST be registered with the Internet Assigned Numbers Authority
   (IANA) [7], as described in Section 5.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 that sequence number.

   The encoding itself consists of a series example, for
   multicast inference of 16 bit units called
   chunks that describe sequences network characteristics (MINC) [11].  With
   MINC, one can discover the topology of packet receipts or losses in the
   trace.  Each chunk either specifies a run length or a bit vector, or
   is multicast tree used for
   distributing a null chunk.  A run length describes between 1 source's RTP packets, and 16,383 events
   that are all of the same (either all receipts or all losses).  A bit
   vector describes 15 events loss rates along
   links within that may tree.  Or they could be mixed receipts and losses.  A
   null chunk describes no events, and is used to round out the block provide raw data to
   a 32 bit word boundary.

   The mapping from network management application.

   Since a sequence Boolean trace of lost and received RTP packets into a
   sequence of chunks is not necessarily unique.  For example, potentially
   lengthy, this block type permits 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

   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 be compressed through
   run of 9 receipts
   null chunk

   The choice of encoding 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 application.  As part of report blocks.  Following this
   freedom of choice, applications MAY terminate a series of run length
   and bit vector chunks with a bit vector chunk approach implies that runs beyond
   accounting for Loss RLE Report Blocks will differ from the
   sequence number space described by accounting
   for the report block.  For example, if generation of the 44th packet SR and RR packets described in the same sequence were 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 RTP
   specification [10] in the following two areas: per-sender accounting
   and per-packet accounting.

   In this example, its per-sender accounting, an RTP session participant SHOULD NOT
   make the last five bits receipt of the second bit vector describe a part threshold minimum number of RTP packets a
   condition for reporting upon the sequence number space that extends beyond sender of those packets.  This
   accounting technique differs from the last
   sequence number technique described in Section
   6.2.1 and Appendix A.1 of the trace.  These bits have been set to zero.

   All bits in a bit vector chunk RTP specification that describe allows a part
   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 space that extends beyond valid or invalid on the last 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
   trace MUST be set to zero, and MUST be ignored by interest,
   for example, of excluding the receiver.

   A null stray old packet MUST appear at from an unrelated
   session from having an effect upon the end calculation of a Loss RLE Report Block if the number of run length plus bit vector chunks is odd. RTCP
   transmission interval.  The null
   chunk MUST NOT appear in any other context.

   Caution should be used in sending Loss RLE Report Blocks because,
   even with presence of stray packets might, on the compression provided by run length encoding, they can
   easily consume bandwidth out
   other hand, be of proportion with normal RTCP packets.
   The block type includes interest to a mechanism, called thinning, network monitoring application.

   One accounting interpretation that allows an
   application to limit report sizes.

   A thinning value, T, selects is still necessary is for a subset of packets within
   participant to decide whether the 16 bit 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 has rolled
   over.  Under ordinary circumstances this is zero then every not a difficult task.
   For example, if packet in the number 65,535 (the highest possible sequence
   number) is followed shortly by packet number space 0, it is reported upon.  If T reasonable to
   assume that there has been a rollover.  However it is fifteen then possible that
   the packet is an earlier one in
   every 32,768 (from 65,535 packets earlier).  It is reported upon.

   Suppose
   also possible that the trace just described begins at sequence number
   13,821. numbers have rolled over multiple
   times, either forward or backward.  The last sequence number in interpretation becomes more
   difficult when there are large gaps between the trace sequence numbers,
   even accounting for rollover, and when there are long intervals
   between received packets.

   The per-packet accounting technique mandated here is 13,865.  If the
   trace were to be thinned with for a thinning value
   participant to keep track 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 number of the bit vector, representing sequence numbers
   13,868, 13,872, 13,876, and 13,880, extend beyond packet most
   recently received from a sender.  For the trace and are
   thus set next packet that arrives
   from that sender, the sequence number MUST be judged to zero and are ignored by fall no more
   than 32,768 packets ahead or behind the receiver.  With thinning, most recent one, whichever
   choice places it closer.  In the
   loss of event that both choices are equally
   distant (only possible when the 22nd packet goes unreported because its sequence number,
   13,842, distance is 32,768), the choice MUST
   be the one that does not require a multiple of four.  Packet receipts for all sequence
   numbers rollover.  Appendix A.1 presents
   an algorithm that are not multiples of four also go unreported.  However,
   in implements this example thinning has permitted the Loss RLE Report Block to
   be shortened technique.

   Each block reports on a single RTP data packet source, identified by one 32 bit word.
   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 thinning value
   trace is left to the application.  These values are reported in the
   block.  The Loss RLE Report Block has last sequence number in 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 trace MAY differ from the
   sequence number reported on in any accompanying SR or RR report.

   Note that because of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          begin_seq            |             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          chunk 1              |             chunk 2           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          chunk n-1            |             chunk n           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   block type (BT): 8 bits sequence number wraparound the ending sequence
   number MAY be less than the beginning sequence number.  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 NOT be set used to zero and
        MUST be ignored by the receiver.

   thinning (T): 4 bits
        The amount report upon a range of thinning performed on 65,534 or
   greater in 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 space, as there is no
        thinning, and all packets are reported on. means to
   identify multiple wraparounds.

   The maximum thinning
        is trace described by a Loss RLE report consists of a sequence of
   Boolean values, one packet in every 32,768 (amounting to two packets within for each 16-bit sequence space).

   block length: 16 bits
        Defined in Section 3.

   begin_seq: 16 bits
        The first sequence number of the trace.  A value
   of one represents a packet receipt, meaning that one or more packets
   having that this block reports on.

   end_seq: 16 bits
        The last sequence number that this block reports on plus one.

   chunk i: 16 bits
        There are three chunk types: run length, bit vector, and
        terminating null, defined in have been received since the following sections.  If most recent
   wraparound of sequence numbers (or since the
        chunk is all zeroes then it is beginning of the RTP
   session if no wraparound has been judged to have occurred).  A value
   of zero represents a terminating null chunk.
        Otherwise, packet loss, meaning that there has been no
   packet receipt for that sequence number as of the leftmost bit time of the chunk determines its type: 0 report.
   If a packet with a given sequence number is received after a report
   of a loss for run length and 1 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 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         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ units called
   chunks that describe sequences of packet receipts or losses in the
   trace.  Each chunk type (C): 1 bit
        A zero identifies this as either specifies a run length chunk.

   run type (R): 1 bit
        Zero indicates or a run of 0s.  One indicates bit vector, or
   is a run of 1s.

   run length: 14 bits null chunk.  A value run length describes between 1 and 16,383.  The value MUST not be zero for a
        run length chunk (zeroes in both 16,383 events
   that are all the run type same (either all receipts or all losses).  A bit
   vector describes 15 events that may be mixed receipts and run length
        fields would make the losses.  A
   null chunk describes no events, and is used to round out the block to
   a terminating null chunk).  Run
        lengths 32 bit word boundary.

   The mapping from a sequence of 15 or less MAY be described with lost and received packets into a run length chunk
        despite
   sequence of chunks is not necessarily unique.  For example, the fact that they could also be described as part
   following trace covers 45 packets, of a which the 22nd and 24th have
   been lost and the others received:

   1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1

   One way to encode this would be:

   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| 1111 1111 1111 111
   bit vector           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   chunk type (C): 1 1111 1101 0111 111
   bit
        A one identifies vector 1111 1111 1111 111
   null chunk

   Another way to encode this as a would be:

   run of 21 receipts
   bit vector chunk.

   bit vector: 15 bits 0101 1111 1111 111
   run of 9 receipts
   null chunk

   The vector choice of encoding is read from left to right, in order the application.  As part of increasing 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 (with space described by the appropriate allowance for wraparound).

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 report block.  For example, if
   the interpretation is different, 44th packet in that the information concerns packet duplicates rather than packet losses.
   The trace to same sequence were lost:

   1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1

   This could be encoded in this case also consists as:

   run of zeros and ones,
   but a zero here indicates 21 receipts
   bit vector 0101 1111 1111 111
   bit vector 1111 1110 1000 000
   null chunk

   In this example, the presence last five bits of duplicate packets for a
   given sequence number, whereas the second bit vector describe
   a one indicates that no duplicates
   were received.

   The existence part of a duplicate for a given the sequence number is
   determined over space that extends beyond the entire reporting period.  For example, if packet
   number 12,593 arrives, followed by other packets with other last
   sequence
   numbers, the arrival later number in the reporting period of another packet
   numbered 12,593 counts as trace.  These bits have been set to zero.

   All bits in 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 bit vector chunk that describe a report does not cover a
   range part of 65,534 or greater in the sequence
   number space.

   No distinction is made between space that extends beyond the existence of a single duplicate
   packet and multiple duplicate packets for a given last sequence number.
   Note also that since there is no duplicate for a lost packet, a loss
   is encoded as a one number in a Duplicate RLE Report Block.

   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 definition, the bits in this field
   trace MUST be set to zero zero, and MUST be ignored by the receiver.

   thinning (T): 4 bits
        As defined

   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 Section 4.1.

   block length: 16 bits
        Defined in Section 3.

   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 any other context.

   Caution should be used in Section 4.1.

4.3 Timestamp sending Loss RLE Report Block

   This 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 permits per-sequence-number reports on packet receipt
   timestamps for includes a given source's RTP packet stream.  Such information
   can be used for MINC inference of the topology of the multicast tree
   used mechanism, called thinning, that allows an
   application to distribute the source's RTP packets, and limit report sizes.

   A thinning value, T, selects a subset of the delays along
   the links packets within the sequence
   number space: those with sequence numbers that tree.  It can also be used to measure partial
   path characteristics are multiples of 2^T.
   Packet reception and loss reports apply only to model distributions for packet jitter.

   At least one those packets.  T can
   vary between 0 and 15.  If T is zero then every packet MUST have been received for each in the
   sequence number space is reported upon in this block. upon.  If this block type T is used 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 report
   timestamps for be thinned with a series thinning value of T=2, then the
   following sequence numbers that includes lost
   packets, several blocks are required.  If duplicate packets have been
   received for a given 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 number, numbers
   13,868, 13,872, 13,876, and those packets differ in
   their receiver timestamps, any timestamp other than 13,880, extend beyond the earliest MUST
   NOT be reported.  This is trace and are
   thus set to ensure consistency among reports.

   Timestamps consume more bits than loss or duplicate information, zero and
   do are ignored by the receiver.  With thinning, the
   loss of the 22nd packet goes unreported because its sequence number,
   13,842, is not lend themselves 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 run length encoding.  The use
   be shortened by one 32 bit word.

   Choice of the thinning value is encouraged left to limit the size of Timestamp Report Blocks. application.

   The Timestamp 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=3     BT=1      | rsvd. |   T   |         block length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          begin_seq            |             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        RTP timestamp          chunk 1              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        RTP timestamp             chunk 2           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        RTP timestamp          chunk n-1            |             chunk n           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   block type (BT): 8 bits
        A Timestamp Loss RLE Report Block is identified by the constant 3. 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
        As defined in Section 4.1.

   block length: 16 bits
        Defined in Section 3.

   begin_seq: 16 bits
        As defined in Section 4.1.

   end_seq: 16 bits
        As defined in Section 4.1.

   RTP timestamp i: 32 bits
        The timestamp reflects the packet arrival time at amount of thinning performed on the receiver.
        It 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 preferable for the timestamp to be established at the link
        layer interface, or in any case as close as possible to the wire
        arrival time.  Units no
        thinning, and format all packets are the same as for the
        timestamp reported on.  The maximum thinning
        is one packet in RTP data packets.  As opposed every 32,768 (amounting to RTP data packet
        timestamps, two packets within
        each 16-bit sequence space).

   block length: 16 bits
        Defined in which nominal values may be used instead Section 3.

   SSRC of
        system clock values in order to convey information useful for
        periodic playout, the receiver timestamps should reflect the
        actual time as closely as possible. source: 32 bits
        The initial value SSRC of the
        timestamp is random, and subsequent timestamps are offset from RTP data packet source being reported upon by
        this report block.

   begin_seq: 16 bits
        The first sequence number that this value.

4.4 Statistics Summary Report Block

   This block reports statistics beyond the information carried in the
   standard RTCP packet format, but not as fine grained as on.

   end_seq: 16 bits
        The last sequence number that carried this block reports on plus one.

   chunk i: 16 bits
        There are three chunk types: run length, bit vector, and
        terminating null, defined in the report blocks previously described.  Information following sections.  If the
        chunk is recorded
   about lost packets, duplicate packets, jitter measurements, and TTL
   values (TTL values being taken from all zeroes then it is a terminating null chunk.
        Otherwise, the TTL field leftmost bit of IPv4 packets, if the data packets are carried over IPv4).  Such information can be
   useful chunk determines its type: 0
        for network management.

   The report block contents are dependent upon a bit vector carried in
   the first part of the header.  Not all parameters need to be reported
   in each block.  Flags indicate which are run length and which are not reported.
   The fields corresponding to unreported parameters MUST be set to
   zero. The receiver MUST ignore any Statistics Summary Report Block
   with a non-zero value in any field flagged as unreported.

   The Statistics Summary Report Block has the following format: 1 for bit vector.

4.1.1 Run Length Chunk

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=4      |L|D|J|T| rsvd. |       block length = 9        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          begin_seq            |             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        lost_packets 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|        bit vector           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        dup_packets                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         min_jitter                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         max_jitter                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         avg_jitter                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         dev_jitter                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   min_ttl     |   max_ttl     |   avg_ttl     |     dev_ttl   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   block
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   chunk type (BT): 8 bits
        A Statistics Summary Report Block is identified by the constant
        4.

   loss report flag (L): (C): 1 bit
        Bit set to 1 if the lost_packets field contains
        A one identifies this as 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 vector chunk.

   bit
        Bit set vector: 15 bits
        The vector is read from left to 1 if right, in order of increasing
        sequence number (with the min_jitter, max_jitter, avg_jitter, and
        dev_jitter fields appropriate allowance for wraparound).

4.1.3 Terminating Null Chunk
   This chunk is all contain reports, zeroes.

    0 if none of them do.

   TTL flag (T):                   1 bit
        Bit set to
    0 1 if the min_ttl, max_ttl, avg_ttl, and dev_ttl
        fields all contain reports, 2 3 4 5 6 7 8 9 0 if none of them do.

   rsvd.: 1 2 3 4 bits 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2 Duplicate RLE Report Block

   This field is reserved for future definition.  In the absence of
        such definition, the bits block type permits per-sequence-number reports on duplicates in this field MUST
   a source's RTP packet stream.  Such information can be set to zero used for
   network diagnosis, and
        MUST be ignored by the receiver.

   block length: 16 bits provide an alternative to packet losses as a
   basis for multicast tree topology inference.

   The constant 9, in accordance with Duplicate RLE Report Block format is identical to the definition of this field
        in Section 3.

   begin_seq: 16 bits
        As defined Loss RLE
   Report Block format.  Only the interpretation is different, in Section 4.1.

   end_seq: 16 bits
        As defined that
   the information concerns packet duplicates rather than packet losses.
   The trace to be encoded in Section 4.1.

   lost_packets: 32 bits
        Number this case also consists of lost packets in zeros and ones,
   but a zero here indicates the above sequence number interval.

   dup_packets: 32 bits
        Number presence of duplicate packets in the above for a
   given sequence number
        interval.

   min_jitter: 32 bits number, whereas a one indicates that no duplicates
   were received.

   The minimum relative transit time between two packets in the
        above existence of a duplicate for a given 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 is
   determined over the same
        units.

   max_jitter: 32 bits
        The maximum relative transit time between two entire reporting period.  For example, if packet
   number 12,593 arrives, followed by other packets with other sequence
   numbers, the arrival later in the
        above reporting period of another packet
   numbered 12,593 counts as a duplicate for that sequence number interval.

   avg_jitter: 32 bits number.  The average relative transit time between each two
   duplicate does not need to follow immediately upon the first packet series
   of that number.  Care must be taken that a report does not cover a
   range of 65,534 or greater in the above sequence number interval.

   dev_jitter: 32 bits
        The standard deviation of the relative transit time between each
        two packet series in space.

   No distinction is made between the above sequence number interval.

   min_ttl: 8 bits
        The minimum TTL value of data packets in sequence number range.

   max_ttl: 8 bits
        The maximum TTL value existence of data a single duplicate
   packet and multiple duplicate packets in for a given sequence number range.

   avg_ttl: 8 bits
        The average TTL value of data packets number.
   Note also that since there is no duplicate for a lost packet, a loss
   is encoded as a one in sequence number range.

   dev_ttl: 8 bits a Duplicate RLE Report Block.

   The standard deviation of TTL values of data packets in sequence
        number range.

4.5 Receiver Timestamp Duplicate RLE Report Block

   This block extends RTCP's timestamp reporting so that non-senders may
   also send timestamps.  It recapitulates the NTP timestamp fields from has the RTCP Sender Report [7, Sec. 6.3.1].  A non-sender may estimate
   its RTT to other participants, as proposed in [11], by sending this
   report block and receiving DLRR Report Blocks (see next section) in
   reply. 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=5     BT=2      |   reserved rsvd. |   T   |         block length = 2          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              NTP timestamp, most significant word                        SSRC of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             NTP timestamp, least significant word          begin_seq            |             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          chunk 1              |             chunk 2           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          chunk n-1            |             chunk n           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   block type (BT): 8 bits
        A Receiver Timestamp Duplicate RLE Report Block is identified by the constant
        5.

   reserved: 8 2.

   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
        As defined in Section 4.1.

   block length: 16 bits
        The constant 2,
        Defined in accordance with the definition Section 3.

   SSRC of this field source: 32 bits
        As defined in Section 3.

   NTP timestamp: 64 4.1.

   begin_seq: 16 bits
        Indicates the wallclock time when this block was sent so that it
        may be used
        As defined in combination with timestamps returned Section 4.1.

   end_seq: 16 bits
        As defined in DLRR Section 4.1.

   chunk i: 16 bits
        As defined in Section 4.1.

4.3 Packet Receipt Times Report Blocks (see next section) from other receivers to measure
        round-trip propagation to those receivers.  Receivers should
        expect that 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 measurement accuracy topology of the timestamp may be
        limited multicast tree used
   to far less than distribute the resolution source's RTP packets, and of the NTP timestamp.
        The measurement uncertainty of delays along the timestamp is not indicated as
        it may not be known. A report block sender
   links within that tree.  It can keep track
        of elapsed time but has no notion of wallclock time may use also be used to measure partial path
   characteristics and to model distributions for packet jitter.

   Packet receipt times are expressed in the
        elapsed time since joining same units as used in the session instead.
   RTP timestamps of data packets.  This is assumed
        to be less than 68 years, so that, for each packet,
   one can establish both the high bit will be zero.  It is
        permissible to use send time and the sampling clock to estimate elapsed
        wallclock time. A report sender receipt time in
   comparable terms.  Note, however, that has no notion of wallclock
        or elapsed as an RTP sender ordinarily
   initializes its time may set the NTP timestamp to zero.

4.6 DLRR Report Block

   This block extends RTCP's delay since last sender report (DLSR)
   mechanism [7, Sec. 6.3.1] so a value chosen at random, there can be no
   expectation that non-senders may also calculate
   round trip times, as proposed in [11].  It is termed DLRR for reported send and receipt times will differ by an
   amount equal to the one-way delay
   since last receiver report, between sender and may receiver.  The
   reported times can nonetheless be sent useful for the purposes mentioned
   above.

   At least one packet MUST have been received for each sequence number
   reported upon in response this block.  If this block type is used to report
   receipt times for a Receiver
   Timestamp Report Block (see previous section) from series of sequence numbers that includes lost
   packets, several blocks are required.  If duplicate packets have been
   received for a receiver given sequence number, and those packets differ in
   their receipt times, any time other than the earliest MUST NOT be
   reported.  This is to
   allow that receiver ensure consistency among reports.

   Times reported in RTP timestamp format consume more bits than loss or
   duplicate information, and do not lend themselves to calculate its round trip time run length
   encoding.  The use of thinning is encouraged to limit the
   respondent.  The report consists size of one or more 3 word sub-blocks:
   one sub-block per receiver report.
   Packet Receipt Times Report Blocks.

   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=6     BT=3      |   reserved rsvd. |   T   |         block length          |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 SSRC_1 (SSRC                        SSRC of first receiver) source                         | sub-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
   |                         last RR (LRR)          begin_seq            |             end_seq           |   1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   delay since last RR (DLRR)       Receipt time of packet begin_seq                        |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 SSRC_2 (SSRC       Receipt time of second receiver) packet (begin_seq + 1) mod 65536        | sub-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
   :                              ...                              :   2
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Receipt time of packet (end_seq - 1) mod 65536          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   block type (BT): 8 bits
        A DLRR Packet Receipt Times Report Block is identified by the
        constant 6.

   reserved: 8 3.

   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.

   block length: 16 bits

   thinning (T): 4 bits
        As defined in Section 4.1.

   block length: 16 bits
        Defined in Section 3.

   last RR timestamp (LRR):

   SSRC of source: 32 bits
        The middle 32
        As defined in Section 4.1.

   begin_seq: 16 bits out of 64
        As defined in the NTP timestamp (as explained Section 4.1.

   end_seq: 16 bits
        As defined in the previous section) received as part Section 4.1.

   Receipt time of a Receiver
        Timestamp Report Block from participant SSRC_n. If no such block
        has been received, the field is set to zero.

   delay since last RR (DLRR): packet i: 32 bits
        The delay, expressed in units receipt time of 1/65536 seconds, between
        receiving the last Receiver Timestamp Report Block from
        participant SSRC_n and sending this DLRR Report Block.  If no
        Receiver Timestamp Report Block has been received yet from
        SSRC_n, packet with sequence number i at the DLRR field
        receiver.  The modular arithmetic shown in the packet format
        diagram is set to zero (or the DLRR allow for sequence number rollover.  It is omitted
        entirely). Let SSRC_r denote
        preferable for the receiver issuing this DLRR
        Report Block. Participant SSRC_n can compute time value to be established at the round-trip
        propagation delay link
        layer interface, or in any case as close as possible to SSRC_r by recording the time A when this
        Receiver Timestamp Report Block is received.  It calculates wire
        arrival time.  Units and format are the
        total round-trip time A-LSR using same as for the last SR
        timestamp (LSR)
        field, and then subtracting this field in RTP data packets.  As opposed to leave the round-trip
        propagation delay as A-LSR-DLSR. This is illustrated RTP data packet
        timestamps, in [7, Fig.
        2].

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 which nominal values may be used instead of losses and
   discards, as both have equal effect on call quality.

   In
        system clock values in order to properly assess convey information useful for
        periodic playout, the quality of a Voice over IP call it is
   desirable to consider receipt times should reflect the degree of burstiness of packet loss [10].
   Following a Gilbert-Elliott model [2], 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 actual
        time between two bursts is as closely as possible.  For a
   "gap."  Bursts correspond to periods of session, if the RTP
        timestamp is chosen at random, the first receipt time during which value
        SHOULD also be chosen at random, and subsequent timestamps
        offset from this value.  On the packet
   loss rate other hand, if the RTP timestamp
        is high enough to produce noticeable degradation in audio
   quality.  Gaps correspond meant to periods of reflect the reference time during which only
   isolated lost packets may occur, and in general these can be masked
   by packet loss concealment.  Delay reports include at the transit delay
   between RTCP end points and sender, then the VoIP end system processing delays,
   both of which contribute
        receipt time SHOULD be as close as possible 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 [2]) and mean opinion scores (MOS scores).

   An implementation that sends these blocks SHOULD send reference
        time at least one
   every ten seconds for the duration of the call, SHOULD send one
   whenever a codec type change or other significant change occurs,
   SHOULD send one when significant call quality degradation is detected
   and SHOULD receiver.

4.4 Receiver Reference Time Report Block

   This block extends RTCP's timestamp reporting so that non-senders may
   also send one upon call termination.  Implementations MUST
   provide values for all timestamps.  It recapitulates the NTP timestamp fields defined here.  For certain metrics,
   if the value is undefined or unknown, then from
   the specified default or
   unknown field value MUST be provided.

   The block is encoded RTCP Sender Report [10, Sec. 6.3.1].  A non-sender may estimate
   its round trip time (RTT) to other participants, as seven 32-bit words: proposed in [17],
   by sending this report block and receiving DLRR Report Blocks (see
   next section) in reply.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=7     BT=4      |   reserved    |       block length = 6        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   loss rate   | discard rate  | burst density |  gap density  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       burst duration          |         gap duration          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     round trip delay          |       end system delay        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | signal level  |  noise level  |     RERL      |     Gmin 2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   R factor    | ext. R factor |    MOS-LQ     |    MOS-CQ              NTP timestamp, most significant word             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   RX config   |  JB nominal   |  JB maximum   |  JB abs max             NTP timestamp, least significant word             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   block type (BT): 8 bits
        A VoIP Metrics Receiver Reference Time Report Block is identified by the
        constant 7. 4.

   reserved: 8 bits
        This field is reserved for future definition.  In the absence of
        such definition, the bits in this field MUST be set to zero and
        MUST be ignored by the receiver.

   block length: 16 bits
        The constant 6, 2, in accordance with the definition of this field
        in Section 3.

   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.

4.7.1 Packet Loss and Discard Metrics

   It is very useful to distinguish between packets lost by

   NTP timestamp: 64 bits
        Indicates the network
   and those discarded due 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 jitter. Both have equal effect on measure
        round-trip propagation to those receivers.  Receivers should
        expect that the
   quality measurement accuracy of the voice stream however having separate counts helps
   identify the source of quality degradation. These fields MUST timestamp may be
   populated.

   loss rate: 8 bits
        The fraction of RTP data packets from the source lost since
        limited to far less than the
        beginning resolution of reception, expressed as a fixed point number with the binary point at the left edge NTP timestamp.
        The measurement uncertainty of the field.  This value timestamp is
        calculated by dividing the total number of packets lost (after
        the effects of applying any error protection such not indicated as FEC) by the
        total number
        it may not be known. A report block sender that can keep track
        of packets expected, multiplying the result elapsed time but has no notion of wallclock time may use the
        division by 256, limiting
        elapsed time since joining the maximum value session instead. This is assumed
        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 less than that which triggers a
        discard.

   discard rate: 8 bits
        The fraction of RTP data packets from 68 years, so the source that have been
        discarded since high bit will be zero.  It is
        permissible to use the beginning of reception, due sampling clock to late or early
        arrival, under-run estimate elapsed
        wallclock time. A report sender that has no notion of wallclock
        or overflow at elapsed time may set the receiving jitter buffer. NTP timestamp to zero.

4.5 DLRR Report Block

   This value is expressed block extends RTCP's delay since last Sender Report (DLSR)
   mechanism [10, Sec. 6.3.1] so that non-senders may also calculate
   round trip times, as a fixed point number with the binary
        point at the left edge of the field. proposed in [17].  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), termed DLRR for delay
   since last Receiver Report, and
        taking the integer part.

4.7.2 Burst Metrics

   A burst, informally, is a period of high packet losses and/or
   discards.  Formally, a burst is defined as may be sent in response to a longest sequence of
   packets bounded by lost or discarded packets with the constraint that
   within Receiver
   Timestamp Report Block (see previous section) from a burst any sequence of successive packets receiver to
   allow that were received,
   and not discarded due receiver to delay variation, is of length less than a
   value Gmin.

   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 calculate its round trip time to the receipt time
   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 the last
   received packet before the first burst, (b) receiver)               | sub-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
   |                         last RR (LRR)                         |   1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   delay since last RR (DLRR)                  |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                 SSRC_2 (SSRC of second receiver)              | sub-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
   :                               ...                             :   2
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   block type (BT): 8 bits
        A DLRR Report Block is identified by the period from constant 5.

   reserved: 8 bits
        This field is reserved for future definition.  In the end absence of
        such definition, the last burst bits in this field MUST be set to either zero and
        MUST be ignored by the time receiver.

   block length: 16 bits
        Defined in Section 3.

   last RR timestamp (LRR): 32 bits
        The middle 32 bits out of 64 in the report or NTP timestamp (as explained
        in the end previous section) received as part of a Receiver
        Reference Time Report Block from participant SSRC_n. If no such
        block has been received, the
   RTP session, whichever comes first, or (c) the period field is set to zero.

   delay since last RR (DLRR): 32 bits
        The delay, expressed in units of time 1/65536 seconds, between
   two bursts.

   For
        receiving the purpose of determining if a lost or discarded packet near last Receiver Reference Time Report Block from
        participant SSRC_n and sending this DLRR Report Block.  If no
        Receiver Reference Time Report Block has been received yet from
        SSRC_n, the
   start or end of an RTP session is within a gap or a burst it DLRR field is
   assumed that set to zero (or the RTP session DLRR is preceded and followed by at least
   Gmin received packets, and that omitted
        entirely). Let SSRC_r denote the time of receiver issuing this DLRR
        Report Block. Participant SSRC_n can compute the report is followed round-trip
        propagation delay to SSRC_r by
   at least Gmin received packets. recording the time A gap has when this
        Receiver Timestamp Report Block is received.  It calculates the property that any lost or discarded packets within
        total round-trip time A-LSR using the
   gap must be preceded and followed by at least Gmin packets that were
   received last SR timestamp (LSR)
        field, and not discarded. then subtracting this field to leave the round-trip
        propagation delay as A-LSR-DLSR. This gives a maximum loss/discard
   density within a gap of: 1 / (Gmin + 1).

   A Gmin value of 16 is RECOMMENDED as it results illustrated 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, 0 a lost, and X a discarded [10,
        Fig. 2].

4.6 Statistics Summary Report Block

   This block reports statistics beyond the information carried in the
   standard RTCP packet format, but not as fine grained as that carried
   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 report blocks previously described.  Information is recorded
   about lost packet.  The first gap starts
   at the beginning of the session packets, duplicate packets, jitter measurements, and the second gap ends at the time TTL
   or Hop Limit values.  Such information can be useful for network
   management.

   The report block contents are dependent upon a series of flags bit
   carried in the report.

   If the packet spacing is 10 ms and the Gmin value is the recommended
   value first part 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 density          12, which corresponds header.  Not all parameters need to 5%
   discard density       12,
   be reported in each block.  Flags indicate which corresponds to 5%
   burst density         84, are and which corresponds are
   not reported.  The fields corresponding to 33%
   gap density           10, which corresponds unreported parameters MUST
   be set to 4%
   burst duration       120, value in milliseconds
   gap duration         520, zero. The receiver MUST ignore any Statistics Summary
   Report Block with a non-zero value in milliseconds

   burst density: 8 bits any field flagged as
   unreported.

   The fraction 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                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         avg_jitter                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         dev_jitter                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | min_ttl_or_hl | max_ttl_or_hl | avg_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, avg_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, avg_ttl_or_hl, or dev_ttl_or_hl contain reports.
        If the field is non-zero then all of these fields contain
        reports.  The value 1 signifies that they report on IPv4 TTL
        values.  The value 2 signifies that they report on IPv6 Hop
        Limit values.  This value 3 is undefined and MUST NOT be used.

   rsvd.: 3 bits
        This field is reserved for future definition.  In the absence of
        such definition, the bits in this field MUST be set to zero and
        MUST be ignored by the receiver.

   block length: 16 bits
        The constant 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.

   avg_jitter: 32 bits
        The average relative transit time between each two packet series
        in the above sequence number interval.

   dev_jitter: 32 bits
        The standard deviation of the relative transit time between each
        two packet series in the above sequence number interval.

   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.

   avg_ttl_or_hl: 8 bits
        The average TTL or Hop Limit value of data packets in the
        sequence number range.

   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 RTCP 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 [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.

   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 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.

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.

   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, informally, is a period of high packet losses and/or
   discards.  Formally, a burst is defined as a longest sequence of
   packets bounded by lost or discarded packets with the constraint that
   within a burst any sequence of successive packets that were received,
   and not discarded due to delay variation, is of length less than a
   value Gmin.

   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
   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
   density 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, 0 a lost, 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 density          12, which corresponds to 5%
   discard density       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

   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.

   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.

   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 that were either lost or discarded. 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 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 to be 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
        value distinction is expressed as a fixed point number
   consistent with the binary point
        at the left edge use of the field.  It is RTCP for delay measurements.

   round trip delay: 16 bits
        The most recently calculated by dividing round trip time between RTP
        interfaces, expressed in milliseconds. This value MAY be
        measured using RTCP, the
        total number DLRR method defined in Section 4.5 of packets lost
        this document or discarded (excluding duplicate
        packet discards) within burst periods by the total number of
        packets expected within other approaches.  If RTCP is used then the burst periods, multiplying
        reported delay value is the
        result time of receipt of the division by 256, limiting most recent
        RTCP packet from source SSRC, minus the maximum 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 255
        (to avoid overflow), and taking the integer part.

   gap density: 8 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 fraction of most recently estimated end system delay, expressed in
        milliseconds.  End system delay is defined as the total
        encoding, decoding and jitter buffer delay determined at the
        reporting endpoint.  This is the time required for an RTP data packets within inter-burst gaps since frame
        to be buffered, decoded, converted to analog form, looped back
        at the beginning of reception that were either lost or discarded. local analog interface, encoded, and made available for
        transmission as an RTP frame.  The manner in which this value is expressed as a fixed point number with
        estimated is implementation dependent.  This parameter MUST be
        provided in all VoIP metrics reports.

   Note that the binary
        point at one way symmetric VoIP segment delay may be calculated
   from the left edge of round trip and end system delays as follows.  If the field.  It round
   trip delay is calculated by
        dividing the total number of packets lost or discarded
        (excluding duplicate packet discards) within gap periods by denoted RTD and the
        total number of packets expected within end system delays associated with
   the gap periods,
        multiplying 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 result non-packet elements of the division by 256, limiting the
        maximum value voice over IP system to 255 (to avoid overflow), and taking
   assist with the integer
        part.

   burst duration: 16 bits
        The mean duration, expressed in milliseconds, identification of problems affecting call quality.
   The values identified below must be determined for the burst
        periods received audio
   signal. The information required to populate these fields may not be
   available in all systems, although it is strongly recommended that have occurred since
   this data SHOULD be provided to support problem diagnosis.

   signal level: 8 bits
        The voice signal relative level is defined as the beginning ratio of reception. the
        signal level to a reference digital milliwatt, expressed in
        decibels as a signed integer in two's complement form.  This is
        measured only for packets containing speech energy.  The duration intent
        of each period this metric is calculated based upon not to provide a precise measurement of the packets
        signal level but to provide a real time indication that mark the beginning and end
        signal level may be excessively high or low.

        signal level = 10 Log10 ( rms talkspurt power (mW) )

        A value of 127 indicates that period.  It this parameter is equal unavailable.
        Typical values should be generally in the -15 to -20 dBm range.

   noise level: 8 bits
        The noise level is defined as the timestamp ratio of the end packet, plus the duration silent period
        background noise level to a reference digital milliwatt,
        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 is defined as the end
        packet, minus the timestamp sum of the beginning packet.  If the
        actual values are not available, estimated values MUST be used.
        If there have been no burst periods,
        measured echo return loss (ERL) and the burst duration value
        MUST be zero.

   gap duration: 16 bits
        The mean duration, echo return loss
        enhancement (ERLE) expressed in milliseconds, of dB as a signed integer in two's
        complement form.  It defines the gap periods ratio of a transmitted voice
        signal that have occurred since is reflected back to the beginning talker.  A low level of reception.  The
        duration
        echo return loss (say less than 20 dB) in conjunction with some
        delay can lead to hollowness or audible echo.  A high level of each period
        echo return loss (say over 40 dB) is calculated based upon preferable.

   The ERL and ERLE parameters are often available directly from the packet that
        marks
   echo canceler contained within the VoIP end of the prior burst and the packet that marks system. They relate to
   the
        beginning of echo on the subsequent burst. It is equal external network attached to the timestamp
        of the subsequent burst packet, minus end point.

   In the timestamp case of a VoIP gateway this would be line echo that typically
   occurs at 2-4 wire conversion points in the prior
        burst packet, plus network.  Echo return
   loss from typical 2-4 wire conversions can be in the duration 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 prior burst packet. case of an IP phone this could be
   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 due to acoustic feedback.

   Typical values for RERL are as follows:

   (i) 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

   (ii) 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

   (iii) IP phone with conventional handset
   Acoustic coupling from handset speaker to microphone 40 dB
   Residual echo return loss = TCL = 40 dB

   If we denote 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 "local" end of the prior burst packet VoIP path as A and the duration of remote end
   as B and if the prior burst packet sender loudness rating (SLR) and receiver loudness
   rating (RLR) are replaced by the
        reception start time.  In known for A (default values 8 dB and 2 dB
   respectively), then the case of a gap that occurs echo loudness level 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 to be part of the voice application A (talker echo
   loudness rating 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 TELR) 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 given by:

   TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)

   TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)

   Hence in milliseconds. This value is order to incorporate echo into a voice quality estimate at
   the time of
        receipt A end of a VoIP connection it is desirable to send the most recent RTCP packet ERL + ERLE
   value from source SSRC, minus B to A.

   For an IP phone with handset this metric MUST be set to the LSR (last SR) time designed
   or measured terminal coupling loss, which would typically be 40-50
   dB.

   For a PC softphone or speakerphone this metric MUST be set to either
   the value reported in its SR (sender report), minus by the DLSR (delay since last SR) acoustic echo canceler or to 127 to
   indicate an undefined value.

   For an IP gateway with ERL and ERLE measurements this metric MUST be
   reported in its SR.  A non-zero
        LSR value as ERL + ERLE.

   For an IP gateway without ERL and ERLE measurement capability then
   this metric MUST be reported as 12 dB if line echo cancellation is REQUIRED in order to calculate round trip delay. A
        value of 0
   disabled and 40 dB if line echo cancellation is permissible during enabled.

   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 first two call quality or three RTCP
        exchanges as insufficient data
   transmission quality, and incorporate the effects of codec type,
   packet loss, discard, burstiness, delay etc.  These metrics may not
   be available to determine
        delay in all systems however MUST SHOULD be populated as soon as a delay estimate is
        available.

   end system delay: 16 provided in order to
   support problem diagnosis.

   R factor: 8 bits
        The most recently estimated end system delay, expressed in
        milliseconds.  End system delay R factor is defined as a voice quality metric describing the total
        encoding, decoding and jitter buffer delay determined at segment of
        the
        reporting endpoint.  This call that is the time required for an carried over this RTP frame session.  It is expressed
        as an integer in the range 0 to be buffered, decoded, converted 100, with a value of 94
        corresponding to analog form, looped back
        at the local analog interface, encoded, "toll quality" and made available for
        transmission values of 50 or less
        regarded as an RTP frame.  The manner in which this 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
        estimated unavailable.

   ext. R factor: 8 bits
        The external R factor is implementation dependent.  This parameter MUST be
        provided in all VoIP metrics reports.

   Note that a voice quality metric describing the one way symmetric VoIP
        segment delay may be calculated
   from the round trip and end system delays as follows.  If of the round
   trip delay call that is denoted RTD and the end system delays associated with carried over a network segment
        external to 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 RTP segment, for example a cellular network. Its
        values are intended to provide real time information
   related to interpreted in the same manner as for the RTP R
        factor.  This metric is defined as including the non-packet elements 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 system to
   assist with the identification of problems affecting call quality.
   The values identified below must be determined termination for the received audio
   signal. The information required to populate these fields may not be
   available in all systems, although it is strongly recommended which this metrics block applies.

        A value of 127 indicates that this data SHOULD parameter is unavailable.

   Note that an overall R factor may be provided to support problem diagnosis.

   signal level: 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 signal relative level 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 ratio effects of the
        signal level delay and can be
        compared to a reference digital milliwatt, MOS scores obtained from listening quality (ACR)
        tests. It is expressed in
        decibels as a signed an 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 range 10 to provide 50,
        corresponding to MOS x 10.  For example, a real time indication that the
        signal level may be excessively high or low.

        signal level = 10 log 10 ( rms talkspurt power (mW) ) value of 35 would
        correspond to an estimated MOS score of 3.5.

        A value of 127 indicates that this parameter is unavailable.
        Typical values should be generally in the -15 to -20 dBm range.

   noise level:

   MOS-CQ: 8 bits
        The noise level estimated mean opinion score for conversational quality
        (MOS-CQ) is defined as including the ratio effects of the silent period
        background noise level delay and other
        effects that would affect conversational quality.  The metric
        may be calculated by converting an R factor determined according
        to a reference digital milliwatt,
        expressed ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an estimated
        MOS using the equation specified in decibels G.107.  It is expressed as a signed
        an integer in two's complement
        form.

        noise level = the range 10 log10 ( rms silence power (mW) ) to 50, corresponding to MOS x 10, as
        for MOS-LQ.

        A value of 127 indicates that this parameter is unavailable.

   residual echo return loss (RERL):

4.7.6 Configuration Parameters

   Gmin: 8 bits
        The residual echo return 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
        packets that occur within Gmin packets of a report being
        generated may be reclassified as being 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 defined as the sum
        reproduced in Appendix A.2 of the
        measured echo return loss (ERL) present document.  Gmin MUST
        not be zero and MUST be provided.

   receiver configuration byte (RX config): 8 bits
        This byte consists of the echo return following fields:

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |PLC|JBA|JB rate|
        +-+-+-+-+-+-+-+-+

        packet loss
        enhancement (ERLE) expressed in dB as a signed integer in two's
        complement form.  It defines the ratio of concealment (PLC): 2 bits
             Standard (11) / enhanced (10) / disabled (01) / unspecified
             (00).  When PLC = 11 then a transmitted voice
        signal that simple replay or interpolation
             algorithm is reflected back being used to fill-in the talker.  A low level of
        echo return loss (say less than 20 dB) in conjunction missing packet.
             This is typically able to conceal isolated lost packets
             with some
        delay can lead loss rates under 3%.  When PLC = 10 then an enhanced
             interpolation algorithm is being used.  This would
             typically be able to hollowness conceal lost packets for loss rates of
             10% or audible echo.  A high level more.  When PLC = 01 then silence is inserted in
             place of
        echo return loss (say over 40 dB) lost packets.  When PLC = 00 then no information
             is preferable.

   The ERL and ERLE parameters are often available directly from concerning the
   echo canceler contained within 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 VoIP end system. They relate jitter buffer is adaptive then its size is
             being dynamically adjusted to deal with varying levels of
             jitter.  When non-adaptive, the echo on the external network attached to jitter buffer size is
             maintained at a fixed level.  When either adaptive or non-
             adaptive modes are specified then the end point.

   In jitter buffer size
             parameters below MUST be specified.

        jitter buffer rate (JB rate): 4 bits
             J = adjustment rate (0-15). This represents the case
             implementation specific adjustment rate of a VoIP gateway this would be line echo that typically
   occurs at 2-4 wire conversion points jitter buffer
             in the network.  Echo return
   loss from typical 2-4 wire conversions can be adaptive mode. This parameter is defined in the 8-12 dB range.
   A line echo canceler can provide an ERLE terms of 30 dB or more and hence
   reduce this to 40-50 dB.  In the case of an IP phone this could be
   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 due
             approximate time taken to acoustic feedback.

   Typical values for RERL are as follows:

   (i) IP gateway connected fully adjust 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

   (ii) IP gateway connected a step change in
             peak to circuit switched network with 2 wire loop
   With echo canceler that improves echo by 30 dB
   RERL = ERL + ERLE = 12 + 30 = 42 dB

   (iii) IP phone with conventional handset
   Acoustic coupling peak jitter from handset speaker 30 ms to microphone 40 dB
   Residual echo return loss = TCL 100 ms such that:

             adjustment time = 40 dB

   If we denote 2 * J * frame size (ms)

             This parameter is intended only to provide a guide to the "local" end
             degree of the VoIP path as A and the remote end
   as B "aggressiveness" of a an adaptive jitter buffer
             and if may be estimated. A value of 0 indicates that the sender loudness rating (SLR) and receiver loudness
   rating (RLR) are known
             adjustment time is unknown for A (default values this implementation.

   reserved: 8 dB 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 2 dB
   respectively), then
        MUST be ignored by the echo loudness level at end A (talker echo
   loudness rating or TELR) receiver.

4.7.7 Jitter Buffer Parameters

   jitter buffer nominal delay (JB nominal): 16 bits
        This is given by:

   TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)

   TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)

   Hence the current nominal jitter buffer delay in order milliseconds,
        which corresponds to incorporate echo into a voice quality estimate at the A end of a VoIP connection it 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 desirable the current maximum jitter buffer delay corresponding to
        the earliest arriving packet that would not be discarded.  In
        simple queue implementations this may correspond to send the ERL + ERLE nominal
        size. In adaptive jitter buffer implementations this value from B may
        dynamically vary up to A.

   For an IP phone with handset this metric JB abs max (see below).  This parameter
        MUST be set to provided for both fixed and adaptive jitter buffer
        implementations.

   jitter buffer absolute maximum delay (JB abs max): 16 bits
        This is the designed
   or measured terminal coupling loss, which would typically absolute maximum delay that the adaptive jitter
        buffer can reach under worst case jitter conditions.  This
        parameter MUST be 40-50
   dB.

   For a PC softphone or speakerphone this metric 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
   the value reported by applications that
   implement the acoustic echo canceler SDP Offer/Answer model [9] or by applications that use
   SDP to 127 to
   indicate an undefined value.

   For an IP gateway with ERL describe media and ERLE measurements this metric MUST transport configurations in connection with
   such protocols as the Session Announcement Protocol (SAP) [15] or the
   Real Time Streaming Protocol (RTSP) [16].  There exist other
   potential signaling methods, which are not defined here.

   The XR blocks MAY be
   reported used without prior signaling.  This is
   consistent with the rules governing other RTCP packet types, as ERL + ERLE.

   For
   described in [10].  An example in which signaling would not be used
   is an IP gateway without ERL and ERLE measurement capability then
   this metric 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 reported used as 12 dB if line echo cancellation is
   disabled and 40 dB if line echo cancellation defined here.  If SDP signaling
   is enabled.

   Gmin
        See Configuration Parameters (Section 4.7.6, below).

4.7.5 Call Quality or Transmission Quality Metrics

   The following metrics used in an environment where XR blocks are direct measures only implemented by
   some fraction of the call quality or
   transmission quality, and incorporate participants, the effects of codec type,
   packet loss, discard, burstiness, delay etc.  These metrics may 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 available 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 systems however SHOULD media
   level blocks in the session.  Any media level specification MUST
   replace a session level specification, if one is present, for that
   media block.

   rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF

   xr-format = pkt-loss-rle
             / pkt-dup-rle
             / pkt-rcpt-times
             / rcvr-rtt
             / stat-summary
             / voip-metrics
             / format-ext

   pkt-loss-rle   = "pkt-loss-rle" ["=" max-size]
   pkt-dup-rle    = "pkt-dup-rle" ["=" max-size]
   pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size]
   rcvr-rtt       = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size]
   stat-summary   = "stat-summary"
   voip-metrics   = "voip-metrics"
   max-size       = 1*DIGIT ; maximum block size in octets
   rcvr-rtt-mode  = "all"
                  / "sender"
   format-ext     = non-ws-string

   non-ws-string  = 1*(%x21-FF)

   The "rtcp-xr" attribute contains zero, one, or more XR block related
   parameters.  Each parameter signals functionality for an XR block, or
   a group of XR blocks.  The attribute is extensible so that parameters
   can be provided 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
   support problem diagnosis.

   R factor: 8 bits
        The R factor carry out their functions.

   Round trip time (RTT) measurement is an example of collaborative
   functionality.  An RTP data packet receiver sends a voice quality metric describing 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 segment 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 call that is carried over unilateral category, this RTP session.  It is expressed document defines the following
   parameters.  The parameter names and their corresponding XR formats
   are as follows:

   Parameter name    XR block (block type and name)
   --------------    ------------------------------------
   pkt-loss-rle      1  Loss RLE Report Block
   pkt-dup-rle       2  Duplicate RLE Report Block
   pkt-rcpt-times    3  Packet Receipt Times Report Block
   stat-summary      6  Statistics Summary Report Block
   voip-metrics      7  VoIP Metrics Report Block

   The "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters
   MAY specify an integer value.  This value indicates the largest size
   the whole report block SHOULD have in octets.  This shall be seen as
   an indication that thinning shall be applied if necessary to meet the
   target size.

   Blocks in the range 0 collaborative category are classified as initiator
   blocks or response blocks.  Signaling SHOULD indicate which
   participants are required to 100, with a value of 94
        corresponding respond 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 [4] and ETSI TS
        101 329-5 [2]. initiator block.  A value of 127 indicates party
   that wishes to receive response blocks from those participants can
   trigger this parameter is unavailable.

   ext. R factor: 8 bits
        The external R factor is a voice quality metric describing by sending an initiator block.

   The collaborative category currently consists only of one
   functionality, namely the
        segment RTT measurement mechanism for RTP data
   receivers.  The collective functionality of the call that Receiver Reference
   Time Report Block and DLRR Report Block is carried over a network segment
        external to the RTP segment, for example a cellular network. Its
        values are interpreted in represented by the same manner "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 R
        factor.  This metric is defined as including the effects of
        delay, consistent with ITU-T G.107 [4] and ETSI TS 101 329-5
        [2], data senders and relates to the outward voice path from data receivers
   MAY send DLRR blocks, while the Voice over
        IP termination for which this metrics block applies.

        A mode value of 127 "sender" indicates that this parameter
   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 unavailable.

   Note included,
   any DLRR Report Blocks that an overall R factor may be estimated from the RTP segment R
   factor and are sent SHALL NOT exceed the external R factor, as follows:

   R total = RTP R factor + ext. R factor - 94

   MOS-LQ: 8 bits
        The estimated specified
   size.  If size limitations mean opinion score for listening quality (MOS-LQ)
        is a voice quality metric on that a scale from 1 to 5, DLRR Report Block sender
   cannot report in one block upon all participants from which 5
        represents excellent and 1 represents unacceptable.  This metric
        is defined as not including the effects of delay and can it has
   received a Receiver Reference Time Report Block then it SHOULD report
   on participants in a round robin fashion across several report
   intervals.

   The "rtcp-xr" attributes parameter list MAY be
        compared to MOS scores obtained from listening quality (ACR)
        tests. It empty.  This is expressed as an integer useful
   in the range 10 cases in which an application needs to 50,
        corresponding signal that it understands
   the SDP signaling but does not wish to MOS x 10. avail itself of XR
   functionality.  For example, an application in a value of 35 would
        correspond SIP controlled
   session could signal that it wishes to an estimated MOS score of 3.5.

        A value of 127 indicates stop using all XR blocks by
   removing all applicable SDP parameters in a re-INVITE message that this parameter is unavailable.

   MOS-CQ: 8 bits
        The estimated mean opinion score for conversational quality
        (MOS-CQ) is defined as including it
   sends.  If XR blocks are not to be used at all from the effects beginning of delay and other
        effects
   a session, it is RECOMMENDED that would affect conversational quality.  The metric
        may the "rtcp-xr" attribute not be calculated by converting an R factor determined according
        to ITU-T G.107 [4] or ETSI TS 101 329-5 [2] into an estimated
        MOS using
   supplied at all.

   When the equation specified in G.107.  It "rtcp-xr" attribute is expressed as
        an integer in present, participants SHOULD NOT send
   XR blocks other than the range 10 to 50, corresponding to MOS x 10, as
        for MOS-LQ.

        A value ones indicated by the parameters.  This
   means that inclusion of 127 indicates a "rtcp-xr" attribute without any parameters
   tells a participant that this parameter is unavailable.

4.7.6 Configuration Parameters

   Gmin: 8 bits it SHOULD NOT send any XR blocks at all.
   The gap threshold. purpose is to conserve bandwidth.  This field contains is especially important
   when collaborative parameters are applied to a large multicast group:
   the value used for this
        report 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 to determine if a gap exists.  The recommended
        value in the absence of 16 corresponds to a burst period having a minimum
        density of 6.25% 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 lost or discarded packets, which may cause
        noticeable degradation other blocks.

5.2 Usage in call quality; during gap periods, if
        packet loss or discard occurs, each lost Offer/Answer

   In the Offer/Answer context [9], the interpretation of SDP signaling
   for XR packets depends upon the direction attribute that is signaled:
   "recvonly", "sendrecv", or discarded packet
        would be preceded by and "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 a sequence discussion of at least 16
        received non-discarded packets.  Note collaborative parameters in
   this section.

   For "sendonly" and "sendrecv" media stream offers that lost or discarded
        packets 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 occur within Gmin packets of a report being
        generated may be reclassified as being part the offerer send the
   corresponding XR blocks.  The offerer SHOULD send these blocks.

   For "recvonly" media stream offers, the offerer's use of a burst or gap the "rtcp-
   xr" attribute in
        later reports.  ETSI TS 101 329-5 [2] defines a computationally
        efficient algorithm for measuring burst and gap density using a
        packet loss/discard event driven approach.  This algorithm connection with unilateral parameters indicates that
   the offerer is
        reproduced capable of sending the corresponding XR blocks.  If
   the answerer responds with an "rtcp-xr" attribute, the offerer SHOULD
   send XR blocks for each specified unilateral parameter that was in Appendix A.2
   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 present document.  Gmin MUST
        not be zero corresponding initiator and MUST be provided.

receiver configuration byte (RX config): 8 bits
        This byte consists of replying with
   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 appropriate responses.  For example, an offer that specifies the
   "rcvr-rtt" parameter means that the offerer is being used prepared to fill-in receive
   Receiver Reference Time Report Blocks and to send DLRR Report Blocks.
   An offer of a collaborative parameter means that the missing packet.
             This is typically able answerer MAY
   send the initiator, and, having received the initiator, the offerer
   SHOULD send the responses.

   There are exceptions to conceal isolated lost packets
             with loss rates under 3%.  When PLC = 10 then the rule that an enhanced
             interpolation algorithm is being used.  This would
             typically be able to conceal lost packets for loss rates offerer of
             10% a collaborative
   parameter should send responses.  For instance, the collaborative
   parameter might specify a mode that excludes the offerer.  Or
   congestion control or more.  When PLC = 01 then silence is inserted in
             place of lost packets.  When PLC = 00 then no information
             is available concerning maximum transmission unit considerations might
   militate against 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 offerer's response.

   By including a collaborative parameter in its answer, the jitter buffer is adaptive then answerer
   declares its size is
             being dynamically adjusted ability to deal with varying levels of
             jitter.  When non-adaptive, receive initiators and to send responses.
   The offerer MAY then send initiators, to which the answerer SHOULD
   reply with responses.  As for the jitter buffer size is
             maintained at offer of a fixed level.  When either adaptive or non-
             adaptive modes collaborative parameter,
   there are specified then exceptions to the jitter buffer size
             parameters below MUST be specified.

        jitter buffer rate (JB rate): 4 bits
             J = adjustment rate (0-15). This represents rule that the
             implementation specific adjustment rate answerer should reply.

   When making an SDP offer of a jitter buffer
             in adaptive mode. This collaborative parameter is defined in terms of for a multicast
   media stream, the
             approximate time taken offerer SHOULD specify which participants are to fully adjust
   respond to a step change 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
             peak to peak jitter from 30 ms to 100 ms such that:

             adjustment time = 2 * J * frame size (ms)

             This the offer and that are
   supported by the answerer.  It SHOULD NOT include any collaborative
   parameter that is intended only to provide absent from the offer.

   If a guide 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
             degree party declares that at a minimum that it is capable
   of "aggressiveness" understanding the signaling.

5.3 Usage Outside of a an adaptive jitter buffer
             and may Offer/Answer

   SDP can be estimated. A value employed outside of 0 indicates the Offer/Answer context, for instance
   for multimedia sessions that are announced through the
             adjustment time Session
   Announcement Protocol (SAP) [15], or streamed through the Real Time
   Streaming Protocol (RTSP) [16].  The signaling model is unknown for this implementation.

4.7.7 Jitter Buffer Parameters

   jitter buffer nominal size in frames (JB nominal): 8 bits
        This simpler, as
   the sender does not negotiate parameters, but the functionality that
   is expected from specifying the "rtcp-xr" attribute is the current nominal fill point within same as in
   Offer/Answer.

   When a unilateral parameter is specified for the jitter buffer,
        which corresponds to "rtcp-xr" attribute
   associated with a media stream, the nominal jitter buffer delay for packets receiver of that arrive exactly on time.  This parameter MUST be provided
        for both fixed and adaptive jitter buffer implementations.

   jitter buffer maximum size in frames (JB maximum): 8 bits
        This is stream SHOULD
   send the current maximum jitter buffer level corresponding to XR block.  When a collaborative parameter is
   specified, only the earliest arriving packet that would not be discarded.  In
        simple queue implementations this may correspond to participants indicated by the nominal
        size. In adaptive jitter buffer implementations this mode 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 size in frames (JB abs max): 8 bits
        This is the absolute maximum size
   collaborative parameter are concerned.  Each such participant that
   receives an initiator block SHOULD send the adaptive jitter
        buffer can reach under worst case jitter conditions.  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. corresponding response
   block.  Each such participant MAY also send initiator blocks.

6. IANA Considerations

   This document defines a new RTP RTCP packet type, the extended report Extended Report
   (XR) type, within the existing Internet Assigned Numbers Authority
   (IANA) registry of RTP RTCP Control Packet Types.  This document also 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:
   registry, the registry of RTP RTCP XR Block Types.
   Within this new registry, this document defines SDP Parameters, and an initial set
   of
   seven block types six parameters, and describes how the remaining types additional parameters are to be
   allocated.

5.1

6.1 XR Packet Type

   The IANA SHALL register the RTP extended report (XR) 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).

5.2 RTP

6.2 RTCP XR Block Type Registry

   The

   This document creates an IANA SHALL create registry called the RTP RTCP XR Block Type
   Registry to cover the name space of the extended report Extended Report block type
   (BT) field specified in Section 3 of this document. 3. The BT field contains eight bits,
   allowing 256 values.  The IANA SHALL manage the RTP RTCP XR Block Type Registry is to be
   managed by the IANA according to the Specification Required policy of
   RFC 2434
   [6]. [8].  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  Timestamp  Packet Receipt Times Report Block
    4  Statistics Summary  Receiver Reference Time Report Block
    5  Receiver Timestamp  DLRR Report Block
    6  DLRR  Statistics Summary Report Block
    7  VoIP Metrics Report Block

   The BT value 255 is reserved for future extensions.

   Furthermore, future specifications SHOULD avoid the values 0 and 255. value 0.  Doing
   so facilitates packet validity checking, since an all-zeros and
   all-ones are values that field
   might commonly be found in an ill-formed
   packets.

6. packet.

6.3 The "rtcp-xr" SDP Attribute

   This SDP attribute "rtcp-xr" defined by this document is registered
   with the IANA registry of SDP Parameters as follows:

   SDP Attribute ("att-field"):

     Attribute name:     rtcp-xr
     Long form:          RTP Control Protocol Extended Report Parameters
     Type of name:       att-field
     Type of attribute:  session and media level
     Subject to charset: no
     Purpose:            see Section 5 of this document
     Reference:          this document
     Values:             see this document and registrations below

   The attribute has an extensible parameter field and therefore a
   registry for these parameters is required.  This document creates an
   IANA registry called the RTCP XR SDP Parameters Registry.  It
   contains the six parameters defined in Section 5.1: "pkt-loss-rle",
   "pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and
   "recv-rtt".

   Additional parameters are to be added to this registry in accordance
   with the Specification Required policy of RFC 2434 [8].  Any
   registration MUST contain the following information:

   - Contact information of the one doing the registration, including at
     least name, address, and email.

   - An Augmented Backus-Naur Form (ABNF) [2] definition of the
     parameter, in accordance with the "format-ext" definition.

   - A description of what the parameter represents and how it shall be
     interpreted, both normally and in Offer/Answer.

7. Security Considerations

   This document extends the RTCP reporting mechanism.  The security
   considerations that apply to RTCP reports 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
   Timestamp
   Packet Receipt Times Report Blocks facilitates MINC inference of multicast
   distribution trees for RTP data packets, and inference of link
   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 delay.  This inference reveals
   information delays, along paths between
   branching points in that tree.  Such information might otherwise be considered confidential
   sensitive to autonomous system administrators.

   The VoIP Metrics Report Block provides information on the quality of
   ongoing voice calls.  Though such information might be carried in
   application specific format in standard RTP sessions, making it
   available in a standard format here makes it more available to
   potential eavesdroppers.

   No new mechanisms are introduced in this document to ensure
   confidentiality.  Standard encryption procedures  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.  Autonomous system
   administrators concerned about  Given that RTCP traffic can be encrypted by the loss end
   hosts, autonomous systems must be prepared for the fact that certain
   aspects of confidentiality regarding their networks network topology can encrypt traffic, or filter it to exclude RTCP
   packets containing the XR report blocks concerned. 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 and employ the
   thinning they employ.  The "thinning" techniques described in this document in order to fit
   reports into Section
   4.1 permit the space available. packet-by-packet report blocks to adhere to a
   predefined size limit.

A. Algorithms

A.1 Sequence Number Interpretation

   This 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 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;
                           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).  It is reproduced from ETSI
   TS 101 329-5 [2]. [3].  The 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

   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.

   // 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 densities */
   loss_density = 256 * loss_count / ctotal;
   discard_density = 256 * discard_count / ctotal;

Intellectual Property

   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 [3]. [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.

Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgments

   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; Magnus Westerlund
   for his detailed comments; Mounir Benzaid for
   drawing our attention to the reporting needs of MLDA; and Dorgham Sisalem
   and Adam Wolisz for encouraging us to incorporate MLDA block types. 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, ShieldIP
   Alan Clark, Telchemy
   Robert Cole, AT&T Labs
   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  Timestamp  Packet Receipt Times Report Block     Friedman, Caceres, Duffield
   4.4  Statistics Summary  Receiver Reference Time Report Block  Almeroth, Sarac  Friedman
   4.5  Receiver Timestamp  DLRR Report Block                     Friedman
   4.6  DLRR  Statistics Summary Report Block                Friedman       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.

Authors' Addresses

      Kevin Almeroth <almeroth@cs.ucsb.edu>
      Department of Computer Science
      University of California
      Santa Barbara, CA 93106 USA

      Ramon Caceres <ramon@shieldip.com>
      ShieldIP, Inc.
      11 West 42nd Street, 31st Floor
      New York, NY 10036 USA
      Alan Clark <alan@telchemy.com>
      Telchemy Incorporated
      3360 Martins Farm Road, Suite 200
      Suwanee, GA 30024 USA
      Tel: +1 770 614 6944
      Fax: +1 770 614 3951

      Robert Cole <rgcole@att.com>
      AT&T Labs
      330 Saint Johns Street,
      2nd Floor
      Havre de Grace, MD 21078 USA
      Tel: +1 410 939 8732
      Fax: +1 410 939 8732

      Nick Duffield <duffield@research.att.com>
      AT&T Labs-Research
      180 Park Avenue, P.O. Box 971
      Florham Park, NJ 07932-0971 USA
      Tel: +1 973 360 8726
      Fax: +1 973 360 8050

      Timur Friedman <timur.friedman@lip6.fr>
      Universite Pierre et Marie Curie (Paris 6)
      Laboratoire LiP6-CNRS
      8, rue du Capitaine Scott
      75015 PARIS France
      Tel: +33 1 44 27 71 06
      Fax: +33 1 44 27 74 95

      Kaynam Hedayat <khedayat@brixnet.com>
      Brix Networks
      285 Mill Road
      Chelmsford, MA 01824 USA
      Tel: +1 978 367 5600
      Fax: +1 978 367 5700

      Kamil Sarac <ksarac@utdallas.edu>
      Department of Computer Science (ES 4.207)
      Eric Jonsson School of Engineering & Computer Science
      University of Texas at Dallas
      Richardson, TX 75083-0688 USA
      Tel: +1 972 883 2337
      Fax: +1 972 883 2349
      Magnus Westerlund <magnus.westerlund@era.ericsson.se>
      Ericsson Research, Corporate Unit
      Ericsson Radio Systems AB
      SE-164 80 Stockholm
      Sweden
      Tel: +46 8 404 82 87
      Fax: +46 8 757 55 50

References

   The references are divided into normative references and non-
   normative references.

Normative References

   [1] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," BCP 14, RFC 2119, IETF, March 1997.

   [2] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications:
   ABNF", RFC 2234, Internet Engineering Task Force, November 1997.

   [3] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI
   TS 101 329-5 V1.1.1 (2000-11), November 2000.

   [3]

   [4] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC
   2327, Internet Engineering Task Force, April 1998.

   [5] R. Hovey and S. Bradner, "The Organizations Involved in the IETF
   Standards Process," best current practice BCP 11, RFC 2028, IETF,
   October 1996.

   [4]

   [6] ITU-T, "The E-Model, a computational model for use in
   transmission planning," Recommendation G.107 (05/00), May 2000.

   [5]

   [7] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2,
   RFC 1700, IETF, October 1994.

   [6]

   [8] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
   Considerations Section in RFCs," best current practice BCP 26, RFC
   2434, IETF, October 1998.

   [7]

   [9] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the
   Session Description Protocol (SDP)", RFC 3264, Internet Engineering
   Task Force, June 2002.

   [10] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:
   A transport protocol for real-time applications," RFC 1889, IETF,
   February 1996.

Non-Normative References

   [8]

   [11] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J.
   Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The
   Use of End-to-End Multicast Measurements for Characterizing Internal
   Network Behavior," IEEE Communications Magazine, May 2000.

   [9]

   [12] Baugher, McGrew, Oran, Blom, Carrara, Naslund, and Norrman, "The
   Secure Real-time Transport Protocol," Internet-Draft draft-ietf-avt-
   srtp-05.txt, June 2002.  Note: this is is a work in progress.

   [13] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu
   measurement infrastructures using RTP," Proc. IEEE Infocom 2002.

   [10]

   [14] A. D. Clark, "Modeling the Effects of Burst Packet Loss and
   Recency on Subjective Voice Quality," Proc. IP Telephony Workshop
   2001.

   [11]

   [15] M. Handley, C. Perkins, E. Whelan, "Session Announcement
   Protocol", RFC 2974, Internet Engineering Task Force, October 2000.

   [16] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming
   protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr.
   1998.

   [17] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion
   Control Framework for Heterogeneous Multicast Environments", Proc.
   IWQoS 2000.