Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3611

RTP Control Protocol Extended Reports (RTCP XR)

Pages: 55
Proposed Standard
Errata
Part 1 of 2 – Pages 1 to 25
None   None   Next

Top   ToC   RFC3611 - Page 1
Network Working Group                                   T. Friedman, Ed.
Request for Comments: 3611                                       Paris 6
Category: Standards Track                                R. Caceres, Ed.
                                                            IBM Research
                                                           A. Clark, Ed.
                                                                Telchemy
                                                           November 2003


            RTP Control Protocol Extended Reports (RTCP XR)

Status of this Memo

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

Copyright Notice

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

Abstract

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

Table of Contents

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

1. Introduction

This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP) [9], and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP) [4]. XR packets convey information beyond that already contained in the reception report blocks of RTCP's sender report (SR) or Receiver Report (RR) packets. The information is of use across RTP profiles, and so is not appropriately carried in SR or RR profile-specific extensions. Information used for network management falls into this category, for instance. The definition is broken out over the three sections that follow the Introduction. Section 2 defines the XR packet as consisting of an eight octet header followed by a series of components called report blocks. Section 3 defines the common format, or framework, consisting of a type and a length field, required for all report blocks. Section 4 defines several specific report block types. Other block types can be defined in future documents as the need arises. The report block types defined in this document fall into three categories. The first category consists of packet-by-packet reports on received or lost RTP packets. Reports in the second category convey reference time information between RTP participants. In the third category, reports convey metrics relating to packet receipts, that are summary in nature but that are more detailed, or of a different type, than that conveyed in existing RTCP packets. All told, seven report block formats are defined by this document. Of these, three are packet-by-packet block types: - Loss RLE Report Block (Section 4.1): Run length encoding of reports concerning the losses and receipts of RTP packets. - Duplicate RLE Report Block (Section 4.2): Run length encoding of reports concerning duplicates of received RTP packets. - Packet Receipt Times Report Block (Section 4.3): A list of reception timestamps of RTP packets. There are two reference time related block types: - Receiver Reference Time Report Block (Section 4.4): Receiver-end wallclock timestamps. Together with the DLRR Report Block mentioned next, these allow non-senders to calculate round-trip times.
Top   ToC   RFC3611 - Page 4
   -  DLRR Report Block (Section 4.5): The delay since the last Receiver
      Reference Time Report Block was received.  An RTP data sender that
      receives a Receiver Reference Time Report Block can respond with a
      DLRR Report Block, in much the same way as, in the mechanism
      already defined for RTCP [9, Section 6.3.1], an RTP data receiver
      that receives a sender's NTP timestamp can respond by filling in
      the DLSR field of an RTCP reception report block.

   Finally, this document defines two summary metric block types:

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

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

   Before proceeding to the XR packet and report block definitions, this
   document provides an applicability statement (Section 1.1) that
   describes the contexts in which these report blocks can be used.  It
   also defines (Section 1.2) the normative use of key words, such as
   MUST and SHOULD, as they are employed in this document.

   Following the definitions of the various report blocks, this document
   describes how applications that employ SDP can signal their use
   (Section 5).  The document concludes with a discussion (Section 6) of
   numbering considerations for the Internet Assigned Numbers Authority
   (IANA), of security considerations (Section 7), and with appendices
   that provide examples of how to implement algorithms discussed in the
   text.

1.1. Applicability

