<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>

  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc compact="yes"?>
  <?rfc subcompact="no"?>
  <?rfc rfcedstyle="yes"?>

<rfc number="7294" category="std" submissionType="IETF" consensus="yes"
     ipr="trust200902">

  <front>
    <title abbrev="RTCP XR Concealment">RTP Control Protocol (RTCP) Extended
    Report (XR) Blocks for Concealment
    Metrics Reporting on Audio Applications</title>

    <author fullname="Alan Clark" initials="A." surname="Clark">
      <organization abbrev="Telchemy">Telchemy Incorporated</organization>

      <address>
        <postal>
          <street>2905 Premiere Parkway, Suite 280</street>

          <city>Duluth</city>

          <region>GA</region>

          <code>30097</code>

          <country>USA</country>
        </postal>

        <email>alan.d.clark@telchemy.com</email>
      </address>
    </author>

    <author fullname="Glen Zorn" initials="G." surname="Zorn">
      <organization>Network Zen</organization>

      <address>
        <postal>
          <street>77/440 Soi Phoomjit, Rama IV Road</street>

          <street>Phra Khanong, Khlong Toie</street>

          <city>Bangkok</city>

          <code>10110</code>

          <country>Thailand</country>
        </postal>

        <phone>+66 (0) 87 502 4274</phone>

        <email>gwz@net-zen.net</email>
      </address>
    </author>

    <author fullname="Claire Bi" initials="C." surname="Bi">
      <organization abbrev="STTRI">Shanghai Research Institute of China
      Telecom Corporation Limited</organization>

      <address>
        <postal>
          <street>No. 1835, South Pudong Road</street>

          <city>Shanghai</city>

          <code>200122</code>

          <country>China</country>
        </postal>

        <email>bijy@sttri.com.cn</email>
      </address>
    </author>

    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>sunseawq@huawei.com</email>
      </address>
    </author>

    <date year="2014" month="July"/>

    <area>Real-time Applications and Infrastructure Area</area>

    <workgroup>Audio/Video Transport Working Group</workgroup>

    <keyword>Real Time Control Protocol</keyword>
    

    <abstract>
      <t>This document defines two RTP Control Protocol (RTCP) Extended Report
      (XR) blocks that allow the
      reporting of concealment metrics for audio applications of RTP.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <section title="Loss Concealment and Concealed Seconds Metrics
		      Blocks" anchor="intro-1">
        <t>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 and also includes locally
        generated signals such as announcements, tones, and comfort noise.
        'Concealed' refers to playout of locally generated signals used to
        mask the impact of network impairments or to reduce the audibility of
        jitter buffer adaptations.</t>

        <t>This document defines two new concealment-related block types to
        augment those defined in <xref target="RFC3611"/> for use in a range of RTP
        applications. These two block types extend the packet loss concealment
        mechanism defined in Section 4.7.6 of <xref target="RFC3611"/>.</t>

        <t>The first block type, the Loss Concealment Metrics Block, provides
	metrics for actions taken by the
        receiver to mitigate the effect of packet loss and packet discard.
        Specifically, the first metric (On-Time Playout Duration) reports the
        duration of normal playout of data that the receiver obtained from
        the sender's stream. A second metric (Loss Concealment Duration)
        reports the total time during which the receiver played out media data
        that was manufactured locally, because the sender's data for these
        periods was not available due to packet loss or discard. A similar
        metric (Buffer Adjustment Concealment Duration) reports the duration
        of playout of locally manufactured data replacing data that is
        unavailable due to adaptation of an adaptive de-jitter buffer. Further
        metrics (Playout Interrupt Count and Mean Playout Interrupt Size)
        report the number of times normal playout was interrupted and the
        mean duration of these interruptions.</t>

        <t>Loss Concealment Duration and Buffer Adjustment Concealment
        Duration are reported separately because buffer adjustment is
        typically arranged to occur in silence periods, so it may have very little
        impact on user experience, whilst loss concealment may occur at any
        time.</t>

<!--[rfced] Please confirm that the treatment of SCS Threshold (see
5th paragraph of Section 1.1) is correct as we do not see it called
out specifically as a metric (as the others in that paragraph), but it
appears in the Appendix and Section 4.2.

-->
        <t>The second block type, the Concealed Seconds Metrics Block,
	provides metrics for Concealed Seconds,
        which are measured at the receiving end of the RTP stream.
        Specifically, the first metric (Unimpaired Seconds) reports the number
        of whole seconds occupied only with normal playout of data that the
        receiver obtained from the sender's stream. The second metric
        (Concealed Seconds) reports the number of whole seconds during which
        the receiver played out any locally generated media data. A third
        metric, Severely Concealed Seconds (SCSs), reports the number of whole
        seconds during which the receiver played out locally generated data
