<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-ietf-xrblock-rtcp-xr-loss-conceal-12.txt"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="RTCP XR Concealment">RTCP XR Report Block 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 Institure 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." role="editor" 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"/>

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

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

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <keyword>Real Time Control Protocol</keyword>

    <abstract>
      <t>This document defines two RTCP XR Report Blocks that allows the
      reporting of concealment metrics for audio applications of RTP.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <section title="Loss Concealment and Concealment Seconds Metrics Reporting Block">
        <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.
        Concealment 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 draft defines two new concealment related block types to
        augment those defined in [RFC3611] for use in a range of RTP
        applications. These two block types extend packet loss concealment
        mechanism defined in section 4.7.6 of RFC3611.</t>

        <t>The first block type 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 which 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
        which 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 which 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 may have very little
        impact on user experience, whilst loss concealment may occur at any
        time.</t>

        <t>The second block type provides metrics for concealment 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 which 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 (SCS), reports the number of whole
        seconds during which the receiver played out locally-generated data
        for more than 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 XR Reports">
        <t>The use of RTCP for reporting is defined in <xref
        target="RFC3550"/>. <xref target="RFC3611"/> defined an extensible
        structure for reporting using an RTCP Extended Report (XR). This draft
        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 Architectures <xref target="RFC6792"/> provides
        guideline for reporting block format using RTCP XR. The Metrics Block
        described in this document are in accordance with those
        guidelines.</t>
      </section>

      <section title="Applicability">
        <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">RFC2119</xref>.</t>
      </section>

      <section title="Notations">
        <t>This report block makes use of binary fractions. The terminology
        used is <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 Block">
      <t>The metrics block described here are 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>Loss Concealment Metrics Block<figure
            title="Figure 1: Report Block Structure">
            <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=NLC     | I |plc|  rsv. |       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">
        <t><list style="hanging">
            <t hangText="Block type (BT): 8 bits"><vspace blankLines="1"/>A
            Loss Concealment Metrics Report Block is identified by the
            constant NLC. <vspace blankLines="1"/>[Note to RFC Editor: please
            replace NLC with the IANA provided RTCP XR block type for this
            block.] <vspace blankLines="1"/></t>

            <t hangText="Interval Metric flag (I): 2 bit"><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. <vspace blankLines="1"/></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 reserved</t>
                  </list><vspace blankLines="1"/></t>
              </list>Note that the enhancement method (plc =3 ) for packet
            loss concealment offers an improved audio quality and a better
            robustness against packet losses [G.711] and is equivalent to
            enhanced in section 4.7.6 of [RFC3611]. <vspace
            blankLines="1"/></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). <vspace blankLines="1"/></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 Block, the block length is equal to 6.<vspace
            blankLines="1"/></t>

            <t hangText="SSRC of source: 32 bits"><vspace blankLines="1"/>As
            defined in Section 4.1 of <xref target="RFC3611"/>.<vspace
            blankLines="1"/></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 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.
            <vspace blankLines="1"/></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. <vspace
            blankLines="1"/></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 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 which
            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. <vspace blankLines="1"/></t>

            <t hangText="Playout Interrupt Count: 16 bits"><vspace
            blankLines="1"/>The number of interruptions to normal playout
            which 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. <vspace blankLines="1"/></t>

            <t hangText="Reserved (resv): 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). <vspace blankLines="1"/></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 which 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. <vspace
            blankLines="1"/></t>
          </list></t>
      </section>
    </section>

    <section title="Concealment Seconds Block">
      <t>This sub-block described here is intended to be used as described in
      this section, in conjunction with information from the Measurement
      Information block <xref target="RFC6776"/> and 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. 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>

      <t>The following metrics are based on successive one second intervals as
      declared by a 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 50ms 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 500ms and shall
      be disregarded if they are less than 500ms.</t>

      <section title="Report Block Structure">
        <t>Concealed Seconds Metrics Block<figure
            title="Figure 2: Report Block Structure">
            <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=NCS     | I |plc|Rserved|       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">
        <t><list style="hanging">
            <t hangText="Block type (BT): 8 bits"><vspace blankLines="1"/>A
            Concealed Seconds Metrics Report Block is identified by the
            constant NCS. <vspace blankLines="1"/>[Note to RFC Editor: please
            replace NCS with the IANA provided RTCP XR block type for this
            block.] <vspace blankLines="1"/></t>

            <t hangText="Interval Metric flag (I): 2 bit"><vspace
            blankLines="1"/>This field is used to indicate whether the
            Concealment 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, Concealment
            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. <vspace blankLines="1"/></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 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 [G.711] and
            is equivalent to enhanced in section 4.7.6 of [RFC3611]. <vspace
            blankLines="1"/></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). <vspace blankLines="1"/></t>

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

            <t hangText="SSRC of source: 32 bits"><vspace blankLines="1"/>As
            defined in Section 4.1 of <xref target="RFC3611"/>.<vspace
            blankLines="1"/></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 signal 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.
            <vspace blankLines="1"/></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 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-type concealment in counts of Concealed Seconds and
            Severely Concealed Seconds if the event occurs at an 'inopportune'
            moment, with an emergency or large, immediate adaptation during
            active speech, or for unsophisticated adaptation during speech
            without regard for the underlying signal, in which cases the
            assumption of low-audibility cannot hold. In other words, jitter
            buffer adaptation events which may be presumed to be audible
            SHOULD be included in Concealed Seconds and Severely Concealed
            Seconds counts.</t>

            <t>Concealment events which 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. <vspace blankLines="1"/></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 [RFC6709] section 4.2). <vspace
            blankLines="1"/></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%
            effective frame loss (50ms effective frame loss ) per second is
            suggested. This corresponds to an SCS Threshold in hexadecimal of
            0x0D. <vspace blankLines="1"/></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 two report blocks defined in this document.</t>

        <figure>
          <artwork>
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 =     &lt;as defined in Section 3 of [RFC5234]&gt;
</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>

      <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 ":
        <figure>
            <artwork>
