Subject: [AVT] draft-clark-avt-rtcphr-00.txt

From: Alan Clark <[email-masked]>
Date: Wed, 04 Jan 2006 11:12:33 -0500

The attached draft was submitted last week however does not seem to have 
emerged from the IETF as yet.  This comprises the "high resolution 
metrics" block from the earlier RTCP XRbis draft - which the AVT chairs 
requested be split into several drafts.  

Comments would be welcomed!!

Regards

Alan

Internet Engineering Task Force                                 A. Clark
Internet-Draft                                     Telchemy Incorporated
Expires: 27th June 2006                                     A. Pendleton
                                                                  Nortel
                                                                R. Kumar
                                                           Cisco Systems
                                                           December 2005

             RTCP XR - High Resolution VoIP Metrics Report Blocks
                     draft-clark-avt-rtcphr-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on 27 June 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines extensions to the RTCP XR extended report
   packet type blocks to support Voice over IP (VoIP) monitoring
   for services that require higher resolution or more detailed
   metrics than those supported by RFC3611.

Clark               Expires June 2006                        [Page 1]

draft-clark-avt-rtcphr-00.txt                          December 2005 

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.   Definitions  . . . . . . . . . . . . . . . . . . . . . . . . 2
   3.   High Resolution VoIP Metrics Report Block    . . . . . . . . 4
   4.   RTCP HR Configuration Block  . . . . . . . . . . . . . . . . 17
   5.   Practical applications   . . . . . . . . . . . . . . . . . . 20
   6.   Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   7.   Security Considerations  . . . . . . . . . . . . . . . . . . 20
   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 20
   9.   Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
   10.  Informative References . . . . . . . . . . . . . . . . . . . 21
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 
        Intellectual Property and Copyright Statements . . . . . . . 

1.  Introduction

   This draft defines several new block types to augment those defined
   in RFC3611 for use in Quality of Service reporting for Voice over IP.  
   The new block types support the reporting of metrics to a higher
   resolution to support certain applications, for example carrier
   backbone networks.

   For certain types of VoIP service it is desirable to report VoIP
   performance metrics to a higher resolution than provided in the
   RFC3611 VoIP Metrics block or RFC3550 Receiver Reports. The report
   blocks described in this section provide both interval based and
   cumulative metrics with a higher resolution than that provided in
   the RFC3611 VoIP metrics report block.

   The new block types defined in this draft are the High Resolution
   VoIP Metrics Report Block, and the High Resolution VoIP Metrics
   Configuration Block.

2.  Definitions

   2.1 Local and Remote IP Endpoints

   A report block produced per this draft is normally produced by the
   endpoint of an RTP stream, and relates to the quality of the received
   RTP stream and impairments that may affect the RTP payload. The
   diagram below illustrates the potential end and mid points that may
   be involved in this process.  Within the context of this example, 
   endpoint "C" is the reporting endpoint and the RTCP HR report relates
   to the RTP stream from "B" to "C".  The other points "A", "B" and "D"
   could potentially be generating RTCP XR or RTCP HR reports.

Clark               Expires June 2006                        [Page 2]

draft-clark-avt-rtcphr-00.txt                          December 2005 

       ----------->    --------RTP---------->   ------------->
   <A>             <B>                       <C>              <D> 
       <-----------    <-------RTP----------- | <-------------
                                              |
                       <------RTCP HR---------|

   With respect to RTCP HR report blocks generated by "C" in relation to
   the RTP stream from "B" to "C".

   (i) The term "External" is used to relate to the network connected to
   the other side of "this" endpoint (i.e. to the connection from "C" to
   "D").

   (ii) The Local IP Endpoint is "this" endpoint (i.e. "C")

   (iii) The Remote IP Endpoint is the source for the RTP stream
   terminated at this endpoint, and for which packet/frame related
   metrics apply. (i.e. "B")

   (iv) The Remote External Endpoint is the remote endpoint on the
   "external" side of this endpoint (i.e. "D").

   (v) The endpoint on the external side of the Remote IP Endpoint (i.e.
   "A") does not have a specific term applied to it, however note that
   some metrics may apply to the "A" to "B" connection.

   If this model is applied to a trunking gateway, then the "B" to "C"
   connection would be the IP network or Voice over IP connection
   whereas the "C" to "D" connection would typically be the PCM trunk. 

   If this model is applied to a conference bridge or session/border
   controller then the "B" to "C" connection would be a Voice over IP
   connection and the "C" to "D" connection may also be Voice over IP.
   In this scenario, "C" could be generating RTCP HR or XR reports in
   both directions, i.e. sent to "D" for the "D" to "C" RTP stream and
   sent to "B" for the "B" to "C" RTP stream.

   2.2 Cumulative and Interval Metrics

   Cumulative metrics relate to the entire duration of the call to the
   point at which metrics are determined and reported, and are typically
   used to report call quality.  Cumulative metrics generally result in
   a lower volume of data that may need to be stored, as each report
   supersedes earlier reports.

   Interval metrics relate to the period since the last Interval report. 
   Interval data may be easier to correlate with specific network events
   for which timing is known, and may also be used as a basis for
   threshold crossing alerts.
   Note that interval metrics for the start and end of calls may be
   unreliable due to factors such as irregular interval length and the
   difficulty in knowing when packet transmission started and ended.