to conceal a lost or discarded frame percentage in excess of the configured
SCS Threshold.
</t>

        <t>These metrics belongs to the class of transport-related terminal
        metrics defined in <xref target="RFC6792"/>.</t>
      </section>

      <section title="RTCP and RTCP Extended Reports">
        <t>The use of RTCP for reporting is defined in <xref
        target="RFC3550"/>. <xref target="RFC3611"/> defines an extensible
        structure for reporting using an RTCP Extended Report (XR). This document
        defines a new Extended Report block that MUST be used as defined in
        <xref target="RFC3550"/> and <xref target="RFC3611"/>.</t>
      </section>

      <section title="Performance Metrics Framework">
        <t>The Performance Metrics Framework <xref target="RFC6390"/> provides
        guidance on the definition and specification of performance metrics.
        The RTP Monitoring Framework <xref target="RFC6792"/> provides
        guidelines for reporting block format using RTCP XR. The metrics blocks
        described in this document are in accordance with those
        guidelines.</t>
      </section>

      <section title="Applicability" anchor="applic-sec">
        <t>These metrics are applicable to audio applications of RTP and the
        audio component of audio/video applications in which the packet loss
        concealment machinery is contained at the receiving end to mitigate
        the impact of network impairments to user's perception of media
        quality.</t>
      </section>
    </section>

    <section title="Terminology">
      <section title="Standards Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>

      <section title="Notations">
        <t>The report blocks in this document make use of binary fractions. The following terminology
        is used:<list>
            <t>Numeric formats S X:Y<list>
                <t>where S indicates a two's complement signed representation,
                X the number of bits prior to the decimal place, and Y the
                number of bits after the decimal place.</t>

                <t>Hence, 8:8 represents an unsigned number in the range 0.0 to
                255.996 with a granularity of 0.0039. S7:8 would represent the
                range -127.996 to +127.996. 0:16 represents a proper binary
                fraction with range</t>

                <t>0.0 to 1 - 1/65536 = 0.9999847</t>

                <t>though note that use of flag values at the top of the
                numeric range slightly reduces this upper limit. For example,
                if the 16-bit values 0xfffe and 0xffff are used as flags for
                "over-range" and "unavailable" conditions, a 0:16 quantity has
                range</t>

                <t>0.0 to 1 - 3/65536 = 0.9999542</t>
              </list></t>
          </list></t>
      </section>
    </section>

    <section title="Loss Concealment Metrics Block" anchor="loss-conceal-sec">
      <t>The Loss Concealment Metrics Block is intended to be used as described
      in this section, in conjunction with information from the Measurement
      Information Block <xref target="RFC6776"/>. Instances of this metrics
      block refer by synchronization source (SSRC) to the separate auxiliary
      Measurement Information Block <xref target="RFC6776"/>, which describes
      measurement periods in use (see <xref target="RFC6776"/>, Section 4.2).
      This metrics block relies on the measurement period in the Measurement
      Information Block indicating the span of the report and SHOULD be sent
      in the same compound RTCP packet as the Measurement Information Block.
      If the measurement period is not received in the same compound RTCP
      packet as this metrics block, this metrics block MUST be discarded.</t>

      <section title="Report Block Structure">
        <t>The structure of the Loss Concealment Metrics Block is as follows.
