Internet Engineering Task Force                    Expires: 3 May 24 July 2003
Audio/Video Transport Working Group

                                                 Timur Friedman, Paris 6
                                                 Ramon Caceres, ShieldIP
                                                    Kevin Almeroth, UCSB
                                                       Kamil Sarac, UCSB
                                                 Alan Clark, Telchemy
                                                       Robert Cole, AT&T
                                           Kaynam Hedayat, Brix Networks

                       RTCP Reporting Extensions

                draft-ietf-avt-rtcp-report-extns-01.txt
                                                 Editors

                     RTP Extended Reports (RTP XR)

                draft-ietf-avt-rtcp-report-extns-02.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 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 (2002). (2003).  All Rights Reserved.

Abstract

   This document defines the XR (extended report) RTCP extended report (XR) packet type for the
   RTP control protocol (RTCP).  XR packets are composed of report
   blocks, and seven XR block types. 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 SR (sender report)
   RTCP's sender report (SR) and RR
   (receiver report) receiver report (RR) packets.  Some
   applications, such as MINC
   (multicast multicast inference of network characteristics) characteristics
   (MINC) or VoIP (voice voice over
   IP) 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 adhereing to
   the simple framework that this document provides.

Table of Contents

   1.     Introduction ..............................................  2
   1.1    Terminology ...............................................  3
   2.     XR Packet Format ..........................................  4
   3.     Extended Report Block Framework ...........................  5
   4.     Extended Report Blocks ....................................  6
   4.1    Loss RLE Report Block .....................................  6
   4.1.1  Run Length Chunk .......................................... 12
   4.1.2  Bit Vector Chunk .......................................... 12
   4.1.3  Terminating Null Chunk .................................... 12
   4.2    Duplicate RLE Report Block ................................ 13
   4.3    Timestamp Report Block .................................... 13
   4.4    Statistics Summary Report Block ........................... 16
   4.5    Receiver Timestamp Report Block ........................... 19
   4.6    DLRR Report Block ......................................... 20
   4.7    VoIP Metrics Report Block ................................. 21
   4.7.1  Packet Loss and Discard Metrics ........................... 23
   4.7.2  Burst Metrics ............................................. 23
   4.7.3  Delay Metrics ............................................. 26
   4.7.4  Signal Related Metrics .................................... 26
   4.7.5  Call Quality or Transmission Quality Metrics .............. 29
   4.7.6  Configuration Parameters .................................. 30
   4.7.7  Jitter Buffer Parameters .................................. 31
   5.     IANA Considerations ....................................... 32
   5.1    XR Packet Type ............................................ 32
   5.2    RTP XR Block Type Registry ................................ 32
   6.     Security Considerations ................................... 33
   A.     Algorithms ................................................ 34
   A.1    Sequence Number Interpretation ............................ 34
   A.2    Example Burst Packet Loss Calculation ..................... 35
          Intellectual Property ..................................... 37
          Full Copyright Statement .................................. 38
          Acknowledegments .......................................... 38
          Contributors .............................................. 39
          Authors' Addresses ........................................ 39
          References ................................................ 40
          Normative References ...................................... 40
          Non-Normative References .................................. 41

1. Introduction

   This document defines the XR (extended report) RTCP extended report (XR) packet type for
   RTCP, the control portion of
   RTP [8].  The definition consists of
   three parts.  First, Section 2 of this document defines a general
   packet framework capable of including a number of different "extended
   report blocks."  Second, Section 3 defines the general format for
   such blocks.  Third, Section 4 defines a number of such blocks.

   The extended report blocks control protocol (RTCP) [7].  XR packets convey information
   beyond that which is already contained in the reception report blocks of
   RTCP's SR sender report (SR) or RR
   packets. XR receiver report blocks carry (RR) packets.  The
   information that is not appropriately
   carried in of use across RTP profiles, and so is not
   appropriately carried in SR or RR profile-specific extensions because it is of use
   across profiles. extensions.
   Information that is useful to 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
   the specific information conveyed.  The framework defined by Section
   2 contains common header information followed by a series of
   components called report blocks.  Section 3 defines the format common
   to such blocks.  Section 4 defines seven block types.

   Seven report block formats are defined by this document:

   - Loss RLE Report Block (Section 4.1): Run-length Run length encoding of RTP
   packet loss reports.

   - Duplicate RLE Report Block (Section 4.2): Run-length Run length encoding of
   reports of RTP packet duplicates.

   - Timestamp Report Block (Section 4.3): A list of timestamps of
   received RTP packets.

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

   - Receiver Timestamp Report Block (Section 4.5): Receiver-end
   timestamps that complement the sender-end timestamps already defined
   for RTCP.

   - DLRR Report Block (Section 4.6): The delay since the last receiver
   timestamp report block Receiver
   Timestamp Report Block was received, allowing non-senders to
   calculate round-trip times.

   - 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 to all XR blocks.  The purpose is to
   maintain flexibility and to keep overhead low.  0ther block formats,
   beyond the seven defined here, may be defined within this framework
   as the need arises.

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

2. XR Packet Format

   The XR packet consists of a header of two 32-bit words, followed by a
   number, possibly zero, 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=205   PT=XP=207   |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           SSRC/CSRC                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                         report blocks                         :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   padding (P): 1 bit
        If the padding bit is set, this individual RTCP XR packet contains some
        additional padding octets at the end that are not part end.  The semantics of the control
   information but this
        field are included in identical to the length field. The last octet semantics of the padding is a count of how many padding octets should be ignored,
   including itself (it will be a multiple of four).  A full description
   of padding in RTCP packets may be found field in the
        the SR packet, as defined by the RTP specification.

   reserved: 5 bits
        This field is reserved for future definition.  In the absence of
        such definition, the bits in this field MUST be set to zero and MUST be
   ignored by
        the receiver. receiver MUST ignore any XR packet with a non-zero value in
        this field.

   packet type (PT): 8 bits
        Contains the constant 205 207 to identify this as an RTCP XR packet.
        This value is a proposed value, pending assignment of a number by registered with the Internet Assigned Numbers
        Authority (IANA) [7]. (IANA), as described in Section 5.1.

   length: 16 bits
   The
        As described for the RTP sender report (SR) packet (see Section
        6.3.1 of the RTP specification [7]).  Briefly, the length of
        this RTCP XR packet in 32-bit words minus one, including the header
        and any padding. (The offset of one makes zero a valid
   length and avoids a possible infinite loop in scanning a compound
   RTCP packet, while counting 32-bit words avoids a validity check for
   a multiple of 4.)

   SSRC: 32 bits
        The synchronization source identifier for the originator of this
        XR packet.

   report blocks: variable length.
        Zero or more extended report blocks.  Each  In keeping with the
        extended report block framework defined below, each block MUST be a multiple
        consist of 32 bits long.  A block MAY be zero bits long. one or more 32-bit words.

3. Extended Report Block Framework

   Extended report blocks are stacked, one after the other, at the end
   of an XR packet.  An individual block's length is a multiple of 4
   octets.  The XR header's length field describes the total length of
   the packet, including these extended report blocks.

   Each block has block type and length fields that facilitate parsing.
   A receiving application can demultiplex the blocks based upon their
   type, and can use the length information to locate each successive
   block, even in the presence of block types it does not recognize.

   An extended report block has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      BT       | type-specific |         block length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      type-specific data                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   block type (BT): 8 bits
        Identifies the specific block format.

type-specific:  Seven block types are defined in
        Section 4.  Additional block types may be defined in future
        specifications.  This field's name space is managed by the
        Internet Assigned Numbers Authority (IANA), as described in
        Section 5.2.

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

   block length: 16 bits
        The length of this report block including the header, in 32-bit
        words minus one, including one.  If the header. block type definition permits, zero is
        an acceptable value, signifying a block that consists of only
        the BT, type-specific, and block length fields, with a null
        type-specific data field.

   type-specific data: variable length
   This
        The use of this field is defined by the particular block type,
        subject to the constraint that it MUST be a multiple of 32 bits
        long.  If the block type definition permits, It MAY be zero bits
        long.

4. Specific Extended Report Blocks

   This section defines seven extended report blocks: block types for
   losses, duplicates, packet reception timestamps, detailed reception
   statistics, receiver timestamps, receiver inter-report delays, and
   VoIP
   voice over IP (VoIP) metrics.  An implementation MAY 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], [5], as described in Section 5. 5.2.