The XR packets are useful across multiple applications, and for that reason are not defined as profile-specific extensions to RTCP sender or Receiver Reports [9, Section 6.4.3]. Nonetheless, they are not of use in all contexts. In particular, the VoIP metrics report block (Section 4.7) is specific to voice applications, though it can be employed over a wide variety of such applications. The VoIP metrics report block can be applied to any one-to-one or one-to-many voice application for which the use of RTP and RTCP is specified. The use of conversational metrics (Section 4.7.5), including the R factor (as described by the E Model defined in [3]) and the mean opinion score for conversational quality (MOS-CQ), in applications other than simple two party calls is not defined; hence, these metrics should be identified as unavailable in multicast conferencing applications.
Top   ToC   RFC3611 - Page 5
   The packet-by-packet report block types, Loss RLE (Section 4.1),
   Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3),
   have been defined with network tomography applications, such as
   multicast inference of network characteristics (MINC) [11], in mind.
   MINC requires detailed packet receipt traces from multicast session
   receivers in order to infer the gross structure of the multicast
   distribution tree and the parameters, such as loss rates and delays,
   that apply to paths between the branching points of that tree.

   Any real time multicast multimedia application can use the packet-
   by-packet report block types.  Such an application could employ a
   MINC inference subsystem that would provide it with multicast tree
   topology information.  One potential use of such a subsystem would be
   for the identification of high loss regions in the multicast tree and
   the identification of multicast session participants well situated to
   provide retransmissions of lost packets.

   Detailed packet-by-packet reports do not necessarily have to consume
   disproportionate bandwidth with respect to other RTCP packets.  An
   application can cap the size of these blocks.  A mechanism called
   "thinning" is provided for these report blocks, and can be used to
   ensure that they adhere to a size limit by restricting the number of
   packets reported upon within any sequence number interval.  The
   rationale for, and use of this mechanism is described in [13].
   Furthermore, applications might not require report blocks from all
   receivers in order to answer such important questions as where in the
   multicast tree there are paths that exceed a defined loss rate
   threshold.  Intelligent decisions regarding which receivers send
   these report blocks can further restrict the portion of RTCP
   bandwidth that they consume.

   The packet-by-packet report blocks can also be used by dedicated
   network monitoring applications.  For such an application, it might
   be appropriate to allow more than 5% of RTP data bandwidth to be used
   for RTCP packets, thus allowing proportionately larger and more
   detailed report blocks.

   Nothing in the packet-by-packet block types restricts their use to
   multicast applications.  In particular, they could be used for
   network tomography similar to MINC, but using striped unicast packets
   instead.  In addition, if it were found useful, they could be used
   for applications limited to two participants.

   One use to which the packet-by-packet reports are not immediately
   suited is for data packet acknowledgments as part of a packet
   retransmission mechanism.  The reason is that the packet accounting
   technique suggested for these blocks differs from the packet
   accounting normally employed by RTP.  In order to favor measurement
Top   ToC   RFC3611 - Page 6
   applications, an effort is made to interpret as little as possible at
   the data receiver, and leave the interpretation as much as possible
   to participants that receive the report blocks.  Thus, for example, a
   packet with an anomalous SSRC ID or an anomalous sequence number
   might be excluded by normal RTP accounting, but would be reported
   upon for network monitoring purposes.

   The Statistics Summary Report Block (Section 4.6) has also been
   defined with network monitoring in mind.  This block type can be used
   equally well for reporting on unicast and multicast packet reception.

   The reference time related block types were conceived for receiver-
   based TCP-friendly multicast congestion control [18].  By allowing
   data receivers to calculate their round trip times to senders, they
   help the receivers estimate the downstream bandwidth they should
   request.  Note that if every receiver is to send Receiver Reference
   Time Report Blocks (Section 4.4), a sender might potentially send a
   number of DLRR Report Blocks (Section 4.5) equal to the number of
   receivers whose RTCP packets have arrived at the sender within its
   reporting interval.  As the number of participants in a multicast
   session increases, an application should use discretion regarding
   which participants send these blocks, and how frequently.

   XR packets supplement the existing RTCP packets, and may be stacked
   with other RTCP packets to form compound RTCP packets [9, Section 6].
   The introduction of XR packets into a session in no way changes the
   rules governing the calculation of the RTCP reporting interval [9,
   Section 6.2].  As XR packets are RTCP packets, they count as such for
   bandwidth calculations.  As a result, the addition of extended
   reporting information may tend to increase the average RTCP packet
   size, and thus the average reporting interval.  This increase may be
   limited by limiting the size of XR packets.

   The SDP signaling defined for XR packets in this document (Section 5)
   was done so with three use scenarios in mind: a Real Time Streaming
   Protocol (RTSP) controlled streaming application, a one-to-many
   multicast multimedia application such as a course lecture with
   enhanced feedback, and a Session Initiation Protocol (SIP) controlled
   conversational session involving two parties.  Applications that
   employ SDP are free to use additional SDP signaling for cases not
   covered here.  In addition, applications are free to use signaling
   mechanisms other than SDP.
Top   ToC   RFC3611 - Page 7

1.2. Terminology

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

2. XR Packet Format