<figure
            title="Loss Concealment Metrics Block" anchor="loss-conceal-block">
            <artwork>
  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=30      | I |plc|  resv |       block length=6          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         SSRC of Source                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                 On-Time Playout Duration                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Loss Concealment Duration                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              Buffer Adjustment Concealment Duration           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Playout Interrupt Count    |           Reserved            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                 Mean Playout Interrupt Size                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
          </figure></t>
      </section>

      <section title="Definition of Fields in Loss Concealment Metrics Block" anchor="loss-conceal-def">
        <t><list style="hanging">
            <t hangText="Block type (BT): 8 bits"><vspace blankLines="1"/>A
            Loss Concealment Metrics Block is identified by the
            constant 30. </t>

            <t hangText="Interval Metric flag (I): 2 bits"><vspace
            blankLines="1"/>This field is used to indicate whether the loss
            concealment metrics are Sampled, Interval, or Cumulative metrics:
            <list>
                <t>I=10: Interval Duration - the reported value applies to the
                most recent measurement interval duration between successive
                metrics reports.</t>

                <t>I=11: Cumulative Duration - the reported value applies to
                the accumulation period characteristic of cumulative
                measurements.</t>

                <t>I=01: Sampled Value - the reported value is a sampled
                instantaneous value (not allowed in this block).</t>

                <t>I=00: Reserved value - this value is reserved for future
                use.</t>
              </list><vspace blankLines="1"/>In this document, Loss
            Concealment metrics can only be measured over definite intervals
            and cannot be sampled. Senders MUST NOT use the values I=00 or
            I=01. If a block is received with I=00 or I=01, the receiver MUST
            discard the block. </t>

            <t hangText="Packet Loss Concealment Method (plc): 2 bits"><vspace
            blankLines="1"/>This field is used to identify the packet loss
            concealment method in use at the receiver, according to the
            following code: <list>

                <t>bits 014-015<list>
                    <t>0 = silence insertion</t>

                    <t>1 = simple replay, no attenuation</t>

                    <t>2 = simple replay, with attenuation</t>

                    <t>3 = enhancement</t>

                    <t>Other values are reserved.</t>
                  </list></t>
              </list>Note that the enhancement method (plc=3) for packet
            loss concealment offers an improved audio quality and better
            robustness against packet losses <xref target="G.711"/> and is equivalent to
            "enhanced" in Section 4.7.6 of <xref target="RFC3611"/>.
            </t>

            <t hangText="Reserved (resv): 4 bits"><vspace
            blankLines="1"/>These bits are reserved. They MUST be set to zero
            by senders and ignored by receivers (see <xref target="RFC6709"/>,
            Section 4.2). </t>

            <t hangText="block length: 16 bits"><vspace blankLines="1"/> The
            length of this report block in 32-bit words, minus one. For the
            Loss Concealment Metrics Block, the block length is equal to 6.
            </t>

            <t hangText="SSRC of Source: 32 bits"><vspace blankLines="1"/>As
            defined in Section 4.1 of <xref target="RFC3611"/>.
            </t>

            <t hangText="On-Time Playout Duration: 32 bits"><vspace
            blankLines="1"/>'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 Voice Activity Detection (VAD) <xref target="VAD"/> is
            used, and locally generated or regenerated tones and
            announcements. <vspace blankLines="1"/>An equivalent definition is
            that on-time playout is playout of any signal other than those
            used for concealment. <vspace blankLines="1"/>On-time playout
            duration is expressed in units of RTP timestamp and MUST include
            both speech and silence intervals, whether VAD is used or not.</t>

            <t>Two values are reserved: a value of 0xFFFFFFFE indicates out of
            range (that is, a measured value exceeding 0xFFFFFFFD), and a value
            of 0xFFFFFFFF indicates that the measurement is unavailable.
            </t>

            <t hangText="Loss Concealment Duration: 32 bits"><vspace
            blankLines="1"/>The duration, expressed in units of RTP timestamp,
            of audio playout corresponding to Loss-Type concealment. <vspace
            blankLines="1"/>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 required. In this case, substitute audio
            samples are generally formed, at the decoder or elsewhere, to
            reduce audible impairment. 

            <vspace blankLines="1"/>Two values are
            reserved: a value of 0xFFFFFFFE indicates out of range (that is, a
            measured value exceeding 0xFFFFFFFD), and a value of 0xFFFFFFFF
            indicates that the measurement is unavailable. 
            </t>

            <t
            hangText="Buffer Adjustment Concealment Duration: 32 bits"><vspace
            blankLines="1"/>The duration, expressed in units of RTP timestamp,
            of audio playout corresponding to Buffer Adjustment-Type
            concealment, if known. <vspace blankLines="1"/>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 decisions, or re-centering decisions within the
            endpoint. <vspace blankLines="1"/>Because this insertion is
            controlled, rather than occurring randomly in response to losses,
            it is typically less audible than Loss-Type concealment. For
            example, jitter buffer adaptation events may be constrained to
            occur during periods of talker silence, in which case only silence
            duration is affected, or sophisticated time-stretching methods for
            insertion/deletion during favorable periods in active speech may
            be employed. <vspace blankLines="1"/>Concealment events that
            cannot be classified as Buffer Adjustment-Type MUST be classified
            as Loss-Type. 

            <vspace blankLines="1"/>Two values are reserved: a
            value of 0xFFFFFFFE indicates out of range (that is, a measured
            value exceeding 0xFFFFFFFD), and a value of 0xFFFFFFFF indicates
            that the measurement is unavailable. </t>

            <t hangText="Playout Interrupt Count: 16 bits"><vspace
            blankLines="1"/>The number of interruptions to normal playout
            that occurred during the reporting period. 


            <vspace blankLines="1"/>Two values are reserved: a value of 0xFFFE
            indicates out of range (that is, a measured value exceeding
            0xFFFD), and a value of 0xFFFF indicates that the measurement is
            unavailable. </t>

            <t hangText="Reserved: 16 bits"><vspace
            blankLines="1"/>These bits are reserved. They MUST be set to zero
            by senders and ignored by receivers (see <xref target="RFC6709"/>,
            Section 4.2). </t>

            <t hangText="Mean Playout Interrupt Size: 32 bits"><vspace
            blankLines="1"/>The mean duration, expressed in units of RTP
            timestamp, of interruptions to normal playout that occurred
            during the reporting period. 


	    <vspace blankLines="1"/> Two values
            are reserved: a value of 0xFFFFFFFE indicates out of range (that
            is, a measured value exceeding 0xFFFFFFFD), and a value of
            0xFFFFFFFF indicates that the measurement is unavailable. 
            </t>
          </list></t>
      </section>
    </section>

    <section title="Concealed Seconds Metrics Block" anchor="conceal-sec-sec">
      <t>The Concealed Seconds Metrics Block is intended to be used as described in
      this section, in conjunction with information from the Measurement
      Information Block <xref target="RFC6776"/>. It 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 Public
      Switched Telephone Network (PSTN)
      T1/E1 errored seconds metric. Instances of this metrics block refer by
      synchronization source (SSRC) to the separate auxiliary Measurement
      Information Block <xref target="RFC6776"/> that describes measurement
      periods in use (see <xref target="RFC6776"/>, Section 4.2). This metrics
      block relies on the measurement period in the Measurement Information
      Block indicating the span of the report and SHOULD be sent in the same
      compound RTCP packet as the Measurement Information Block. If the
      measurement period is not received in the same compound RTCP packet as
      this metrics block, this metrics block MUST be discarded.</t>

      <t>The following metrics are based on successive one-second intervals as
      declared by an RTP clock. This RTP clock does not need to be synchronized
      to any external time reference. The starting time of this clock is
      unspecified. Note that this implies that the same loss pattern could
      result in slightly different count values, depending on where the losses
      occur relative to the particular one-second demarcation points. For
      example, two loss events occurring 50 ms apart could result in either one
      Concealed Second or two, depending on the particular one-second
      boundaries used.</t>

      <t>The seconds in this sub-block are not necessarily calendar seconds.
      At the tail end of a session, periods of time of less than one second
      shall be incorporated into these counts if they exceed 500 ms and shall
      be disregarded if they are less than 500 ms.</t>

      <section title="Report Block Structure">
        <t>The structure of the Concealed Seconds Metrics Block is as follows.