Clark               Expires June 2006                        [Page 3]

draft-clark-avt-rtcphr-00.txt                          December 2005 

   2.3 Bursts, Gaps, and Concealed Seconds

   The terms Burst and Gap are used in a manner consistent with that of
   RTCP XR (RFC3611).  A Gap is a period of time between Bursts such
   that any lost or discarded packets or frames are separated by some
   number of "good" packets or frames.  A Burst is a period of time that
   fails the test for a Gap, and hence corresponds to a degraded quality
   period.  The recommended value for Gmin in RFC3611 resulted in a
   Burst being a period of time during which the packet loss/discard
   rate exceeded 5%.

   The term Concealed Seconds defines a count of seconds during which
   the proportion of time lost through packet loss and discard exceeds
   some threshold.  

   2.4 Numeric formats

   This report block makes use of binary fractions.  The terminology
   used is
   
   S X:Y, where S indicates a signed representation, 
                X the number of bits prior to the decimal place and 
                Y the number of bits after the decimal place.

   Hence 8:8 represents an unsigned number in the range 0.0039 to
   255.996.

3   High Resolution VoIP Metrics Report Block

3.1 Block Description

   This block comprises a header and a series of sub-blocks.  The 
   Map field in the header defines which sub-blocks are present.

   Header sub-block
    0               1               2               3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=N      |           Map                  | block length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Correlation tag                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Duration                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Basic Loss/Discard Metrics sub-block
    0               1               2               3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Loss percentage         |      Discard percentage       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Number of frames expected                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Clark               Expires June 2006                        [Page 4]

draft-clark-avt-rtcphr-00.txt                          December 2005 

   Burst/Gap metrics sub-block
    0               1               2               3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Threshold     |             Burst Duration (ms)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Gap Duration (ms)                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Burst Loss/Disc Percentage    |  Gap Loss/Disc Percentage     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Playout metrics sub-block
    0               1               2               3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 On-time Playout Duration                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              On-time Active Speech Playout Duration         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Loss Concealment Duration                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Buffer Adjustment Concealment Duration         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Concealed Seconds metrics sub-block
   0               1               2               3
   0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Unimpaired Seconds                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Concealed Seconds                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Severely Concealed Seconds    | RESERVED      |  threshold  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Delay and PDV metrics sub-block
    0               1               2               3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Network Round Trip Delay      |       End System Delay        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       External Delay          |           Mean PDV            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Max PDV              |       PDV Percentile          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   JB config   |  JB Metric    |          JB nominal           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          JB maximum           |          JB abs max           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Clark               Expires June 2006                        [Page 5]

draft-clark-avt-rtcphr-00.txt                          December 2005 

   Call Quality metrics sub-block
    0               1               2               3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               R-LQ            |             R-CQ              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              MOS-LQ           |            MOS-CQ             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | R-LQ Ext In   | R-LQ Ext Out  |RFC3550 Payload| Media Type    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RxSigLev (IP) |RxNoiseLev (IP)|  Local RERL   |  Remote RERL  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RxSigLev (Ext)|RxNoiseLev(Ext)|       Metric Status           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor specific extension sub-block
  0               1               2               3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Vendor ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vendor ID Src |Manuf Code Src |     Extension Block Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Vendor-specific extension data             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2 Header

   Implementations MUST send the Header block within each High
   Resolution Metrics report.

   3.2.1 Block type
   Nine High Resolution VoIP Metrics blocks are defined
		
   mmm   = HR VoIP Metrics- Cumulative, Locally Generated
   mmm+1 = HR VoIP Metrics- Cumulative, Relayed from Remote IP Endpoint
   mmm+2 = HR VoIP Metrics- Cumulative. Relayed from Remote External
           Endpoint
   mmm+3 = HR VoIP Metrics- Interval - Locally Generated
   mmm+4 = HR VoIP Metrics- Interval - Relayed from Remote IP Endpoint
   mmm+5 = HR VoIP Metrics- Interval - Relayed from Remote External
           Endpoint
   mmm+6 = HR VoIP Metrics- Alert - Locally Generated
   mmm+7 = HR VoIP Metrics- Alert - Relayed from Remote IP Endpoint
   mmm+8 = HR VoIP Metrics- Alert - Relayed from Remote External
           Endpoint

   The time interval associated with these report blocks is left to the
   implementation.  Spacing of RTCP reports should be in accordance
   with RFC3550 however the specific timing of RTCP HR reports may
   be determined in response to an internally derived alert such as a
   threshold crossing.