An XR packet consists of a header of two 32-bit words, followed by a number, possibly zero, of extended report blocks. This type of packet is laid out in a manner consistent with other RTCP packets, as concerns the essential version, packet type, and length information. XR packets are thus backwards compatible with RTCP receiver implementations that do not recognize them, but that ought to be able to parse past them using the length information. A padding field and an SSRC field are also provided in the same locations that they appear in other RTCP packets, for simplicity. The format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|reserved | PT=XR=207 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : report blocks : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP. This specification applies to RTP version two. padding (P): 1 bit If the padding bit is set, this XR packet contains some additional padding octets at the end. The semantics of this field are identical to the semantics of the padding field in the SR packet, as defined by the RTP specification. reserved: 5 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
Top   ToC   RFC3611 - Page 8
   packet type (PT): 8 bits
         Contains the constant 207 to identify this as an RTCP XR
         packet.  This value is registered with the Internet Assigned
         Numbers Authority (IANA), as described in Section 6.1.

   length: 16 bits
         As described for the RTCP Sender Report (SR) packet (see
         Section 6.4.1 of the RTP specification [9]).  Briefly, the
         length of this XR packet in 32-bit words minus one, including
         the header and any padding.

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

   report blocks: variable length.
         Zero or more extended report blocks.  In keeping with the
         extended report block framework defined below, each block MUST
         consist of one or more 32-bit words.

3. Extended Report Block Framework

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

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

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

4. Extended Report Blocks

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

4.1. Loss RLE Report Block

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

   In its per-sender accounting, an RTP session participant SHOULD NOT
   make the receipt of a threshold minimum number of RTP packets a
   condition for reporting upon the sender of those packets.  This
   accounting technique differs from the technique described in Section
   6.2.1 and Appendix A.1 of the RTP specification that allows a
   threshold to determine whether a sender is considered valid.

   In its per-packet accounting, an RTP session participant SHOULD treat
   all sequence numbers as valid.  This accounting technique differs
   from the technique described in Appendix A.1 of the RTP specification
   that suggests ruling a sequence number valid or invalid on the basis
   of its contiguity with the sequence numbers of previously received
   packets.

   Sender validity and sequence number validity are interpretations of
   the raw data.  Such interpretations are justified in the interest,
   for example, of excluding the stray old packet from an unrelated
   session from having an effect upon the calculation of the RTCP
   transmission interval.  The presence of stray packets might, on the
   other hand, be of interest to a network monitoring application.

   One accounting interpretation that is still necessary is for a
   participant to decide whether the 16 bit sequence number has rolled
   over.  Under ordinary circumstances this is not a difficult task.
   For example, if packet number 65,535 (the highest possible sequence
   number) is followed shortly by packet number 0, it is reasonable to
   assume that there has been a rollover.  However, it is possible that
   the packet is an earlier one (from 65,535 packets earlier).  It is
   also possible that the sequence numbers have rolled over multiple
   times, either forward or backward.  The interpretation becomes more
   difficult when there are large gaps between the sequence numbers,
   even accounting for rollover, and when there are long intervals
   between received packets.

   The per-packet accounting technique mandated here is for a
   participant to keep track of the sequence number of the packet most
   recently received from a sender.  For the next packet that arrives
   from that sender, the sequence number MUST be judged to fall no more
   than 32,768 packets ahead or behind the most recent one, whichever
   choice places it closer.  In the event that both choices are equally
   distant (only possible when the distance is 32,768), the choice MUST
   be the one that does not require a rollover.  Appendix A.1 presents
   an algorithm that implements this technique.
Top   ToC   RFC3611 - Page 11
   Each block reports on a single RTP data packet source, identified by
   its SSRC.  The receiver that is supplying the report is identified in
   the header of the RTCP packet.

   Choice of beginning and ending RTP packet sequence numbers for the
   trace is left to the application.  These values are reported in the
   block.  The last sequence number in the trace MAY differ from the
   sequence number reported on in any accompanying SR or RR report.

   Note that because of sequence number wraparound, the ending sequence
   number MAY be less than the beginning sequence number.  A Loss RLE
   Report Block MUST NOT be used to report upon a range of 65,534 or
   greater in the sequence number space, as there is no means of
   identifying multiple wraparounds.

   The trace described by a Loss RLE report consists of a sequence of
   Boolean values, one for each sequence number of the trace.  A value
   of one represents a packet receipt, meaning that one or more packets
   having that sequence number have been received since the most recent
   wraparound of sequence numbers (or since the beginning of the RTP
   session if no wraparound has been judged to have occurred).  A value
   of zero represents a packet loss, meaning that there has been no
   packet receipt for that sequence number as of the time of the report.
   If a packet with a given sequence number is received after a report
   of a loss for that sequence number, a later Loss RLE report MAY
   report a packet receipt for that sequence number.

   The encoding itself consists of a series of 16 bit units called
   chunks that describe sequences of packet receipts or losses in the
   trace.  Each chunk either specifies a run length or a bit vector, or
   is a null chunk.  A run length describes between 1 and 16,383 events
   that are all the same (either all receipts or all losses).  A bit
   vector describes 15 events that may be mixed receipts and losses.  A
   null chunk describes no events, and is used to round out the block to
   a 32 bit word boundary.

   The mapping from a sequence of lost and received packets into a
   sequence of chunks is not necessarily unique.  For example, the
   following trace covers 45 packets, of which the 22nd and 24th have
   been lost and the others received:

      1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