<figure
            title="Concealed Seconds Metrics Block" anchor="concealed-seconds-block">
            <artwork>
  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=31      | I |plc|  resv |       block length=4          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         SSRC of Source                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Unimpaired Seconds                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Concealed Seconds                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Severely Concealed Seconds    | Reserved      | SCS Threshold |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure></t>
      </section>

      <section title="Definition of Fields in Concealed Seconds Metrics Block"
	       anchor="conceal-sec-def">
        <t><list style="hanging">
            <t hangText="Block type (BT): 8 bits"><vspace blankLines="1"/>A
            Concealed Seconds Metrics Block is identified by the
            constant 31. </t>

            <t hangText="Interval Metric flag (I): 2 bits"><vspace
            blankLines="1"/>This field is used to indicate whether the
            Concealed Seconds metrics are Sampled, Interval, or Cumulative
            metrics: <list>
                <t>I=10: Interval Duration - the reported value applies to the
                most recent measurement interval duration between successive
                metrics reports.</t>

                <t>I=11: Cumulative Duration - the reported value applies to
                the accumulation period characteristic of cumulative
                measurements.</t>

                <t>I=01: Sampled Value - the reported value is a sampled
                instantaneous value (Not allowed in this block).</t>

                <t>I=00: Reserved value - this value is reserved for future
                use.</t>
              </list><vspace blankLines="1"/>In this document, Concealed
            Seconds metrics can only be measured over definite intervals and
            cannot be sampled. Senders MUST NOT use the values I=00 or I=01.
            If a block is received with I=00 or I=01, the receiver MUST
            discard the block. </t>

            <t hangText="Packet Loss Concealment Method (plc): 2 bits"><vspace
            blankLines="1"/>This field is used to identify the packet loss
            concealment method in use at the receiver, according to the
            following code: <list>
                <t>bits 014-015<list>
                    <t>0 = silence insertion</t>

                    <t>1 = simple replay, no attenuation</t>

                    <t>2 = simple replay, with attenuation</t>

                    <t>3 = enhancement</t>

                    <t>Other values are reserved.</t>
                  </list></t>
              </list><vspace blankLines="1"/>Note that the enhancement method
            (plc=3) for packet loss concealment offers an improved audio
            quality and a better robustness against packet losses <xref
	    target="G.711"/> and
            is equivalent to "enhanced" in Section 4.7.6 of <xref target="RFC3611"/>. 
            </t>

            <t hangText="Reserved (resv): 4 bits"><vspace
            blankLines="1"/>These bits are reserved. They MUST be set to zero
            by senders and ignored by receivers (see <xref target="RFC6709"/>,
            Section 4.2).</t>

            <t hangText="Block Length: 16 bits"><vspace blankLines="1"/> The
            length of this report block in 32-bit words, minus one. For the
            Concealed Seconds Metrics Block, the block length is equal to 4.
            </t>

            <t hangText="SSRC of Source: 32 bits"><vspace blankLines="1"/>As
            defined in Section 4.1 of <xref target="RFC3611"/>.
            </t>

            <t hangText="Unimpaired Seconds: 32 bits"><vspace
            blankLines="1"/>A count of the number of Unimpaired Seconds that
            have occurred.<vspace blankLines="1"/>An Unimpaired Second is
            defined as a continuous period of one second during which no frame
            loss or discard due to late arrival has occurred. Every second in
            a session must be classified as either OK or Concealed. <vspace
            blankLines="1"/>Normal playout of comfort noise or other
	    silence-concealment signals during periods of talker silence, if
	    VAD is
            used, shall be counted as Unimpaired Seconds.</t>


            <t> Two values are reserved: a value of 0xFFFFFFFE indicates out
            of range (that is, a measured value exceeding 0xFFFFFFFD), and a
            value of 0xFFFFFFFF indicates that the measurement is unavailable.
            </t>

            <t hangText="Concealed Seconds: 32 bits"><vspace blankLines="1"/>A
            count of the number of Concealed Seconds that have
            occurred.<vspace blankLines="1"/>A Concealed Second is defined as
            a continuous period of one second during which any frame loss or
            discard due to late arrival has occurred. <vspace blankLines="1"/>
            Equivalently, a Concealed Second is one in which some Loss-Type
            concealment has occurred. Buffer Adjustment-Type concealment
            SHOULD NOT cause Concealed Seconds to be incremented, with the
            following exception. An implementation MAY cause Concealed Seconds
            to be incremented for 'emergency' buffer adjustments made during
            talkspurts. <vspace blankLines="1"/>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 required. In
            this case, substitute audio samples are generally formed, at the
            decoder or elsewhere, to reduce audible impairment. <vspace
            blankLines="1"/>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 decisions, or re-centering
            decisions within the endpoint. <vspace blankLines="1"/>Because
            this insertion is controlled, rather than occurring randomly in
            response to losses, it is typically less audible than Loss-Type
            concealment. For example, jitter buffer adaptation events may be
            constrained to occur during periods of talker silence, in which
            case only silence duration is affected, or sophisticated
            time-stretching methods for insertion/deletion during favorable
            periods in active speech may be employed. For these reasons,
            Buffer Adjustment-Type concealment MAY be exempted from inclusion
            in calculations of Concealed Seconds and Severely Concealed
            Seconds. <vspace blankLines="1"/>
      However, an implementation SHOULD include Buffer Adjustment-Type concealment
      in counts of Concealed Seconds and Severely Concealed Seconds if
      the event occurs at an 'inopportune' moment, such as an emergency or
      large, immediate adaptation during active speech or an
      unsophisticated adaptation during speech without regard for the
      underlying signal. In these cases, the assumption of low audibility
      cannot hold.
