doc: Add RFC documents

1 files changed, 3083 insertions, 0 deletions

diff --git a/doc/rfc/rfc3611.txt b/doc/rfc/rfc3611.txt
new file mode 100644
index 0000000..d88c4e4
--- /dev/null
+++ b/doc/rfc/rfc3611.txt
@@ -0,0 +1,3083 @@
+
+
+
+
+
+
+Network Working Group                                   T. Friedman, Ed.
+Request for Comments: 3611                                       Paris 6
+Category: Standards Track                                R. Caceres, Ed.
+                                                            IBM Research
+                                                           A. Clark, Ed.
+                                                                Telchemy
+                                                           November 2003
+
+
+            RTP Control Protocol Extended Reports (RTCP XR)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document defines the Extended Report (XR) packet type for the
+   RTP Control Protocol (RTCP), and defines how the use of XR packets
+   can be signaled by an application if it employs the Session
+   Description Protocol (SDP).  XR packets are composed of report
+   blocks, and seven block types are defined here.  The purpose of the
+   extended reporting format is to convey information that supplements
+   the six statistics that are contained in the report blocks used by
+   RTCP's Sender Report (SR) and Receiver Report (RR) packets.  Some
+   applications, such as multicast inference of network characteristics
+   (MINC) or voice over IP (VoIP) monitoring, require other and more
+   detailed statistics.  In addition to the block types defined here,
+   additional block types may be defined in the future by adhering to
+   the framework that this document provides.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                     [Page 1]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.1.  Applicability. . . . . . . . . . . . . . . . . . . . . .  4
+       1.2.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  7
+   2.  XR Packet Format . . . . . . . . . . . . . . . . . . . . . . .  7
+   3.  Extended Report Block Framework. . . . . . . . . . . . . . . .  8
+   4.  Extended Report Blocks . . . . . . . . . . . . . . . . . . . .  9
+       4.1.  Loss RLE Report Block. . . . . . . . . . . . . . . . . .  9
+             4.1.1.  Run Length Chunk . . . . . . . . . . . . . . . . 15
+             4.1.2.  Bit Vector Chunk . . . . . . . . . . . . . . . . 15
+             4.1.3.  Terminating Null Chunk . . . . . . . . . . . . . 16
+       4.2.  Duplicate RLE Report Block . . . . . . . . . . . . . . . 16
+       4.3.  Packet Receipt Times Report Block. . . . . . . . . . . . 18
+       4.4.  Receiver Reference Time Report Block . . . . . . . . . . 20
+       4.5.  DLRR Report Block. . . . . . . . . . . . . . . . . . . . 21
+       4.6.  Statistics Summary Report Block. . . . . . . . . . . . . 22
+       4.7.  VoIP Metrics Report Block. . . . . . . . . . . . . . . . 25
+             4.7.1.  Packet Loss and Discard Metrics. . . . . . . . . 27
+             4.7.2.  Burst Metrics. . . . . . . . . . . . . . . . . . 27
+             4.7.3.  Delay Metrics. . . . . . . . . . . . . . . . . . 30
+             4.7.4.  Signal Related Metrics . . . . . . . . . . . . . 31
+             4.7.5.  Call Quality or Transmission Quality Metrics . . 33
+             4.7.6.  Configuration Parameters . . . . . . . . . . . . 34
+             4.7.7.  Jitter Buffer Parameters . . . . . . . . . . . . 36
+   5.  SDP Signaling. . . . . . . . . . . . . . . . . . . . . . . . . 36
+       5.1.  The SDP Attribute. . . . . . . . . . . . . . . . . . . . 37
+       5.2.  Usage in Offer/Answer. . . . . . . . . . . . . . . . . . 40
+       5.3.  Usage Outside of Offer/Answer. . . . . . . . . . . . . . 42
+   6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 42
+       6.1.  XR Packet Type . . . . . . . . . . . . . . . . . . . . . 42
+       6.2.  RTCP XR Block Type Registry. . . . . . . . . . . . . . . 42
+       6.3.  The "rtcp-xr" SDP Attribute. . . . . . . . . . . . . . . 43
+   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 44
+   A.  Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 46
+       A.1.  Sequence Number Interpretation . . . . . . . . . . . . . 46
+       A.2.  Example Burst Packet Loss Calculation. . . . . . . . . . 47
+   Intellectual Property Notice . . . . . . . . . . . . . . . . . . . 49
+   Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 50
+   Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
+   References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
+   Normative References . . . . . . . . . . . . . . . . . . . . . . . 51
+   Informative References . . . . . . . . . . . . . . . . . . . . . . 51
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 55
+
+
+
+
+
+
+Friedman, et al.            Standards Track                     [Page 2]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+1.  Introduction
+
+   This document defines the Extended Report (XR) packet type for the
+   RTP Control Protocol (RTCP) [9], and defines how the use of XR
+   packets can be signaled by an application if it employs the Session
+   Description Protocol (SDP) [4].  XR packets convey information beyond
+   that already contained in the reception report blocks of RTCP's
+   sender report (SR) or Receiver Report (RR) packets.  The information
+   is of use across RTP profiles, and so is not appropriately carried in
+   SR or RR profile-specific extensions.  Information used for network
+   management falls into this category, for instance.
+
+   The definition is broken out over the three sections that follow the
+   Introduction.  Section 2 defines the XR packet as consisting of an
+   eight octet header followed by a series of components called report
+   blocks.  Section 3 defines the common format, or framework,
+   consisting of a type and a length field, required for all report
+   blocks.  Section 4 defines several specific report block types.
+   Other block types can be defined in future documents as the need
+   arises.
+
+   The report block types defined in this document fall into three
+   categories.  The first category consists of packet-by-packet reports
+   on received or lost RTP packets.  Reports in the second category
+   convey reference time information between RTP participants.  In the
+   third category, reports convey metrics relating to packet receipts,
+   that are summary in nature but that are more detailed, or of a
+   different type, than that conveyed in existing RTCP packets.
+
+   All told, seven report block formats are defined by this document.
+   Of these, three are packet-by-packet block types:
+
+   -  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.
+
+
+
+
+Friedman, et al.            Standards Track                     [Page 3]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   -  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.
+
+
+
+Friedman, et al.            Standards Track                     [Page 4]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   The packet-by-packet report block types, Loss RLE (Section 4.1),
+   Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3),
+   have been defined with network tomography applications, such as
+   multicast inference of network characteristics (MINC) [11], in mind.
+   MINC requires detailed packet receipt traces from multicast session
+   receivers in order to infer the gross structure of the multicast
+   distribution tree and the parameters, such as loss rates and delays,
+   that apply to paths between the branching points of that tree.
+
+   Any real time multicast multimedia application can use the packet-
+   by-packet report block types.  Such an application could employ a
+   MINC inference subsystem that would provide it with multicast tree
+   topology information.  One potential use of such a subsystem would be
+   for the identification of high loss regions in the multicast tree and
+   the identification of multicast session participants well situated to
+   provide retransmissions of lost packets.
+
+   Detailed packet-by-packet reports do not necessarily have to consume
+   disproportionate bandwidth with respect to other RTCP packets.  An
+   application can cap the size of these blocks.  A mechanism called
+   "thinning" is provided for these report blocks, and can be used to
+   ensure that they adhere to a size limit by restricting the number of
+   packets reported upon within any sequence number interval.  The
+   rationale for, and use of this mechanism is described in [13].
+   Furthermore, applications might not require report blocks from all
+   receivers in order to answer such important questions as where in the
+   multicast tree there are paths that exceed a defined loss rate
+   threshold.  Intelligent decisions regarding which receivers send
+   these report blocks can further restrict the portion of RTCP
+   bandwidth that they consume.
+
+   The packet-by-packet report blocks can also be used by dedicated
+   network monitoring applications.  For such an application, it might
+   be appropriate to allow more than 5% of RTP data bandwidth to be used
+   for RTCP packets, thus allowing proportionately larger and more
+   detailed report blocks.
+
+   Nothing in the packet-by-packet block types restricts their use to
+   multicast applications.  In particular, they could be used for
+   network tomography similar to MINC, but using striped unicast packets
+   instead.  In addition, if it were found useful, they could be used
+   for applications limited to two participants.
+
+   One use to which the packet-by-packet reports are not immediately
+   suited is for data packet acknowledgments as part of a packet
+   retransmission mechanism.  The reason is that the packet accounting
+   technique suggested for these blocks differs from the packet
+   accounting normally employed by RTP.  In order to favor measurement
+
+
+
+Friedman, et al.            Standards Track                     [Page 5]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   applications, an effort is made to interpret as little as possible at
+   the data receiver, and leave the interpretation as much as possible
+   to participants that receive the report blocks.  Thus, for example, a
+   packet with an anomalous SSRC ID or an anomalous sequence number
+   might be excluded by normal RTP accounting, but would be reported
+   upon for network monitoring purposes.
+
+   The Statistics Summary Report Block (Section 4.6) has also been
+   defined with network monitoring in mind.  This block type can be used
+   equally well for reporting on unicast and multicast packet reception.
+
+   The reference time related block types were conceived for receiver-
+   based TCP-friendly multicast congestion control [18].  By allowing
+   data receivers to calculate their round trip times to senders, they
+   help the receivers estimate the downstream bandwidth they should
+   request.  Note that if every receiver is to send Receiver Reference
+   Time Report Blocks (Section 4.4), a sender might potentially send a
+   number of DLRR Report Blocks (Section 4.5) equal to the number of
+   receivers whose RTCP packets have arrived at the sender within its
+   reporting interval.  As the number of participants in a multicast
+   session increases, an application should use discretion regarding
+   which participants send these blocks, and how frequently.
+
+   XR packets supplement the existing RTCP packets, and may be stacked
+   with other RTCP packets to form compound RTCP packets [9, Section 6].
+   The introduction of XR packets into a session in no way changes the
+   rules governing the calculation of the RTCP reporting interval [9,
+   Section 6.2].  As XR packets are RTCP packets, they count as such for
+   bandwidth calculations.  As a result, the addition of extended
+   reporting information may tend to increase the average RTCP packet
+   size, and thus the average reporting interval.  This increase may be
+   limited by limiting the size of XR packets.
+
+   The SDP signaling defined for XR packets in this document (Section 5)
+   was done so with three use scenarios in mind: a Real Time Streaming
+   Protocol (RTSP) controlled streaming application, a one-to-many
+   multicast multimedia application such as a course lecture with
+   enhanced feedback, and a Session Initiation Protocol (SIP) controlled
+   conversational session involving two parties.  Applications that
+   employ SDP are free to use additional SDP signaling for cases not
+   covered here.  In addition, applications are free to use signaling
+   mechanisms other than SDP.
+
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                     [Page 6]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+1.2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119 [1]
+   and indicate requirement levels for compliance with this
+   specification.
+
+2.  XR Packet Format
+
+   An XR packet consists of a header of two 32-bit words, followed by a
+   number, possibly zero, of extended report blocks.  This type of
+   packet is laid out in a manner consistent with other RTCP packets, as
+   concerns the essential version, packet type, and length information.
+   XR packets are thus backwards compatible with RTCP receiver
+   implementations that do not recognize them, but that ought to be able
+   to parse past them using the length information.  A padding field and
+   an SSRC field are also provided in the same locations that they
+   appear in other RTCP packets, for simplicity.  The format is as
+   follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|reserved |   PT=XR=207   |             length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              SSRC                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :                         report blocks                         :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   version (V): 2 bits
+         Identifies the version of RTP.  This specification applies to
+         RTP version two.
+
+   padding (P): 1 bit
+         If the padding bit is set, this XR packet contains some
+         additional padding octets at the end.  The semantics of this
+         field are identical to the semantics of the padding field in
+         the SR packet, as defined by the RTP specification.
+
+   reserved: 5 bits
+         This field is reserved for future definition.  In the absence
+         of such definition, the bits in this field MUST be set to zero
+         and MUST be ignored by the receiver.
+
+
+
+
+
+
+Friedman, et al.            Standards Track                     [Page 7]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   packet type (PT): 8 bits
+         Contains the constant 207 to identify this as an RTCP XR
+         packet.  This value is registered with the Internet Assigned
+         Numbers Authority (IANA), as described in Section 6.1.
+
+   length: 16 bits
+         As described for the RTCP Sender Report (SR) packet (see
+         Section 6.4.1 of the RTP specification [9]).  Briefly, the
+         length of this XR packet in 32-bit words minus one, including
+         the header and any padding.
+
+   SSRC: 32 bits
+         The synchronization source identifier for the originator of
+         this XR packet.
+
+   report blocks: variable length.
+         Zero or more extended report blocks.  In keeping with the
+         extended report block framework defined below, each block MUST
+         consist of one or more 32-bit words.
+
+3.  Extended Report Block Framework
+
+   Extended report blocks are stacked, one after the other, at the end
+   of an XR packet.  An individual block's length is a multiple of 4
+   octets.  The XR header's length field describes the total length of
+   the packet, including these extended report blocks.
+
+   Each block has block type and length fields that facilitate parsing.
+   A receiving application can demultiplex the blocks based upon their
+   type, and can use the length information to locate each successive
+   block, even in the presence of block types it does not recognize.
+
+   An extended report block has the following format:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      BT       | type-specific |         block length          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :             type-specific block contents                      :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   block type (BT): 8 bits
+         Identifies the block format.  Seven block types are defined in
+         Section 4.  Additional block types may be defined in future
+         specifications.  This field's name space is managed by the
+         Internet Assigned Numbers Authority (IANA), as described in
+         Section 6.2.
+
+
+
+Friedman, et al.            Standards Track                     [Page 8]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   type-specific: 8 bits
+         The use of these bits is determined by the block type
+         definition.
+
+   block length: 16 bits
+         The length of this report block, including the header, in 32-
+         bit words minus one.  If the block type definition permits,
+         zero is an acceptable value, signifying a block that consists
+         of only the BT, type-specific, and block length fields, with a
+         null type-specific block contents field.
+
+   type-specific block contents: variable length
+         The use of this field is defined by the particular block type,
+         subject to the constraint that it MUST be a multiple of 32 bits
+         long.  If the block type definition permits, It MAY be zero
+         bits long.
+
+4.  Extended Report Blocks
+
+   This section defines seven extended report blocks: block types for
+   reporting upon received packet losses and duplicates, packet
+   reception times, receiver reference time information, receiver
+   inter-report delays, detailed reception statistics, and voice over IP
+   (VoIP) metrics.  An implementation SHOULD ignore incoming blocks with
+   types not relevant or unknown to it.  Additional block types MUST be
+   registered with the Internet Assigned Numbers Authority (IANA) [16],
+   as described in Section 6.2.
+
+4.1.  Loss RLE Report Block
+
+   This block type permits detailed reporting upon individual packet
+   receipt and loss events.  Such reports can be used, for example, for
+   multicast inference of network characteristics (MINC) [11].  With
+   MINC, one can discover the topology of the multicast tree used for
+   distributing a source's RTP packets, and of the loss rates along
+   links within that tree, or they could be used to provide raw data to
+   a network management application.
+
+   Since a Boolean trace of lost and received RTP packets is potentially
+   lengthy, this block type permits the trace to be compressed through
+   run length encoding.  To further reduce block size, loss event
+   reports can be systematically dropped from the trace in a mechanism
+   called thinning that is described below and that is studied in [13].
+
+   A participant that generates a Loss RLE Report Block should favor
+   accuracy in reporting on observed events over interpretation of those
+   events whenever possible.  Interpretation should be left to those who
+   observe the report blocks.  Following this approach implies that
+
+
+
+Friedman, et al.            Standards Track                     [Page 9]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   accounting for Loss RLE Report Blocks will differ from the accounting
+   for the generation of the SR and RR packets described in the RTP
+   specification [9] in the following two areas: per-sender accounting
+   and per-packet accounting.
+
+   In its per-sender accounting, an RTP session participant SHOULD NOT
+   make the receipt of a threshold minimum number of RTP packets a
+   condition for reporting upon the sender of those packets.  This
+   accounting technique differs from the technique described in Section
+   6.2.1 and Appendix A.1 of the RTP specification that allows a
+   threshold to determine whether a sender is considered valid.
+
+   In its per-packet accounting, an RTP session participant SHOULD treat
+   all sequence numbers as valid.  This accounting technique differs
+   from the technique described in Appendix A.1 of the RTP specification
+   that suggests ruling a sequence number valid or invalid on the basis
+   of its contiguity with the sequence numbers of previously received
+   packets.
+
+   Sender validity and sequence number validity are interpretations of
+   the raw data.  Such interpretations are justified in the interest,
+   for example, of excluding the stray old packet from an unrelated
+   session from having an effect upon the calculation of the RTCP
+   transmission interval.  The presence of stray packets might, on the
+   other hand, be of interest to a network monitoring application.
+
+   One accounting interpretation that is still necessary is for a
+   participant to decide whether the 16 bit sequence number has rolled
+   over.  Under ordinary circumstances this is not a difficult task.
+   For example, if packet number 65,535 (the highest possible sequence
+   number) is followed shortly by packet number 0, it is reasonable to
+   assume that there has been a rollover.  However, it is possible that
+   the packet is an earlier one (from 65,535 packets earlier).  It is
+   also possible that the sequence numbers have rolled over multiple
+   times, either forward or backward.  The interpretation becomes more
+   difficult when there are large gaps between the sequence numbers,
+   even accounting for rollover, and when there are long intervals
+   between received packets.
+
+   The per-packet accounting technique mandated here is for a
+   participant to keep track of the sequence number of the packet most
+   recently received from a sender.  For the next packet that arrives
+   from that sender, the sequence number MUST be judged to fall no more
+   than 32,768 packets ahead or behind the most recent one, whichever
+   choice places it closer.  In the event that both choices are equally
+   distant (only possible when the distance is 32,768), the choice MUST
+   be the one that does not require a rollover.  Appendix A.1 presents
+   an algorithm that implements this technique.
+
+
+
+Friedman, et al.            Standards Track                    [Page 10]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   Each block reports on a single RTP data packet source, identified by
+   its SSRC.  The receiver that is supplying the report is identified in
+   the header of the RTCP packet.
+
+   Choice of beginning and ending RTP packet sequence numbers for the
+   trace is left to the application.  These values are reported in the
+   block.  The last sequence number in the trace MAY differ from the
+   sequence number reported on in any accompanying SR or RR report.
+
+   Note that because of sequence number wraparound, the ending sequence
+   number MAY be less than the beginning sequence number.  A Loss RLE
+   Report Block MUST NOT be used to report upon a range of 65,534 or
+   greater in the sequence number space, as there is no means of
+   identifying multiple wraparounds.
+
+   The trace described by a Loss RLE report consists of a sequence of
+   Boolean values, one for each sequence number of the trace.  A value
+   of one represents a packet receipt, meaning that one or more packets
+   having that sequence number have been received since the most recent
+   wraparound of sequence numbers (or since the beginning of the RTP
+   session if no wraparound has been judged to have occurred).  A value
+   of zero represents a packet loss, meaning that there has been no
+   packet receipt for that sequence number as of the time of the report.
+   If a packet with a given sequence number is received after a report
+   of a loss for that sequence number, a later Loss RLE report MAY
+   report a packet receipt for that sequence number.
+
+   The encoding itself consists of a series of 16 bit units called
+   chunks that describe sequences of packet receipts or losses in the
+   trace.  Each chunk either specifies a run length or a bit vector, or
+   is a null chunk.  A run length describes between 1 and 16,383 events
+   that are all the same (either all receipts or all losses).  A bit
+   vector describes 15 events that may be mixed receipts and losses.  A
+   null chunk describes no events, and is used to round out the block to
+   a 32 bit word boundary.
+
+   The mapping from a sequence of lost and received packets into a
+   sequence of chunks is not necessarily unique.  For example, the
+   following trace covers 45 packets, of which the 22nd and 24th have
+   been lost and the others received:
+
+      1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
+
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 11]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   One way to encode this would be:
+
+      bit vector 1111 1111 1111 111
+      bit vector 1111 1101 0111 111
+      bit vector 1111 1111 1111 111
+      null chunk
+
+   Another way to encode this would be:
+
+      run of 21 receipts
+      bit vector 0101 1111 1111 111
+      run of 9 receipts
+      null chunk
+
+   The choice of encoding is left to the application.  As part of this
+   freedom of choice, applications MAY terminate a series of run length
+   and bit vector chunks with a bit vector chunk that runs beyond the
+   sequence number space described by the report block.  For example, if
+   the 44th packet in the same sequence was lost:
+
+      1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
+
+   This could be encoded as:
+
+      run of 21 receipts
+      bit vector 0101 1111 1111 111
+      bit vector 1111 1110 1000 000
+      null chunk
+
+
+   In this example, the last five bits of the second bit vector describe
+   a part of the sequence number space that extends beyond the last
+   sequence number in the trace.  These bits have been set to zero.
+
+   All bits in a bit vector chunk that describe a part of the sequence
+   number space that extends beyond the last sequence number in the
+   trace MUST be set to zero, and MUST be ignored by the receiver.
+
+   A null packet MUST appear at the end of a Loss RLE Report Block if
+   the number of run length plus bit vector chunks is odd.  The null
+   chunk MUST NOT appear in any other context.
+
+   Caution should be used in sending Loss RLE Report Blocks because,
+   even with the compression provided by run length encoding, they can
+   easily consume bandwidth out of proportion with normal RTCP packets.
+   The block type includes a mechanism, called thinning, that allows an
+   application to limit report sizes.
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 12]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   A thinning value, T, selects a subset of packets within the sequence
+   number space: those with sequence numbers that are multiples of 2^T.
+   Packet reception and loss reports apply only to those packets.  T can
+   vary between 0 and 15.  If T is zero, then every packet in the
+   sequence number space is reported upon.  If T is fifteen, then one in
+   every 32,768 packets is reported upon.
+
+   Suppose that the trace just described begins at sequence number
+   13,821.  The last sequence number in the trace is 13,865.  If the
+   trace were to be thinned with a thinning value of T=2, then the
+   following sequence numbers would be reported upon: 13,824, 13,828,
+   13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860,
+   13,864.  The thinned trace would be as follows:
+
+      1    1    1    1    1    0    1    1    1    1    0
+
+   This could be encoded as follows:
+
+      bit vector 1111 1011 1100 000
+      null chunk
+
+   The last four bits in the bit vector, representing sequence numbers
+   13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are
+   thus set to zero and are ignored by the receiver.  With thinning, the
+   loss of the 22nd packet goes unreported because its sequence number,
+   13,842, is not a multiple of four.  Packet receipts for all sequence
+   numbers that are not multiples of four also go unreported.  However,
+   in this example thinning has permitted the Loss RLE Report Block to
+   be shortened by one 32 bit word.
+
+   Choice of the thinning value is left to the application.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 13]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   The Loss RLE Report Block has the following format:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     BT=1      | rsvd. |   T   |         block length          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        SSRC of source                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          begin_seq            |             end_seq           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          chunk 1              |             chunk 2           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :                              ...                              :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          chunk n-1            |             chunk n           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   block type (BT): 8 bits
+         A Loss RLE Report Block is identified by the constant 1.
+
+   rsvd.: 4 bits
+         This field is reserved for future definition.  In the absence
+         of such definition, the bits in this field MUST be set to zero
+         and MUST be ignored by the receiver.
+
+   thinning (T): 4 bits
+         The amount of thinning performed on the sequence number space.
+         Only those packets with sequence numbers 0 mod 2^T are reported
+         on by this block.  A value of 0 indicates that there is no
+         thinning, and all packets are reported on.  The maximum
+         thinning is one packet in every 32,768 (amounting to two
+         packets within each 16-bit sequence space).
+
+   block length: 16 bits
+         Defined in Section 3.
+
+   SSRC of source: 32 bits
+         The SSRC of the RTP data packet source being reported upon by
+         this report block.
+
+   begin_seq: 16 bits
+         The first sequence number that this block reports on.
+
+   end_seq: 16 bits
+         The last sequence number that this block reports on plus one.
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 14]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   chunk i: 16 bits
+         There are three chunk types: run length, bit vector, and
+         terminating null, defined in the following sections.  If the
+         chunk is all zeroes, then it is a terminating null chunk.
+         Otherwise, the left most bit of the chunk determines its type:
+         0 for run length and 1 for bit vector.
+
+4.1.1.  Run Length Chunk
+
+    0                   1
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |C|R|        run length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   chunk type (C): 1 bit
+         A zero identifies this as a run length chunk.
+
+   run type (R): 1 bit
+         Zero indicates a run of 0s.  One indicates a run of 1s.
+
+   run length: 14 bits
+         A value between 1 and 16,383.  The value MUST not be zero for a
+         run length chunk (zeroes in both the run type and run length
+         fields would make the chunk a terminating null chunk).  Run
+         lengths of 15 or less MAY be described with a run length chunk
+         despite the fact that they could also be described as part of a
+         bit vector chunk.
+
+4.1.2.  Bit Vector Chunk
+
+    0                   1
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |C|        bit vector           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   chunk type (C): 1 bit
+         A one identifies this as a bit vector chunk.
+
+   bit vector: 15 bits
+         The vector is read from left to right, in order of increasing
+         sequence number (with the appropriate allowance for
+         wraparound).
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 15]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+4.1.3.  Terminating Null Chunk
+
+   This chunk is all zeroes.
+
+    0                   1
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.2.  Duplicate RLE Report Block
+
+   This block type permits per-sequence-number reports on duplicates in
+   a source's RTP packet stream.  Such information can be used for
+   network diagnosis, and provide an alternative to packet losses as a
+   basis for multicast tree topology inference.
+
+   The Duplicate RLE Report Block format is identical to the Loss RLE
+   Report Block format.  Only the interpretation is different, in that
+   the information concerns packet duplicates rather than packet losses.
+   The trace to be encoded in this case also consists of zeros and ones,
+   but a zero here indicates the presence of duplicate packets for a
+   given sequence number, whereas a one indicates that no duplicates
+   were received.
+
+   The existence of a duplicate for a given sequence number is
+   determined over the entire reporting period.  For example, if packet
+   number 12,593 arrives, followed by other packets with other sequence
+   numbers, the arrival later in the reporting period of another packet
+   numbered 12,593 counts as a duplicate for that sequence number.  The
+   duplicate does not need to follow immediately upon the first packet
+   of that number.  Care must be taken that a report does not cover a
+   range of 65,534 or greater in the sequence number space.
+
+   No distinction is made between the existence of a single duplicate
+   packet and multiple duplicate packets for a given sequence number.
+   Note also that since there is no duplicate for a lost packet, a loss
+   is encoded as a one in a Duplicate RLE Report Block.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 16]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   The Duplicate RLE Report Block has the following format:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     BT=2      | rsvd. |   T   |         block length          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        SSRC of source                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          begin_seq            |             end_seq           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          chunk 1              |             chunk 2           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :                              ...                              :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          chunk n-1            |             chunk n           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   block type (BT): 8 bits
+         A Duplicate RLE Report Block is identified by the constant 2.
+
+   rsvd.: 4 bits
+         This field is reserved for future definition.  In the absence
+         of such a definition, the bits in this field MUST be set to
+         zero and MUST be ignored by the receiver.
+
+   thinning (T): 4 bits
+         As defined in Section 4.1.
+
+   block length: 16 bits
+         Defined in Section 3.
+
+   SSRC of source: 32 bits
+         As defined in Section 4.1.
+
+   begin_seq: 16 bits
+         As defined in Section 4.1.
+
+   end_seq: 16 bits
+         As defined in Section 4.1.
+
+   chunk i: 16 bits
+         As defined in Section 4.1.
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 17]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+4.3.  Packet Receipt Times Report Block
+
+   This block type permits per-sequence-number reports on packet receipt
+   times for a given source's RTP packet stream.  Such information can
+   be used for MINC inference of the topology of the multicast tree used
+   to distribute the source's RTP packets, and of the delays along the
+   links within that tree.  It can also be used to measure partial path
+   characteristics and to model distributions for packet jitter.
+
+   Packet receipt times are expressed in the same units as in the RTP
+   timestamps of data packets.  This is so that, for each packet, one
+   can establish both the send time and the receipt time in comparable
+   terms.  Note, however, that as an RTP sender ordinarily initializes
+   its time to a value chosen at random, there can be no expectation
+   that reported send and receipt times will differ by an amount equal
+   to the one-way delay between sender and receiver.  The reported times
+   can nonetheless be useful for the purposes mentioned above.
+
+   At least one packet MUST have been received for each sequence number
+   reported upon in this block.  If this block type is used to report
+   receipt times for a series of sequence numbers that includes lost
+   packets, several blocks are required.  If duplicate packets have been
+   received for a given sequence number, and those packets differ in
+   their receipt times, any time other than the earliest MUST NOT be
+   reported.  This is to ensure consistency among reports.
+
+   Times reported in RTP timestamp format consume more bits than loss or
+   duplicate information, and do not lend themselves to run length
+   encoding.  The use of thinning is encouraged to limit the size of
+   Packet Receipt Times Report Blocks.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 18]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   The Packet Receipt Times Report Block has the following format:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     BT=3      | rsvd. |   T   |         block length          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        SSRC of source                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          begin_seq            |             end_seq           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Receipt time of packet begin_seq                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Receipt time of packet (begin_seq + 1) mod 65536        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :                              ...                              :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Receipt time of packet (end_seq - 1) mod 65536          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   block type (BT): 8 bits
+         A Packet Receipt Times Report Block is identified by the
+         constant 3.
+
+   rsvd.: 4 bits
+         This field is reserved for future definition.  In the absence
+         of such a definition, the bits in this field MUST be set to
+         zero and MUST be ignored by the receiver.
+
+   thinning (T): 4 bits
+         As defined in Section 4.1.
+
+   block length: 16 bits
+         Defined in Section 3.
+
+   SSRC of source: 32 bits
+         As defined in Section 4.1.
+
+   begin_seq: 16 bits
+         As defined in Section 4.1.
+
+   end_seq: 16 bits
+         As defined in Section 4.1.
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 19]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   Packet i receipt time: 32 bits
+         The receipt time of the packet with sequence number i at the
+         receiver.  The modular arithmetic shown in the packet format
+         diagram is to allow for sequence number rollover.  It is
+         preferable for the time value to be established at the link
+         layer interface, or in any case as close as possible to the
+         wire arrival time.  Units and format are the same as for the
+         timestamp in RTP data packets.  As opposed to RTP data packet
+         timestamps, in which nominal values may be used instead of
+         system clock values in order to convey information useful for
+         periodic playout, the receipt times should reflect the actual
+         time as closely as possible.  For a session, if the RTP
+         timestamp is chosen at random, the first receipt time value
+         SHOULD also be chosen at random, and subsequent timestamps
+         offset from this value.  On the other hand, if the RTP
+         timestamp is meant to reflect the reference time at the sender,
+         then the receipt time SHOULD be as close as possible to the
+         reference time at the receiver.
+
+4.4.  Receiver Reference Time Report Block
+
+   This block extends RTCP's timestamp reporting so that non-senders may
+   also send timestamps.  It recapitulates the NTP timestamp fields from
+   the RTCP Sender Report [9, Sec. 6.3.1].  A non-sender may estimate
+   its round trip time (RTT) to other participants, as proposed in [18],
+   by sending this report block and receiving DLRR Report Blocks (see
+   next section) in reply.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     BT=4      |   reserved    |       block length = 2        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              NTP timestamp, most significant word             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             NTP timestamp, least significant word             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   block type (BT): 8 bits
+         A Receiver Reference Time Report Block is identified by the
+         constant 4.
+
+   reserved: 8 bits
+         This field is reserved for future definition.  In the absence
+         of such definition, the bits in this field MUST be set to zero
+         and MUST be ignored by the receiver.
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 20]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   block length: 16 bits
+         The constant 2, in accordance with the definition of this field
+         in Section 3.
+
+   NTP timestamp: 64 bits
+         Indicates the wallclock time when this block was sent so that
+         it may be used in combination with timestamps returned in DLRR
+         Report Blocks (see next section) from other receivers to
+         measure round-trip propagation to those receivers.  Receivers
+         should expect that the measurement accuracy of the timestamp
+         may be limited to far less than the resolution of the NTP
+         timestamp.  The measurement uncertainty of the timestamp is not
+         indicated as it may not be known.  A report block sender that
+         can keep track of elapsed time but has no notion of wallclock
+         time may use the elapsed time since joining the session
+         instead.  This is assumed to be less than 68 years, so the high
+         bit will be zero.  It is permissible to use the sampling clock
+         to estimate elapsed wallclock time.  A report sender that has
+         no notion of wallclock or elapsed time may set the NTP
+         timestamp to zero.
+
+4.5.  DLRR Report Block
+
+   This block extends RTCP's delay since the last Sender Report (DLSR)
+   mechanism [9, Sec. 6.3.1] so that non-senders may also calculate
+   round trip times, as proposed in [18].  It is termed DLRR for delay
+   since the last Receiver Report, and may be sent in response to a
+   Receiver Timestamp Report Block (see previous section) from a
+   receiver to allow that receiver to calculate its round trip time to
+   the respondent.  The report consists of one or more 3 word sub-
+   blocks: one sub-block per Receiver Report.
+
+  0                   1                   2                   3
+  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |     BT=5      |   reserved    |         block length          |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ |                 SSRC_1 (SSRC of first receiver)               | sub-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
+ |                         last RR (LRR)                         |   1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                   delay since last RR (DLRR)                  |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ |                 SSRC_2 (SSRC of second receiver)              | sub-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
+ :                               ...                             :   2
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 21]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   block type (BT): 8 bits
+         A DLRR Report Block is identified by the constant 5.
+
+   reserved: 8 bits
+         This field is reserved for future definition.  In the absence
+         of such definition, the bits in this field MUST be set to zero
+         and MUST be ignored by the receiver.
+
+   block length: 16 bits
+         Defined in Section 3.
+
+   last RR timestamp (LRR): 32 bits
+         The middle 32 bits out of 64 in the NTP timestamp (as explained
+         in the previous section), received as part of a Receiver
+         Reference Time Report Block from participant SSRC_n.  If no
+         such block has been received, the field is set to zero.
+
+   delay since last RR (DLRR): 32 bits
+         The delay, expressed in units of 1/65536 seconds, between
+         receiving the last Receiver Reference Time Report Block from
+         participant SSRC_n and sending this DLRR Report Block.  If a
+         Receiver Reference Time Report Block has yet to be received
+         from SSRC_n, the DLRR field is set to zero (or the DLRR is
+         omitted entirely).  Let SSRC_r denote the receiver issuing this
+         DLRR Report Block.  Participant SSRC_n can compute the round-
+         trip propagation delay to SSRC_r by recording the time A when
+         this Receiver Timestamp Report Block is received.  It
+         calculates the total round-trip time A-LRR using the last RR
+         timestamp (LRR) field, and then subtracting this field to leave
+         the round-trip propagation delay as A-LRR-DLRR.  This is
+         illustrated in [9, Fig. 2].
+
+4.6.  Statistics Summary Report Block
+
+   This block reports statistics beyond the information carried in the
+   standard RTCP packet format, but is not as finely grained as that
+   carried in the report blocks previously described.  Information is
+   recorded about lost packets, duplicate packets, jitter measurements,
+   and TTL or Hop Limit values.  Such information can be useful for
+   network management.
+
+   The report block contents are dependent upon a series of flag bits
+   carried in the first part of the header.  Not all parameters need to
+   be reported in each block.  Flags indicate which are and which are
+   not reported.  The fields corresponding to unreported parameters MUST
+   be present, but are set to zero.  The receiver MUST ignore any
+   Statistics Summary Report Block with a non-zero value in any field
+   flagged as unreported.
+
+
+
+Friedman, et al.            Standards Track                    [Page 22]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   The Statistics Summary Report Block has the following format:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     BT=6      |L|D|J|ToH|rsvd.|       block length = 9        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        SSRC of source                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          begin_seq            |             end_seq           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        lost_packets                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        dup_packets                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         min_jitter                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         max_jitter                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         mean_jitter                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         dev_jitter                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | min_ttl_or_hl | max_ttl_or_hl |mean_ttl_or_hl | dev_ttl_or_hl |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   block type (BT): 8 bits
+         A Statistics Summary Report Block is identified by the constant
+         6.
+
+   loss report flag (L): 1 bit
+         Bit set to 1 if the lost_packets field contains a report, 0
+         otherwise.
+
+   duplicate report flag (D): 1 bit
+         Bit set to 1 if the dup_packets field contains a report, 0
+         otherwise.
+
+   jitter flag (J): 1 bit
+         Bit set to 1 if the min_jitter, max_jitter, mean_jitter, and
+         dev_jitter fields all contain reports, 0 if none of them do.
+
+   TTL or Hop Limit flag (ToH): 2 bits
+         This field is set to 0 if none of the fields min_ttl_or_hl,
+         max_ttl_or_hl, mean_ttl_or_hl, or dev_ttl_or_hl contain
+         reports.  If the field is non-zero, then all of these fields
+         contain reports.  The value 1 signifies that they report on
+         IPv4 TTL values.  The value 2 signifies that they report on
+
+
+
+Friedman, et al.            Standards Track                    [Page 23]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+         IPv6 Hop Limit values.  The value 3 is undefined and MUST NOT
+         be used.
+
+   rsvd.: 3 bits
+         This field is reserved for future definition.  In the absence
+         of such a definition, the bits in this field MUST be set to
+         zero and MUST be ignored by the receiver.
+
+   block length: 16 bits
+         The constant 9, in accordance with the definition of this field
+         in Section 3.
+
+   SSRC of source: 32 bits
+         As defined in Section 4.1.
+
+   begin_seq: 16 bits
+         As defined in Section 4.1.
+
+   end_seq: 16 bits
+         As defined in Section 4.1.
+
+   lost_packets: 32 bits
+         Number of lost packets in the above sequence number interval.
+
+   dup_packets: 32 bits
+         Number of duplicate packets in the above sequence number
+         interval.
+
+   min_jitter: 32 bits
+         The minimum relative transit time between two packets in the
+         above sequence number interval.  All jitter values are measured
+         as the difference between a packet's RTP timestamp and the
+         reporter's clock at the time of arrival, measured in the same
+         units.
+
+   max_jitter: 32 bits
+         The maximum relative transit time between two packets in the
+         above sequence number interval.
+
+   mean_jitter: 32 bits
+         The mean relative transit time between each two packet series
+         in the above sequence number interval, rounded to the nearest
+         value expressible as an RTP timestamp.
+
+   dev_jitter: 32 bits
+         The standard deviation of the relative transit time between
+         each two packet series in the above sequence number interval.
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 24]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   min_ttl_or_hl: 8 bits
+         The minimum TTL or Hop Limit value of data packets in the
+         sequence number range.
+
+   max_ttl_or_hl: 8 bits
+         The maximum TTL or Hop Limit value of data packets in the
+         sequence number range.
+
+   mean_ttl_or_hl: 8 bits
+         The mean TTL or Hop Limit value of data packets in the sequence
+         number range, rounded to the nearest integer.
+
+   dev_ttl_or_hl: 8 bits
+         The standard deviation of TTL or Hop Limit values of data
+         packets in the sequence number range.
+
+4.7.  VoIP Metrics Report Block
+
+   The VoIP Metrics Report Block provides metrics for monitoring voice
+   over IP (VoIP) calls.  These metrics include packet loss and discard
+   metrics, delay metrics, analog metrics, and voice quality metrics.
+   The block reports separately on packets lost on the IP channel, and
+   those that have been received but then discarded by the receiving
+   jitter buffer.  It also reports on the combined effect of losses and
+   discards, as both have equal effect on call quality.
+
+   In order to properly assess the quality of a Voice over IP call, it
+   is desirable to consider the degree of burstiness of packet loss
+   [14].  Following a Gilbert-Elliott model [3], a period of time,
+   bounded by lost and/or discarded packets with a high rate of losses
+   and/or discards, is a "burst", and a period of time between two
+   bursts is a "gap".  Bursts correspond to periods of time during which
+   the packet loss rate is high enough to produce noticeable degradation
+   in audio quality.  Gaps correspond to periods of time during which
+   only isolated lost packets may occur, and in general these can be
+   masked by packet loss concealment.  Delay reports include the transit
+   delay between RTP end points and the VoIP end system processing
+   delays, both of which contribute to the user perceived delay.
+   Additional metrics include signal, echo, noise, and distortion
+   levels.  Call quality metrics include R factors (as described by the
+   E Model defined in [6,3]) and mean opinion scores (MOS scores).
+
+   Implementations MUST provide values for all the fields defined here.
+   For certain metrics, if the value is undefined or unknown, then the
+   specified default or unknown field value MUST be provided.
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 25]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   The block is encoded as seven 32-bit words:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     BT=7      |   reserved    |       block length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        SSRC of source                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   loss rate   | discard rate  | burst density |  gap density  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       burst duration          |         gap duration          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     round trip delay          |       end system delay        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | signal level  |  noise level  |     RERL      |     Gmin      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   R factor    | ext. R factor |    MOS-LQ     |    MOS-CQ     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   RX config   |   reserved    |          JB nominal           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          JB maximum           |          JB abs max           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   block type (BT): 8 bits
+         A VoIP Metrics Report Block is identified by the constant 7.
+
+   reserved: 8 bits
+         This field is reserved for future definition.  In the absence
+         of such a definition, the bits in this field MUST be set to
+         zero and MUST be ignored by the receiver.
+
+   block length: 16 bits
+         The constant 8, in accordance with the definition of this field
+         in Section 3.
+
+   SSRC of source: 32 bits
+         As defined in Section 4.1.
+
+   The remaining fields are described in the following six sections:
+   Packet Loss and Discard Metrics, Delay Metrics, Signal Related
+   Metrics, Call Quality or Transmission Quality Metrics, Configuration
+   Metrics, and Jitter Buffer Parameters.
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 26]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+4.7.1.  Packet Loss and Discard Metrics
+
+   It is very useful to distinguish between packets lost by the network
+   and those discarded due to jitter.  Both have equal effect on the
+   quality of the voice stream, however, having separate counts helps
+   identify the source of quality degradation.  These fields MUST be
+   populated, and MUST be set to zero if no packets have been received.
+
+   loss rate: 8 bits
+         The fraction of RTP data packets from the source lost since the
+         beginning of reception, expressed as a fixed point number with
+         the binary point at the left edge of the field.  This value is
+         calculated by dividing the total number of packets lost (after
+         the effects of applying any error protection such as FEC) by
+         the total number of packets expected, multiplying the result of
+         the division by 256, limiting the maximum value to 255 (to
+         avoid overflow), and taking the integer part.  The numbers of
+         duplicated packets and discarded packets do not enter into this
+         calculation.  Since receivers cannot be required to maintain
+         unlimited buffers, a receiver MAY categorize late-arriving
+         packets as lost.  The degree of lateness that triggers a loss
+         SHOULD be significantly greater than that which triggers a
+         discard.
+
+   discard rate: 8 bits
+         The fraction of RTP data packets from the source that have been
+         discarded since the beginning of reception, due to late or
+         early arrival, under-run or overflow at the receiving jitter
+         buffer.  This value is expressed as a fixed point number with
+         the binary point at the left edge of the field.  It is
+         calculated by dividing the total number of packets discarded
+         (excluding duplicate packet discards) by the total number of
+         packets expected, multiplying the result of the division by
+         256, limiting the maximum value to 255 (to avoid overflow), and
+         taking the integer part.
+
+4.7.2.  Burst Metrics
+
+   A burst is a period during which a high proportion of packets are
+   either lost or discarded due to late arrival.  A burst is defined, in
+   terms of a value Gmin, as the longest sequence that (a) starts with a
+   lost or discarded packet, (b) does not contain any occurrences of
+   Gmin or more consecutively received (and not discarded) packets, and
+   (c) ends with a lost or discarded packet.
+
+   A gap, informally, is a period of low packet losses and/or discards.
+   Formally, a gap is defined as any of the following: (a) the period
+   from the start of an RTP session to the receipt time of the last
+
+
+
+Friedman, et al.            Standards Track                    [Page 27]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   received packet before the first burst, (b) the period from the end
+   of the last burst to either the time of the report or the end of the
+   RTP session, whichever comes first, or (c) the period of time between
+   two bursts.
+
+   For the purpose of determining if a lost or discarded packet near the
+   start or end of an RTP session is within a gap or a burst, it is
+   assumed that the RTP session is preceded and followed by at least
+   Gmin received packets, and that the time of the report is followed by
+   at least Gmin received packets.
+
+   A gap has the property that any lost or discarded packets within the
+   gap must be preceded and followed by at least Gmin packets that were
+   received and not discarded.  This gives a maximum loss/discard rate
+   within a gap of: 1 / (Gmin + 1).
+
+   A Gmin value of 16 is RECOMMENDED, as it results in gap
+   characteristics that correspond to good quality (i.e., low packet
+   loss rate, a minimum distance of 16 received packets between lost
+   packets), and hence differentiates nicely between good and poor
+   quality periods.
+
+   For example, a 1 denotes a received packet, 0 a lost packet, and X a
+   discarded packet in the following pattern covering 64 packets:
+
+      11110111111111111111111X111X1011110111111111111111111X111111111
+      |---------gap----------|--burst---|------------gap------------|
+
+   The burst consists of the twelve packets indicated above, starting at
+   a discarded packet and ending at a lost packet.  The first gap starts
+   at the beginning of the session and the second gap ends at the time
+   of the report.
+
+   If the packet spacing is 10 ms and the Gmin value is the recommended
+   value of 16, the burst duration is 120 ms, the burst density 0.33,
+   the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04.
+
+   This would result in reported values as follows (see field
+   descriptions for semantics and details on how these are calculated):
+
+      loss rate             12, which corresponds to 5%
+      discard rate          12, which corresponds to 5%
+      burst density         84, which corresponds to 33%
+      gap density           10, which corresponds to 4%
+      burst duration       120, value in milliseconds
+      gap duration         520, value in milliseconds
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 28]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   burst density: 8 bits
+         The fraction of RTP data packets within burst periods since the
+         beginning of reception that were either lost or discarded.
+         This value is expressed as a fixed point number with the binary
+         point at the left edge of the field.  It is calculated by
+         dividing the total number of packets lost or discarded
+         (excluding duplicate packet discards) within burst periods by
+         the total number of packets expected within the burst periods,
+         multiplying the result of the division by 256, limiting the
+         maximum value to 255 (to avoid overflow), and taking the
+         integer part.  This field MUST be populated and MUST be set to
+         zero if no packets have been received.
+
+   gap density: 8 bits
+         The fraction of RTP data packets within inter-burst gaps since
+         the beginning of reception that were either lost or discarded.
+         The value is expressed as a fixed point number with the binary
+         point at the left edge of the field.  It is calculated by
+         dividing the total number of packets lost or discarded
+         (excluding duplicate packet discards) within gap periods by the
+         total number of packets expected within the gap periods,
+         multiplying the result of the division by 256, limiting the
+         maximum value to 255 (to avoid overflow), and taking the
+         integer part.  This field MUST be populated and MUST be set to
+         zero if no packets have been received.
+
+   burst duration: 16 bits
+         The mean duration, expressed in milliseconds, of the burst
+         periods that have occurred since the beginning of reception.
+         The duration of each period is calculated based upon the
+         packets that mark the beginning and end of that period.  It is
+         equal to the timestamp of the end packet, plus the duration of
+         the end packet, minus the timestamp of the beginning packet.
+         If the actual values are not available, estimated values MUST
+         be used.  If there have been no burst periods, the burst
+         duration value MUST be zero.
+
+   gap duration: 16 bits
+         The mean duration, expressed in milliseconds, of the gap
+         periods that have occurred since the beginning of reception.
+         The duration of each period is calculated based upon the packet
+         that marks the end of the prior burst and the packet that marks
+         the beginning of the subsequent burst.  It is equal to the
+         timestamp of the subsequent burst packet, minus the timestamp
+         of the prior burst packet, plus the duration of the prior burst
+         packet.  If the actual values are not available, estimated
+         values MUST be used.  In the case of a gap that occurs at the
+         beginning of reception, the sum of the timestamp of the prior
+
+
+
+Friedman, et al.            Standards Track                    [Page 29]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+         burst packet and the duration of the prior burst packet are
+         replaced by the reception start time.  In the case of a gap
+         that occurs at the end of reception, the timestamp of the
+         subsequent burst packet is replaced by the reception end time.
+         If there have been no gap periods, the gap duration value MUST
+         be zero.
+
+4.7.3.  Delay Metrics
+
+   For the purpose of the following definitions, the RTP interface is
+   the interface between the RTP instance and the voice application
+   (i.e., FEC, de-interleaving, de-multiplexing, jitter buffer).  For
+   example, the time delay due to RTP payload multiplexing would be
+   considered part of the voice application or end-system delay, whereas
+   delay due to multiplexing RTP frames within a UDP frame would be
+   considered part of the RTP reported delay.  This distinction is
+   consistent with the use of RTCP for delay measurements.
+
+   round trip delay: 16 bits
+         The most recently calculated round trip time between RTP
+         interfaces, expressed in milliseconds.  This value MAY be
+         measured using RTCP, the DLRR method defined in Section 4.5 of
+         this document, where it is necessary to convert the units of
+         measurement from NTP timestamp values to milliseconds, or other
+         approaches.  If RTCP is used, then the reported delay value is
+         the time of receipt of the most recent RTCP packet from source
+         SSRC, minus the LSR (last SR) time reported in its SR (Sender
+         Report), minus the DLSR (delay since last SR) reported in its
+         SR.  A non-zero LSR value is required in order to calculate
+         round trip delay.  A value of 0 is permissible; however, this
+         field MUST be populated as soon as a delay estimate is
+         available.
+
+   end system delay: 16 bits
+         The most recently estimated end system delay, expressed in
+         milliseconds.  End system delay is defined as the sum of the
+         total sample accumulation and encoding delay associated with
+         the sending direction and the jitter buffer, decoding, and
+         playout buffer delay associated with the receiving direction.
+         This delay MAY be estimated or measured.  This value SHOULD be
+         provided in all VoIP metrics reports.  If an implementation is
+         unable to provide the data, the value 0 MUST be used.
+
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 30]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   Note that the one way symmetric VoIP segment delay may be calculated
+   from the round trip and end system delays is as follows; if the round
+   trip delay is denoted, RTD and the end system delays associated with
+   the two endpoints are ESD(A) and ESD(B) then:
+
+    one way symmetric voice path delay  =  ( RTD + ESD(A) + ESD(B) ) / 2
+
+4.7.4.  Signal Related Metrics
+
+   The following metrics are intended to provide real time information
+   related to the non-packet elements of the voice over IP system to
+   assist with the identification of problems affecting call quality.
+   The values identified below must be determined for the received audio
+   signal.  The information required to populate these fields may not be
+   available in all systems, although it is strongly recommended that
+   this data SHOULD be provided to support problem diagnosis.
+
+   signal level: 8 bits
+         The voice signal relative level is defined as the ratio of the
+         signal level to a 0 dBm0 reference [10], expressed in decibels
+         as a signed integer in two's complement form.  This is measured
+         only for packets containing speech energy.  The intent of this
+         metric is not to provide a precise measurement of the signal
+         level but to provide a real time indication that the signal
+         level may be excessively high or low.
+
+         signal level = 10 Log10 ( rms talkspurt power (mW) )
+
+         A value of 127 indicates that this parameter is unavailable.
+         Typical values should generally be in the -15 to -20 dBm range.
+
+   noise level: 8 bits
+         The noise level is defined as the ratio of the silent period
+         background noise level to a 0 dBm0 reference, expressed in
+         decibels as a signed integer in two's complement form.
+
+         noise level = 10 Log10 ( rms silence power (mW) )
+
+         A value of 127 indicates that this parameter is unavailable.
+
+   residual echo return loss (RERL): 8 bits
+         The residual echo return loss value may be measured directly by
+         the VoIP end system's echo canceller or may be estimated by
+         adding the echo return loss (ERL) and echo return loss
+         enhancement (ERLE) values reported by the echo canceller.
+
+         RERL(dB) = ERL (dB) + ERLE (dB)
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 31]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+         In the case of a VoIP gateway, the source of echo is typically
+         line echo that occurs at 2-4 wire conversion points in the
+         network.  This can be in the 8-12 dB range.  A line echo
+         canceler can provide an ERLE of 30 dB or more and hence reduce
+         this to 40-50 dB.  In the case of an IP phone, this could be
+         acoustic coupling between handset speaker and microphone or
+         residual acoustic echo from speakerphone operation, and may
+         more correctly be termed terminal coupling loss (TCL).  A
+         typical handset would result in 40-50 dB of echo loss due to
+         acoustic feedback.
+
+         Examples:
+
+         -  IP gateway connected to circuit switched network with 2 wire
+            loop.  Without echo cancellation, typical 2-4 wire converter
+            ERL of 12 dB.  RERL = ERL + ERLE = 12 + 0 = 12 dB.
+
+         -  IP gateway connected to circuit switched network with 2 wire
+            loop.  With echo canceler that improves echo by 30 dB.
+            RERL = ERL + ERLE = 12 + 30 = 42 dB.
+
+         -  IP phone with conventional handset.  Acoustic coupling from
+            handset speaker to microphone (terminal coupling loss) is
+            typically 40 dB.  RERL = TCL = 40 dB.
+
+         If we denote the local end of the VoIP path as A and the remote
+         end as B, and if the sender loudness rating (SLR) and receiver
+         loudness rating (RLR) are known for A (default values 8 dB and
+         2 dB respectively), then the echo loudness level at end A
+         (talker echo loudness rating or TELR) is given by:
+
+         TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)
+
+         TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)
+
+         Hence, in order to incorporate echo into a voice quality
+         estimate at the A end of a VoIP connection, it is desirable to
+         send the ERL + ERLE value from B to A using a format such as
+         RTCP XR.
+
+         Echo related information may not be available in all VoIP end
+         systems.  As echo does have a significant effect on
+         conversational quality, it is recommended that estimated values
+         for echo return loss and terminal coupling loss be provided (if
+         sensible estimates can be reasonably determined).
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 32]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+         Typical values for end systems are given below to provide
+         guidance:
+
+         -  IP Phone with handset: typically 45 dB.
+
+         -  PC softphone or speakerphone: extremely variable, consider
+            reporting "undefined" (127).
+
+         -  IP gateway with line echo canceller: typically has ERL and
+            ERLE available.
+
+         -  IP gateway without line echo canceller: frequently a source
+            of echo related problems, consider reporting either a low
+            value (12 dB) or "undefined" (127).
+
+   Gmin
+         See Configuration Parameters (Section 4.7.6, below).
+
+4.7.5.  Call Quality or Transmission Quality Metrics
+
+   The following metrics are direct measures of the call quality or
+   transmission quality, and incorporate the effects of codec type,
+   packet loss, discard, burstiness, delay etc.  These metrics may not
+   be available in all systems, however, they SHOULD be provided in
+   order to support problem diagnosis.
+
+   R factor: 8 bits
+         The R factor is a voice quality metric describing the segment
+         of the call that is carried over this RTP session.  It is
+         expressed as an integer in the range 0 to 100, with a value of
+         94 corresponding to "toll quality" and values of 50 or less
+         regarded as unusable.  This metric is defined as including the
+         effects of delay, consistent with ITU-T G.107 [6] and ETSI TS
+         101 329-5 [3].
+
+         A value of 127 indicates that this parameter is unavailable.
+         Values other than 127 and the valid range defined above MUST
+         not be sent and MUST be ignored by the receiving system.
+
+   ext. R factor: 8 bits
+         The external R factor is a voice quality metric describing the
+         segment of the call that is carried over a network segment
+         external to the RTP segment, for example a cellular network.
+         Its values are interpreted in the same manner as for the RTP R
+         factor.  This metric is defined as including the effects of
+         delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5
+         [3], and relates to the outward voice path from the Voice over
+         IP termination for which this metrics block applies.
+
+
+
+Friedman, et al.            Standards Track                    [Page 33]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+         A value of 127 indicates that this parameter is unavailable.
+         Values other than 127 and the valid range defined above MUST
+         not be sent and MUST be ignored by the receiving system.
+
+   Note that an overall R factor may be estimated from the RTP segment R
+   factor and the external R factor, as follows:
+
+   R total = RTP R factor + ext. R factor - 94
+
+   MOS-LQ: 8 bits
+         The estimated mean opinion score for listening quality (MOS-LQ)
+         is a voice quality metric on a scale from 1 to 5, in which 5
+         represents excellent and 1 represents unacceptable.  This
+         metric is defined as not including the effects of delay and can
+         be compared to MOS scores obtained from listening quality (ACR)
+         tests.  It is expressed as an integer in the range 10 to 50,
+         corresponding to MOS x 10.  For example, a value of 35 would
+         correspond to an estimated MOS score of 3.5.
+
+         A value of 127 indicates that this parameter is unavailable.
+         Values other than 127 and the valid range defined above MUST
+         not be sent and MUST be ignored by the receiving system.
+
+   MOS-CQ: 8 bits
+         The estimated mean opinion score for conversational quality
+         (MOS-CQ) is defined as including the effects of delay and other
+         effects that would affect conversational quality.  The metric
+         may be calculated by converting an R factor determined
+         according to ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an
+         estimated MOS using the equation specified in G.107.  It is
+         expressed as an integer in the range 10 to 50, corresponding to
+         MOS x 10, as for MOS-LQ.
+
+         A value of 127 indicates that this parameter is unavailable.
+         Values other than 127 and the valid range defined above MUST
+         not be sent and MUST be ignored by the receiving system.
+
+4.7.6.  Configuration Parameters
+
+   Gmin: 8 bits
+         The gap threshold.  This field contains the value used for this
+         report block to determine if a gap exists.  The recommended
+         value of 16 corresponds to a burst period having a minimum
+         density of 6.25% of lost or discarded packets, which may cause
+         noticeable degradation in call quality; during gap periods, if
+         packet loss or discard occurs, each lost or discarded packet
+         would be preceded by and followed by a sequence of at least 16
+         received non-discarded packets.  Note that lost or discarded
+
+
+
+Friedman, et al.            Standards Track                    [Page 34]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+         packets that occur within Gmin packets of a report being
+         generated may be reclassified as part of a burst or gap in
+         later reports.  ETSI TS 101 329-5 [3] defines a computationally
+         efficient algorithm for measuring burst and gap density using a
+         packet loss/discard event driven approach.  This algorithm is
+         reproduced in Appendix A.2 of the present document.  Gmin MUST
+         not be zero, MUST be provided, and MUST remain constant across
+         VoIP Metrics report blocks for the duration of the RTP session.
+
+   receiver configuration byte (RX config): 8 bits
+         This byte consists of the following fields:
+
+             0 1 2 3 4 5 6 7
+            +-+-+-+-+-+-+-+-+
+            |PLC|JBA|JB rate|
+            +-+-+-+-+-+-+-+-+
+
+   packet loss concealment (PLC): 2 bits
+         Standard (11) / enhanced (10) / disabled (01) / unspecified
+         (00).  When PLC = 11, then a simple replay or interpolation
+         algorithm is being used to fill-in the missing packet; this
+         approach is typically able to conceal isolated lost packets at
+         low packet loss rates.  When PLC = 10, then an enhanced
+         interpolation algorithm is being used; algorithms of this type
+         are able to conceal high packet loss rates effectively.  When
+         PLC = 01, then silence is being inserted in place of lost
+         packets.  When PLC = 00, then no information is available
+         concerning the use of PLC; however, for some codecs this may be
+         inferred.
+
+   jitter buffer adaptive (JBA): 2 bits
+         Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown
+         (00).  When the jitter buffer is adaptive, then its size is
+         being dynamically adjusted to deal with varying levels of
+         jitter.  When non-adaptive, the jitter buffer size is
+         maintained at a fixed level.  When either adaptive or non-
+         adaptive modes are specified, then the jitter buffer size
+         parameters below MUST be specified.
+
+   jitter buffer rate (JB rate): 4 bits
+         J = adjustment rate (0-15).  This represents the implementation
+         specific adjustment rate of a jitter buffer in adaptive mode.
+         This parameter is defined in terms of the approximate time
+         taken to fully adjust to a step change in peak to peak jitter
+         from 30 ms to 100 ms such that:
+
+         adjustment time = 2 * J * frame size (ms)
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 35]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+         This parameter is intended only to provide a guide to the
+         degree of "aggressiveness" of an adaptive jitter buffer and may
+         be estimated.  A value of 0 indicates that the adjustment time
+         is unknown for this implementation.
+
+   reserved: 8 bits
+         This field is reserved for future definition.  In the absence
+         of such a definition, the bits in this field MUST be set to
+         zero and MUST be ignored by the receiver.
+
+4.7.7.  Jitter Buffer Parameters
+
+   The values reported in these fields SHOULD be the most recently
+   obtained values at the time of reporting.
+
+   jitter buffer nominal delay (JB nominal): 16 bits
+         This is the current nominal jitter buffer delay in
+         milliseconds, which corresponds to the nominal jitter buffer
+         delay for packets that arrive exactly on time.  This parameter
+         MUST be provided for both fixed and adaptive jitter buffer
+         implementations.
+
+   jitter buffer maximum delay (JB maximum): 16 bits
+         This is the current maximum jitter buffer delay in milliseconds
+         which corresponds to the earliest arriving packet that would
+         not be discarded.  In simple queue implementations this may
+         correspond to the nominal size.  In adaptive jitter buffer
+         implementations, this value may dynamically vary up to JB abs
+         max (see below).  This parameter MUST be provided for both
+         fixed and adaptive jitter buffer implementations.
+
+   jitter buffer absolute maximum delay (JB abs max): 16 bits
+         This is the absolute maximum delay in milliseconds that the
+         adaptive jitter buffer can reach under worst case conditions.
+         If this value exceeds 65535 milliseconds, then this field SHALL
+         convey the value 65535.  This parameter MUST be provided for
+         adaptive jitter buffer implementations and its value MUST be
+         set to JB maximum for fixed jitter buffer implementations.
+
+5.  SDP Signaling
+
+   This section defines Session Description Protocol (SDP) [4] signaling
+   for XR blocks that can be employed by applications that utilize SDP.
+   This signaling is defined to be used either by applications that
+   implement the SDP Offer/Answer model [8] or by applications that use
+   SDP to describe media and transport configurations in connection
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 36]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   with such protocols as the Session Announcement Protocol (SAP) [15]
+   or the Real Time Streaming Protocol (RTSP) [17].  There exist other
+   potential signaling methods that are not defined here.
+
+   The XR blocks MAY be used without prior signaling.  This is
+   consistent with the rules governing other RTCP packet types, as
+   described in [9].  An example in which signaling would not be used is
+   an application that always requires the use of one or more XR blocks.
+   However, for applications that are configured at session initiation,
+   the use of some type of signaling is recommended.
+
+   Note that, although the use of SDP signaling for XR blocks may be
+   optional, if used, it MUST be used as defined here.  If SDP signaling
+   is used in an environment where XR blocks are only implemented by
+   some fraction of the participants, the ones not implementing the XR
+   blocks will ignore the SDP attribute.
+
+5.1.  The SDP Attribute
+
+   This section defines one new SDP attribute "rtcp-xr" that can be used
+   to signal participants in a media session that they should use the
+   specified XR blocks.  This attribute can be easily extended in the
+   future with new parameters to cover any new report blocks.
+
+   The RTCP XR blocks SDP attribute is defined below in Augmented
+   Backus-Naur Form (ABNF) [2].  It is both a session and a media level
+   attribute.  When specified at session level, it applies to all media
+   level blocks in the session.  Any media level specification MUST
+   replace a session level specification, if one is present, for that
+   media block.
+
+    rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
+
+     xr-format = pkt-loss-rle
+               / pkt-dup-rle
+               / pkt-rcpt-times
+               / rcvr-rtt
+               / stat-summary
+               / voip-metrics
+               / format-ext
+
+     pkt-loss-rle   = "pkt-loss-rle" ["=" max-size]
+     pkt-dup-rle    = "pkt-dup-rle" ["=" max-size]
+     pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size]
+     rcvr-rtt       = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size]
+     rcvr-rtt-mode  = "all"
+                    / "sender"
+     stat-summary   = "stat-summary" ["=" stat-flag *("," stat-flag)]
+
+
+
+Friedman, et al.            Standards Track                    [Page 37]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+     stat-flag      = "loss"
+                    / "dup"
+                    / "jitt"
+                    / "TTL"
+                    / "HL"
+     voip-metrics   = "voip-metrics"
+     max-size       = 1*DIGIT ; maximum block size in octets
+     DIGIT          = %x30-39
+     format-ext     = non-ws-string
+
+     non-ws-string  = 1*(%x21-FF)
+     CRLF           = %d13.10
+
+   The "rtcp-xr" attribute contains zero, one, or more XR block related
+   parameters.  Each parameter signals functionality for an XR block, or
+   a group of XR blocks.  The attribute is extensible so that parameters
+   can be defined for any future XR block (and a parameter should be
+   defined for every future block).
+
+   Each "rtcp-xr" parameter belongs to one of two categories.  The first
+   category, the unilateral parameters, are for report blocks that
+   simply report on the RTP stream and related metrics.  The second
+   category, collaborative parameters, are for XR blocks that involve
+   actions by more than one party in order to carry out their functions.
+
+   Round trip time (RTT) measurement is an example of collaborative
+   functionality.  An RTP data packet receiver sends a Receiver
+   Reference Time Report Block (Section 4.4).  A participant that
+   receives this block sends a DLRR Report Block (Section 4.5) in
+   response, allowing the receiver to calculate its RTT to that
+   participant.  As this example illustrates, collaborative
+   functionality may be implemented by two or more different XR blocks.
+   The collaborative functionality of several XR blocks may be governed
+   by a single "rtcp-xr" parameter.
+
+   For the unilateral category, this document defines the following
+   parameters.  The parameter names and their corresponding XR formats
+   are as follows:
+
+      Parameter name    XR block (block type and name)
+      --------------    ------------------------------------
+      pkt-loss-rle      1  Loss RLE Report Block
+      pkt-dup-rle       2  Duplicate RLE Report Block
+      pkt-rcpt-times    3  Packet Receipt Times Report Block
+      stat-summary      6  Statistics Summary Report Block
+      voip-metrics      7  VoIP Metrics Report Block
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 38]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   The "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters
+   MAY specify an integer value.  This value indicates the largest size
+   the whole report block SHOULD have in octets.  This shall be seen as
+   an indication that thinning shall be applied if necessary to meet the
+   target size.
+
+   The "stat-summary" parameter contains a list indicating which fields
+   SHOULD be included in the Statistics Summary report blocks that are
+   sent.  The list is a comma separated list, containing one or more
+   field indicators.  The space character (0x20) SHALL NOT be present
+   within the list.  Field indicators represent the flags defined in
+   Section 4.6.  The field indicators and their respective flags are as
+   follows:
+
+      Indicator    Flag
+      ---------    ---------------------------
+      loss         loss report flag (L)
+      dup          duplicate report flag (D)
+      jitt         jitter flag (J)
+      TTL          TTL or Hop Limit flag (ToH)
+      HL           TTL or Hop Limit flag (ToH)
+
+   For "loss", "dup", and "jitt", the presence of the indicator
+   indicates that the corresponding flag should be set to 1 in the
+   Statistics Summary report blocks that are sent.  The presence of
+   "TTL" indicates that the corresponding flag should be set to 1.  The
+   presence of "HL" indicates that the corresponding flag should be set
+   to 2.  The indicators "TTL" and "HL" MUST NOT be signaled together.
+
+   Blocks in the collaborative category are classified as initiator
+   blocks or response blocks.  Signaling SHOULD indicate which
+   participants are required to respond to the initiator block.  A party
+   that wishes to receive response blocks from those participants can
+   trigger this by sending an initiator block.
+
+   The collaborative category currently consists only of one
+   functionality, namely the RTT measurement mechanism for RTP data
+   receivers.  The collective functionality of the Receiver Reference
+   Time Report Block and DLRR Report Block is represented by the "rcvr-
+   rtt" parameter.  This parameter takes as its arguments a mode value
+   and, optionally, a maximum size for the DLRR report block.  The mode
+   value "all" indicates that both RTP data senders and data receivers
+   MAY send DLRR blocks, while the mode value "sender" indicates that
+   only active RTP senders MAY send DLRR blocks, i.e., non RTP senders
+   SHALL NOT send DLRR blocks.  If a maximum size in octets is included,
+   any DLRR Report Blocks that are sent SHALL NOT exceed the specified
+   size.  If size limitations mean that a DLRR Report Block sender
+   cannot report in one block upon all participants from which it has
+
+
+
+Friedman, et al.            Standards Track                    [Page 39]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   received a Receiver Reference Time Report Block then it SHOULD report
+   on participants in a round robin fashion across several report
+   intervals.
+
+   The "rtcp-xr" attributes parameter list MAY be empty.  This is useful
+   in cases in which an application needs to signal that it understands
+   the SDP signaling but does not wish to avail itself of XR
+   functionality.  For example, an application in a SIP controlled
+   session could signal that it wishes to stop using all XR blocks by
+   removing all applicable SDP parameters in a re-INVITE message that it
+   sends.  If XR blocks are not to be used at all from the beginning of
+   a session, it is RECOMMENDED that the "rtcp-xr" attribute not be
+   supplied at all.
+
+   When the "rtcp-xr" attribute is present, participants SHOULD NOT send
+   XR blocks other than the ones indicated by the parameters.  This
+   means that inclusion of a "rtcp-xr" attribute without any parameters
+   tells a participant that it SHOULD NOT send any XR blocks at all.
+   The purpose is to conserve bandwidth.  This is especially important
+   when collaborative parameters are applied to a large multicast group:
+   the sending of an initiator block could potentially trigger responses
+   from all participants.  There are, however, contexts in which it
+   makes sense to send an XR block in the absence of a parameter
+   signaling its use.  For instance, an application might be designed so
+   as to send certain report blocks without negotiation, while using SDP
+   signaling to negotiate the use of other blocks.
+
+5.2.  Usage in Offer/Answer
+
+   In the Offer/Answer context [8], the interpretation of SDP signaling
+   for XR packets depends upon the direction attribute that is signaled:
+   "recvonly", "sendrecv", or "sendonly" [4].  If no direction attribute
+   is supplied, then "sendrecv" is assumed.  This section applies only
+   to unicast media streams, except where noted.  Discussion of
+   unilateral parameters is followed by discussion of collaborative
+   parameters in this section.
+
+   For "sendonly" and "sendrecv" media stream offers that specify
+   unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send
+   the corresponding XR blocks.  For "sendrecv" offers, the answerer MAY
+   include the "rtcp-xr" attribute in its response, and specify any
+   unilateral parameters in order to request that the offerer send the
+   corresponding XR blocks.  The offerer SHOULD send these blocks.
+
+   For "recvonly" media stream offers, the offerer's use of the "rtcp-
+   xr" attribute in connection with unilateral parameters indicates that
+   the offerer is capable of sending the corresponding XR blocks.  If
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 40]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   the answerer responds with an "rtcp-xr" attribute, the offerer SHOULD
+   send XR blocks for each specified unilateral parameter that was in
+   its offer.
+
+   For multicast media streams, the inclusion of an "rtcp-xr" attribute
+   with unilateral parameters means that every media recipient SHOULD
+   send the corresponding XR blocks.
+
+   An SDP offer with a collaborative parameter declares the offerer
+   capable of receiving the corresponding initiator and replying with
+   the appropriate responses.  For example, an offer that specifies the
+   "rcvr-rtt" parameter means that the offerer is prepared to receive
+   Receiver Reference Time Report Blocks and to send DLRR Report Blocks.
+   An offer of a collaborative parameter means that the answerer MAY
+   send the initiator, and, having received the initiator, the offerer
+   SHOULD send the responses.
+
+   There are exceptions to the rule that an offerer of a collaborative
+   parameter should send responses.  For instance, the collaborative
+   parameter might specify a mode that excludes the offerer; or
+   congestion control or maximum transmission unit considerations might
+   militate against the offerer's response.
+
+   By including a collaborative parameter in its answer, the answerer
+   declares its ability to receive initiators and to send responses.
+   The offerer MAY then send initiators, to which the answerer SHOULD
+   reply with responses.  As for the offer of a collaborative parameter,
+   there are exceptions to the rule that the answerer should reply.
+
+   When making an SDP offer of a collaborative parameter for a multicast
+   media stream, the offerer SHOULD specify which participants are to
+   respond to a received initiator.  A participant that is not specified
+   SHOULD NOT send responses.  Otherwise, undue bandwidth might be
+   consumed.  The offer indicates that each participant that is
+   specified SHOULD respond if it receives an initiator.  It also
+   indicates that a specified participant MAY send an initiator block.
+
+   An SDP answer for a multicast media stream SHOULD include all
+   collaborative parameters that are present in the offer and that are
+   supported by the answerer.  It SHOULD NOT include any collaborative
+   parameter that is absent from the offer.
+
+   If a participant receives an SDP offer and understands the "rtcp-xr"
+   attribute but does not wish to implement XR functionality offered,
+   its answer SHOULD include an "rtcp-xr" attribute without parameters.
+   By doing so, the party declares that, at a minimum, is capable of
+   understanding the signaling.
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 41]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+5.3.  Usage Outside of Offer/Answer
+
+   SDP can be employed outside of the Offer/Answer context, for instance
+   for multimedia sessions that are announced through the Session
+   Announcement Protocol (SAP) [15], or streamed through the Real Time
+   Streaming Protocol (RTSP) [17].  The signaling model is simpler, as
+   the sender does not negotiate parameters, but the functionality
+   expected from specifying the "rtcp-xr" attribute is the same as in
+   Offer/Answer.
+
+   When a unilateral parameter is specified for the "rtcp-xr" attribute
+   associated with a media stream, the receiver of that stream SHOULD
+   send the corresponding XR block.  When a collaborative parameter is
+   specified, only the participants indicated by the mode value in the
+   collaborative parameter are concerned.  Each such participant that
+   receives an initiator block SHOULD send the corresponding response
+   block.  Each such participant MAY also send initiator blocks.
+
+6.  IANA Considerations
+
+   This document defines a new RTCP packet type, the Extended Report
+   (XR) type, within the existing Internet Assigned Numbers Authority
+   (IANA) registry of RTP RTCP Control Packet Types.  This document also
+   defines a new IANA registry: the registry of RTCP XR Block Types.
+   Within this new registry, this document defines an initial set of
+   seven block types and describes how the remaining types are to be
+   allocated.
+
+   Further, this document defines a new SDP attribute, "rtcp-xr", within
+   the existing IANA registry of SDP Parameters.  It defines a new IANA
+   registry, the registry of RTCP XR SDP Parameters, and an initial set
+   of six parameters, and describes how additional parameters are to be
+   allocated.
+
+6.1.  XR Packet Type
+
+   The XR packet type defined by this document is registered with the
+   IANA as packet type 207 in the registry of RTP RTCP Control Packet
+   types (PT).
+
+6.2.  RTCP XR Block Type Registry
+
+   This document creates an IANA registry called the RTCP XR Block Type
+   Registry to cover the name space of the Extended Report block type
+   (BT) field specified in Section 3.  The BT field contains eight bits,
+   allowing 256 values.  The RTCP XR Block Type Registry is to be
+   managed by the IANA according to the Specification Required policy of
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 42]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   RFC 2434 [7].  Future specifications SHOULD attribute block type
+   values in strict numeric order following the values attributed in
+   this document:
+
+      BT  name
+      --  ----
+       1  Loss RLE Report Block
+       2  Duplicate RLE Report Block
+       3  Packet Receipt Times Report Block
+       4  Receiver Reference Time Report Block
+       5  DLRR Report Block
+       6  Statistics Summary Report Block
+       7  VoIP Metrics Report Block
+
+      The BT value 255 is reserved for future extensions.
+
+   Furthermore, future specifications SHOULD avoid the value 0.  Doing
+   so facilitates packet validity checking, since an all-zeros field
+   might commonly be found in an ill-formed packet.
+
+   Any registration MUST contain the following information:
+
+   -  Contact information of the one doing the registration, including
+      at least name, address, and email.
+
+   -  The format of the block type being registered, consistent with the
+      extended report block format described in Section 3.
+
+   -  A description of what the block type represents and how it shall
+      be interpreted, detailing this information for each of its fields.
+
+6.3.  The "rtcp-xr" SDP Attribute
+
+   The SDP attribute "rtcp-xr" defined by this document is registered
+   with the IANA registry of SDP Parameters as follows:
+
+   SDP Attribute ("att-field"):
+
+     Attribute name:     rtcp-xr
+     Long form:          RTP Control Protocol Extended Report Parameters
+     Type of name:       att-field
+     Type of attribute:  session and media level
+     Subject to charset: no
+     Purpose:            see Section 5 of this document
+     Reference:          this document
+     Values:             see this document and registrations below
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 43]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   The attribute has an extensible parameter field and therefore a
+   registry for these parameters is required.  This document creates an
+   IANA registry called the RTCP XR SDP Parameters Registry.  It
+   contains the six parameters defined in Section 5.1: "pkt-loss-rle",
+   "pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and
+   "recv-rtt".
+
+   Additional parameters are to be added to this registry in accordance
+   with the Specification Required policy of RFC 2434 [7].  Any
+   registration MUST contain the following information:
+
+   -  Contact information of the one doing the registration, including
+      at least name, address, and email.
+
+   -  An Augmented Backus-Naur Form (ABNF) [2] definition of the
+      parameter, in accordance with the "format-ext" definition of
+      Section 5.1.
+
+   -  A description of what the parameter represents and how it shall be
+      interpreted, both normally and in Offer/Answer.
+
+7.  Security Considerations
+
+   This document extends the RTCP reporting mechanism.  The security
+   considerations that apply to RTCP reports [9, Appendix B] also apply
+   to XR reports.  This section details the additional security
+   considerations that apply to the extensions.
+
+   The extensions introduce heightened confidentiality concerns.
+   Standard RTCP reports contain a limited number of summary statistics.
+   The information contained in XR reports is both more detailed and
+   more extensive (covering a larger number of parameters).  The per-
+   packet report blocks and the VoIP Metrics Report Block provide
+   examples.
+
+   The per-packet information contained in Loss RLE, Duplicate RLE, and
+   Packet Receipt Times Report Blocks facilitates multicast inference of
+   network characteristics (MINC) [11].  Such inference can reveal the
+   gross topology of a multicast distribution tree, as well as
+   parameters, such as the loss rates and delays, along paths between
+   branching points in that tree.  Such information might be considered
+   sensitive to autonomous system administrators.
+
+   The VoIP Metrics Report Block provides information on the quality of
+   ongoing voice calls.  Though such information might be carried in an
+   application specific format in standard RTP sessions, making it
+   available in a standard format here makes it more available to
+   potential eavesdroppers.
+
+
+
+Friedman, et al.            Standards Track                    [Page 44]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   No new mechanisms are introduced in this document to ensure
+   confidentiality.  Encryption procedures, such as those being
+   suggested for a Secure RTCP (SRTCP) [12] at the time that this
+   document was written, can be used when confidentiality is a concern
+   to end hosts.  Given that RTCP traffic can be encrypted by the end
+   hosts, autonomous systems must be prepared for the fact that certain
+   aspects of their network topology can be revealed.
+
+   Any encryption or filtering of XR report blocks entails a loss of
+   monitoring information to third parties.  For example, a network that
+   establishes a tunnel to encrypt VoIP Report Blocks denies that
+   information to the service providers traversed by the tunnel.  The
+   service providers cannot then monitor or respond to the quality of
+   the VoIP calls that they carry, potentially creating problems for the
+   network's users.  As a default, XR packets should not be encrypted or
+   filtered.
+
+   The extensions also make certain denial of service attacks easier.
+   This is because of the potential to create RTCP packets much larger
+   than average with the per packet reporting capabilities of the Loss
+   RLE, Duplicate RLE, and Timestamp Report Blocks.  Because of the
+   automatic bandwidth adjustment mechanisms in RTCP, if some session
+   participants are sending large RTCP packets, all participants will
+   see their RTCP reporting intervals lengthened, meaning they will be
+   able to report less frequently.  To limit the effects of large
+   packets, even in the absence of denial of service attacks,
+   applications SHOULD place an upper limit on the size of the XR report
+   blocks they employ.  The "thinning" techniques described in Section
+   4.1 permit the packet-by-packet report blocks to adhere to a
+   predefined size limit.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 45]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+A.  Algorithms
+
+A.1.  Sequence Number Interpretation
+
+   This is the algorithm suggested by Section 4.1 for keeping track of
+   the sequence numbers from a given sender.  It implements the
+   accounting practice required for the generation of Loss RLE Report
+   Blocks.
+
+   This algorithm keeps track of 16 bit sequence numbers by translating
+   them into a 32 bit sequence number space.  The first packet received
+   from a source is considered to have arrived roughly in the middle of
+   that space.  Each packet that follows is placed either ahead of or
+   behind the prior one in this 32 bit space, depending upon which
+   choice would place it closer (or, in the event of a tie, which choice
+   would not require a rollover in the 16 bit sequence number).
+
+   // The reference sequence number is an extended sequence number
+   // that serves as the basis for determining whether a new 16 bit
+   // sequence number comes earlier or later in the 32 bit sequence
+   // space.
+   u_int32 _src_ref_seq;
+   bool    _uninitialized_src_ref_seq;
+
+   // Place seq into a 32-bit sequence number space based upon a
+   // heuristic for its most likely location.
+   u_int32 extend_seq(const u_int16 seq) {
+
+           u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b;
+           if(_uninitialized_src_ref_seq) {
+
+                   // This is the first sequence number received.  Place
+                   // it in the middle of the extended sequence number
+                   // space.
+                   _src_ref_seq                = seq | 0x80000000u;
+                   _uninitialized_src_ref_seq  = false;
+                   extended_seq                = _src_ref_seq;
+           }
+           else {
+
+                   // Prior sequence numbers have been received.
+                   // Propose two candidates for the extended sequence
+                   // number: seq_a is without wraparound, seq_b with
+                   // wraparound.
+                   seq_a = seq | (_src_ref_seq & 0xFFFF0000u);
+                   if(_src_ref_seq < seq_a) {
+                           seq_b  = seq_a - 0x00010000u;
+                           diff_a = seq_a - _src_ref_seq;
+
+
+
+Friedman, et al.            Standards Track                    [Page 46]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+                           diff_b = _src_ref_seq - seq_b;
+                   }
+                   else {
+                           seq_b  = seq_a + 0x00010000u;
+                           diff_a = _src_ref_seq - seq_a;
+                           diff_b = seq_b - _src_ref_seq;
+                   }
+
+                   // Choose the closer candidate.  If they are equally
+                   // close, the choice is somewhat arbitrary: we choose
+                   // the candidate for which no rollover is necessary.
+                   if(diff_a < diff_b) {
+                           extended_seq = seq_a;
+                   }
+                   else {
+                           extended_seq = seq_b;
+                   }
+
+                   // Set the reference sequence number to be this most
+                   // recently-received sequence number.
+                   _src_ref_seq = extended_seq;
+           }
+
+           // Return our best guess for a 32-bit sequence number that
+           // corresponds to the 16-bit number we were given.
+           return extended_seq;
+   }
+
+A.2.  Example Burst Packet Loss Calculation.
+
+   This is an algorithm for measuring the burst characteristics for the
+   VoIP Metrics Report Block (Section 4.7).  The algorithm, which has
+   been verified against a working implementation for correctness, is
+   reproduced from ETSI TS 101 329-5 [3].  The algorithm, as described
+   here, takes precedence over any change that might eventually be made
+   to the algorithm in future ETSI documents.
+
+   This algorithm is event driven and hence extremely computationally
+   efficient.
+
+   Given the following definition of states:
+
+      state 1 = received a packet during a gap
+      state 2 = received a packet during a burst
+      state 3 = lost a packet during a burst
+      state 4 = lost an isolated packet during a gap
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 47]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   The "c" variables below correspond to state transition counts, i.e.,
+   c14 is the transition from state 1 to state 4.  It is possible to
+   infer one of a pair of state transition counts to an accuracy of 1
+   which is generally sufficient for this application.
+
+   "pkt" is the count of packets received since the last packet was
+   declared lost or discarded, and "lost" is the number of packets lost
+   within the current burst.  "packet_lost" and "packet_discarded" are
+   Boolean variables that indicate if the event that resulted in this
+   function being invoked was a lost or discarded packet.
+
+   if(packet_lost) {
+           loss_count++;
+   }
+   if(packet_discarded) {
+           discard_count++;
+   }
+   if(!packet_lost && !packet_discarded) {
+           pkt++;
+   }
+   else {
+           if(pkt >= gmin) {
+                   if(lost == 1) {
+                           c14++;
+                   }
+                   else {
+                           c13++;
+                   }
+                   lost = 1;
+                   c11 += pkt;
+           }
+           else {
+                   lost++;
+                   if(pkt == 0) {
+                           c33++;
+                   }
+                   else {
+                           c23++;
+                           c22 += (pkt - 1);
+                   }
+           }
+           pkt = 0;
+   }
+
+   At each reporting interval the burst and gap metrics can be
+   calculated as follows.
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 48]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   // Calculate additional transition counts.
+   c31 = c13;
+   c32 = c23;
+   ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33;
+
+   // Calculate burst and densities.
+   p32 = c32 / (c31 + c32 + c33);
+   if((c22 + c23) < 1) {
+           p23 = 1;
+   }
+   else {
+           p23 = 1 - c22/(c22 + c23);
+   }
+   burst_density = 256 * p23 / (p23 + p32);
+   gap_density = 256 * c14 / (c11 + c14);
+
+   // Calculate burst and gap durations in ms
+   m = frameDuration_in_ms * framesPerRTPPkt;
+   gap_length = (c11 + c14 + c13) * m / c13;
+   burst_length = ctotal * m / c13 - lgap;
+
+   /* calculate loss and discard rates */
+   loss_rate = 256 * loss_count / ctotal;
+   discard_rate = 256 * discard_count / ctotal;
+
+Intellectual Property Notice
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP 11 [5].  Copies
+   of claims of rights made available for publication and any assurances
+   of licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 49]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+Acknowledgments
+
+   We thank the following people: Colin Perkins, Steve Casner, and
+   Henning Schulzrinne for their considered guidance; Sue Moon for
+   helping foster collaboration between the authors; Mounir Benzaid for
+   drawing our attention to the reporting needs of MLDA; Dorgham Sisalem
+   and Adam Wolisz for encouraging us to incorporate MLDA block types;
+   and Jose Rey for valuable review of the SDP Signaling section.
+
+Contributors
+
+   The following people are the authors of this document:
+
+     Kevin Almeroth, UCSB
+     Ramon Caceres, IBM Research
+     Alan Clark, Telchemy
+     Robert G. Cole, JHU Applied Physics Laboratory
+     Nick Duffield, AT&T Labs-Research
+     Timur Friedman, Paris 6
+     Kaynam Hedayat, Brix Networks
+     Kamil Sarac, UT Dallas
+     Magnus Westerlund, Ericsson
+
+   The principal people to contact regarding the individual report
+   blocks described in this document are as follows:
+
+   sec. report block                         principal contributors
+   ---- ------------                         ----------------------
+   4.1  Loss RLE Report Block                Friedman, Caceres, Duffield
+   4.2  Duplicate RLE Report Block           Friedman, Caceres, Duffield
+   4.3  Packet Receipt Times Report Block    Friedman, Caceres, Duffield
+   4.4  Receiver Reference Time Report Block Friedman
+   4.5  DLRR Report Block                    Friedman
+   4.6  Statistics Summary Report Block      Almeroth, Sarac
+   4.7  VoIP Metrics Report Block            Clark, Cole, Hedayat
+
+   The principal person to contact regarding the SDP signaling described
+   in this document is Magnus Westerlund.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 50]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+References
+
+Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 2234, November 1997.
+
+   [3]  ETSI, "Quality of Service (QoS) measurement methodologies", ETSI
+        TS 101 329-5 V1.1.1 (2000-11), November 2000.
+
+   [4]  Handley, M. and V. Jacobson, "SDP: Session Description
+        Protocol", RFC 2327, April 1998.
+
+   [5]  Hovey, R. and S. Bradner, "The Organizations Involved in the
+        IETF Standards Process", BCP 11, RFC 2028, October 1996.
+
+   [6]  ITU-T, "The E-Model, a computational model for use in
+        transmission planning", Recommendation G.107, January 2003.
+
+   [7]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [8]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+        the Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+   [9]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
+        "RTP: A Transport Protocol for Real-Time Applications", RFC
+        3550, July 2003.
+
+   [10] TIA/EIA-810-A Transmission Requirements for Narrowband Voice
+        over IP and Voice over PCM Digital Wireline Telephones, December
+        2000.
+
+Informative References
+
+   [11] Adams, A., Bu, T., Caceres, R., Duffield, N.G., Friedman, T.,
+        Horowitz, J., Lo Presti, F., Moon, S.B., Paxson, V. and D.
+        Towsley, "The Use of End-to-End Multicast Measurements for
+        Characterizing Internal Network Behavior", IEEE Communications
+        Magazine, May 2000.
+
+   [12] Baugher, McGrew, Oran, Blom, Carrara, Naslund and Norrman, "The
+        Secure Real-time Transport Protocol", Work in Progress.
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 51]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   [13] Caceres, R., Duffield, N.G. and T. Friedman, "Impromptu
+        measurement infrastructures using RTP", Proc. IEEE Infocom 2002.
+
+   [14] Clark, A.D., "Modeling the Effects of Burst Packet Loss and
+        Recency on Subjective Voice Quality", Proc. IP Telephony
+        Workshop 2001.
+
+   [15] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
+        Protocol", RFC 2974, October 2000.
+
+   [16] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an
+        On-line Database", RFC 3232, January 2002.
+
+   [17] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
+        Protocol (RTSP)", RFC 2326, April 1998.
+
+   [18] Sisalem D. and A. Wolisz, "MLDA: A TCP-friendly Congestion
+        Control Framework for Heterogeneous Multicast Environments",
+        Proc. IWQoS 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 52]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+Authors' Addresses
+
+   Kevin Almeroth
+   Department of Computer Science
+   University of California
+   Santa Barbara, CA 93106 USA
+
+   EMail: almeroth@cs.ucsb.edu
+
+
+   Ramon Caceres
+   IBM Research
+   19 Skyline Drive
+   Hawthorne, NY 10532 USA
+
+   EMail: caceres@watson.ibm.com
+
+
+   Alan Clark
+   Telchemy Incorporated
+   3360 Martins Farm Road, Suite 200
+   Suwanee, GA 30024 USA
+
+   Phone: +1 770 614 6944
+   Fax:   +1 770 614 3951
+   EMail: alan@telchemy.com
+
+
+   Robert G. Cole
+   Johns Hopkins University Applied Physics Laboratory
+   MP2-S170
+   11100 Johns Hopkins Road
+   Laurel, MD 20723-6099 USA
+
+   Phone: +1 443 778 6951
+   EMail: robert.cole@jhuapl.edu
+
+
+   Nick Duffield
+   AT&T Labs-Research
+   180 Park Avenue, P.O. Box 971
+   Florham Park, NJ 07932-0971 USA
+
+   Phone: +1 973 360 8726
+   Fax:   +1 973 360 8050
+   EMail: duffield@research.att.com
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 53]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+   Timur Friedman
+   Universite Pierre et Marie Curie (Paris 6)
+   Laboratoire LiP6-CNRS
+   8, rue du Capitaine Scott
+   75015 PARIS France
+
+   Phone: +33 1 44 27 71 06
+   Fax:   +33 1 44 27 74 95
+   EMail: timur.friedman@lip6.fr
+
+
+   Kaynam Hedayat
+   Brix Networks
+   285 Mill Road
+   Chelmsford, MA 01824 USA
+
+   Phone: +1 978 367 5600
+   Fax:   +1 978 367 5700
+   EMail: khedayat@brixnet.com
+
+
+   Kamil Sarac
+   Department of Computer Science (ES 4.207)
+   Eric Jonsson School of Engineering & Computer Science
+   University of Texas at Dallas
+   Richardson, TX 75083-0688 USA
+
+   Phone: +1 972 883 2337
+   Fax:   +1 972 883 2349
+   EMail: ksarac@utdallas.edu
+
+
+   Magnus Westerlund
+   Ericsson Research
+   Ericsson AB
+   SE-164 80 Stockholm Sweden
+
+   Phone: +46 8 404 82 87
+   Fax:   +46 8 757 55 50
+   EMail: magnus.westerlund@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 54]
+
+RFC 3611                        RTCP XR                    November 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Friedman, et al.            Standards Track                    [Page 55]
+