4.1 Loss RLE Report Block

   This block type permits detailed reporting upon individual packet
   receipt and loss events.  Such reports could can be used, for example, for MINC
   multicast inference [1] of network characteristics (MINC) [8].  With
   MINC, one can discover the topology of the multicast tree used for
   distributing a source's RTP packets, and of the loss rates along
   links within that tree.  Or they could be used to provide raw data to
   a network management application.

   Since a Boolean trace of lost and received RTP packets is potentially
   lengthy, this block type permits the trace to be compressed through
   run length encoding.

   Each  To further reduce block size, loss event
   reports on can be systematically dropped from the trace in a single source, identified by its SSRC.  The
   receiver mechanism
   called thinning that is supplying the report described below and that is identified studied in the header [9].

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

   The beginning and ending RTP packet sequence numbers report blocks.  Following this approach implies that
   accounting for Loss RLE Report Blocks will differ from the trace
   are specified in the block, accounting
   for the ending sequence number being generation of the last
   sequence number SR and RR packets described in the trace plus one.  The last sequence number RTP
   specification [7] in the trace MAY differ from following two areas: per-sender accounting
   and per-packet accounting.

   In its per-sender accounting, an RTP session participant SHOULD NOT
   make the sequence receipt of a threshold minimum number reported on in any
   accompanying SR or RR packet.

   The ending sequence number MAY be less than of RTP packets a
   condition for reporting upon the beginning sequence
   number. sender of those packets.  This happens when
   accounting technique differs from the sequence numbers technique described in Section
   6.2.1 and Appendix A.1 of the RTP specification that are being
   reported upon have wrapped around.  However, allows a Loss RLE Block MUST
   NOT be used
   threshold to report upon determine whether a range of 65,534 or greater in the sender is considered valid.

   In its per-packet accounting, an RTP session participant SHOULD treat
   all sequence number space, numbers as there is no means to identify multiple
   wrap-arounds.

   The encoding itself consists of a series valid.  This accouting technique differs from
   the technique described in Appendix A.1 of 16 bit chunks the RTP specification that
   describe packet receipts or losses.  Each chunk either specifies a
   run length or
   suggests ruling a bit vector, sequence number valid or is a null chunk.  A run length
   describes between 1 invalid on the basis of
   its contiguity with the sequence numbers of previously received
   packets.

   Sender validity and 16,383 events that sequence number validity are all interpretations of
   the same (either
   all receipts or all losses).  A bit vector describes 15 events that
   may be mixed receipts and losses.  A null chunk describes no events,
   and is used to to round out raw data.  Such interpretations are justified in the block to a 32 bit word boundary.

   The mapping interest,
   for example, of excluding the stray old packet from a sequence an unrelated
   session from having an effect upon the calculation of lost and received the RTCP
   transmission interval.  The presence of stray packets into might, on the
   other hand, be of interest to a network monitoring application.

   One accounting interpretation that is still necessary is for a
   participant to decide whether the 16 bit sequence of chunks number has rolled
   over.  Under ordinary circumstances this is not necessarily unique. a difficult task.
   For example, if packet number 65,535 (the highest possible sequence
   number) is followed shortly by packet number 0, it is reasonable to
   assume that there has been a rollover.  However it is possible that
   the fol-
   lowing trace covers 45 packets, of which the 22nd and 24th packet is an earlier one (from 65,535 packets earlier).  It is
   also possible that the sequence numbers have been
   lost and rolled over multiple
   times, either forward or backward.  The interpretation becomes more
   difficult when there are large gaps between 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
run of 9 receipts
null chunk sequence numbers,
   even accounting for rollover, and when there are long intervals
   between received packets.

   The choice of encoding per-packet accounting technique mandated here is left to the application.  As part of this
   freedom of choice, applications MAY terminate for a series
   participant to keep track of run length
   and bit vector chunks with a bit vector chunk that runs beyond the sequence number space described by of the report block. packet most
   recently received from a sender.  For example, if the 44th next packet in that arrives
   from that sender, the same sequence were lost:

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

   This could number MUST be encoded as:

run of 21 receipts
bit vector 0101 1111 1111 111
bit vector 1111 1110 1000 000
null chunk

   In this example, judged to fall no more
   than 32,768 packets ahead or behind the last five bits of most recent one, whichever
   choice places it closer.  In the second bit vector describe event that both choices are equally
   distant (only possible when the distance is 32,768), the choice MUST
   be the one that does not require a part 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 report is identified in the header of
   the RTCP packet.

   Choice of beginning and ending RTP packet sequence number space that extends beyond numbers for the
   trace is left to the application.  These values are reported in the
   block.  The last sequence number in the trace.  These bits have been set to zero.

   All bits trace MAY differ from the
   sequence number reported on in a bit vector chunk any accompanying SR or RR report.

   Note that describe a part because of the sequence number space that extends beyond wrap around the last ending sequence
   number in the
   trace MUST be set to zero and MUST MAY be ignored by less than the receiver. beginning sequence number.  A null packet MUST appear at the end of a Loss RLE
   Report Block if the num-
   ber of run length plus bit vector chunks is odd.  The null chunk MUST NOT appear in any other context.

   Caution should be used to report upon a range of 65,534 or
   greater in sending Loss RLE Blocks because, even with the compression provided by run-length encoding, they can easily con-
   sume bandwidth out of proportion with normal RTCP packets. sequence number space, as there is no means to
   identify multiple wrap arounds.

   The block
   type includes trace described by a mechanism, called thinning, that allows an applica-
   tion to limit Loss RLE report sizes.

   A thinning value, T, selects consists of a subset sequence of packets within the
   Boolean values, one for each sequence number space: those with sequence numbers that are multiples of 2^T.
   Packet reception and loss reports apply only to those packets.  T can
   vary between 0 and 15.  If T is zero then every packet in the
   sequence number space is reported upon.  If T is fifteen then trace.  A value
   of one in
   every 32,768 represents a packet receipt, meaning that one or more packets is reported upon.

   Suppose
   having that the trace just described begins at sequence number
   13,821.  The last sequence number in the trace is 13,865.  If have been received since the
   trace were to be thinned with a thinning value most recent
   wrap around of T=2, then the fol-
   lowing 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 (or since the bit vector, representing sequence numbers
   13,868, 13,872, 13,876, and 13,880, extend beyond beginning of the trace and are
   thus set RTP
   session if no wrap around has been judged to have occurred).  A value
   of zero and are ignored by the receiver.  With thinning, represents a packet loss, meaning that there has been no
   packet receipt for that sequence number as of the
   loss time of the 22nd report.
   If a packet goes unreported because its with a given sequence number,
   13,842, number is not received after a multiple report
   of four.  Packet receipts a loss for all sequence
   numbers that are not multiples of four also go unreported.  However,
   in this example thinning has permitted the sequence number, a later Loss RLE Block to be
   shortened by one 32 report MAY
   report a packet receipt for that sequence number.

   The encoding itself consists of a series of 16 bit word.

   Choice units called
   chunks that describe sequences of packet receipts or losses in the thinning value
   trace.  Each chunk either specifies a run length or a bit vector, or
   is left to the application.

   The Loss RLE 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=17     | rsvd. |   T   |         block a null chunk.  A run length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          begin_seq            |             end_seq           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          chunk describes between 1              |             chunk 2           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          chunk n-1            |             chunk n           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

block type (BT): 8 bits
   A Loss RLE block is identified by and 16,383 events
   that are all the constant 17.

rsvd.: 4 bits
   This field same (either all receipts or all losses).  A bit
   vector describes 15 events that may be mixed receipts and losses.  A
   null chunk describes no events, and is reserved for future definition.  In the absence of such
   definition, used to to round out the bits in this field MUST be set block
   to zero and receivers
   MUST ignore this field.

thinning (T): 4 bits a 32 bit word boundary.

   The amount of thinning performed on the mapping from a sequence number space.  Only
   those of lost and received packets with into a
   sequence numbers 0 mod 2^T are reported on by this
   block.  A value of 0 indicates that there chunks is no thinning, not necessarily unique.  For example, the
   following trace covers 45 packets, of which the 22nd and all
   packets are reported on.  The maximum thinning is one packet in every
   32,768 (amounting 24th have
   been lost and the others received:

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

   One way to two packets within each 16-bit sequence space).

length: 16 bits
   Defined in Section 3.

begin_seq: 16 bits
   The first sequence number that this block reports on.

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

chunk i: 16 bits
   There are three would be:

   bit vector 1111 1111 1111 111
   bit vector 1111 1101 0111 111
   bit vector 1111 1111 1111 111
   null chunk types:

   Another way to encode this would be:

   run length, of 21 receipts
   bit vector, and terminating
   null.  If the vector 0101 1111 1111 111
   run of 9 receipts
   null chunk

   The choice of encoding is all zeroes then it is a terminating null
   chunk. Otherwise, left to the leftmost bit application.  As part of this
   freedom of choice, applications MAY terminate a series of the chunk determines its type:
   0 for run length
   and 1 for bit vector.

4.1.1 Run-Length Chunk

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R|        run length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

chunk type (C): 1 bit
   A zero identifies this as vector chunks with a runlength chunk.

run type (R): 1 bit
   Zero indicates a run of losses.  One indicates a run of received
   packets.

run length: 14 bits
   A value between 1 and 16,383.  The value MUST not be zero (zeroes in
   both the run type and run length fields would make the vector chunk a termi-
   nating null chunk).  Run lengths of 15 or less MAY be that runs beyond the
   sequence number space described with
   a run length chunk despite by the fact that they report block.  For example, if
   the 44th packet in the same sequence were lost:

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

   This could also be described
   as part encoded as:

   run of a 21 receipts
   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| 0101 1111 1111 111
   bit vector           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 1110 1000 000
   null chunk type (C): 1 bit
   A one identifies

   In this as a example, the last five bits of the second bit vector chunk.