Top   ToC   RFC3611 - Page 12
   One way to encode this would be:

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

   Another way to encode this would be:

      run of 21 receipts
      bit vector 0101 1111 1111 111
      run of 9 receipts
      null chunk

   The choice of encoding is left to the application.  As part of this
   freedom of choice, applications MAY terminate a series of run length
   and bit vector chunks with a bit vector chunk that runs beyond the
   sequence number space described by the report block.  For example, if
   the 44th packet in the same sequence was lost:

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

   This could be encoded as:

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


   In this example, the last five bits of the second bit vector describe
   a part of the sequence number space that extends beyond the last
   sequence number in the trace.  These bits have been set to zero.

   All bits in a bit vector chunk that describe a part of the sequence
   number space that extends beyond the last sequence number in the
   trace MUST be set to zero, and MUST be ignored by the receiver.

   A null packet MUST appear at the end of a Loss RLE Report Block if
   the number of run length plus bit vector chunks is odd.  The null
   chunk MUST NOT appear in any other context.

   Caution should be used in sending Loss RLE Report Blocks because,
   even with the compression provided by run length encoding, they can
   easily consume bandwidth out of proportion with normal RTCP packets.
   The block type includes a mechanism, called thinning, that allows an
   application to limit report sizes.
Top   ToC   RFC3611 - Page 13
   A thinning value, T, selects a subset of packets within the sequence
   number space: those with sequence numbers that are multiples of 2^T.
   Packet reception and loss reports apply only to those packets.  T can
   vary between 0 and 15.  If T is zero, then every packet in the
   sequence number space is reported upon.  If T is fifteen, then one in
   every 32,768 packets is reported upon.

   Suppose that the trace just described begins at sequence number
   13,821.  The last sequence number in the trace is 13,865.  If the
   trace were to be thinned with a thinning value of T=2, then the
   following sequence numbers would be reported upon: 13,824, 13,828,
   13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860,
   13,864.  The thinned trace would be as follows:

      1    1    1    1    1    0    1    1    1    1    0

   This could be encoded as follows:

      bit vector 1111 1011 1100 000
      null chunk

   The last four bits in the bit vector, representing sequence numbers
   13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are
   thus set to zero and are ignored by the receiver.  With thinning, the
   loss of the 22nd packet goes unreported because its sequence number,
   13,842, is not a multiple of four.  Packet receipts for all sequence
   numbers that are not multiples of four also go unreported.  However,
   in this example thinning has permitted the Loss RLE Report Block to
   be shortened by one 32 bit word.

   Choice of the thinning value is left to the application.
Top   ToC   RFC3611 - Page 14
   The Loss RLE Report Block has the following format:

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

   block type (BT): 8 bits
         A Loss RLE Report Block is identified by the constant 1.

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

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

   block length: 16 bits
         Defined in Section 3.

   SSRC of source: 32 bits
         The SSRC of the RTP data packet source being reported upon by
         this report block.

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

   end_seq: 16 bits
         The last sequence number that this block reports on plus one.
Top   ToC   RFC3611 - Page 15
   chunk i: 16 bits
         There are three chunk types: run length, bit vector, and
         terminating null, defined in the following sections.  If the
         chunk is all zeroes, then it is a terminating null chunk.
         Otherwise, the left most bit of the chunk determines its type:
         0 for run length and 1 for bit vector.

4.1.1. Run Length Chunk

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

4.1.2. Bit Vector Chunk

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

4.1.3. Terminating Null Chunk

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

4.2. Duplicate RLE Report Block

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

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

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

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

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

   block length: 16 bits
         Defined in Section 3.

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

   begin_seq: 16 bits
         As defined in Section 4.1.

   end_seq: 16 bits
         As defined in Section 4.1.

   chunk i: 16 bits
         As defined in Section 4.1.
Top   ToC   RFC3611 - Page 18

4.3. Packet Receipt Times Report Block

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=3      | rsvd. |   T   |         block length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          begin_seq            |             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Receipt time of packet begin_seq                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Receipt time of packet (begin_seq + 1) mod 65536        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Receipt time of packet (end_seq - 1) mod 65536          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

   block length: 16 bits
         Defined in Section 3.

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

   begin_seq: 16 bits
         As defined in Section 4.1.

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