Name:       LCB
Long Name:  Loss Concealment Block
Value       &lt;NLC&gt;
Reference:  Section 3.1

Name:       CSB
Long Name:  Concealment Seconds Block
Value       &lt;NCS&gt;
Reference:  Section 4.1
</artwork>
          </figure></t>

        <t>[Note to RFC Editor: please replace &lt;NLC&gt; and &lt;NCS&gt;
        with the RTCP XR block type assigned by IANA for this block.]</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><figure>
            <artwork>
The contact information for the registrations is:
      
RAI Area Directors

rai-ads@tools.ietf.org
</artwork>
          </figure><vspace blankLines="1"/></t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>It is believed that this proposed RTCP XR report block introduces no
      new security considerations beyond those described in <xref
      target="RFC3611"/>. This block does 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 draft 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, Claus
      Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert Higashi, Tom Hock,
      Shane Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz, Mohamed Mostafa,
      Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi Raviraj, Albrecht
      Schwarz, Tom Taylor, Hideaki Yamada ,Alissa Cooper,Meral Shirazipour and
      ,MORTON, ALFRED C (AL),Adrian Farrel and Pete Resnick. </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
          Requirement Levels</title>

          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>

            <address>
              <postal>
                <street>1350 Mass. Ave.</street>

                <street>Cambridge</street>

                <street>MA 02138</street>
              </postal>

              <phone>- +1 617 495 3864</phone>

              <email>sob@harvard.edu</email>
            </address>
          </author>

          <date month="March" year="1997"/>

          <area>General</area>

          <keyword>keyword</keyword>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. Authors who follow these
            guidelines should incorporate this phrase near the beginning of
            their document: <list>
                <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 RFC 2119.</t>
              </list></t>

            <t>Note that the force of these words is modified by the
            requirement level of the document in which they are used.</t>
          </abstract>
        </front>
      </reference>

      <reference anchor="RFC3611">
        <front>
          <title>RTP Control Protocol Extended Reports (RTCP XR)</title>

          <author fullname="T. Friedman" initials="T." surname="Friedman">
            <organization/>
          </author>

          <author fullname="R. Caceres" initials="R." surname="Caceres">
            <organization/>
          </author>

          <author fullname="A. Clark" initials="A." surname="Clark">
            <organization/>
          </author>

          <date month="November" year="2003"/>

          <abstract>
            <t>This document defines the Extended Report (XR) packet type for
            the RTP Control Protocol (RTCP), and defines how the use of XR
            packets can be signaled by an application if it employs the
            Session Description Protocol (SDP). XR packets are composed of
            report blocks, and seven block types are defined here. The purpose
            of the extended reporting format is to convey information that
            supplements the six statistics that are contained in the report
            blocks used by RTCP's Sender Report (SR) and Receiver Report (RR)
            packets. Some applications, such as multicast inference of network
            characteristics (MINC) or voice over IP (VoIP) monitoring, require
            other and more detailed statistics. In addition to the block types
            defined here, additional block types may be defined in the future
            by adhering to the framework that this document provides.</t>
          </abstract>
        </front>
      </reference>

      <reference anchor="RFC4566">
        <front>
          <title>SDP: Session Description Protocol</title>

          <author fullname="M. Handley" initials="M." surname="Handley">
            <organization/>
          </author>

          <author fullname="V. Jacobson" initials="V." surname="Jacobson">
            <organization/>
          </author>

          <author fullname="C. Perkins" initials="C." surname="Perkins">
            <organization/>
          </author>

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

          <abstract>
            <t>This memo defines the Session Description Protocol (SDP). SDP
            is intended for describing multimedia sessions for the purposes of
            session announcement, session invitation, and other forms of
            multimedia session initiation. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>

      <reference anchor="RFC3550">
        <front>
          <title>RTP: A Transport Protocol for Real-Time Applications</title>

          <author fullname="Henning Schulzrinne" initials="H."
                  surname="Schulzrinne">
            <organization>Columbia University</organization>
          </author>

          <date month="July" year="2003"/>
        </front>

        <seriesInfo name="RFC" value="3550"/>

        <format type="TXT"/>
      </reference>

      <reference anchor="RFC6776">
        <front>
          <title>Measurement Identity and information Reporting using SDES
          item and XR Block</title>

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

          <date month="August" year="2012"/>
        </front>

        <seriesInfo name="RFC" value="6776"/>

        <format type="TXT"/>
      </reference>

      <reference anchor="RFC5234">
        <front>
          <title>Augmented BNF for Syntax Specifications: ABNF</title>

          <author fullname="D.Crocker" initials="D." surname="Crocker">
            <organization/>
          </author>

          <author fullname="P. Overell" initials="P." surname="Overell">
            <organization/>
          </author>

          <date month="January" year="2008"/>
        </front>

        <seriesInfo name="RFC" value="5234"/>

        <format type="TXT"/>
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="RFC6792">
        <front>
          <title>Monitoring Architectures for RTP</title>

          <author fullname="Geoff Hunt" initials="G." surname="Hunt">
            <organization/>
          </author>

          <date month="November" year="2012"/>
        </front>

        <seriesInfo name="RFC" value="6792"/>

        <format type="TXT"/>
      </reference>

      <reference anchor="RFC6390">
        <front>
          <title>Framework for Performance Metric Development</title>

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

          <author fullname="Benoit Claise " initials="B." surname="Claise">
            <organization/>
          </author>

          <date month="October" year="2011"/>
        </front>

        <seriesInfo name="RFC" value="6390"/>
      </reference>

      <reference anchor="RFC6709">
        <front>
          <title>Design Considerations for Protocol Extensions</title>

          <author fullname="B.Carpenter" initials="B." surname="Carpenter">
            <organization/>
          </author>

          <author fullname="B.Aboba" initials="B." surname="Aboba">
            <organization/>
          </author>

          <author fullname="S.Cheshire" initials="S." surname="Cheshire">
            <organization/>
          </author>

          <date month="September" year="2012"/>
        </front>

        <seriesInfo name="RFC" value="6709"/>

        <format type="TXT"/>
      </reference>

      <reference anchor="VAD">
        <front>
          <title>http://en.wikipedia.org/wiki/Voice_activity_detection</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
    </references>

    <section title="Metrics represented using RFC6390 Template">
      <t>RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC
      number, when assigned.</t>

      <t><list style="letters">
          <t>On-time Playout Duration Metric<vspace blankLines="1"/><list
              style="symbols">
              <t>Metric Name: On-time Playout Duration<vspace
              blankLines="1"/></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<vspace blankLines="1"/></t>

              <t>Method of Measurement or Calculation: See section 3. 2,
              On-time Playout Duration definition [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Units of Measurement: See section 3.2, On-time Playout
              Duration definition [RFCXXXX]. <vspace blankLines="1"/></t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              section 1.1, 3rd paragraph [RFCXXXX]. <vspace
              blankLines="1"/></t>

              <t>Measurement Timing: See section 3, 1st paragraph [RFCXXXX]
              for measurement timing and section 3.2 [RFCXXXX] for Interval
              Metric flag. <vspace blankLines="1"/></t>

              <t>Use and applications: See section 1.4 [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Reporting model: See RFC3611.<vspace blankLines="1"/></t>
            </list></t>

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

              <t>Metric Description: The duration of audio playout
              corresponding to Loss-type concealment.<vspace
              blankLines="1"/></t>

              <t>Method of Measurement or Calculation: See section 3.2, Loss
              Concealment Duration definition [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Units of Measurement: See section 3.2, Loss Concealment
              Duration definition [RFCXXXX].<vspace blankLines="1"/></t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              section 1.1, 3rd paragraph [RFCXXXX]. <vspace
              blankLines="1"/></t>

              <t>Measurement Timing: See section 3, 1st paragraph [RFCXXXX]
              for measurement timing and section 3. 2 [RFCXXXX] for Interval
              Metric flag. <vspace blankLines="1"/></t>

              <t>Use and applications: See section 1.4 [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Reporting model: See RFC3611.<vspace blankLines="1"/></t>
            </list></t>

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

              <t>Metric Description: The duration of audio playout
              corresponding to Buffer Adjustment-type concealment.<vspace
              blankLines="1"/></t>

              <t>Method of Measurement or Calculation: See section 3. 2,
              Buffer Adjustment Concealment Duration definition
              [RFCXXXX].<vspace blankLines="1"/></t>

              <t>Units of Measurement: See section 3.2, Buffer Adjustment
              Concealment Duration definition [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              section 1.1, 3rd paragraph [RFCXXXX]. <vspace
              blankLines="1"/></t>

              <t>Measurement Timing: See section 3, 1st paragraph [RFCXXXX]
              for measurement timing and section 3.2 [RFCXXXX] for Interval
              Metric flag. <vspace blankLines="1"/></t>

              <t>Use and applications: See section 1.4 [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Reporting model: See RFC3611.<vspace blankLines="1"/></t>
            </list></t>

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

              <t>Metric Description: The number of interruptions to normal
              playout which occurred during the reporting period.<vspace
              blankLines="1"/></t>

              <t>Method of Measurement or Calculation: See section 3. 2,
              Playout Interrupt Count definition [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Units of Measurement: See section 3.2, Playout Interrupt
              Count definition [RFCXXXX].<vspace blankLines="1"/></t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              section 1.1, 3rd paragraph [RFCXXXX]. <vspace
              blankLines="1"/></t>

              <t>Measurement Timing: See section 3, 1st paragraph [RFCXXXX]
              for measurement timing and section 3.2 [RFCXXXX] for Interval
              Metric flag. <vspace blankLines="1"/></t>

              <t>Use and applications: See section 1.4 [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Reporting model: See RFC3611.<vspace blankLines="1"/></t>
            </list></t>

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

              <t>Metric Description: The mean duration of interruptions to
              normal playout which occurred during the reporting
              period.<vspace blankLines="1"/></t>

              <t>Method of Measurement or Calculation: See section 3. 2,
              Playout Interrupt Count definition [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Units of Measurement: See section 3.2, Playout Interrupt
              Count definition [RFCXXXX].<vspace blankLines="1"/></t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              section 1.1, 3rd paragraph [RFCXXXX]. <vspace
              blankLines="1"/></t>

              <t>Measurement Timing: See section 3, 1st paragraph [RFCXXXX]
              for measurement timing and section 3.2 [RFCXXXX] for Interval
              Metric flag. <vspace blankLines="1"/></t>

              <t>Use and applications: See section 1.4 [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Reporting model: See RFC3611.<vspace blankLines="1"/></t>
            </list></t>

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

              <t>Metric Description: A count of the number of unimpaired
              Seconds that have occurred.<vspace blankLines="1"/></t>

              <t>Method of Measurement or Calculation: See section 4. 2,
              Unimpaired Seconds definition [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Units of Measurement: See section 4.2, Unimpaired Seconds
              definition [RFCXXXX].<vspace blankLines="1"/></t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              section 1.1, 5th paragraph [RFCXXXX]. <vspace
              blankLines="1"/></t>

              <t>Measurement Timing: See section 4, 1st paragraph [RFCXXXX]
              for measurement timing and section 4.2 paragraph [RFCXXXX] for
              Interval Metric flag. <vspace blankLines="1"/></t>

              <t>Use and applications: See section 1.4 [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Reporting model: See RFC3611.<vspace blankLines="1"/></t>
            </list></t>

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

              <t>Metric Description: A count of the number of Concealed
              Seconds that have occurred.<vspace blankLines="1"/></t>

              <t>Method of Measurement or Calculation: See section 4. 2,
              Concealed Seconds definition [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Units of Measurement: See section 4.2, Concealed Seconds
              definition [RFCXXXX].<vspace blankLines="1"/></t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              section 1.1, 5th paragraph [RFCXXXX]. <vspace
              blankLines="1"/></t>

              <t>Measurement Timing: See section 4, 1st paragraph [RFCXXXX]
              for measurement timing and section 4.2 [RFCXXXX] for Interval
              Metric flag. <vspace blankLines="1"/></t>

              <t>Use and applications: See section 1.4 [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Reporting model: See RFC3611.<vspace blankLines="1"/></t>
            </list></t>

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

              <t>Metric Description: A count of the number of Severely
              Concealed Seconds that have occurred.<vspace
              blankLines="1"/></t>

              <t>Method of Measurement or Calculation: See section 4. 2,
              Severely Concealed Seconds definition [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Units of Measurement: See section 4.2, Severely Concealed
              Seconds definition [RFCXXXX].<vspace blankLines="1"/></t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              section 1.1, 5th paragraph [RFCXXXX]. <vspace
              blankLines="1"/></t>

              <t>Measurement Timing: See section 4, 1st paragraph [RFCXXXX]
              for measurement timing and section 4.2 [RFCXXXX] for Interval
              Metric flag. <vspace blankLines="1"/></t>

              <t>Use and applications: See section 1.4 [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Reporting model: See RFC3611.<vspace blankLines="1"/></t>
            </list></t>

          <t>SCS Threshold Metric<vspace blankLines="1"/><list style="symbols">
              <t>Metric Name: SCS Threshold<vspace blankLines="1"/></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. <vspace blankLines="1"/></t>

              <t>Method of Measurement or Calculation: See section 4. 2, SCS
              Threshold definition [RFCXXXX].<vspace blankLines="1"/></t>

              <t>Units of Measurement: See section 4.2, SCS Threshold
              definition [RFCXXXX].<vspace blankLines="1"/></t>

              <t>Measurement Point(s) with Potential Measurement Domain: See
              section 1.1, 5th paragraph [RFCXXXX]. <vspace
              blankLines="1"/></t>

              <t>Measurement Timing: See section 4, 1st paragraph [RFCXXXX]
              for measurement timing and section 4.2 [RFCXXXX] for Interval
              Metric flag. <vspace blankLines="1"/></t>

              <t>Use and applications: See section 1.4 [RFCXXXX].<vspace
              blankLines="1"/></t>

              <t>Reporting model: See RFC3611.<vspace blankLines="1"/></t>
            </list></t>
        </list></t>
    </section>

    <section title="Change Log">
      <t>Note to the RFC-Editor: please remove this section prior to
      publication as an RFC.</t>

      <section title="draft-ietf-xrblock-rtcp-xr-loss-conceal-11">
        <t>The following are the major changes to previous version : <list
            style="symbols">
            <t>Address comments recieved in Gen-Art Review and OPS-DIR
            Review.</t>
          </list></t>
      </section>

      <section title="draft-ietf-xrblock-rtcp-xr-loss-conceal-09">
        <t>The following are the major changes to previous version : <list
            style="symbols">
            <t>Only Version Number changes.</t>
          </list></t>
      </section>

      <section title="draft-ietf-xrblock-rtcp-xr-loss-conceal-07">
        <t>The following are the major changes to previous version : <list
            style="symbols">
            <t>Change units for threshold and units used for reporting in loss
            concealment block and concealment seconds block.</t>

            <t>Change 16bit "Mean Playout Interrupt Size" into 32bits.</t>
          </list></t>
      </section>

      <section title="draft-ietf-xrblock-rtcp-xr-loss-conceal-06">
        <t>The following are the major changes to previous version : <list
            style="symbols">
            <t>Comments in the WGLC are addressed in this version.</t>
          </list></t>
      </section>

      <section title="draft-ietf-xrblock-rtcp-xr-loss-conceal-05">
        <t>The following are the major changes to previous version : <list
            style="symbols">
            <t>Add text to clarify the definition of enhanced method.</t>

            <t>Add appendix to apply RFC6390 template to the metrics.</t>
          </list></t>
      </section>

      <section title="draft-ietf-xrblock-rtcp-xr-loss-conceal-04">
        <t>The following are the major changes to previous version : <list
            style="symbols">
            <t>Merge Concealment Seconds draft into this draft (i.e.,Loss
            Concealment draft).</t>

            <t>Updated references.</t>
          </list></t>
      </section>
    </section>
  </back>
</rfc>
