RFC 3611 - RTP Control Protocol Extended Reports (RTCP XR)(3)

时间:2006-10-21 来源: 作者: 点击:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NTPtimestamp,leastsignificantword| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ blocktype(BT):8bits AReceiverRe
  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             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.

   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
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   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.

   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

         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.

   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.

   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.

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

   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

   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
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容