bit vector: 15 describe
   a part of the sequence number space that extends beyond the last
   sequence number in the trace.  These bits
   The vector is read from left have been set to right, zero.

   All bits in order a bit vector chunk that describe a part of increasing the sequence
   number (with space that extends beyond the appropriate allowance for wrap around). last sequence number in the
   trace MUST be set to zero, and MUST be ignored by the receiver.

   A
   zero indicates a null packet loss and a one indicates MUST appear at the end of a received packet.

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 Loss RLE Report Block

   This block type permits per-sequence-number reports on duplicates if
   the number of run length plus bit vector chunks is odd.  The null
   chunk MUST NOT appear in
   a source's RTP packet stream.  Such information can any other context.

   Caution should be used for net-
   work diagnosis, and provide an alternative to packet losses as a
   basis for multicast tree topology inference.

   The Duplicate RLE Block format is identical to the in sending Loss RLE Block
   format.  Only the interpretation is different, in that Report Blocks because,
   even with the informa-
   tion concerns packet duplicates rather than packet losses. compression provided by run length encoding, they can
   easily consume bandwidth out of proportion with normal RTCP packets.
   The trace block type includes a mechanism, called thinning, that allows an
   application to be encoded in this case also consists of zeros and ones, but limit report sizes.

   A thinning value, T, selects a
   zero here indicates the presence subset of duplicate packets for a given within the sequence number, whereas a one indicates
   number space: those with sequence numbers that no duplicates were
   received.

   The existence are multiples of a duplicate for a given sequence number 2^T.
   Packet reception and loss reports apply only to those packets.  T can
   vary between 0 and 15.  If T is deter-
   mined over the entire reporting period.  For example, if zero then every packet num-
   ber 12,593 arrives, followed by other packets with other sequence
   numbers, the arrival later in the reporting period of another packet
   numbered 12,593 counts as a duplicate for
   sequence number space is reported upon.  If T is fifteen then one in
   every 32,768 packets is reported upon.

   Suppose that the trace just described begins at sequence number. number
   13,821.  The
   duplicate does not need to follow immediately upon last sequence number in the first packet
   of that number.  Care must trace is 13,865.  If the
   trace were to be taken that a report does not cover thinned with a
   range thinning value of 65,534 or greater T=2, then the
   following sequence numbers would be reported upon: 13,824, 13,828,
   13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860,
   13,864.  The thinned trace would be as follows:

      1    1    1    1    1    0    1    1    1    1    0

   This could be encoded as follows:

   bit vector 1111 1011 1100 000
   null chunk

   The last four bits in the bit vector, representing sequence number space.

   No distinction is made between numbers
   13,868, 13,872, 13,876, and 13,880, extend beyond the existance trace and are
   thus set to zero and are ignored by the receiver.  With thinning, the
   loss of a single duplicate the 22nd packet and goes unreported because its sequence number,
   13,842, is not a multiple duplicate packets of four.  Packet receipts for a given all sequence number.
   Note also
   numbers that since there is no duplicate for a lost packet, a loss
   is encoded as a one are not multiples of four also go unreported.  However,
   in a Duplicate RLE Block.

   The Duplicate this example thinning has permitted the Loss RLE Report Block has to
   be shortened by one 32 bit word.

   Choice of the following thinning value is left to the application.

   The Loss RLE Report Block has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    BT=33     BT=1      | rsvd. |   T   |         block length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          begin_seq            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          chunk 1              |             chunk 2           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          chunk n-1            |             chunk n           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   block type (BT): 8 bits
        A Duplicate Loss RLE block Report Block is identified by the constant 33. 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 receivers
        the receiver MUST ignore any Loss RLE Report Block with a non-
        zero value in this field.

   thinning (T): 4 bits
        The amount of thinning performed on the sequence number space.
        Only those packets with sequence numbers 0 mod 2^T are reported
        on by this block.  A value of 0 indicates that there is no
        thinning, and all packets are reported on.  The maximum thinning
        is one packet in every 32,768 (amounting to two packets within
        each 16-bit sequence space).

   block length: 16 bits
        Defined in Section 3.

   begin_seq: 32 16 bits
        The first sequence number that this block reports on.

   end_seq: 32 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.  All null, defined in the following sections.  If the
        chunk is all zeroes indicates then it is a terminating null. null chunk.
        Otherwise, the left-
   most leftmost bit of the chunk determines its type: 0
        for run length and 1 for bit vector.  See the descriptions of these block types in the section
   on the Loss RLE Block, above, for details.

4.3 Timestamp Report Block

   This block type permits per-sequence-number reports on packet receipt
   timestamps for a given source's RTP packet stream.  Such information
   can be used for MINC inference of the topology of the multicast tree
   used to distribute the source's RTP packets, and of the delays along
   the links within that tree.  It can also be used to measure partial
   path characteristics and to model distributions for packet jitter.

   Timestamps consume more bits than loss or duplicate information, and
   do not lend themselves to run length encoding.  The use of thinning
   is encouraged to limit the size of Timestamp Report Blocks.

   The Timestamp Report Block has the following format:

 0                   1                   2                   3

4.1.1 Run Length Chunk

    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=48      | rsvd. |   T   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|R|        run length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          begin_seq                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          end_seq                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        RTP timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   chunk type (C): 1                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        RTP timestamp 2                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        RTP timestamp n                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

block bit
        A zero identifies this as a run length chunk.

   run type (BT): 8 (R): 1 bit
        Zero indicates a run of 0s.  One indicates a run of 1s.

   run length: 14 bits
        A Timestamp Report Block is identified by the constant 48.

rsvd.: 4 bits
   This field is reserved value between 1 and 16,383.  The value MUST not be zero for future definition.  In a
        run length chunk (zeroes in both the absence run type and run length
        fields would make the chunk a terminating null chunk).  Run
        lengths of such
   definition, 15 or less MAY be described with a run length chunk
        despite the bits in this field MUST fact that they could also be set to zero and receivers
   MUST ignore this field.

thinning (T): described as part of a
        bit vector chunk.

4.1.2 Bit Vector Chunk

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|        bit vector           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   chunk type (C): 1 bit
        A one identifies this as a bit vector chunk.

   bit vector: 15 bits
        The amount of thinning performed on the sequence number space.

length: 16 bits
   Defined vector is read from left to right, in Section 3.

begin_seq: 32 bits
   The first order of increasing
        sequence number that this block reports on.

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

RTP timestamp i: 32 bits
   The timestamp reflects the packet arrival time at the receiver.  It
   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 and format are the same as for (with the timestamp in RTP data
   packets.  As opposed to RTP data packet timestamps, in which nominal
   values may be used instead of system clock values in order to convey
   information useful appropriate allowance for periodic playout, the receiver timestamps
   should reflect the actual time as closely as possible.  The initial
   value of the timestamp is random, and subsequent timestamps are off-
   set from this value.

4.4 Statistics Summary Report Block wrap
        around).

4.1.3 Terminating Null Chunk

   This block reports statistics beyond the information carried in the
   standard RTCP packet format, but not as fine grained as that carried
   in the report blocks previously described.  Information chunk is recorded
   about lost packets, duplicate packets, jitter measurements, and TTL
   values (TTL values being taken from the TTL field of IPv4 packets, if
   the data packets are carried over IPv4).  Such information can be
   useful for network management.

   The packet contents are dependent upon a bit vector carried in the
   first part of the header.  Not all values need to be carried in each
   packet.  Header fields for values not carried are not included in the
   packet.

   The Statistics Summary Report Block has the following format: zeroes.

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

4.2 Duplicate RLE Report Block

   This block type (BT): 8 bits
   A Statistics Summary block is identified by the constant 1.

content bits (L,D,J,T): 4 bits
   Bit set 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 1 if packet contains (L)oss, (D)uplicate, (J)itter, and/or
   (T)TL report.

resvd.: 4 bits
   This field is reserved losses as a
   basis for future definition.  In the absence of such
   definition, all bits in this field MUST be set multicast tree topology inference.

   The Duplicate RLE Report Block format is identical to zero, and receivers
   MUST ignore this field.

length: 16 bits
   Defined the Loss RLE
   Report Block format.  Only the interpretation is different, in Section 3.

begin_seq: 32 bits
   The first sequence number that this block reports on.

end_seq: 32 bits
   the information concerns packet duplicates rather than packet losses.
   The last sequence number that trace to be encoded in this block reports on plus one.

lost_packets: 32 bits
   Number 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 dif-
   ference 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 in the above with other sequence number interval.

avg_jitter: 32 bits
   The average relative transit time between each two packet series
   numbers, the arrival later in the above reporting period of another packet
   numbered 12,593 counts as a duplicate for that sequence number interval.

dev_jitter: 32 bits number.  The standard deviation of
   duplicate does not need to follow immediately upon the relative transit time between each two 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.

min_ttl: 8 bits
   The minimum TTL value space.

   No distinction is made between the existance of data a single duplicate
   packet and multiple duplicate packets in for a given sequence number range.

max_ttl: 8 bits
   The maximum 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.

avg_ttl: 8 bits a Duplicate RLE Report Block.

   The average TTL value of data packets in sequence number range.

dev_ttl: 8 bits
   The standard deviation of TTL values of data packets in sequence num-
   ber 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 [9], 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=2      |                 reserved rsvd. |   T   |         block length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              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 block Duplicate RLE Report Block is identified by the constant 2.

reserved: 24

   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, zero and receivers
        the receiver MUST ignore any Duplicate RLE Report Block with a
        non-zero value in this field.

NTP timestamp: 64

   thinning (T): 4 bits
   Indicates the wallclock time when this
        As defined in Section 4.1.

   block was sent so that it may
   be used length: 16 bits
        Defined in combination with timestamps returned Section 3.

   begin_seq: 16 bits
        As defined in DLRR report blocks
   from other receivers to measure round-trip propagation to those
   receivers.  Receivers should expect that Section 4.1.

   end_seq: 16 bits
        As defined in Section 4.1.

   chunk i: 16 bits
        As defined in Section 4.1.

4.3 Timestamp Report Block

   This block type permits per-sequence-number reports on packet receipt
   timestamps 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 the
   elapsed time since joining the session instead. This is assumed to be
   less than 68 years, so the high bit will also be zero.  It is permissible
   to use the sampling clock used to estimate elapsed wallclock time. A
   report sender that has no notion of wallclock or elapsed time may set
   the NTP timestamp measure partial
   path characteristics and to zero.