4.4. Receiver Reference Time Report Block

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

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

4.5. DLRR Report Block

This block extends RTCP's delay since the last Sender Report (DLSR) mechanism [9, Sec. 6.3.1] so that non-senders may also calculate round trip times, as proposed in [18]. It is termed DLRR for delay since the last Receiver Report, and may be sent in response to a Receiver Timestamp Report Block (see previous section) from a receiver to allow that receiver to calculate its round trip time to the respondent. The report consists of one or more 3 word sub- blocks: one sub-block per Receiver Report. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=5 | reserved | block length | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block | last RR (LRR) | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last RR (DLRR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 (SSRC of second receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block : ... : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Top   ToC   RFC3611 - Page 22
   block type (BT): 8 bits
         A DLRR Report Block is identified by the constant 5.

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

   block length: 16 bits
         Defined in Section 3.

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

   delay since last RR (DLRR): 32 bits
         The delay, expressed in units of 1/65536 seconds, between
         receiving the last Receiver Reference Time Report Block from
         participant SSRC_n and sending this DLRR Report Block.  If a
         Receiver Reference Time Report Block has yet to be received
         from SSRC_n, the DLRR field is set to zero (or the DLRR is
         omitted entirely).  Let SSRC_r denote the receiver issuing this
         DLRR Report Block.  Participant SSRC_n can compute the round-
         trip propagation delay to SSRC_r by recording the time A when
         this Receiver Timestamp Report Block is received.  It
         calculates the total round-trip time A-LRR using the last RR
         timestamp (LRR) field, and then subtracting this field to leave
         the round-trip propagation delay as A-LRR-DLRR.  This is
         illustrated in [9, Fig. 2].

4.6. Statistics Summary Report Block

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=6      |L|D|J|ToH|rsvd.|       block length = 9        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          begin_seq            |             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        lost_packets                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        dup_packets                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         min_jitter                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         max_jitter                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         mean_jitter                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         dev_jitter                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | min_ttl_or_hl | max_ttl_or_hl |mean_ttl_or_hl | dev_ttl_or_hl |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   loss report flag (L): 1 bit
         Bit set to 1 if the lost_packets field contains a report, 0
         otherwise.

   duplicate report flag (D): 1 bit
         Bit set to 1 if the dup_packets field contains a report, 0
         otherwise.

   jitter flag (J): 1 bit
         Bit set to 1 if the min_jitter, max_jitter, mean_jitter, and
         dev_jitter fields all contain reports, 0 if none of them do.

   TTL or Hop Limit flag (ToH): 2 bits
         This field is set to 0 if none of the fields min_ttl_or_hl,
         max_ttl_or_hl, mean_ttl_or_hl, or dev_ttl_or_hl contain
         reports.  If the field is non-zero, then all of these fields
         contain reports.  The value 1 signifies that they report on
         IPv4 TTL values.  The value 2 signifies that they report on
Top   ToC   RFC3611 - Page 24
         IPv6 Hop Limit values.  The value 3 is undefined and MUST NOT
         be used.

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

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

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

   begin_seq: 16 bits
         As defined in Section 4.1.

   end_seq: 16 bits
         As defined in Section 4.1.

   lost_packets: 32 bits
         Number of lost packets in the above sequence number interval.

   dup_packets: 32 bits
         Number of duplicate packets in the above sequence number
         interval.

   min_jitter: 32 bits
         The minimum relative transit time between two packets in the
         above sequence number interval.  All jitter values are measured
         as the difference between a packet's RTP timestamp and the
         reporter's clock at the time of arrival, measured in the same
         units.

   max_jitter: 32 bits
         The maximum relative transit time between two packets in the
         above sequence number interval.

   mean_jitter: 32 bits
         The mean relative transit time between each two packet series
         in the above sequence number interval, rounded to the nearest
         value expressible as an RTP timestamp.

   dev_jitter: 32 bits
         The standard deviation of the relative transit time between
         each two packet series in the above sequence number interval.
Top   ToC   RFC3611 - Page 25
   min_ttl_or_hl: 8 bits
         The minimum TTL or Hop Limit value of data packets in the
         sequence number range.

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

   mean_ttl_or_hl: 8 bits
         The mean TTL or Hop Limit value of data packets in the sequence
         number range, rounded to the nearest integer.

   dev_ttl_or_hl: 8 bits
         The standard deviation of TTL or Hop Limit values of data
         packets in the sequence number range.



(page 25 continued on part 2)

Next Section