In other words, jitter
            buffer adaptation events that may be presumed to be audible
            SHOULD be included in Concealed Seconds and Severely Concealed
            Seconds counts.</t>

            <t>Concealment events that cannot be classified as Buffer
            Adjustment-Type MUST be classified as Loss-Type.</t>

            <t>For clarification, the count of Concealed Seconds MUST include
            the count of Severely Concealed Seconds.</t>


            <t> Two values are reserved: a value of 0xFFFFFFFE indicates out
            of range (that is, a measured value exceeding 0xFFFFFFFD), and a
            value of 0xFFFFFFFF indicates that the measurement is unavailable.
            </t>

            <t hangText="Severely Concealed Seconds: 16 bits"><vspace
            blankLines="1"/>A count of the number of Severely Concealed
            Seconds.<vspace blankLines="1"/>A Severely Concealed Second is
            defined as a non-overlapping period of one second during which the
            cumulative amount of time that has been subject to frame loss or
            discard due to late arrival exceeds the SCS Threshold. 


            <vspace blankLines="1"/> Two values are reserved: a value of 0xFFFE
            indicates out of range (that is, a measured value exceeding
            0xFFFD), and a value of 0xFFFF indicates that the measurement is
            unavailable. </t>

            <t hangText="Reserved: 8 bits"><vspace blankLines="1"/>These bits
            are reserved. They MUST be set to zero by senders and ignored by
            receivers (see <xref target="RFC6709"/>, Section 4.2). 
            </t>

            <t hangText="SCS Threshold: 8 bits"><vspace blankLines="1"/>The
            SCS Threshold is defined as the percentage of packets
            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 numeric format 0:8
            and hence can represent a range of 0 to 99.6 percent loss or
            discard. <vspace blankLines="1"/>A default threshold of 5 percent
            effective frame loss (50 ms effective frame loss ) per second is
            suggested. This corresponds to an SCS Threshold in hexadecimal of
            0x0D. </t>
          </list></t>
      </section>
    </section>

    <section title="SDP Signaling">
      <t><xref target="RFC3611"/> defines the use of SDP (Session Description
      Protocol) <xref target="RFC4566"/> for signaling the use of XR blocks.
      XR blocks MAY be used without prior signaling.</t>

      <section title="SDP rtcp-xr-attrib Attribute Extension">
        <t>This section augments the SDP attribute "rtcp-xr" <xref
        target="RFC3611"/> by providing two additional values of "xr-format"
        to signal the use of the two report blocks defined in this document.</t>