4.6 DLRR Report Block

   This block extends RTCP's DLSR mechanism [7, Sec. 6.3.1] so that non-
   senders may also calculate round trip times, as proposed in [9]. It
   is termed DLRR model distributions for Delay since Last Receiver Report, and may be sent packet jitter.

   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 a Receiver Timestamp report block (see previous sec-
   tion) from
   timestamps for a receiver to allow series of sequence numbers that includes lost
   packets, several blocks are required.  If duplicate packets have been
   received for a given sequence number, and those packets differ in
   their receiver timestamps, any timestamp other than the earliest MUST
   NOT be reported.  This is to calculate its round
   trip time ensure consistency among reports.

   Timestamps consume more bits than loss or duplicate information, and
   do not lend themselves to the respondant. run length encoding.  The report consists use of one or more 3
   word sub-blocks: one sub-block per receiver report. thinning
   is encouraged to limit the size of Timestamp Report Blocks.

   The Timestamp 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      |   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)                        RTP timestamp 1                        |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 SSRC_2 (SSRC of second receiver)                        RTP timestamp 2                        | sub-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
   :                              ...                              :   2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        RTP timestamp n                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   block type (BT): 8 bits
        A DLRR block Timestamp Report Block is identified by the constant 3.

reserved: 8

   rsvd.: 4 bits
        This field is reserved for future definition.  In the absence of
        such definition, all the bits in this field MUST be set to zero, zero and receivers
        the receiver MUST ignore any Timestamp Report Block with a non-
        zero value in this field.

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

   block length: 16 bits
        Defined in Section 3.

last RR

   begin_seq: 16 bits
        As defined in Section 4.1.

   end_seq: 16 bits
        As defined in Section 4.1.

   RTP timestamp (LRR): i: 32 bits
        The middle 32 bits out of 64 in timestamp reflects the packet arrival time at the receiver.
        It is preferable for the NTP timestamp (as explained to be established at the link
        layer interface, or in any case as close as possible to the previous section) received wire
        arrival time.  Units and format are the same as part of a Receiver Timestamp report
   block from participant SSRC_n. If no such block has been received, for the field is set
        timestamp in RTP data packets.  As opposed to zero.

delay since last RR (DLRR): 32 bits
   The delay, expressed RTP data packet
        timestamps, in units which nominal values may be used instead 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, the DLRR field is set to
   zero (or the DLRR is omitted entirely). Let SSRC_r denote
        system clock values in order to convey information useful for
        periodic playout, the receiver issuing this DLRR report block. Participant SSRC_n can com-
   pute the round-trip propagation delay to SSRC_r by recording the time
   A when this Receiver Timestamp report block is received.  It calcu-
   lates timestamps should reflect the total round-trip
        actual time A-LSR using as closely as possible.  The initial value of the last SR
        timestamp
   (LSR) field, is random, and then subtracting subsequent timestamps are offset from
        this field to leave the round-trip
   propagation delay as (A- LSR - DLSR). This is illustrated in [7, Fig.
   2].

4.7 VoIP Metrics value.

4.4 Statistics Summary Report Block

4.7.1 Summary

   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

   This block reports separately on packets lost on statistics beyond the IP channel, and
   those that have been received information carried in the
   standard RTCP packet format, but then discarded by not as fine grained as that carried
   in the receiving report blocks previously described.  Information is recorded
   about lost packets, duplicate packets, jitter buffer.  It also reports on the combined effect of losses measurements, and
   discards, as both have equal effect on call quality.

   In order to properly assess TTL
   values (TTL values being taken from the quality TTL field of a Voice over IP call it is
   desirable to consider IPv4 packets, if
   the degree of burstiness of packet loss [4].
   Following a Gilbert-Elliott model [5], an interval, bounded by lost
   and/or discarded packets, with a high rate of losses and/or discards
   is a "burst," and an interval between two bursts is data packets are carried over IPv4).  Such information can be
   useful for network management.

   The report block contents are dependent upon a "gap."  Bursts
   correspond to intervals bit vector carried in
   the first part of time during which the packet loss rate is
   high enough header.  Not all parameters need to produce noticeable degradation be reported
   in audio quality.  Gaps
   correspond to periods of time during each block.  Flags indicate which only isolated lost packets
   may occur, and in general these can  be masked by packet loss con-
   cealment.   Delay reports include the transit delay between RTCP end
   points are and the VoIP end system processing delays, both of which con-
   tribute are not reported.
   The fields corresponding to the user perceived delay.  Additional metrics include sig-
   nal, echo, noise, and distortion levels.  Call quality metrics
   include R factors (E Model) [5] and MOS scores (Mean Opinion Scores).

   An implementation that sends these blocks SHOULD send at least one
   every ten seconds for the duration of a call, and SHOULD send one
   upon call termination.  An implementation unreported parameters MUST supply values for all
   fields defined here.

4.7.2 VoIP Metrics block structure be set to
   zero. The block is encoded receiver MUST ignore any Statistics Summary Report Block
   with a non-zero value in any field flagged as seven 32-bit words: unreported.

   The Statistics Summary Report Block has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=64     |   reserved     BT=4      |L|D|J|T|resvd. |          length=6       block length = 9        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   loss rate                        SSRC of source                         | discard rate
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       burst duration          begin_seq            |             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | burst density |         gap duration          |  gap density                        lost_packets                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     round trip delay          |       end system delay                        dup_packets                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | signal power  | doubletalk                         min_jitter                            |  noise level
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Gmin                         max_jitter                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   R factor    | ext. R factor                         avg_jitter                            |    MOS-LQ
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    MOS-CQ                         dev_jitter                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   RX Config   min_ttl     | JB Nominal   max_ttl     |   JB Maximum   avg_ttl     |  JB Abs Max     dev_ttl   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   block type (BT): 8 bits
        A VoIP Metrics block Statistics Summary Report Block is identified by the constant 64.

reserved: 8
        4.

   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 flag (T): 1 bit
        Bit set to 1 if the min_ttl, max_ttl, avg_ttl, and dev_ttl
        fields all contain reports, 0 if none of them do.

   resvd.: 4 bits
        This field is reserved for future definition.  In the absence of
        such definition, all bits in this field MUST be set to zero, and receivers
        the receiver MUST ignore any Statistics Summary Report Block
        with a non-zero value in this field.

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

   begin_seq: 16 bits
        As defined in Section 3, this is the constant 6 for this block type.

4.7.3 Packet loss and discard metrics

   It is very useful to distinguish between packets 4.1.

   end_seq: 16 bits
        As defined in Section 4.1.

   lost_packets: 32 bits
        Number of lost by the network
   and those discarded due to jitter. Both have equal effect on packets in the
   quality above sequence number interval.

   dup_packets: 32 bits
        Number of duplicate packets in the voice stream however having separate counts helps
   identify the source of quality degradation. These fields MUST be pop-
   ulated.

loss rate: 8 above sequence number
        interval.

   min_jitter: 32 bits
        The fraction of RTP data minimum relative transit time between two packets from the source lost since in the
   beginning of reception, expressed
        above sequence number interval.  All jitter values are measured
        as the difference between a fixed point number with packet's RTP timestamp and the
   binary point
        reporter's clock at the left edge time of arrival, measured in the field.  This value is calculated
   by dividing the total number of same
        units.

   max_jitter: 32 bits
        The maximum relative transit time between two packets lost (after the effects of
   applying any error protection such as FEC) by in the total
        above sequence number of
   packets expected, multiplying interval.

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

   dev_jitter: 32 bits
        The standard deviation of the division by 256, and
   taking relative transit time between each
        two packet series in the integer part. above sequence number interval.

   min_ttl: 8 bits
        The numbers minimum TTL value of duplicated packets and dis-
   carded data packets do not enter into this calculation.  Since receivers
   cannot be required to maintain unlimited buffers, a receiver MAY cat-
   egorize late-arriving in sequence number range.

   max_ttl: 8 bits
        The maximum TTL value of data packets as lost. in sequence number range.

   avg_ttl: 8 bits
        The degree average TTL value of lateness that
   triggers a loss SHOULD be significantly greater than that which trig-
   gers a discard.

discard rate: data packets in sequence number range.

   dev_ttl: 8 bits
        The fraction standard deviation of TTL values of RTP data packets from the source in sequence
        number range.

4.5 Receiver Timestamp Report Block

   This block extends RTCP's timestamp reporting so that have been dis
   carded since non-senders may
   also send timestamps.  It recapitulates the beginning of reception, due to late or early
   arrival, under-run or overflow at NTP timestamp fields from
   the receiving jitter buffer.  This
   value is expressed RTCP Sender Report [7, Sec. 6.3.1].  A non-sender may estimate
   its RTT to other participants, as a fixed point number with the binary point at
   the left edge of the field.  It is calculated proposed in [11], by dividing the total
   number of packets discarded (excluding duplicate packet discards) sending this
   report block and receiving DLRR Report Blocks (see next section) in
   reply.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=5      |   reserved    |       block length = 2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              NTP timestamp, most significant word             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             NTP timestamp, least significant word             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   block type (BT): 8 bits
        A Receiver Timestamp Report Block is identified by the total number of packets expected, multiplying constant
        5.

   reserved: 8 bits
        This field is reserved for future definition.  In the result absence of
        such definition, the
   division by 256, bits in this field MUST be set to zero and taking
        the integer part.

burst metrics:
   A burst is defined as a longest sequence of packets bounded by lost
   or discarded packets receiver MUST ignore any Receiver Timestamp Report Block
        with the constraint that within a burst non-zero value in this field.

   block length: 16 bits
        The constant 2, in accordance with the num-
   ber definition of successive packets this field
        in Section 3.

   NTP timestamp: 64 bits
        Indicates the wallclock time when this block was sent so that were received, and not discarded due
   to delay variation, is less than some value Gmin.  A gap is defined
   as the interval between bursts, and has the property that any lost or
   discarded packets must it
        may 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).