Clark               Expires June 2006                        [Page 6]

draft-clark-avt-rtcphr-00.txt                          December 2005 

   3.2.2 Map field
   An Map field indicates the optional sub-blocks present in this
   report. A 1 indicates that the sub-block is present, and a 0 that
   the block is absent.  If present, the sub-blocks must be in the 
   sequence defined in this document. 
   The bits have the following definitions:

   0 Burst/Gap Metrics block 
   1 Concealed Seconds Metrics block
   2 Playout Metrics block 
   3 Call Quality Metrics
   4 Vendor specific extension block
   5-15 Reserved, set to 0

   3.2.3 Block Length
   The block length indicates the length of this report in 32 bit 
   words and includes the header and any extension octets.

   3.2.4 SSRC
   The SSRC of the stream to which this report relates.

   3.2.5 Correlation tag
   The correlation tag facilitates the correlation of this report
   block with other call or session related data or endpoint data.

   3.2.6 Duration
   The duration of time for which this report applies expressed in 
   milliseconds.  For cumulative reports this would be the call
   duration. For interval reports this would be the duration of the
   interval.
   
3.3 Basic Loss/ Discard Metrics

   The Basic Loss/Discard Metrics sub-block MUST be present. This
   reports the proportion of frames lost by the network and the
   proportion of frames discarded due to jitter.  For sample based
   codecs such as G.711, a frame shall be defined as an RTP frame.  
   For endpoints that incorporate jitter buffers capable of fractional
   frame discard the proportion of frames discarded MAY be determined on
   the basis of the proportion of samples discarded.
   If Voice Activity Detection is used then the proportion of frames
   lost and discarded shall be determined based on transmitted packets,
   i.e. frames that contained silence and were not transmitted shall 
   not be considered.
   A frame shall be regarded as lost if it fails to arrive within an
   implementation specific time window.  A frame that arrives within 
   this time window but is too early or late to be played out shall 
   be regarded as discarded.  A frame shall be classified as one of 
   received (or OK), discarded or lost.  
   The Loss and Discard metrics are determined after the effects of
   FEC, redundancy (RFC2198) or other similar process.

   3.3.1 Proportion of frames lost
   Proportion of frames lost within the network expressed as a binary
   fraction.  Duplicate frames shall be disregarded.  

Clark               Expires June 2006                        [Page 7]

draft-clark-avt-rtcphr-00.txt                          December 2005 

   3.3.2 Proportion of frames discarded
   Proportion of voice frames received but discarded due to late or
   early arrival.

   3.3.3 Dead connection detection
   If no RTP, SID or RTP no-op packets have been received for a pre-
   specified time interval(for example ten seconds) then an RTCP HR 
   dead connection indication MUST be sent.  This time interval may
   be changed during the connection, for example being longer at the
   start of a call.  A dead connection is indicated by 
   setting both the fields above to 0xFFFF (equivalent to indicating 
   that 99.99% of packets have been both lost and discarded).
   Receipt of an RTCP HR block with either field set to a value other
   than 0xFFFF shall indicate that the remote endpoint HAS received
   some valid RTP packets.

   3.3.4 Number of frames expected
   An count of the number of frames expected, estimated if necessary.
   If no frames have been received then this count shall be set to 
   zero, however if a dead connection is indicated then this count
   shall be regarded as undefined.

3.4 Burst/Gap metrics sub-block

   The Burst/Gap metrics sub-block MAY be present and if present MUST
   be indicated in the Map field.  The definition of Burst and Gap is
   consistent with that defined in the RFC3611 VoIP Metrics block, with
   the clarification that Loss and Discard are defined in terms of
   frames (as described in 3.3 above). To accomodate the range of
   jitter buffer algorithms and packet discard logic that may be used
   by implementors, the method used to distinguish between bursts and
   gaps may be an equivalent method to that defined in RFC3611.  The
   method used SHOULD produce the same result as that defined in RFC3611
   for conditions of burst packet loss however MAY produce different
   results for conditions of time varying jitter.

   If Voice Activity Detection is used the Burst and Gap Duration
   shall be determined as if silence frames had been sent, i.e. a
   period of silence in excess of Gmin frames MUST terminate a burst 
   condition.

   The Burst/Gap Metrics sub-block contains the following elements.

   3.4.1 Threshold
   The Threshold is equivalent to Gmin in RFC3611, i.e. the number of
   successive frames that must be received and not discarded prior to
   and following a lost or discarded frame in order for this lost or
   discarded frame to be regarded as part of a gap.

   3.4.2 Burst Duration (ms)
   The average duration of a burst of lost and discarded frames.  

   3.4.3 Gap Duration (ms)
   The average duration of periods between bursts.

Clark               Expires June 2006                        [Page 8]