<figure><artwork><![CDATA[
xr-format =/ xr-conceal-block
           / xr-conc-sec-block

xr-conceal-block = "loss-conceal"
xr-conc-sec-block = "conc-sec" ["=" thresh]

thresh      = 1*DIGIT          ; threshold for SCS (ms)
DIGIT =     <as defined in Section 3 of [RFC5234]>
]]></artwork></figure>
      </section>

      <section title="Offer/Answer Usage">
        <t>When SDP is used in Offer/Answer context, the SDP Offer/Answer
        usage defined in <xref target="RFC3611"/> applies. Note that "thresh"
        is declared by the offer.</t>
      </section>
    </section>

    <section title="IANA Considerations">
      <t>New block types for RTCP XR are subject to IANA registration. For
      general guidelines on IANA considerations for RTCP XR, refer to <xref
      target="RFC3611"/>.</t>

<!--[rfced] As discussed previously, the text in Section 6.1 has been
updated.  We will request the following updates to the registry at
http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xhtml:


Old:
   Name:       LCB
   Long Name:  Loss Concealment Block
   Value       <NLC>
   Reference:  Section 3.1

   Name:       CSB
   Long Name:  Concealment Seconds Block
   Value       <NCS>
   Reference:  Section 4.1


New:
   Name:       LCB
   Long Name:  Loss Concealment Metrics Block
   Value       30
   Reference:  Section 3.1

   Name:       CSB
   Long Name:  Concealed Seconds Metrics Block
   Value       31
   Reference:  Section 4.1

-->

      <section title="New RTCP XR Block Type Values">
        <t>This document assigns two block type values in the IANA "RTP
        Control Protocol Extended Reports (RTCP XR) Block Type Registry" under the subregistry "RTCP XR Block Type":
        <figure>
            <artwork>
Name:       LCB
Long Name:  Loss Concealment Metrics Block
Value       30
Reference:  Section 3.1

Name:       CSB
Long Name:  Concealed Seconds Metrics Block
Value       31
Reference:  Section 4.1
</artwork>
          </figure></t>


      </section>

      <section title="New RTCP XR SDP Parameters">
        <t>This document also registers two new parameters in the "RTP Control
        Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP)
        Parameters Registry":<list style="symbols">
            <t>"loss-conceal"</t>

            <t>"conc-sec"</t>
          </list></t>
      </section>

      <section title="Contact Information for Registrations">
        <t>
The contact information for the registrations is:
</t>
<t>      
RAI Area Directors
</t>
<t>
rai-ads@tools.ietf.org
</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>It is believed that the RTCP XR blocks defined in this document
      introduce no
      new security considerations beyond those described in <xref
      target="RFC3611"/>. These blocks do not provide per-packet statistics, so
      the risk to confidentiality documented in Section 7, Paragraph 3 of
      <xref target="RFC3611"/> does not apply.</t>
    </section>

    <section title="Contributors">
      <t>Geoff Hunt wrote the initial version of this document.</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors gratefully acknowledge reviews and feedback provided by
      Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin Connor, Alissa
      Cooper, Claus
      Dahm, Randy Ethier, Roni Even, Adrian Farrel, Jim Frauenthal, Albert Higashi, Tom Hock,
      Shane Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz, Alfred
      C.&nbsp;Morton, Mohamed Mostafa,
      Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi Raviraj, Pete Resnick, Albrecht
      Schwarz, Meral Shirazipour, Tom Taylor, and Hideaki Yamada.
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">

         <?rfc include="reference.RFC.2119"?>

         <?rfc include="reference.RFC.3611"?>

         <?rfc include="reference.RFC.4566"?>

         <?rfc include="reference.RFC.3550"?>

         <?rfc include="reference.RFC.6776"?>

         <?rfc include="reference.RFC.5234"?>

    </references>

    <references title="Informative References">

         <?rfc include="reference.RFC.6792"?>

         <?rfc include="reference.RFC.6390"?>

         <?rfc include="reference.RFC.6709"?>

      <reference anchor="VAD" target="http://en.wikipedia.org/w/index.php?title=Voice_activity_detection&amp;oldid=593287643">
        <front>
          <title>Voice activity detection</title>

          <author>
            <organization>Wikipedia</organization>
          </author>

          <date month="January" year="2014"/>
        </front>
      </reference>

      <reference anchor="G.711">
        <front>
          <title>Pulse Code Modulation (PCM) of Voice Frequencies</title>

          <author>
            <organization>ITU-T</organization>
          </author>

          <date year="1988"/>
        </front>