burst duration: 16 bits
   The mean duration, expressed used in milliseconds, of the burst intervals
   that have occurred since the beginning of reception.  The duration of
   each interval is calculated based upon the packets combination with timestamps returned in DLRR
        Report Blocks (see next section) from other receivers to measure
        round-trip propagation to those receivers.  Receivers should
        expect that mark the
   beginning and end measurement accuracy of that interval.  It is equal to the timestamp of
   the end packet, plus may be
        limited to far less than the duration resolution of the end packet, minus the times
   tamp NTP timestamp.
        The measurement uncertainty of the beginning packet.  If the actual values are timestamp is not indicated as
        it may not avail
   able, estimated values MUST be used.  If there have been known. A report block sender that can keep track
        of elapsed time but has no burst
   intervals, the burst duration value MUST be zero.

burst density: 8 bits
   The fraction notion of RTP data packets within burst intervals wallclock time may use the
        elapsed time since joining the
   beginning of reception that were either lost or discarded. session instead. This
   value is expressed as a fixed point number with the binary point at
   the left edge of assumed
        to be less than 68 years, so the field. high bit will be zero.  It is calculated by dividing
        permissible to use the total
   number sampling clock to estimate elapsed
        wallclock time. A report sender that has no notion of packets lost wallclock
        or discarded (excluding duplicate packet dis-
   cards) within burst intervals by the total number of packets expected
   within the burst intervals, multiplying the result of the division by
   256, and taking the integer part.

gap duration: 16 bits
   The mean duration, expressed in milliseconds, of elapsed time may set the gap intervals
   that have occurred NTP timestamp to zero.

4.6 DLRR Report Block

   This block extends RTCP's delay since the beginning of reception.  The duration of
   each interval is calculated based upon the packet that marks the end
   of the prior burst and the packet last sender report (DLSR)
   mechanism [7, Sec. 6.3.1] so that marks the beginning of the
   subsequent burst. non-senders may also calculate
   round trip times, as proposed in [11].  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 termed DLRR for delay
   since last receiver report, and may be used.  In the case of sent in response to 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 Receiver
   Timestamp Report Block (see previous section) from a gap receiver to
   allow that
   occurs at receiver to calculate its round trip time to the end
   respondant.  The report consists of reception, the timestamp one or more 3 word sub-blocks:
   one sub-block per receiver report.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=6      |   reserved    |         block length          |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                 SSRC_1 (SSRC of the subsequent burst
   packet first receiver)               | sub-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
   |                         last RR (LRR)                         |   1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   delay since last RR (DLRR)                  |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                 SSRC_2 (SSRC of second receiver)              | sub-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
   :                               ...                             :   2
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   block type (BT): 8 bits
        A DLRR Report Block is replaced identified by the reception end time.  If there have been no
   gap intervals, constant 6.

   reserved: 8 bits
        This field is reserved for future definition.  In the gap duration value absence of
        such definition, all bits in this field MUST be zero.

gap density: 8 set to zero, the
        receiver MUST ignore any DLRR Report Block with a non-zero value
        in this field.

   block length: 16 bits
        Defined in Section 3.

   last RR timestamp (LRR): 32 bits
        The fraction of RTP data packets within inter-burst gaps since the
   beginning middle 32 bits out of reception that were either lost or discarded.  The value
   is expressed as a fixed point number with 64 in the binary point at NTP timestamp (as explained
        in the
   left edge previous section) received as part of a Receiver
        Timestamp Report Block from participant SSRC_n. If no such block
        has been received, the field.  It field is calculated by dividing the total num-
   ber of packets lost or discarded (excluding duplicate packet dis
   cards) within gap intervals by the total number of packets expected
   within the gap intervals, multiplying the result set to zero.

   delay since last RR (DLRR): 32 bits
        The delay, expressed in units of 1/65536 seconds, between
        receiving the division by
   256, last Receiver Timestamp Report Block from
        participant SSRC_n and taking the integer part.

   For example, if sending this DLRR Report Block.  If no
        Receiver Timestamp Report Block has been received yet from
        SSRC_n, the packet spacing DLRR field is 10mS and a 1 denotes a received
   packet and 0, a lost, and X, a discarded, packet then set to zero (or the following
   pattern:

     11110111111111111111111X111X1011110111111111111111111X111111111
                            |--burst---|

   would have a burst duration of 120mS, a burst density of 0.33, a gap
   duration of 510mS and a gap density of 0.04, for a GMIN value of 4 or
   larger.

4.7.4 Delay metrics

   For DLRR is omitted
        entirely). Let SSRC_r denote the purpose of receiver issuing this DLRR
        Report Block. Participant SSRC_n can compute the following definitions, round-trip
        propagation delay to SSRC_r by recording the RTP interface time A when this
        Receiver Timestamp Report Block is received.  It calculates the interface between
        total round-trip time A-LSR using the RTP instance last SR timestamp (LSR)
        field, 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 con-
   sidered then subtracting this field to be part of leave the voice application or end-system delay
   whereas round-trip
        propagation delay due to multiplexing RTP frames within a UDP frame would
   be considered part of the RTP reported delay. as A-LSR-DLSR. This distinction is
   consistent with the use of RTCP for delay measurements.

round trip delay: 16 bits
   The most recently calculated round trip time between RTP interfaces,
   expressed illustrated in milliseconds. This value is [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 time IP channel, and
   those that have been received but then discarded by the receiving
   jitter buffer.  It also reports on the combined effect of receipt 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
   most recent RTCP degree of burstiness of packet from source SSRC, minus the LSR (last SR) 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 time reported in its SR (sender report), minus between two bursts is a
   "gap."  Bursts correspond to periods of time during which the DLSR (delay since
   last SR) reported in its SR.  A non-zero LSR value packet
   loss rate is REQUIRED high enough to produce noticeable degradation in
   order audio
   quality.  Gaps correspond to calculate round trip delay. A value periods of 0 is permissible dur-
   ing the first 2-3 RTCP exchanges as insufficient data time during which only
   isolated lost packets may occur, and in general these can be avail-
   able to determine delay however MUST be populated as soon as a masked
   by packet loss concealment.  Delay reports include the transit delay
   estimate is available.

end system delay: 16 bits
   The most recently estimated
   between RTCP end system delay, expressed in millisec-
   onds.  End system delay is defined as the total encoding, decoding points and jitter buffer delay determined at the reporting endpoint.  This
   is the time required for an RTP frame to be buffered, decoded, con-
   verted VoIP end system processing delays,
   both of which contribute to analog form, looped back at the local analog interface,
   encoded, user perceived delay.  Additional
   metrics include signal, echo, noise, and made available for transmission as an RTP frame.  The
   manner distortion levels.  Call
   quality metrics include R factors (as described by the E Model
   defined in which this value is estimated is [2]) and mean opinion scores (MOS scores).

   An implementation dependent.
   This parameter MUST be provided in all VoIP metrics reports.

   Note that the sends these blocks SHOULD send at least one way symmetric VoIP segment delay may be calculated
   from
   every ten seconds for the round trip and end system delays as follows.  If duration of the round
   trip delay call, SHOULD send one
   whenever a CODEC type change or other significant change occurs,
   SHOULD send one when significant call quality degradation is denoted RTD detected
   and the end system delays associated with
   the two endpoints are ESD(A) and ESD(B) then: SHOULD send one way symmetric voice path delay  =  ( RTD + ESD(A) + ESD(B) ) / 2

4.7.5 Signal related metrics

   The following metrics are intended to provide real time information
   related to the non-packet elements of the voice over IP system to
   assist with the identification of problems affecting upon call quality.
   The termination.  Implementations MUST
   provide values identified below must be determined for all the received audio
   signal. The information required to populate these fields may not be
   available in all systems, although it defined here.  For certain metrics,
   if the value is strongly recommended that
   this data SHOULD undefined or unknown, then the specified default or
   unknown field value MUST be provided to support problem diagnosis.

signal level: 8 bits provided.

   The voice signal relative level block is defined encoded as the ratio of the 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 = 6        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   loss rate   | discard rate  | burst density |  gap density  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       burst duration          |         gap duration          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     round trip delay          |       end system delay        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | signal power  |     RERL      |  noise level to overflow signal level, expressed in decibels as a signed
   integer in two's complement form.  |     Gmin      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   R factor    | ext. R factor |    MOS-LQ     |    MOS-CQ     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   RX config   |  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 measured only reserved for packets
   containing speech energy.  The intent future definition.  In the absence of
        such definition, all bits in this metric is not field MUST be set to pro-
   vide a precise measurement of zero and
        the signal level but to provide receiver MUST ignore any VoIP Metrics Report Block with a real
   time indication that the signal level may be excessively high or low.
   If
        non-zero value in this field.

   block length: 16 bits
        The constant 6, in accordance with the full range (overflow level) definition of this field
        in Section 3.

   The remaining fields are described in the Vocoder's Digital to Analog
   conversion function 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 +/- L very useful to distinguish between packets lost by the network
   and those discarded due to jitter. Both have equal effect on the value
   quality of a decoded sample during
   a talkspurt is V then the signal level is given by

         Signal level = 10 log10 ( mean( abs(V) / L ) )

   A value voice stream however having separate counts helps
   identify the source of 127 indicates that this parameter is unavailable.

doubletalk level: quality degradation. These fields MUST be
   populated.

   loss rate: 8 bits
        The doubletalk level is defined as the proportion of voice frame
   intervals during which speech energy was present in both sending and
   receiving directions.  High levels fraction of doubletalk can provide an indi-
   cation RTP data packets from the source lost since the
        beginning of delay or echo related problems. The value is reception, expressed as a fixed point number with
        the binary point at the left edge of the field.  It  This value is
        calculated by dividing the total number of voice frame
   intervals packets lost (after
        the effects of applying any error protection such as FEC) by the
        total number of voice frame intervals during which energy
   was present in both sending and receiving directions, packets expected, multiplying the result of the
        division by 256, limiting the maximum value to 255 (to avoid
        overflow), and taking the integer part.

   A value of 255 indicates that this value is unavailable

noise level: 8 bits  The noise level is defined as the ratio numbers of the silent period back
   ground noise level to overflow signal power, expressed in decibels as
   a signed integer in two's complement form.   If the full range (over-
   flow level) of the Vocoder's Digital to Analog conversion function is
   +/- L
        duplicated packets and the value of a decoded sample during a silence period is V
   then the noise level is given by

         Noise level = 10 log10 ( mean( abs(V) / L ) )

   A value of 127 indicates that discarded packets do not enter into this parameter is unavailable.