draft-clark-avt-rtcphr-00.txt                          December 2005 

   3.4.4 Burst Loss/Discard Rate
   The proportion of Lost and Discarded frames during Bursts expressed
   as a binary fraction.

   3.4.5 Gap Loss/Discard Rate
   The proportion of Lost and Discarded frames during Gaps expressed
   as a binary fraction.

3.5 Playout Metrics sub-block

    The Playout Duration metrics sub-block MAY be present and
    if present MUST be indicated in the Map field.

    At any instant, the audio output at a receiver may be classified
    as either 'normal' or 'concealed'.  'Normal' refers to playout of
    audio payload received from the remote end.  Concealment refers
    to playout of locally-generated signals used to mask the impact
    of network impairments or to reduce the audibilty of jitter buffer
    adaptations.

    This sub-block accounts for the source of the output audio, in
    millisecond units.  The on-time and active speech playout durations
    allow calculation of the voice activity fraction.  The on-time, and
    concealment durations allow calculation of concealment ratios.
    A distinction between reactive (due to effective packet loss)
    and proactive (due to buffer adaptation) concealment types MAY
    be made.

    3.5.1 On-time Playout Duration

    'On-time' playout is the uninterrupted, in-sequence playout of valid
    decoded audio information originating from the remote endpoint.
    This includes comfort noise during periods of remote talker
    silence, if VAD is used, and regenerated tones.  Equivalently,
    on-time playout is that which is not concealed.

    On-time playout duration MUST include both speech and silence
    intervals, whether VAD is used or not.  This duration is reported
    in millisecond units.

    3.5.2 On-time Active Speech Playout Duration (optional)

    The duration, in milliseconds, of the on-time playout duration
    corresponding to playout of active speech signals, if known. If
    not known, then this field is set to all ones (0x FFFF FFFF).

    3.5.3 Loss Concealment Duration

    The duration, in milliseconds, of audio playout corresponding to
    Loss-type concealment.

    Loss-type concealment is reactive insertion or deletion of samples
    in the audio playout stream due to effective frame loss at the audio
    decoder. "Effective frame loss" is the event in which a frame of
    coded audio is simply not present at the audio decoder when

Clark               Expires June 2006                        [Page 9]

draft-clark-avt-rtcphr-00.txt                          December 2005 

    required.  In this case, substitute audio samples are generally
    formed, at the decoder or elsewhere, to reduce audible impairment.

    Only loss-type concealment is used to form Concealed and Severely
    Concealed Seconds counts, in Section 3.6.

    3.5.4 Buffer Adjustment Concealment Duration (optional)

    The duration, in milliseconds, of audio playout corresponding to
    Buffer Adjustment-type concealment, if known. If not known, then
    this field is set to all ones (0x FFFF FFFF).

    Buffer Adjustment-type concealment is proactive or controlled
    insertion or deletion of samples in the audio playout stream due to
    jitter buffer adaptation, re-sizing or re-centering decisions within
    the endpoint.

    Concealment events which cannot be classified as Buffer Adjustment
    -type MUST be classified as Loss-type.

    Buffer adjustment-type concealment has lower audible impact, in
    general, than loss-type concealment, and is hence exempted from
    calculations of Concealed Second and Severely Concealed Seconds
    counts (Section 3.6).

3.6 Concealed Seconds metrics sub-block

    The Concealed Seconds metrics sub-block MAY be present and if
    present MUST be indicated in the Map field.

    This block provides a description of potentially audible impairments
    due to lost and discarded packets at the endpoint, expressed on a
    time basis analogous to a traditional PSTN T1/E1 errored seconds
    metric.

    Periods of time of less than 1000ms shall be incorporated into these
    counts if they exceed 500mS and shall be disregarded if they are
    less than 500mS.

    3.6.1 Unimpaired Seconds
    A count of the number of unimpaired Seconds that have occurred on
    this call.

    An unimpaired Second is defined as a non-overlapping period of
    1000ms during which no frame loss or discard due to late arrival has
    occurred.  Every second in a call must be classified as either
    OK or Concealed.

    Normal playout of comfort noise or other silence concealment
    signal during periods of talker silence, if VAD is used, shall be
    counted as unimpaired seconds.

Clark               Expires June 2006                        [Page 10]

draft-clark-avt-rtcphr-00.txt                          December 2005 

    3.6.2 Concealed Seconds

    A count of the number of Concealed Seconds that have occurred on
    this call.

    A Concealed Second is defined as a non-overlapping period of 1000ms
    during which any frame loss or discard due to late arrival has
    occurred.

    Equivalently, a concealed second is one in which
    some Loss-type concealment (defined in S. 3.6) has occurred.
    Buffer adjustment-type concealment shall not cause Concealed
    Seconds to be incremented.

    For clarification, the count of Concealed Seconds MUST
    include the count of Severely Concealed Seconds.

    3.6.3 Severely Concealed Seconds
    A count of the number of Severely Concealed Seconds that have
    occurred on this call.
    A Severely Concealed Second is defined as a non-overlapping period
    of 1000 ms during which the cumulative amount of time that has been
    subject to frame loss or discard due to late arrival, exceeds the
    SCS Threshold.

    3.6.4 SCS Threshold
    The SCS Threshold defines the amount of time corresponding to lost
    or discarded frames that must occur within a one second period in
    order for the second to be classified as a Severely Concealed
    Second.  This is expressed in milliseconds and hence can represent
    a range of 0.1 to 25.5 percent loss/ discard.

    A default threshold of 50ms (5% effective frame loss per second)
    is suggested.