<seriesInfo name='ITU-T Recommendation' value='G.711' />
      </reference>



    </references>

    <section title="Metrics Represented Using the Template from RFC 6390">


<!-- [rfced] FYI, we have removed citations to the current document in the
appendix. We believe it is clear that the section number is referring to the
current document. Also, this is in keeping with a similar appendix in RFCs
6958 and 7003. See example below:

Original:
       *  Measurement Timing: See section 3, 1st paragraph [RFCXXXX] for
          measurement timing and section 3.2 [RFCXXXX] for Interval
          Metric flag.

       *  Use and applications: See section 1.4 [RFCXXXX].

Current:
       *  Measurement Timing: See Section 3, 1st paragraph for
          measurement timing and Section 3.2 for Interval Metric flag.

       *  Use and Applications: See Section 1.4.
-->

      <t><list style="letters">
          <t>On-Time Playout Duration Metric
              <list style="symbols">
              <t>Metric Name: On-Time Playout Duration
              </t>

              <t>Metric Description: 'On-time playout' is the uninterrupted,
              in-sequence playout of valid decoded audio information
              originating from the remote endpoint. On-time playout duration
              is playout duration of any signal other than those used for
              concealment.</t>

              <t>Method of Measurement or Calculation: See <xref target="loss-conceal-def"/>,
              On-Time Playout Duration definition.
              </t>

              <t>Units of Measurement: See <xref target="loss-conceal-def"/>, On-Time Playout
              Duration definition. </t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              <xref target="intro-1"/>, 3rd paragraph. 
              </t>

              <t>Measurement Timing: See <xref target="loss-conceal-sec"/>, 1st paragraph
              for measurement timing and <xref target="loss-conceal-def"/> for Interval
              Metric flag. </t>

              <t>Use and Applications: See <xref target="applic-sec"/>.
              </t>

              <t>Reporting Model: See RFC 3611.</t>
            </list></t>

          <t>Loss Concealment Duration Metric
<list style="symbols">
              <t>Metric Name: Loss Concealment Duration
              </t>

              <t>Metric Description: The duration of audio playout
              corresponding to Loss-Type concealment.
              </t>

              <t>Method of Measurement or Calculation: See <xref target="loss-conceal-def"/>, Loss
              Concealment Duration definition.
              </t>

              <t>Units of Measurement: See <xref target="loss-conceal-def"/>, Loss Concealment
              Duration definition.</t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              <xref target="intro-1"/>, 3rd paragraph. 
              </t>

              <t>Measurement Timing: See <xref target="loss-conceal-sec"/>, 1st paragraph
              for measurement timing and <xref target="loss-conceal-def"/> for Interval
              Metric flag. </t>

              <t>Use and Applications: See <xref target="applic-sec"/>.
              </t>

              <t>Reporting Model: See RFC 3611.</t>
            </list></t>

          <t>Buffer Adjustment Concealment Duration Metric
          <list style="symbols">
              <t>Metric Name: Buffer Adjustment Concealment Duration
              </t>

              <t>Metric Description: The duration of audio playout
              corresponding to Buffer Adjustment-Type concealment.
              </t>

              <t>Method of Measurement or Calculation: See <xref target="loss-conceal-def"/>,
              Buffer Adjustment Concealment Duration definition.
              </t>

              <t>Units of Measurement: See <xref target="loss-conceal-def"/>, Buffer Adjustment
              Concealment Duration definition.
              </t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              <xref target="intro-1"/>, 3rd paragraph. 
              </t>

              <t>Measurement Timing: See <xref target="loss-conceal-sec"/>, 1st paragraph
              for measurement timing and <xref target="loss-conceal-def"/> for Interval
              Metric flag.</t>

              <t>Use and Applications: See <xref target="applic-sec"/>.
              </t>

              <t>Reporting Model: See RFC 3611.</t>
            </list></t>

          <t>Playout Interrupt Count Metric