4.7.6 Call quality/ transmission quality metrics
        calculation.  Since receivers cannot be required to maintain
        unlimited buffers, a receiver MAY categorize late-arriving
        packets as lost.  The following metrics are direct measures of the transmission quality
   or call quality, and incorporate the effects degree of CODEC type, packet
   loss, discard, burstiness, delay etc.  These metrics may not be
   available in all systems however lateness that triggers a loss
        SHOULD be provided in order to sup-
   port problem diagnosis.

R factor: significantly greater than that which triggers a
        discard.

   discard rate: 8 bits
        The R factor is a voice quality metric describing the segment fraction of RTP data packets from the
   call source that is carried over this RTP session.  It is expressed as an
   integer in have been
        discarded since the range 0 to 100, with a value beginning of 94 corresponding reception, due to
   "toll quality" and values of 50 late or less regarded as unusable. early
        arrival, under-run or overflow at the receiving jitter buffer.
        This
   metric value is defined expressed as including the effects of delay, consistent a fixed point number with
   ITU-T G.107 [6] and ETSI TS 101 329-5 [5].

   A value the binary
        point at the left edge of 127 indicates that this parameter is unavailable.

ext. R factor: 8 bits
   The external R factor the field.  It is a voice quality metric describing calculated by
        dividing the seg
   ment total number of packets discarded (excluding
        duplicate packet discards) by the call that is carried over a network segment external to total number of packets
        expected, multiplying the RTP segment, for example a cellular network. Its values are
   interpreted in result of the same manner as for division by 256,
        limiting the RTP R factor.  This metric 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 including the effects a longest sequence of delay, consistent
   packets bounded by lost or discarded packets with ITU-T
   G.107 [6] and ETSI TS 101 329-5 [5], and relates to the outward voice
   path from the Voice over IP termination for which this metrics block
   applies.

   Note constraint that an overall R factor may be estimated from the RTP segment R
   factor and the external R factor, as follows:

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

   A value
   within a burst any sequence of 127 indicates successive packets that this parameter were received,
   and not discarded due to delay variation, is unavailable.

MOS-LQ: 8 bits
   The estimated mean opinion score for listening quality (MOS-LQ) of length less than a
   value Gmin.

   A gap, informally, is a
   voice quality metric on period of low packet losses and/or discards.
   Formally, a scale from 1 to 5, in which 5 represents
   excellent and 1 represents unacceptable.  This metric gap is defined as
   not including any of the effects following: (a) the period
   from the start of delay and can be compared an RTP session to MOS scores
   obtained the receipt time of the last
   received packet before the first burst, (b) the period from listening quality (ACR) tests. It is expressed as an
   integer in the range 10 to 50, corresponding to MOS x 10.  For exam-
   ple, a value end
   of 35 would correspond the last burst to an estimated MOS score of 3.5.

   A value either the time of 127 indicates that this parameter is unavailable.

MOS-CQ: 8 bits
   The estimated mean opinion score for conversational quality (MOS-CQ)
   is defined as including the effects report or the end of delay and other effects that
   would affect conversational quality.  The metric may be calculated by
   converting an R factor determined according to ITU-T G.107 [6] the
   RTP session, whichever comes first, or
   ETSI TS 101 329-5 [5] into an estimated MOS using (c) the equation speci-
   fied in G.107

   A value period of 127 indicates that this parameter is unavailable.

4.7.7 Configuration parameters:

Gmin: 8 bits
   The gap threshold.  This field contains time between
   two bursts.

   For the value used for this
   report block to determine if a gap exists.  The recommended value purpose of
   16 (octal 0x10) corresponds to a burst interval having determining if a minimum den-
   sity of 6.25% of lost or discarded packets, which may cause notice-
   able degradation in call quality; during gap intervals, if packet
   loss near the
   start or dis card occurs, each lost end of an RTP session is within a gap or discarded packet would be pre-
   ceded by a burst it is
   assumed that the RTP session is preceded and followed by a sequence at least
   Gmin received packets, and that the time of the report is followed by
   at least 16 Gmin received non-dis-
   carded packets.  Note

   A gap has the property that any lost or discarded packets that occur within Gmin packets of a report being generated may be reclassified
   as being part of a burst or the
   gap in later reports.  ETSI TS 101 329-5
   [5] defines a computationally efficient algorithm for measuring burst must be preceded and gap density using a packet loss/discard event driven approach. followed by at least Gmin MUST not be zero packets that were
   received and MUST be provided.

   Receiver Configuration byte:

    0 not discarded.  This gives a maximum loss/discard
   density within a gap of: 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |PLC|JBA|JB rate|
   +-+-+-+-+-+-+-+-+