3.7 Delay and PDV metrics sub-block

   The Delay and PDV metrics sub-block MUST be present.  This sub-block
   contains a number of parameters related to overall delay (latency),
   delay variation and the current jitter buffer configuration.

   [Editor's note - need to add high and low water marks]

   3.7.1 Network Round Trip Delay (ms)
   The Network Round Trip Delay is the most recently measured value
   of the RTP-to-RTP interface round trip delay, typically determined 
   using RTCP SR/RR. If no measured delay is available then this 
   field shall be set to 0xFFFF

   3.7.2 End System Delay (ms)
   The End System Delay is the internal round trip delay within the
   endpoint, calculated using the nominal value of the jitter buffer 
   delay plus the accumulation/ encoding and decoding / playout delay 
   associated with the codec being used.

Clark               Expires June 2006                        [Page 11]

draft-clark-avt-rtcphr-00.txt                          December 2005 

   3.7.3 External Network Delay (ms)
   The External Network Delay parameter indicates external network 
   round trip delay through cellular, satellite or other types of 
   network with significant delay impact, if known.  A value of 
   oxFFFF shall indicate that the delay is unknown.
   If the external network is VoIP based then this parameter is
   typically determined using RTCP SR/RR.  If the external network delay
   is known and does not vary materially then this value may be
   provisioned.

   3.7.4 PDV/ Jitter Metrics
   Jitter metrics defined are:

    (i)  Mean PDV - for cumulative reports this is a running average of 
         PDV and for interval reports this is an interval average
         (16 bit, 12:4 format) expressed in milliseconds

    (ii) Max PDV - the maximum PDV associated with the PDV percentile
         (16 bit, 12:4 format) expressed in milliseconds

    (iii)PDV Percentile - the percentage of time on the call during 
         which individual packet delays were below Max PDV, expressed
         in 8:8 format.

   3.7.5 PDV Type
   Indicates the type of algorithm used to calculate PDV:

      PPDV (0), 
      MAPDV (1), 
      Y.1540 (2)
      Other values reserved

   For example:-

     (a) To report PPDV (RFC3550):
         Mean PDV = PPDV
         Max PDV = Undefined (FF FF)
         PDV Percentile = Undefined (FFF)
         PDV type = 0 PPDV

     (b) To report 95th percentile MAPDV (G.1020):
         Mean PDV = average MAPDV
         Max PDV = Max MAPDV
         PDV Percentile = 95.3
         PDV type = 1 MAPDV

    Note that implementations may either fix the reported percentile 
    and calculate the associated PDV level OR may fix a threshold PDV 
    level and calculate the associated percentile. 

   3.7.6 Jitter Buffer and PLC Configuration
   Indicates the configuration of the jitter buffer and the type of PLC
   algorithm in use.

Clark               Expires June 2006                        [Page 12]

draft-clark-avt-rtcphr-00.txt                          December 2005 

        bits 0-3
              0 = silence insertion
              1 = simple replay, no attenuation
              2 = simple replay, with attenuation
              3 = enhanced
              ? = ?
              Other values reserved

        bits 4-7
              0 = Fixed jitter buffer
              1 = Adaptive jitter buffer
              Other values reserved

   3.7.7 Jitter Buffer Size parameters
   Current nominal, maximum and absolute maximum jitter buffer size
   expressed in milliseconds.  

3.8 Call Quality Metrics sub-block 
   The Call Quality Metrics sub-block MAY be present however if present
   it MUST be indicated in the Header Map field. This sub-block reports
   call quality metrics and estimates of signal, noise and echo levels.

   Signal, noise and echo metrics should be long term averages and
   should not be instantaneous values.

   3.8.1 Listening and Conversation Quality R Factors
   Expresses listening and conversational quality in terms of R factor,
   a 0-120 scaled parameter in 8:8 format.  The algorithm used to
   calculate R factor MAY be defined in the Voice/Data Quality Metric
   Algorithm block. 

   3.8.2 Listening and Conversation Quality MOS Scores
   Expresses listening and conversational quality in terms of MOS,
   a 1-5 scaled parameter in 8:8 format.  The algorithm used to
   calculate MOS MAY be defined in the Voice/Data Quality Metric
   Algorithm block. 

   Note that R factors and MOS scores may be defined for both narrow
   and wide-band VoIP calls.  R Factors are continuous for narrow and
   wideband, hence the R factor for a wideband call may be higher than
   that for a narrowband call.  MOS scores are scaled relative to 
   reference conditions and hence both narrow and wideband MOS occupy
   the same 1-5 scale; this can lead to a wideband MOS being lower than
   a narrowband MOS even though the listening quality may be higher. 

   3.8.3 R-LQ External In and Out.
     R-LQ External In - measured by this endpoint for incoming 
                        connection on "other" side of this endpoint

     R-LQ External Out - copied from RTCP XR message received from 
                      remote endpoint on "other" side of this endpoint

   e.g. PhoneA <---> Bridge <----> Phone B

   In XR message from Bridge to Phone A:-

Clark               Expires June 2006                        [Page 13]

draft-clark-avt-rtcphr-00.txt                          December 2005 

        - R-LQ = quality for PhoneA ----> Bridge path

        - R-LQ-ExtIn = quality for Bridge <---- Phone B path

        - R-LQ-ExtOut = quality for Bridge -----> Phone B path

   This allows PhoneA to assess 

     (i) received quality from the combination of 

         R-LQ measured at A 
               and
         R-LQ-ExtIn reported by the Bridge to A

     (ii) remote endpoint quality from the combination of

         R-LQ reported by the Bridge
               and
         R-LQ-ExtOut reported by the Bridge

   3.8.4 RFC3550 RTP Payload Type

   The RTP Payload type field - as per RFC3551 and
   http://www.iana.org/assignments/rtp-parameters

   If the RFC3550 Payload type indicates a dynamic payload then
   it is strongly recommended that the Extended Payload Descriptor
   sub-block be sent in order that mid-stream management systems
   can identify the codec type used. 

   3.8.5 Media Type
      Media type - 
                  0 = No media present
                  1 = Narrowband audio
                  2 = Wideband audio
                  3 = Fax Relay (T.38)
                  4 = Voiceband data (V.152)
                  5 = Modem Relay (V.150.1)
                  6 = Text Relay (V.151)
                  7 = Video

   3.8.6 Received Signal and Noise Levels - IP side
   The received signal level during talkspurts and the noise level
   expressed in dBm0, for the decoded packet stream.

   3.8.7 Received Signal and Noise Levels - External
   The received signal level during talkspurts and the noise level
   expressed in dBm0, for the PCM side of a gateway, audio input
   from a handset or decoded packet stream for an IP-IP gateway.

   3.8.8 Local and Remote Echo Return Loss
   The Local and Remote Residual Echo Return Loss expressed in dB.
   The Local RERL is the echo level that would be reflected into the
   IP path due to line echo on the trunk side of this IP endpoint if
   a gateway or acoustic echo if a handset.

Clark               Expires June 2006                        [Page 14]

draft-clark-avt-rtcphr-00.txt                          December 2005 

   The Remote RERL is the echo level that would be reflected into 
   the remote IP endpoint from the network "behind" it, and would
   typically be measured at and reported from the remote endpoint.
   This value is included as it may be used in calculating the R-CQ and
   MOS-CQ values expressed in this report block.

   3.8.9 Metric Status
   Indicates the source of parameter values used in call quality 
   calculation:

   Bit      Description                 Source

   0-1    Local IP side Signal/Noise Levels measured on the incoming
          decoded VoIP stream to this endpoint

              00 = assumed
              01 = measured for this call
              10 = measured across multiple calls on this port
              11 = measured across multiple ports 

   2-3    Remote IP side Signal/Noise Levels reported by the remote
          IP endpoint through RTCP XR or equivalent

              00 = assumed
              01 = measured for this call
              10 = measured across multiple calls on this port
              11 = measured across multiple ports 

   4-5    Local Trunk side Signal/Noise Levels measured on the incoming
          PCM, Audio or non-IP side of this endpoint

              00 = assumed
              01 = measured for this call
              10 = measured across multiple calls on this port
              11 = measured across multiple ports 

   6-7    Local Echo level measured in the incoming line/ trunk/ 
          handset direction at this endpoint after the effects of echo 
          cancellation

              00 = assumed
              01 = measured for this call
              10 = measured across multiple calls on this port
              11 = measured across multiple ports 

   8      Remote Echo level measured in the incoming line/ trunk/ 
          handset direction at the remote endpoint after the effects of 
          echo cancellation and reported to this endpoint via RTCP XR 
          or equivalent.

              0 = assumed
              1 = reported from remote endpoint

   9-15  Reserved

Clark               Expires June 2006                        [Page 15]

draft-clark-avt-rtcphr-00.txt                          December 2005 

   For example, if this endpoint is "C" in the diagram below then the
   following definitions would apply.

   Endpoint B -----RTP-------> Gateway C <-----PCM-------> D
   "Remote"                    "Local"        "Trunk/PCM/External"
       Reporting endpoint is "B"

       Local IP side signal/noise metrics relate to signal/noise levels
       from decoded RTP packets received by C from B

       Remote IP side signal/noise metrics relate to signal/noise levels
       from decoded RTP packets received by B from C, and reported by B
       to C through RTCP XR or RTCP HR VoIP Metrics blocks

       Local Trunk side signal/noise metrics relate to signal/noise
       levels from the PCM signal received by C from D

       Local Echo level relates to the proportion of the signal passing
       from B to C to D that is reflected back to C at some point
       between C and D or on the far side of D.  This would typically be
       line echo or acoustic echo.

       Remote Echo level relates to the proportion of the signal passing
       from D to C to B that is reflected back to B at some point 
       between B and the user.  This echo level is typically measured at
       B and reported to C via RTCP XR or RTCP HR VoIP Metrics blocks.

3.9 Vendor Extension sub-block

   The Vendor Extension sub-block MAY be present however if present
   it MUST be indicated in the Header Map field.

   One or more vendor extension sub-blocks may be added.  Each 
   extension block consists of an extension header and vendor-specific 
   extension data. The extension header has the form Vendor ID, Vendor 
   ID Source and Extension Block Length. The Extension Block Length is 
   defined as including these extension header and extension data
   octets but does not include any subsequent vendor extension
   sub-blocks.  An implementation can skip over a 
   vendor extension sub-block that it does not understand. 

   The Vendor ID Source field indicates whether the four-octet Vendor ID
   is based on ITU T.35 or is an IANA private enterprise number. The 
   designated values for these options are 1 and 2 respectively. If the 
   Vendor ID Source field is assigned a value of 0, then all of the 
   fields in the vendor extension sub-block with the exception of the 
   Vendor ID Source field and the Extension Block Length field have
   proprietary definitions. 

   If the Vendor ID is based on ITU T.35, its first two octets either 
   contain a country code from Annex A of ITU Recommendation T.35
   followed by 0x00 or an escape code of 0xFF followed by a country code
   from Annex B of T.35. The next two octets comprise a terminal
   provider code allocated by a national assignment authority 

Clark               Expires June 2006                        [Page 16]

draft-clark-avt-rtcphr-00.txt                          December 2005 

   (http://people.itu.int/~campos/t35/t35db.htm). This field is padded 
   with leading zeros if necessary. If a vendor has multiple
   terminal provider codes in different registries (e.g. the H-series, 
   T-series and V-series registries for the USA), then this provenance
   shall be indicated in the Manufacturer Code Source field. Possible
   values of the Manufacturer Code Source field are:
         0 Unspecified/don't care (may be used if there is no conflict)
         1 G-series registry
         2 H-series registry
         3 T-series registry
         4 V-series registry
         5-255 Reserved. 
   
   If the four-octet Vendor ID is an IANA private enterprise number, 
   then it is padded with leading zeros as necessary. Current private 
   enterprise numbers (www.iana.org/assignments/enterprise-numbers)
   can be accommodated within two octets. The additional two octets
   provide for future growth.
  
4. RTCP HR Configuration Block

   This block type provides a flexible means to describe the algorithms
   used for call quality calculation and other data.  This block need 
   only be exchanged occasionally, for example sent once at the start 
   of a call.

   Header sub-block
    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=N      |           Map                  | block length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Correlation tag                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Algorithm sub-block
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Alg type      | Descriptor len|       Algorithm descriptor... |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   ... Algorithm descriptor                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Extended Payload Descriptor sub-block
    0               1               2               3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Sample Rate                             | Frames per Pkt |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Frame Size (octets)        |        Frame size (mS)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Payload descriptor (optional)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Clark               Expires June 2006                        [Page 17]

draft-clark-avt-rtcphr-00.txt                          December 2005 

   Vendor Specific Extensions sub-block
    0               1               2               3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Vendor ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vendor ID Src |Manuf Code Src |     Extension Block Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Vendor-specific extension data             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1 Header

   Implementations MUST send the Header block within each RTCP HR
   Configuration report.

   4.2.1 Block type
   One RTCP HR Configuration blocks is defined
		
   mmm+9   = RTCP HR Configuration Block

   The time interval associated with these report blocks is left to the
   implementation.  Spacing of RTCP reports should be in accordance
   with RFC3550 however the specific timing of RTCP HR reports may
   be determined in response to an internally derived alert such as a
   threshold crossing.

   4.2.2 Map field
   An Map field indicates the optional sub-blocks present in this
   report. A 1 indicates that the sub-block is present, and a 0 that
   the block is absent.  If present, the sub-blocks must be in the 
   sequence defined in this document. 
   The bits have the following definitions:

   0 Algorithm Descriptor 1 
   1 Algorithm Descriptor 2 
   2 Algorithm Descriptor 3  
   3 Algorithm Descriptor 4 
   4 Algorithm Descriptor 5 
   5 Algorithm Descriptor 6 
   6 Algorithm Descriptor 7 
   7 Algorithm Descriptor 8 
   8 Payload Descriptor 
   9 Vendor Specific Extension
   10-15 Reserved, set to 0

   4.2.3 Block Length
   The block length indicates the length of this report in 32 bit 
   words and includes the header and any extension octets.

   4.2.4 SSRC
   The SSRC of the stream to which this report relates.

Clark               Expires June 2006                        [Page 18]

draft-clark-avt-rtcphr-00.txt                          December 2005 

   4.2.5 Correlation tag
   The correlation tag facilitates the correlation of this report
   block with other call or session related data or endpoint data.

4.3 Algorithm description

   The Algorithm Description sub-block MAY be present however if present
   MUST be indicated in the MAP field
   The Algorithm descriptor is a bit field which indicates which
   algorithm is being described.  The bits are defined as:-

      Bit 0:      MOS-LQ Algorithm
      Bit 1:      MOS-CQ Algorithm
      Bit 2:      R-LQ Algorithm
      Bit 3:      R-CQ Algorithm
      Bit 4-7:    Reserved and set to 0

  The descriptor length gives the overall length of the descriptor in
  32 bit words and includes the algorithm descriptor and length fields.

  The algorithm descriptor is a text field that contains the
  description or name of the algorithm.  If the algorithm name is 
  shorter than the length of the field then the trailing octets 
  must be set to 0x00.

  For example, an implementation may report:

      Algorithm descriptor = 0x0F   - R and MOS algorithms
      Descriptor length = 3         - 3 words
      Descriptor = "Alg X" 0x00     - description
  
  Call quality estimation algorithms may be defined for listening or
  conversational quality MOS or R factor.

4.4 Extended payload description field

   The Extended Payload Description sub-block MAY be present however 
   if present it MUST be indicated in the Header Map field. This sub
   -block provides a detailed description of the payload format used.

    0               1               2               3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Sample Rate (Hz)               | Frames per Pkt |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Frame Size (octets)        |        Frame size (ms)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Payload descriptor                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Payload descriptor                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   4.3.1 Sample Rate (Hz)
   The sample rate used for this codec.

Clark               Expires June 2006                        [Page 19]

draft-clark-avt-rtcphr-00.txt                          December 2005 

   4.3.2 Frames per Packet
   The number of RTP frames incorporated into an IP packet
 
   4.3.3 Frame Size (octets)
   The size of the RTP payload expressed in octets

   4.3.4 Frame Size (ms)
   The time interval represented by each RTP payload.

   4.3.5 Payload descriptor
   A textual representation of the type of codec, intended to assist
   test and management systems.  
  
4.4 Vendor Extension field

   One or more vendor specific extension blocks may be added, as defined
   in Section 3.10

5. Practical Applications

5.1 Overview
   The objective of this section is to identify a number of cases in
   which there could potentially be some ambiguity in the application
   of the report blocks defined above or some exceptions to the 
   defined operation of the metrics.  

5.2 Call Hold and Transfer

5.3 VAD/ Silence Elimination

5.4 Endpoint configuration changes mid-call

5.5 SSRC changes mid-call

6. Summary

7. IANA Considerations

8.  Security Considerations

   RTCP reports can contain sensitive information since they can provide
   information about the nature and duration of a session established
   between two endpoints.  As a result, any third party wishing to
   obtain this information should be properly authenticated and the
   information transferred securely.

9.  Contributors

   The authors gratefully acknowledge the comments and contributions
   made by Jim Frauenthal, Mike Ramalho, Kevin Connor, Paul Jones, 
   Claus Dahm, Bob Biskner, Mohamed Mostafa, Tom Hock, Albert Higashi,
   Shane Holthaus, Amit Arora and Bruce Adams.

Clark               Expires June 2006                        [Page 20]

draft-clark-avt-rtcphr-00.txt                          December 2005 

10.  Informative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications", STD 64,
        RFC 3550, July 2003.

   [3]  Friedman, T., Caceres, R. and A. Clark, "RTP Control Protocol
        Extended Reports (RTCP XR)", RFC 3611, November 2003.

Authors' Addresses

   Alan Clark
   Telchemy Incorporated
   3360 Martins Farm Road, Suite 200
   Suwanee, GA  30024
   Email: [email-masked]

   Amy Pendleton
   Nortel
   2380 Performance Drive
   Richardson, TX  75081
   Email: [email-masked]

   Rajesh Kumar
   Cisco Systems 
   170 West Tasman Drive
   San Jose, CA 95134
   Email: [email-masked]

Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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

Clark               Expires June 2006                        [Page 21]

draft-clark-avt-rtcphr-00.txt                          December 2005 

   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [email-masked].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Clark               Expires June 2006                        [Page 22]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt