tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3611

 
 
 

RTP Control Protocol Extended Reports (RTCP XR)

Part 2 of 2, p. 25 to 55
Prev RFC Part

 


prevText      Top      Up      ToC       Page 25 
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.

Top      Up      ToC       Page 26 
   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.

Top      Up      ToC       Page 27 
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

Top      Up      ToC       Page 28 
   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

Top      Up      ToC       Page 29 
   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

Top      Up      ToC       Page 30 
         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.

Top      Up      ToC       Page 31 
   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)

Top      Up      ToC       Page 32 
         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).

Top      Up      ToC       Page 33 
         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.

Top      Up      ToC       Page 34 
         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

Top      Up      ToC       Page 35 
         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)

Top      Up      ToC       Page 36 
         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

Top      Up      ToC       Page 37 
   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)]

Top      Up      ToC       Page 38 
     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

Top      Up      ToC       Page 39 
   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

Top      Up      ToC       Page 40 
   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

Top      Up      ToC       Page 41 
   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.

Top      Up      ToC       Page 42 
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

Top      Up      ToC       Page 43 
   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

Top      Up      ToC       Page 44 
   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.

Top      Up      ToC       Page 45 
   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.

Top      Up      ToC       Page 46 
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;

Top      Up      ToC       Page 47 
                           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

Top      Up      ToC       Page 48 
   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.

Top      Up      ToC       Page 49 
   // 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.

Top      Up      ToC       Page 50 
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.

Top      Up      ToC       Page 51 
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.

Top      Up      ToC       Page 52 
   [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.

Top      Up      ToC       Page 53 
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

Top      Up      ToC       Page 54 
   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

Top      Up      ToC       Page 55 
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.