PLC - packet loss concealment
   Standard (11) / enhanced (10) / disabled (01) / unspecified (00).
   When PLC=11 then a simple replay or interpolation algorithm (Gmin + 1).

   A Gmin value of 16 is being
   used RECOMMENDED as it results in gap
   characteristics that correspond to fill-in the missing good quality (i.e. low packet - this is typically able to con-
   ceal isolated lost packets with loss rates under 3%.  When PLC=10
   then an enhanced interpolation algorithm is being used - this would
   typically be able to conceal lost packets for loss rates
   rate, a minimum distance of 10% or
   more.  When PLC=01 then silence is inserted 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 place 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 packets.
   When PLC = 00 then no information is available concerning packet.  The first gap starts
   at the use beginning of
   PLC however for some CODECs this may be inferred.

JBA - Jitter Buffer Adaptive
   Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When
   Jitter Buffer the session and the second gap ends at the time
   of the report.

   If the packet spacing is adaptive then its size 10 ms and the Gmin value is being dynamically adjusted
   to deal with varying levels the recommended
   value of jitter.  When non-adaptive then 16, the
   Jitter Buffer size burst duration is maintained at a fixed level.  When either adap-
   tive or non-adaptive modes are specified then 120 ms, the Jitter Buffer Size
   parameters below MUST be specified.

JB Rate - Jitter Buffer Rate
   J burst density 0.33,
   the gap duration 230 ms + 290 ms = adjustment rate (0-15). This represents 520 ms, and the implementation spe-
   cific adjustment rate of a Jitter Buffer in adaptive mode. gap density 0.04.

   This
   parameter is defined in terms of the approximate time taken to fully
   adjust to a step change would result in peak reported values as follows (see field
   descriptions for semantics and details on how these are calculated):

   loss density          12, which corresponds to peak jitter from 30mS 5%
   discard density       12, which corresponds to 100mS
   such that:

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

   This parameter is intended only 5%
   burst density         84, which corresponds to provide a guide 33%
   gap density           10, which corresponds to the degree of
   "aggressiveness" of a an adaptive jitter buffer and may be estimated.
   A 4%
   burst duration       120, value in milliseconds
   gap duration         520, value in milliseconds
   burst density: 8 bits
        The fraction of 0 indicates that RTP data packets within burst periods since the adjustment time is unknown for this
   implementation.

4.7.7 Jitter Buffer Parameters

Jitter Buffer - nominal size in frames (8 bit)
        beginning of reception that were either lost or discarded.  This
        value is expressed as a fixed point number with the current nominal fill binary point within
        at the jitter buffer,
   which corresponds to left edge of the nominal jitter buffer delay for packets that
   arrive exactly on time.  This parameter MUST be provided for both
   fixed and adaptive jitter buffer implementations.

Jitter Buffer Maximum - size in frames (8 bit)
   This field.  It is calculated by dividing the current maximum jitter buffer level corresponding to the
   earliest arriving
        total number of packets lost or discarded (excluding duplicate
        packet that would not be discarded.  In simple
   queue implementations this may correspond to discards) within burst periods by the nominal size. In
   adaptive jitter buffer implementations this total number of
        packets expected within the burst periods, multiplying the
        result of the division by 256, limiting the maximum value may dynamically
   vary up to Jitter Buffer Absolute Maximum.  This parameter MUST be
   provided for both fixed 255
        (to avoid overflow), and adaptive jitter buffer implementations.

Jitter Buffer Absolute Maximum - size in frames (8 bit)
   This is taking the absolute maximum size that integer part.

   gap density: 8 bits
        The fraction of RTP data packets within inter-burst gaps since
        the adaptive jitter buffer can
   reach under worst case jitter conditions.  This parameter MUST be
   provided for adaptive jitter buffer implementations and its beginning of reception that were either lost or discarded.
        The value
   MUST be set to JB Maximum for is expressed as a fixed jitter buffer implementations.

   Example point number with the binary
        point at the left edge of burst packet loss calculation.

   This is an event driven algorithm for measuring burst characteristics
   and the field.  It is hence extremely computationally efficient.

   Given calculated by
        dividing the following definition total number of states:

     State 1 = received a packets lost or discarded
        (excluding duplicate packet during a discards) within 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 periods by the
        total number of packets expected within the gap

   The "c" variables below correspond periods,
        multiplying the result of the division by 256, limiting the
        maximum value to state transition counts, i.e.
   c14 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 transition from state 1 to state 4. packets
        that mark the beginning and end of that period.  It is possible equal to
   infer one
        the timestamp of a pair the end packet, plus the duration of state transition counts to an accuracy the end
        packet, minus the timestamp of 1
   which is generally sufficient for this application.  "pkt" is the
   count 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 packets received the gap periods
        that have occurred since the last beginning of reception.  The
        duration of each period is calculated based upon the packet was declared lost or
   discarded that
        marks the end of the prior burst and "lost" is the number packet that marks the
        beginning of packets lost within the current subsequent burst.

    if ( packet_lost ) loss_count++;
    if ( packet_discarded ) discard_count++;
    if (pkt >= gmin)
    {
        if (lost == 1)
           c14++;
        else
            c13++;
        lost = 1;
        c11 += pkt;
    }
    else
    {
        lost++;
        if (pkt == 0)
            c33++;
        else
        {
            c23++;
            c22 += (pkt - 1);
        }
    }

   At each reporting interval It is equal to the timestamp
        of the subsequent burst and gap metrics can be calcu-
   lated as follows.

    /* calculate additional transition counts */
    c31 = c13;
    c32 = c23;
    ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33;

    /* calculate packet, minus the timestamp of the prior
        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 packet, plus the duration of the prior burst and packet.  If
        the actual values are not available, estimated values MUST be
        used.  In the case of a gap durations in mS */
    m = frameDuration_in_mS * framesPerRTPPkt;
    gap_length = (c11 + c14 + c13) * m / c13;
    burst_length = ctotal * m / c13 - lgap;

    /* calculate loss that occurs at the beginning of
        reception, the sum of the timestamp of the prior burst packet
        and discard densities */
    loss_density = 256 * loss_count / ctotal;
    discard_density = 256 * discard_count / ctotal;

5. IANA Considerations

   The extended report block type (BT) field defined by this document is
   a name space to be managed by the Internet Assigned Numbers Authority
   (IANA).  The field contains eight bits, allowing 256 values, duration of which
   seven the prior burst packet are defined here:

 1 (Statistics Summary Block, see Section 4.4)
 2 (Receiver Timestamp Report Block, see Section 4.5)
 3 (DLRR Report Block, see Section 4.6)
17 (Loss RLE Block, see Section 4.1)
33 (Duplicate RLE Block, see Section 4.2)
48 (Timestamp Report Block, see Section 4.3)
64 (VoIP Metrics Report Block, see Section 4.7) replaced by the
        reception start time.  In addition, the value 0 is reserved for experimental use.

   No review case of a gap that occurs at the
        end of reception, the timestamp of the subsequent burst packet
        is necessary replaced by the IANA in order for it to record reception end time.  If there have been no
        gap periods, the gap duration value MUST be zero.

4.7.3 Delay Metrics

   For the
   assignment purpose of additional numbers from this name space.  Such numbers
   are 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 assigned as part of the IETF standards process.

6. Security Considerations

   This document extends the RTCP reporting mechanism, so all security
   considerations for RTCP reports also apply voice application or end-system delay
   whereas delay due to multiplexing RTP frames within a UDP frame would
   be considered part of the XR packets
   described here. RTP reported delay.  This section details the additional security consid-
   erations that apply to distinction is
   consistent with the extensions.

   The extensions introduce heightened confidentiality concerns.  Stan-
   dard RTCP reports contain a limited number use of summary statistics. RTCP for delay measurements.

   round trip delay: 16 bits
        The information contained most recently calculated round trip time between RTP
        interfaces, expressed in XR reports milliseconds. This value is both more detailed and
   more extensive (covering a larger number the time of parameters).  The per
   packet information contained in Loss RLE, Duplicate RLE, and Times-
   tamp Report Blocks facilitates MINC inference
        receipt of multicast distribu-
   tion trees for RTP data packets, and inference of link characteris-
   tics such as loss and delay.  This inference reveals information that
   might otherwise be considered confidential 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 most recent RTCP packet from source SSRC, minus
        the LSR (last SR) time reported in standard RTP sessions,
   making it available its SR (sender report), minus
        the DLSR (delay since last SR) reported in a standard format here makes it more available
   to potential eavesdroppers.

   No new mechanisms are introduced its SR.  A non-zero
        LSR value is REQUIRED in this document order to ensure confiden-
   tiality.  Already calculate round trip delay. A
        value of 0 is permissible during the first two or three RTCP
        exchanges as insufficient data may be available authentification and encryption proce-
   dures should to determine
        delay however MUST be used when confidentiality is populated as soon as a concern to delay estimate is
        available.

   end hosts.
   Autonomous system administrators concerned about delay: 16 bits
        The most recently estimated end system delay, expressed in
        milliseconds.  End system delay is defined as the loss of confi-
   dentiality regarding their networks can filter traffic to exclude
   RTCP packets containing total
        encoding, decoding and jitter buffer delay determined at the XR report blocks concerned.

   The extensions also make certain denial of service attacks easier.
        reporting endpoint.  This is because of the potential time required for an RTP frame
        to create RTCP packets much larger
   than average with the per packet reporting capabilities of be buffered, decoded, converted to analog form, looped back
        at the Loss
   RLE, Duplicate RLE, local analog interface, encoded, and Timestamp Report Blocks.  Because made available for
        transmission as an RTP frame.  The manner in which this value is
        estimated is implementation dependent.  This parameter MUST be
        provided in all VoIP metrics reports.

   Note that the one way symmetric VoIP segment delay may be calculated
   from the round trip and end system delays as follows.  If the round
   trip delay is denoted RTD and the end system delays associated with
   the two endpoints are ESD(A) and ESD(B) then:

   one way symmetric voice path delay  =  ( RTD + ESD(A) + ESD(B) ) / 2

4.7.4 Signal Related Metrics
   The following metrics are intended to provide real time information
   related to the non-packet elements of the
   automatic bandwidth adjustment mechanisms voice over IP system to
   assist with the identification of problems affecting call quality.
   The values identified below must be determined for the received audio
   signal. The information required to populate these fields may not be
   available in RTCP, if some session
   participants are sending large RTCP packets, all participants will
   see their RTCP reporting intervals lengthened, meaning they will systems, although it is strongly recommended that
   this data SHOULD be
   able provided to report less frequently.

   No new mechanisms are introduced support problem diagnosis.

   signal power: 8 bits
        The voice signal relative level is defined as the ratio of the
        signal level to overflow signal level, expressed in decibels as
        a signed integer in two's complement form.  This is measured
        only for packets containing speech energy.  The intent of this document
        metric is not to prevent such
   denial provide a precise measurement of service attacks.

7. Acknowledgements

   We thank the following people: Colin Perkins, Steve Casner, signal
        level but to provide a real time indication that the signal
        level may be excessively high or low.  If the full range
        (overflow level) of the Vocoder's digital to analog conversion
        function is +/- L and the value of a decoded sample during a
        talkspurt is V then the signal level is given by:

        signal level = 10 log10 ( mean( abs(V) / L ) )

        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 sum of the
        measured echo return loss (ERL) and the echo return loss
        enhancement (ERLE) expressed in dB as a signed integer in two's
        complement form.  It defines the ratio of a transmitted voice
        signal that is reflected back to the talker.  A low level of
        echo return loss (say less than 20 dB) in conjunction with some
        delay can lead to hollowness or audible echo.  A high level of
        echo return loss (say over 40 dB) is preferable.

   The ERL and ERLE parameters are often available directly from the
   echo cancellor contained within the VoIP end system. They relate to
   the echo on the external network attached to the end point.

   In the case of a VoIP gateway this would be line echo that typically
   occurs at 2-4 wire conversion points in the network.  Echo return
   loss from typical 2-4 wire conversions can be in the 8-12 dB range.
   A line echo cancellor can provide an ERLE of 30 dB or more and hence
   reduce this to 40-50 dB.  In the case of an IP phone this could be
   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 convertor 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 cancellor 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 "local" end of the VoIP path as A and the remote end
   as B and if the sender loudness rating (SLR) and receiver loudness
   rating (RLR) are known for A (default values 8 dB and 2 dB
   respectively), then the echo loudness level at end A (talker echo
   loudness rating or TELR) is given by:

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

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

   Hence in order to incorporate echo into a voice quality estimate at
   the A end of a VoIP connection it is desirable to send the ERL + ERLE
   value from B to A.

   For an IP phone with handset this metric MUST be set to the 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 by the acoustic echo cancellor or to 127 to
   indicate an undefined value.

   For an IP gateway with ERL and ERLE measurements this metric MUST be
   reported 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
   disabled and 40 dB if line echo cancellation is enabled.

   noise level: 8 bits
        The noise level is defined as the ratio of the silent period
        back ground noise level to overflow signal power, expressed in
        decibels as a signed integer in two's complement form.  If the
        full range (overflow level) of the Vocoder's digital to analog
        conversion function is +/- L and the value of a decoded sample
        during a silence period is V then the noise level is given by
        noise level = 10 log10 ( mean( abs(V) / L ) )

        A value of 127 indicates that this parameter is unavailable.

   Gmin
        See Configuration Parameters (Section 4.7.6, below).

4.7.5 Call Quality or Transmission Quality Metrics

   The following metrics are direct measures of the call quality or
   transmission quality, and incorporate the effects of CODEC type,
   packet loss, discard, burstiness, delay etc.  These metrics may not
   be available in all systems however SHOULD be provided in order to
   support problem diagnosis.

   R factor: 8 bits
        The R factor is a voice quality metric describing the segment of
        the call that is carried over this RTP session.  It is expressed
        as an integer in the range 0 to 100, with a value of 94
        corresponding to "toll quality" and values of 50 or less
        regarded as unusable.  This metric is defined as including the
        effects of delay, consistent with ITU-T G.107 [4] and ETSI TS
        101 329-5 [2].

        A value of 127 indicates that this parameter is unavailable.

   ext. R factor: 8 bits
        The external R factor is a voice quality metric describing the
        seg ment of the call that is carried over a network segment
        external to the RTP segment, for example a cellular network. Its
        values are interpreted in the same manner as for the RTP R
        factor.  This metric is defined as including the effects of
        delay, consistent with ITU-T G.107 [4] and ETSI TS 101 329-5
        [2], and relates to the outward voice path from the Voice over
        IP termination for which this metrics block applies.

        A value of 127 indicates that this parameter is unavailable.

   Note that an overall R factor may be estimated from the RTP segment R
   factor and the external R factor, as follows:

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

   MOS-LQ: 8 bits
        The estimated mean opinion score for listening quality (MOS-LQ)
        is a voice quality metric on a scale from 1 to 5, in which 5
        represents excellent and 1 represents unacceptable.  This metric
        is defined as not including the effects of delay and can be
        compared to MOS scores obtained from listening quality (ACR)
        tests. It is expressed as an integer in the range 10 to 50,
        corresponding to MOS x 10.  For example, a value of 35 would
        correspond to an estimated MOS score of 3.5.

        A value of 127 indicates that this parameter is unavailable.

   MOS-CQ: 8 bits
        The estimated mean opinion score for conversational quality
        (MOS-CQ) is defined as including the effects of delay and other
        effects that would affect conversational quality.  The metric
        may be calculated by converting an R factor determined according
        to ITU-T G.107 [4] or ETSI TS 101 329-5 [2] into an estimated
        MOS using the equation specified in G.107.  It is expressed as
        an integer in the range 10 to 50, corresponding to MOS x 10, as
        for MOS-LQ.

        A value of 127 indicates that this parameter is unavailable.

4.7.6 Configuration Parameters

   Gmin: 8 bits
        The gap threshold.  This field contains the value used for this
        report block to determine if a gap exists.  The recommended
        value of 16 corresponds to a burst period having a minimum
        density of 6.25% of lost or discarded packets, which may cause
        noticeable degradation in call quality; during gap periods, if
        packet loss or dis card 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 [2] defines a computationally
        efficient algorithm for measuring burst and gap density using a
        packet loss/discard event driven approach.  This algorithm is
        reproduced in Appendix A.2 of the present document.  Gmin MUST
        not be zero and MUST be provided.

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

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |PLC|JBA|JB rate|
        +-+-+-+-+-+-+-+-+
        packet loss concealment (PLC): 2 bits
             Standard (11) / enhanced (10) / disabled (01) / unspecified
             (00).  When PLC = 11 then a simple replay or interpolation
             algorithm is being used to fill-in the missing packet.
             This is typically able to conceal isolated lost packets
             with loss rates under 3%.  When PLC = 10 then an enhanced
             interpolation algorithm is being used.  This would
             typically be able to conceal lost packets for loss rates of
             10% or more.  When PLC = 01 then silence is inserted in
             place of lost packets.  When PLC = 00 then no information
             is available concerning the use of PLC however for some
             CODECs this may be inferred.

        jitter buffer adaptive (JBA): 2 bits
             Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown
             (00).  When the jitter buffer is adaptive then its size is
             being dynamically adjusted to deal with varying levels of
             jitter.  When non-adaptive, the jitter buffer size is
             maintained at a fixed level.  When either adaptive or non-
             adaptive modes are specified then the jitter buffer size
             parameters below MUST be specified.

        jitter buffer rate (JB rate): 4 bits
             J = adjustment rate (0-15). This represents the
             implementation specific adjustment rate of a jitter buffer
             in adaptive mode. This parameter is defined in terms of the
             approximate time taken to fully adjust to a step change in
             peak to peak jitter from 30 ms to 100 ms such that:

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

             This parameter is intended only to provide a guide to the
             degree of "aggressiveness" of a an adaptive jitter buffer
             and may be estimated. A value of 0 indicates that the
             adjustment time is unknown for this implementation.

4.7.7 Jitter Buffer Parameters

   jitter buffer nominal size in frames (JB nominal): 8 bits
        This is the current nominal fill point within the jitter buffer,
        which corresponds to the nominal jitter buffer delay for packets
        that arrive exactly on time.  This parameter MUST be provided
        for both fixed and adaptive jitter buffer implementations.

   jitter buffer maximum size in frames (JB maximum): 8 bits
        This is the current maximum jitter buffer level corresponding to
        the earliest arriving packet that would not be discarded.  In
        simple queue implementations this may correspond to the nominal
        size. In adaptive jitter buffer implementations this value may
        dynamically vary up to JB abs max (see below).  This parameter
        MUST be provided for both fixed and adaptive jitter buffer
        implementations.

   jitter buffer absolute maximum size in frames (JB abs max): 8 bits
        This is the absolute maximum size that 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. IANA Considerations

   This document defines a new RTP packet type, the extended report (XR)
   type, within the existing Internet Assigned Numbers Authority (IANA)
   registry of RTP RTCP Control Packet Types.  This document also
   defines a new IANA registry: the registry of RTP 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.

5.1 XR Packet Type

   The IANA SHALL register the RTP extended report (XR) packet defined
   by this document as packet type 207 in the registry of RTP RTCP
   Control Packet types (PT).

5.2 RTP XR Block Type Registry

   The IANA SHALL create the RTP XR Block Type Registry to cover the
   name space of the extended report block type (BT) field specified in
   Section 3 of this document.  The BT field contains eight bits,
   allowing 256 values.  The IANA SHALL manage the RTP XR Block Type
   Registry according to the Specification Required policy of RFC 2434
   [6].  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 Report Block
    4  Statistics Summary Report Block
    5  Receiver Timestamp Report Block
    6  DLRR Report Block
    7  VoIP Metrics Report Block

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

6. Security Considerations

   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 information contained in Loss RLE, Duplicate RLE, and
   Timestamp Report Blocks facilitates MINC inference of multicast
   distribution trees for RTP data packets, and inference of link
   characteristics such as loss and delay.  This inference reveals
   information that might otherwise be considered confidential 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 can be used when
   confidentiality is a concern to end hosts.  Autonomous system
   administrators concerned about the loss of confidentiality regarding
   their networks can encrypt traffic, or filter it to exclude RTCP
   packets containing the XR report blocks concerned.

   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 Hen-
   ning Schulzrinne 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 limit the size of XR report blocks and employ the
   thinning techniques described in this document in order to fit
   reports into the space available.

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 their considered guidance; Nick Duffield 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
   extensive ongoing contributions; Sue Moon 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].  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 helping foster collabo-
   ration between this application.

   "pkt" is the authors 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 document;
   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 Mounir Benzaid for
   drawing our attention to the reporting needs of MLDA.