<list style="symbols">
              <t>Metric Name: Playout Interrupt Count
              </t>

              <t>Metric Description: The number of interruptions to normal
              playout that occurred during the reporting period.
              </t>

              <t>Method of Measurement or Calculation: See <xref target="loss-conceal-def"/>,
              Playout Interrupt Count definition.
              </t>

              <t>Units of Measurement: See <xref target="loss-conceal-def"/>, Playout Interrupt
              Count definition.</t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              <xref target="intro-1"/>, 3rd paragraph. 
              </t>

              <t>Measurement Timing: See <xref target="loss-conceal-sec"/>, 1st paragraph 
              for measurement timing and <xref target="loss-conceal-def"/> for Interval
              Metric flag.</t>

              <t>Use and Applications: See <xref target="applic-sec"/>.
              </t>

              <t>Reporting Model: See RFC 3611.</t>
            </list></t>

          <t>Mean Playout Interrupt Size Metric
 <list style="symbols">
              <t>Metric Name: Mean Playout Interrupt Size
              </t>

              <t>Metric Description: The mean duration of interruptions to
              normal playout that occurred during the reporting
              period.</t>

              <t>Method of Measurement or Calculation: See <xref target="loss-conceal-def"/>,
              Playout Interrupt Count definition.
              </t>

              <t>Units of Measurement: See <xref target="loss-conceal-def"/>, Playout Interrupt
              Count definition.</t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              <xref target="intro-1"/>, 3rd paragraph. 
              </t>

              <t>Measurement Timing: See <xref target="loss-conceal-sec"/>, 1st paragraph 
              for measurement timing and <xref target="loss-conceal-def"/> for Interval
              Metric flag.</t>

              <t>Use and Applications: See <xref target="applic-sec"/>.
              </t>

              <t>Reporting Model: See RFC 3611.</t>
            </list></t>

          <t>Unimpaired Seconds Metric

<list style="symbols">
              <t>Metric Name: Unimpaired Seconds</t>

              <t>Metric Description: A count of the number of Unimpaired
              Seconds that have occurred.</t>

              <t>Method of Measurement or Calculation: See <xref target="conceal-sec-def"/>,
              Unimpaired Seconds definition.
              </t>

              <t>Units of Measurement: See <xref target="conceal-sec-def"/>, Unimpaired Seconds
              definition.</t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              <xref target="intro-1"/>, 5th paragraph. 
              </t>

              <t>Measurement Timing: See <xref target="conceal-sec-sec"/>, 1st paragraph 
              for measurement timing and <xref target="conceal-sec-def"/> paragraph for
              Interval Metric flag.</t>

              <t>Use and Applications: See <xref target="applic-sec"/>.
              </t>

              <t>Reporting Model: See RFC 3611.</t>
            </list></t>

          <t>Concealed Seconds Metric
<list style="symbols">
              <t>Metric Name: Concealed Seconds</t>

              <t>Metric Description: A count of the number of Concealed
              Seconds that have occurred.</t>

              <t>Method of Measurement or Calculation: See <xref target="conceal-sec-def"/>,
              Concealed Seconds definition.
              </t>

              <t>Units of Measurement: See <xref target="conceal-sec-def"/>, Concealed Seconds
              definition.</t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              <xref target="intro-1"/>, 5th paragraph. 
              </t>

              <t>Measurement Timing: See <xref target="conceal-sec-sec"/>, 1st paragraph 
              for measurement timing and <xref target="conceal-sec-def"/> for Interval
              Metric flag.</t>

              <t>Use and Applications: See <xref target="applic-sec"/>.
              </t>

              <t>Reporting Model: See RFC 3611.</t>
            </list></t>

          <t>Severely Concealed Seconds Metric
<list style="symbols">
              <t>Metric Name: Severely Concealed Seconds
              </t>

              <t>Metric Description: A count of the number of Severely
              Concealed Seconds that have occurred.
              </t>

              <t>Method of Measurement or Calculation: See <xref target="conceal-sec-def"/>,
              Severely Concealed Seconds definition.
              </t>

              <t>Units of Measurement: See <xref target="conceal-sec-def"/>, Severely Concealed
              Seconds definition.</t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              <xref target="intro-1"/>, 5th paragraph. 
              </t>

              <t>Measurement Timing: See <xref target="conceal-sec-sec"/>, 1st paragraph 
              for measurement timing and <xref target="conceal-sec-def"/> for Interval
              Metric flag. </t>

              <t>Use and Applications: See <xref target="applic-sec"/>.
              </t>

              <t>Reporting Model: See RFC 3611.</t>
            </list></t>

          <t>SCS Threshold Metric

<list style="symbols">
              <t>Metric Name: SCS Threshold</t>

              <t>Metric Description: 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. </t>

              <t>Method of Measurement or Calculation: See <xref target="conceal-sec-def"/>, SCS
              Threshold definition.</t>

              <t>Units of Measurement: See <xref target="conceal-sec-def"/>, SCS Threshold
              definition.</t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              <xref target="intro-1"/>, 5th paragraph. 
              </t>

              <t>Measurement Timing: See <xref target="conceal-sec-sec"/>, 1st paragraph 
              for measurement timing and <xref target="conceal-sec-def"/> for Interval
              Metric flag. </t>

              <t>Use and Applications: See <xref target="applic-sec"/>.
              </t>

              <t>Reporting Model: See RFC 3611.</t>
            </list></t>
        </list></t>
    </section>

  </back>
</rfc>