8. 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 per-
   tain
   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
   standards-related documentation can be found in BCP 11 [7]. [3].  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 propri-
   etary
   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.

9. References

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

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

   [3] R. Caceres, N.G. Duffield, and T. Friedman, "Impromptu measure-
   ment infrastructures using RTP," Proc. IEEE Infocom 2002.

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

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

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

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

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

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

10. 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 (2002). (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 doc-
   ument
   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 develop-
   ing
   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 MER-
   CHANTABILITY
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

9. Authors' Addresses

Acknowledgements

   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.

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

   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 Report Block           Friedman, Caceres, Duffield
   4.4  Statistics Summary Report Block  Almeroth, Sarac
   4.5  Receiver Timestamp Report Block  Friedman <timur.friedman@lip6.fr>
   4.6  DLRR Report Block                Friedman
   4.7  VoIP Metrics Report Block        Clark, Cole, Hedayat

Authors' Addresses

   Kevin Almeroth <almeroth@cs.ucsb.edu>
   Department of Computer Science
   University of Paris 6
    Laboratoire LiP6-CNRS
    8, rue du Capitaine Scott
    75015 PARIS, FRANCE California
   Santa Barbara, CA 93106 USA

   Ramon Caceres <ramon@shieldip.com>
   ShieldIP, Inc.
   11 West 42nd Street, 31st Floor
   New York, NY 10036, USA

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

    Kamil Sarac <ksarac@cs.uscb.edu>
    Department of Computer Science
    University of California
    Santa Barbara, CA 93106, 10036 USA

   Alan Clark <alan@telchemy.com>
   Telchemy Incorporated
   3360 Martins Farm Road, Suite 200
   Suwanee, GA 30024 USA
   Tel: +1 770 614-6944 614 6944
   Fax: +1 770 614-3951 614 3951
   Robert Cole <rgcole@att.com>
   AT&T Labs
   330 Saint Johns Street,
   2nd Floor
   Havre de Grace, MD, USA 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: +1 410 939-8732 +33 1 44 27 71 06
   Fax: +1 410 939-8732 +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 367 5600
   Fax: +1 978 367-5700 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

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] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI
   TS 101 329-5 V1.1.1 (2000-11), November 2000.

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

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

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

   [6] 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] 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] 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] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu
   measurement infrastructures using RTP," Proc. IEEE Infocom 2002.

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

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