<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2250 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2250.xml">
<!ENTITY rfc3611 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3611.xml">
<!ENTITY rfc3357 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3357.xml">
<!ENTITY rfc3550 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc4566 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY rfc5216 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5216.xml">
<!ENTITY rfc5234 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY rfc5296 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml">
<!ENTITY rfc5247 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml">
<!ENTITY I-D.ietf-avt-rapid-rtp-sync PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-rapid-rtp-sync.xml">
<!ENTITY I-D.ietf-pmol-metrics-framework PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pmol-metrics-framework.xml">
<!ENTITY I-D.hunt-avt-monarch PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hunt-avt-monarch.xml">
<!ENTITY I-D.ietf-avt-rtp-svc PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-rtp-svc.xml">
]>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc category="std" docName="draft-wu-avt-rtcp-xr-quality-monitoring-04"
     ipr="trust200902">
  <front>
    <title abbrev="RTCP XR Video Quality Report Blocks">RTP Control Protocol
    Extended Reports (RTCP XR) Report Blocks for Real-time Video Quality
    Monitoring</title>

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

    <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="Roland Schott" initials="R." surname="Schott">
      <organization>Deutsche Telekom Laboratories</organization>

      <address>
        <postal>
          <street>Deutsche-Telekom-Allee 7</street>

          <street></street>

          <city>Darmstadt</city>

          <code>64295</code>

          <country>Germany</country>
        </postal>

        <email>Roland.Schott@telekom.de</email>
      </address>
    </author>

    <date year="2010" />

    <abstract>
      <t>This document defines a set of RTP Control Protocol Extended Reports
      (RTCP XR) Report Blocks and associated SDP parameters allowing the
      report of video quality metrics, primarily for video applications of
      RTP.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Along with the wide deployment of broadband access and the
      development of new IPTV services (e.g., broadcast video, video on
      demand), there is increasing interest in monitoring and managing
      networks and applications that deliver real-time applications over IP,
      to ensure that all end users obtain acceptable video/audio quality. The
      main drives come from operators, since offering performance monitoring
      capability can help diagnose network impairments, facilitate in root
      cause analysis and aid in verifying compliance with service level
      agreements (SLAs) between Internet Service Providers (ISPs) and content
      providers. <vspace blankLines="1" /> The factors that affect real-time
      application quality can be split into two categories. The first category
      consists of transport-dependent factors such as packet loss, delay and
      jitter (which also translates into losses in the playback buffer). The
      factors in the second category are application-specific factors that
      affect video quality and are sensitivity to network errors. These
      factors can be but not limited to video codec and loss recovery
      technique, coding bit rate, packetization scheme, and content
      characteristics. <vspace blankLines="1" /> Compared with
      application-specific factors, the transport-dependent factors sometimes
      are not sufficient to measure video quality, since the ability to
      analyze the video in the application layer provides quantifiable
      measurements for subscriber Quality of Experience (QoE) that may not be
      captured in the transmission layers or from the RTP layer down. In a
      typical scenario, monitoring of the transmission layers can produce
      statistics suggesting that quality is not an issue, such as the fact
      that network jitter is not excessive. However, problems may occur in the
      service layers leading to poor subscriber QoE. Therefore monitoring
      using only network-level measurements may be insufficient when
      application layer video quality is required. <vspace blankLines="1" />
      In order to provide accurate measures of video quality for operators
      when transporting video across a network, the video quality Metrics is
      highly required which can be conveyed in the RTCP XR packets<xref
      target="RFC3611"></xref> and may have the following three benefits:
      <list>
          <t><list style="symbols">
              <t>Tuning the video encoder algorithm to satisfy video quality
              requirements</t>

              <t>Determining which system techniques to use in a given
              situation and when to switch from one technique to another as
              system parameters change</t>

              <t>Verifying the continued correct operation of an existing
              system</t>
            </list></t>
        </list> <vspace blankLines="1" /> <xref target="RFC3611">RFC
      3611</xref> defines seven report block formats for network management
      and quality monitoring. However, there are no block types specifically
      designed for conveying video quality metrics. This document focuses on
      specifying new report block types used to convey video-specific quality
      metrics. <vspace blankLines="1" /> The report block types defined in
      this document fall into two categories. The first category consists of
      general information regarding transmission quality, to be generated and
      processed by the RTP transport. The report blocks in the second category
      convey metrics above transport that affect video quality and are
      sensitivity to network errors.<vspace blankLines="1" /> Seven report
      block formats are defined by this document. Of these, three are
      transport layer metrics: <list>
          <t><list style="symbols">
              <t>RTP Flows Initial Synchronization Delay Report Block</t>

              <t>Audio-Video Playout Offset Report Block</t>

              <t>Layered Streams Statistics Metrics Block</t>
            </list></t>
        </list> <vspace blankLines="1" /> The other four are application layer
      metrics: <list>
          <t><list style="symbols">
              <t>Video Statistics Summary Report Block</t>

              <t>Video Stream Loss and Discard Metrics Block</t>

              <t>Video Stream Burst Metrics Block</t>

              <t>Synthetical Multimedia Quality Metrics Block</t>
            </list></t>
        </list></t>
    </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>

        <t>In addition, the following terms are defined:</t>

        <t><list style="hanging">
            <t hangText="Layered Component Packet"><vspace blankLines="1" />a
            RTP packet using layered codecs containing the specified layered
            component, e.g., encoded stream at the base layer or at the
            enhancement layer.<vspace blankLines="1" /></t>

            <t hangText="Picture Type"><vspace blankLines="1" />Picture types
            used in the different video algorithms compose of the key-frame
            and the Derivation frame. Key-frame is also called as reference
            frame and used as a reference for predicting other pictures. It is
            coded without prediction from other pictures. The Derivation frame
            is derived from Key-frame using prediction from the reference
            frame. <vspace blankLines="1" /></t>
          </list></t>
      </section>

      <section title="Acronyms">
        <t><list style="hanging">
            <t hangText="SSRC"><vspace blankLines="0" /> <xref
            target="RFC3550">Synchronization Source</xref> <vspace
            blankLines="1" /></t>

            <t hangText="TS"><vspace blankLines="0" /> <xref
            target="ISO-IEC.13818-1.2007">Transport Stream</xref></t>
          </list></t>
      </section>
    </section>

    <section title="Applicability">
      <t>All the report blocks defined in this document could be used by
      dedicated network monitoring applications. As specified in <xref
      target="RFC3611">RFC 3611</xref>, for such an application it might be
      appropriate to allow more than 5% of RTP data bandwidth to be used for
      RTCP packets, thus allowing proportionately larger and more detailed
      report blocks. <vspace blankLines="1" /> The Flows General
      Synchronization Offset Block <xref target="AVPO"></xref> has been
      defined for various multimedia applications. Such applications can use
      this report block to monitor offset between two RTP streams
      synchronization to ensure satisfactory QoE. Tighter tolerances than
      typically used have been recommended for such applications. <vspace
      blankLines="1" /> The Flows Synchronization Delay Report Block has been
      defined primarily for layered or multi-description video coding
      applications. When joining a layered video session in such an
      application, a receiver may not synchronize playout across the
      multimedia session until RTCP SR packets have been received on all of
      the component RTP sessions. This report block can be used to ensure
      synchronization between different media layers for the same multimedia
      session. <vspace blankLines="1" /> The Video Stream Loss and Discard
      Metrics Report Block, Video Stream Burst Metrics report Block, Video
      Statistics Summary Report Block and Layered Video Statistics Metrics
      Block can be applied to any real time video application, while
      Synthetical Multimedia Quality Metrics Report Block can be used in any
      real-time AV application .</t>
    </section>

    <section title="Transport Layer Metrics">
      <section anchor="RFISD"
               title="RTP Flows Initial Synchronization Delay Report Block">
        <t>This block reports the initial synchronization delay between RTP
        sessions of the same media stream sent using Multi-Session
        Transmission <xref target="I-D.ietf-avt-rtp-svc"></xref> or the
        initial synchronization delay betwen RTP session of the different
        media types <xref target="I-D.ietf-avt-rapid-rtp-sync"></xref>, which
        is beyond the information carried in the standard RTCP packet format.
        Information is recorded about session bandwidth and synchronization
        delay. <vspace blankLines="1" /> The RTP Flows Intial Synchronization
        Delay Report Block has the following format: <figure>
            <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=TBD    |   Reserved    |          Block length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      SSRC of Sender                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Initial Synchronization Delay                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure> <list style="hanging">
            <t hangText="Block type (BT): 8 bits"><vspace blankLines="0" />
            The Statistics Summary Report Block is identified by the constant
            &lt;RFISD&gt;. <vspace blankLines="1" /></t>

            <t hangText="Reserved: 8 bits"><vspace blankLines="0" /> This
            field is reserved for future definition. In the absence of such a
            definition, the bits in this field MUST be set to zero and MUST be
            ignored by the receiver. <vspace blankLines="1" /></t>

            <t hangText="Block length: 16 bits"><vspace blankLines="0" /> The
            constant 3, in accordance with the definition of this field in
            Section 3 of <xref target="RFC3611">RFC 3611</xref>. <vspace
            blankLines="1" /></t>

            <t hangText="SSRC of Sender: 32 bits"><vspace blankLines="0" />The
            SSRC of the RTP data packet source being reported upon by this
            report block. (<xref target="RFC3611">Section 4.1 of</xref>).
            <vspace blankLines="1" /></t>

            <t hangText="Initial Synchronization Delay: 32 bits"><vspace
            blankLines="0" /> The average delay, expressed in units of 1/65536
            seconds, between the RTCP packets received on all of the
            components RTP sessions and the beginning of session <xref
            target="I-D.ietf-avt-rapid-rtp-sync"></xref>. The value is
            calculated as follows: <vspace blankLines="1" /> <list>
                <t>The average time, expressed in units of 1/65536 seconds,
                taken to receive the first RTCP packet in the RTP session with
                the longest RTCP reporting interval <xref
                target="I-D.ietf-avt-rapid-rtp-sync"></xref></t>
              </list></t>
          </list></t>
      </section>

      <section anchor="AVPO"
               title="RTP Flow General Synchronization Offset Metrics Block">
        <t> In an RTP multimedia session, there can be an arbitrary number of
        streams, with the same RTCP CNAME. This block reports the general
        Synchronization offset requirements of these RTP streams beyond the
        information carried in the standard RTCP packet format. Information is
        recorded about the synchronization offset time of each RTP stream
        relative to the reference RTP stream with the same CNAME and General
        Synchronisation Offset of zero.. The RTP Flow General Synchronization
        Offset Report Block has the following format: <figure>
            <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=TBD    |I|  Reserved   |         Block length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                General Synchronization Offset                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure> <list style="hanging">
            <t hangText="Block type (BT): 8 bits"><vspace blankLines="0" />
            The Statistics Summary Report Block is identified by the constant
            &lt;AVPO&gt;. <vspace blankLines="1" /></t>

            <t hangText="Interval Metric flag (I): 1 bit"><vspace
            blankLines="1" /> This field is used to indicate whether the
            Audio-Video synchronization metrics are Interval or Cumulative
            metrics, that is, whether the reported values applies to the most
            recent measurement interval duration between successive metrics
            reports (I=1) (the Interval Duration) or to the accumulation
            period characteristic of cumulative measurements (I=0) (the
            Cumulative Duration).<vspace blankLines="1" /></t>

            <t hangText="Reserved: 8 bits"><vspace blankLines="0" /> This
            field is reserved for future definition. In the absence of such a
            definition, the bits in this field MUST be set to zero and MUST be
            ignored by the receiver. <vspace blankLines="1" /></t>

            <t hangText="Block length: 16 bits"><vspace blankLines="0" /> The
            constant 2, in accordance with the definition of this field in
            Section 3 of <xref target="RFC3611">RFC 3611</xref>. <vspace
            blankLines="1" /></t>

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

            <t hangText="General synchronization offset: 32 bits"><vspace
            blankLines="0" /> This field indicates the synchronization offset
            time of one RTP stream in milliseconds relative to the reference
            RTP stream with the same CNAME and General Synchronisation Offset
            of zero <xref target="I-D.ietf-avt-rapid-rtp-sync"></xref> This
            value is calculated based on the interarrival time between
            arbitray RTP packet and the reference RTP packet with the same
            CNAME , and timestamps of this arbitray RTP packet and the
            reference RTP packet with the same CNAME.</t>
          </list></t>
      </section>

      <section anchor="LSSM" title="Layered Streams Statistics Metrics Block">
        <t>This block reports layered streams statistics beyond the
        information carried in the Statistics Summary Report Block RTCP packet
        specified in the section 4.6 of <xref target="RFC3611">RFC
        3611</xref>. Information is recorded about lost layered component
        packets, duplicated layered component packets. Such information can be
        useful for network management and video quality monitoring. <vspace
        blankLines="1" /> The report block contents are dependent upon a
        series of flag bits carried in the first part of the header. Not all
        parameters need to be reported in each block. Flags indicate which
        parameters are reported and which are not. The fields corresponding to
        unreported parameters MUST be present, but are set to zero. The
        receiver MUST ignore any Layered Streams Statistics Metrics Block with
        a non-zero value in any field flagged as unreported. <vspace
        blankLines="1" /> The Layered Stream Statistics metrics Block has the
        following format: <figure>
            <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=TBD    |T|     rsd.    |        block length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          begin_seq            |             end_seq           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Lost_Layered Component Packets                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Dup Layered Component_Packets                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure> <list style="hanging">
            <t hangText="Block type (BT): 8 bits"><vspace blankLines="0" />
            The Layered stream Statistics Metrics Block is identified by the
            constant &lt;LSSM&gt;. <vspace blankLines="1" /></t>

            <t hangText="Layer Type flag (T): 1 bits"><vspace
            blankLines="0" /> This field is used to indicate the Layer Type of
            layered video to be reported. LT is set to 0 if the
            loss_component_packet field and dup_component packet contain the
            base layer packet in layered codecs,e.g, SVC in <xref
            target="I-D.ietf-avt-rtp-svc"></xref>, 1 if the loss_component
            packet field and dup_component packet contain enhancement layer
            packet in layered codec. <vspace blankLines="1" /></t>

            <t hangText="Rsd.: 3 bits"><vspace blankLines="0" /> This field is
            reserved for future definition. In the absence of such a
            definition, the bits in this field MUST be set to zero and MUST be
            ignored by the receiver.<vspace blankLines="1" /></t>

            <t hangText="Block length: 16 bits"><vspace blankLines="0" /> The
            constant 3, in accordance with the definition of this field in
            Section 3 of <xref target="RFC3611">RFC 3611</xref>. <vspace
            blankLines="1" /></t>

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

            <t hangText="begin_seq: 16 bits "><vspace blankLines="0" /> As
            defined in Section 4.1 of <xref target="RFC3611">RFC 3611</xref>.
            <vspace blankLines="1" /></t>

            <t hangText="end_seq: 16 bits "><vspace blankLines="0" /> As
            defined in Section 4.1 of <xref target="RFC3611">RFC 3611</xref>.
            <vspace blankLines="1" /></t>

            <t hangText="Lost_Layered Component Packets: 32 bits"><vspace
            blankLines="0" />Number of lost_component packets in the above
            sequence number interval.<vspace blankLines="1" /></t>

            <t hangText="Dup_Layered Component Packets: 32 bits"><vspace
            blankLines="0" />Number of dup_component packets in the above
            sequence number interval.<vspace blankLines="1" /></t>
          </list></t>
      </section>
    </section>

    <section title="Application Layer Metrics">
      <section anchor="VSS"
               title="RTP Streams Statistics Summary Report Block">
        <t>This block reports statistics beyond the information carried in the
        Statistics Summary Report Block RTCP packet specified in the section
        4.6 of <xref target="RFC3611">RFC 3611</xref>. Information is recorded
        about lost frame packets, duplicated frame packets, lost layered
        component packets, duplicated layered component packets. Such
        information can be useful for network management and video quality
        monitoring. <vspace blankLines="1" /> The report block contents are
        dependent upon a series of flag bits carried in the first part of the
        header. Not all parameters need to be reported in each block. Flags
        indicate which parameters are reported and which are not. The fields
        corresponding to unreported parameters MUST be present, but are set to
        zero. The receiver MUST ignore any Video Statistics Summary Report
        Block with a non-zero value in any field flagged as unreported.
        <vspace blankLines="1" /> The RTP Streams Statistics Summary Report
        Block has the following format: <figure>
            <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=TBD    |T|P|    rsd.   |        block length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          begin_seq            |             end_seq           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         lost_frames                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          dup frames                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    lost_partial frame packets                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     dup partial frame_packets                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure> <list style="hanging">
            <t hangText="Block type (BT): 8 bits"><vspace blankLines="0" />
            The Video Statistics Summary Report Block is identified by the
            constant &lt;VSS&gt;. <vspace blankLines="1" /></t>

            <t hangText="Picture type indicator (T): 1 bits"><vspace
            blankLines="0" /> Picture types used in the different video
            algorithms compose of key-frame and derivation frame. This field
            is used to indicate the frame type to be reported. Bits set to 0
            if the lost_frames field or dup_frames field contain a key_frame
            report or reference frame report, 1 if the lost_frames field and
            dup_frames field contain other derivation frame report. <vspace
            blankLines="1" /></t>

            <t hangText="P: 1 bit"><vspace blankLines="0" /> Bit set to 1 if
            the lost_partial frame packets field or the dup_partial_frame
            packets field contains a report, 0 otherwise. <vspace
            blankLines="1" /></t>

            <t hangText="Rsd.: 3 bits"><vspace blankLines="0" /> This field is
            reserved for future definition. In the absence of such a
            definition, the bits in this field MUST be set to zero and MUST be
            ignored by the receiver.<vspace blankLines="1" /></t>

            <t hangText="Block length: 16 bits"><vspace blankLines="0" /> The
            constant 5, in accordance with the definition of this field in
            Section 3 of <xref target="RFC3611">RFC 3611</xref>. <vspace
            blankLines="1" /></t>

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

            <t hangText="begin_seq: 16 bits "><vspace blankLines="0" /> As
            defined in Section 4.1 of <xref target="RFC3611">RFC 3611</xref>.
            <vspace blankLines="1" /></t>

            <t hangText="end_seq: 16 bits "><vspace blankLines="0" /> As
            defined in Section 4.1 of <xref target="RFC3611">RFC 3611</xref>.
            <vspace blankLines="1" /></t>

            <t hangText="lost_frames: 32 bits"><vspace blankLines="0" />
            Number of lost_frames in the above sequence number interval.
            <vspace blankLines="1" /></t>

            <t hangText="dup_frames: 32 bits"><vspace blankLines="0" /> Number
            of dup_frames in the above sequence number interval. <vspace
            blankLines="1" /></t>

            <t hangText="lost_partial frame packets: 32 bits"><vspace
            blankLines="0" /> Number of lost_partial frame packets in the
            above sequence number interval. <vspace blankLines="1" /></t>

            <t hangText="dup_partial frame packets: 32 bits"><vspace
            blankLines="0" /> Number of dup_partial frame packets in the above
            sequence number interval. <vspace blankLines="1" /></t>
          </list></t>
      </section>

      <section anchor="VSLDM"
               title="Video Stream Loss and Discard Metrics Block">
        <t>This block reports Loss and Discard metrics statistics beyond the
        information carried in the standard RTCP packet format. The block
        reports separately on packets lost on the IP channel, and those that
        have been received but then discarded by the receiving jitter buffer.
        <vspace blankLines="1" />It is very useful to distinguish between
        packets lost by the network and those discarded due to jitter. Both
        have equal effect on the quality of the video stream, however, having
        separate counts helps identify the source of quality degradation.
        These fields MUST be populated, and MUST be set to zero if no packets
        have been received. <vspace blankLines="1" /> Implementations MUST
        provide values for all the fields defined here. For certain metrics,
        if the value is undefined or unknown, then the specified default or
        unknown field value MUST be provided.<vspace blankLines="1" />The
        block is encoded as six 32-bit words: <figure>
            <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=TBD    |T |  reserved  |        block length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Loss rate            |        Discard rate           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure><list style="hanging">
            <t hangText="block type (BT): 8 bits"><vspace blankLines="0" /> A
            Video Stream Metrics Report Block is identified by the constant
            &lt;VSLDM&gt;. <vspace blankLines="1" /></t>

            <t hangText="Picture type indicator (T): 1 bits"><vspace
            blankLines="0" /> Picture types used in the different video
            algorithms compose of key-frame and derivation frame. This field
            is used to indicate the picture type to be reported. Bits set to 0
            if the Loss rate field and discard rate field contain a Key_frame
            report or reference frame report, 1 if the Loss rate field and
            discard rate field contain other derivation frame reports. <vspace
            blankLines="1" /></t>

            <t hangText="reserved: 6 bits"><vspace blankLines="0" /> This
            field is reserved for future definition. In the absence of such a
            definition, the bits in this field MUST be set to zero and MUST be
            ignored by the receiver. <vspace blankLines="1" /></t>

            <t hangText="block length: 16 bits"><vspace blankLines="0" /> The
            constant 1, in accordance with the definition of this field in
            Section 3 of <xref target="RFC3611">RFC 3611</xref>. <vspace
            blankLines="1" /></t>

            <t hangText="SSRC of source: 32 bits"><vspace blankLines="0" />
            The SSRC of the RTP data packet source being reported upon by this
            report block. in accordance with the definition of this field in
            Section 3 of <xref target="RFC3611">RFC 3611</xref>.</t>

            <t hangText="Loss rate: 8 bits"><vspace blankLines="0" /> The
            fraction of RTP data packets from the source lost since the
            beginning of reception, expressed as a fixed point number with the
            binary point at the left edge of the field. This value is
            calculated by dividing the total number of lost packets containing
            specified frame (e.g., Key frame) (after the effects of applying
            any error protection such as FEC) by the total number of packets
            expected, multiplying the result of the division by 256, limiting
            the maximum value to 255 (to avoid overflow), and taking the
            integer part. The numbers of duplicated packets and discarded
            packets do not enter into this calculation. Since receivers cannot
            be required to maintain unlimited buffers, a receiver MAY
            categorize late-arriving packets as lost. The degree of lateness
            that triggers a loss SHOULD be significantly greater than that
            which triggers a discard.<vspace blankLines="1" /></t>

            <t hangText="Discard rate: 8 bits"><vspace blankLines="0" /> The
            fraction of RTP data packets from the source that have been
            discarded since the beginning of reception, due to late or early
            arrival, under-run or overflow at the receiving jitter buffer.
            This value is expressed as a fixed point number with the binary
            point at the left edge of the field. It is calculated by dividing
            the total number of discarded packets containing specified frame
            (e.g., Key Frame) (excluding duplicate packet discards) by the
            total number of packets expected, multiplying the result of the
            division by 256, limiting the maximum value to 255 (to avoid
            overflow), and taking the integer part.<vspace
            blankLines="1" /></t>
          </list></t>
      </section>

      <section anchor="VSBM" title="Video Stream Burst Metrics Block">
        <t>This block reports Burst metrics statistics beyond the information
        carried in the standard RTCP packet format. It reports on the combined
        effect of losses and discards, as both have equal effect on video
        quality. <vspace blankLines="1" /> In order to properly assess the
        quality of a video stream, it is desirable to consider the degree of
        burstiness of packet loss <xref target="RFC3357">RFC 3357</xref>.
        Following the one-way loss pattern sample metrics discussed in <xref
        target="RFC3357"></xref>, a measure of the spacing between consecutive
        network packet loss or error events, is a ”loss distance”. The loss
        distance metric captures the spacing between the loss periods. The
        duration of a loss or error event (e.g. and how many packets are lost
        in that duration) is a “loss period”, the loss period metric captures
        the frequency and length (burstiness) of loss once it starts. Delay
        reports include the transit delay between RTP end points and the end
        system processing delays, both of which contribute to the user
        perceived delay. <vspace blankLines="1" />Implementations MUST provide
        values for all the fields defined here. For certain metrics, if the
        value is undefined or unknown, then the specified default or unknown
        field value MUST be provided. <vspace blankLines="1" />The block is
        encoded as six 32-bit words: <figure>
            <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=TBD    |  Reserved     |        block length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Loss Distance        |          Loss Period          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Max Loss Duration        |           Reserved.           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure><list style="hanging">
            <t hangText="block type (BT): 8 bits"><vspace blankLines="0" /> A
            Video Stream Metrics Report Block is identified by the constant
            &lt;VSBM&gt;. <vspace blankLines="1" /></t>

            <t hangText="reserved: 8 bits"><vspace blankLines="0" /> This
            field is reserved for future definition. In the absence of such a
            definition, the bits in this field MUST be set to zero and MUST be
            ignored by the receiver. <vspace blankLines="1" /></t>

            <t hangText="block length: 16 bits"><vspace blankLines="0" /> The
            constant 2, in accordance with the definition of this field in
            Section 3 of <xref target="RFC3611">RFC 3611</xref>. <vspace
            blankLines="1" /></t>

            <t hangText="SSRC of source: 32 bits"><vspace blankLines="0" />
            The SSRC of the RTP data packet source being reported upon by this
            report block. in accordance with the definition of this field in
            Section 3 of <xref target="RFC3611">RFC 3611</xref>.<vspace
            blankLines="1" /></t>

            <t hangText="Loss Distance: 16 bits"><vspace blankLines="0" /> The
            mean duration, expressed in milliseconds, of the loss intervals
            that have occurred since the beginning of reception <xref
            target="DSLF"></xref>. The duration of each loss distance is
            calculated based upon the frames that mark the beginning and end
            of that period. It is equal to the timestamp of the end frame,
            plus the duration of the end frame, minus the timestamp of the
            beginning frame. If the actual values are not available, estimated
            values MUST be used. If there have been no burst periods, the
            burst duration value MUST be zero. <vspace blankLines="1" /></t>

            <t hangText="Loss Period: 16 bits"><vspace blankLines="0" /> The
            mean duration, expressed in milliseconds, of the burst loss
            periods that have occurred since the beginning of reception <xref
            target="DSLF"></xref>. The duration of each period is calculated
            based upon the frame that marks the end of the prior burst loss
            and the frame that marks the beginning of the subsequent burst
            loss. It is equal to the timestamp of the subsequent burst frame,
            minus the timestamp of the prior burst packet, plus the duration
            of the prior burst packet. If the actual values are not available,
            estimated values MUST be used. In the case of a gap that occurs at
            the beginning of reception, the sum of the timestamp of the prior
            burst packet and the duration of the prior burst packet are
            replaced by the reception start time. In the case of a gap that
            occurs at the end of reception, the timestamp of the subsequent
            burst packet is replaced by the reception end time. If there have
            been no gap periods, the gap duration value MUST be zero. <vspace
            blankLines="1" /></t>

            <t hangText="Max Loss Duration of a single error: 16 bits"><vspace
            blankLines="0" /> The maximum loss duration, expressed in
            milliseconds, of the loss periods that have occurred since the
            beginning of reception. The recommended max loss duration is
            specified as less than 16 ms in <xref target="DSLF"></xref>, which
            provides a balance between interleaver depth protection from xDSL
            errors induced by impulse noise, delay added to other applications
            and video service QoE requirements to reduce visible
            impairments.<vspace blankLines="1" /></t>

            <t hangText="Reserved: 16 bits"><vspace blankLines="0" />All bits
            SHALL be set to 0 by the sender and SHALL be ignored on
            reception.<vspace blankLines="1" /></t>

            <t hangText="block length: 16 bits"><vspace blankLines="0" /> The
            constant 2, in accordance with the definition of this field in
            Section 3 of <xref target="RFC3611">RFC 3611</xref>. <vspace
            blankLines="1" /></t>
          </list></t>
      </section>

      <section anchor="SMQM"
               title="Synthetical Multimedia Quality Metrics Block">
        <t>This block reports the multimedia quality metrics beyond the
        information carried in the standard RTCP packet format. Information is
        recorded about Video MOS, Audio MOS, Audio Video MOS, Video Service
        Transmission Quality <xref target="G.1082"></xref><xref
        target="P.NAMS"></xref>. <vspace blankLines="1" /> The report block
        contents are dependent upon a series of flag bits carried in the first
        part of the header. Not all parameters need to be reported in each
        block. Flags indicate which are and which are not reported. The fields
        corresponding to unreported parameters MUST be present, but are set to
        zero. The receiver MUST ignore any Perceptual Quality Metrics Block
        with a non-zero value in any field flagged as unreported. <vspace
        blankLines="1" /> The Synthetical Multimedia Quality Metrics Block has
        the following format: <figure>
            <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=TBD    |I|V|A|M|T|Rsd. |        block length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              MOS-V            |           MOS-A               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              MOS-AV           |           VSTQ                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure> <list style="hanging">
            <t hangText="Block type (BT): 8 bits"><vspace blankLines="0" />
            The Perceptual Quality Metrics Block is identified by the constant
            &lt;SMQM&gt;. <vspace blankLines="1" /></t>

            <t hangText="Interval Metric flag (I): 1 bit "><vspace
            blankLines="0" /> This field is used to indicate whether the Basic
            Loss/Discard metrics are Interval or Cumulative metrics, that is,
            whether the reported values applies to the most recent measurement
            interval duration between successive metrics reports (I=1) (the
            Interval Duration) or to the accumulation period characteristic of
            cumulative measurements (I=0) (the Cumulative Duration). <vspace
            blankLines="1" /></t>

            <t hangText="MOS-V flag (V): 1 bit "><vspace blankLines="0" /> Bit
            set to 1 if the MOS-V field and MOS-AV field contain a report, 0
            otherwise. <vspace blankLines="1" /></t>

            <t hangText="MOS-A flag (A): 1 bit "><vspace blankLines="0" /> Bit
            set to 1 if the MOS-A field contain a report, 0 otherwise. <vspace
            blankLines="1" /></t>

            <t hangText="MOS-AV flag (M): 1 bit "><vspace blankLines="0" />
            Bit set to 1 if the MOS-AV field contain a report, 0 otherwise.
            <vspace blankLines="1" /></t>

            <t
            hangText="Video Service Transmission Quality flag (T): 1 bit "><vspace
            blankLines="0" /> Bit set to 1 if the VSTQ field contains a
            report, 0 otherwise. <vspace blankLines="1" /></t>

            <t hangText="Rsd.: 3 bits "><vspace blankLines="0" /> This field
            is reserved for future definition. In the absence of such a
            definition, the bits in this field MUST be set to zero and MUST be
            ignored by the receiver. <vspace blankLines="1" /></t>

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

            <t hangText="MOS-V: 16 bits"><vspace blankLines="0" /> The
            estimated mean opinion score for video quality (MOS-V) is a video
            quality metric on a scale from 1 to 5, in which 5 represents
            excellent and 1 represents unacceptable <xref
            target="G.1082"></xref><xref target="P.NAMS"></xref>. This metric
            is defined as not including the effects of audio impairments and
            can be compared to MOS scores obtained from video quality tests.
            It is expressed as an integer in the range 10 to 50, corresponding
            to MOS x 10. For example, a value of 35 would correspond to an
            estimated MOS score of 3.5. <vspace blankLines="1" /> A value of
            127 indicates that this parameter is unavailable. Values other
            than 127 and the valid range defined above MUST NOT be sent and
            MUST be ignored by the receiving system. <vspace
            blankLines="1" /></t>

            <t hangText="MOS-A: 16 bits"><vspace blankLines="0" /> The
            estimated mean opinion score for Audio quality (MOS-A) is defined
            as including the effects of delay and other effects that would
            affect Audio-Video quality <xref target="RFC3611"></xref>. It is
            expressed as an integer in the range 10 to 50, corresponding to
            MOS x 10, as for MOS-A.<vspace blankLines="1" /> A value of 127
            indicates that this parameter is unavailable. Values other than
            127 and the valid range defined above MUST not be sent and MUST be
            ignored by the receiving system.<vspace blankLines="1" /></t>

            <t hangText="MOS-AV: 16 bits"><vspace blankLines="1" /> The
            estimated mean opinion score for Audio-Video quality (MOS-AV) is
            defined as including the effects of delay and other effects that
            would affect Audio-Video quality <xref
            target="G.1082"></xref><xref target="P.NAMS"></xref>. It is
            expressed as an integer in the range 10 to 50, corresponding to
            MOS x 10, as for MOS-AV. A value of 127 indicates that this
            parameter is unavailable. Values other than 127 and the valid
            range defined above MUST NOT be sent and MUST be ignored by the
            receiving system. <vspace blankLines="1" /></t>

            <t hangText="VSTQ: 16 bits"><vspace blankLines="0" /> Video
            Service Transmission Quality (TBC) .<vspace blankLines="1" /></t>
          </list></t>
      </section>
    </section>

    <section title="SDP Signaling">
      <t>Six new parameters are defined for the six report blocks defined in
      this document to be used with Session Description Protocol (SDP) <xref
      target="RFC4566"></xref> using the Augmented Backus-Naur Form (ABNF)
      <xref target="RFC5234"></xref>. They have the following syntax within
      the "rtcp-xr" attribute <xref target="RFC3611"></xref>: <figure
          align="left">
          <artwork>
rtcp-xr-attrib =  "a=rtcp-xr:" 
                  [xr-format *(SP xr-format)] CRLF

   xr-format = RTP-flows-syn
               / audio-video-ofset
               / multimedia-quality-metrics
               / video-stream-loss-metrics
               / video-stream-burst-metrics
               / video-stat-summary
               / layered-video-stat-metrics

      RTP-flows-syn = "RTP-flows-syn" 
                      ["=" max-size]
         max-size = 1*DIGIT ; maximum block size in octets

      audio-video-ofset = "audio-video-ofset" 
                        ["=" max-size]
         max-size = 1*DIGIT ; maximum block size in octets
  
      video-stream-burst-metrics = "video-stream-burst-metrics" 
                            ["=" max-size]
         max-size = 1*DIGIT ; maximum block size in octets

      video-stream-loss-metrics = "video-stream-loss-metrics" 
                              ["=" stat-flag *("," stat-flag)]
            stat-flag = "key Frame loss and duplication"
                        / "derivation Frame loss and duplication"

      video-stat-summary = "video-stat-summary" 
                              ["=" stat-flag *("," stat-flag)]
            stat-flag = "key Frame loss and duplication"
                        / "derivation Frame loss and duplication"


      layered-stream-stat-metrics = "layered-stream-stat-metrics" 
                           ["=" stat-flag *("," stat-flag)]
            stat-flag = "base layer packet"
                        / "enhancment layer packet"

      multimedia-quality-metrics = "multimedia-quality-metrics" 
                            ["=" stat-flag *("," stat-flag)]
         stat-flag = "Interval Metric"
                     / "MOS-V"
                     / "MOS-A"
                     / "MOS-AV"
                     / "VSTQ"
</artwork>
        </figure> Refer to Section 5.1 of <xref target="RFC3611">RFC
      3611</xref> for a detailed description and the full syntax of the
      "rtcp-xr" attribute.</t>
    </section>

    <section title="IANA Considerations">
      <t>New report block types for RTCP XR are subject to IANA registration.
      For general guidelines on IANA allocations for RTCP XR, refer to <xref
      target="RFC3611">Section 6.2 of</xref>. <vspace blankLines="1" /> This
      document assigns six new block type values in the RTCP XR Block Type
      Registry: <list>
          <t><list hangIndent="12" style="hanging">
              <t hangText="Name:">RFISD</t>

              <t hangText="Long Name:">RTP Flows Initial Synchronization
              Delay</t>

              <t hangText="Value">&lt;RFISD&gt;</t>

              <t hangText="Reference:"><xref target="RFISD"></xref> <vspace
              blankLines="1" /></t>

              <t hangText="Name:">AVPO</t>

              <t hangText="Long Name:">Audio-Video Playout Offset</t>

              <t hangText="Value">&lt;AVPO&gt;</t>

              <t hangText="Reference:"><xref target="AVPO"></xref> <vspace
              blankLines="1" /></t>

              <t hangText="Name:">VSS</t>

              <t hangText="Long Name:">Video Statistics Summary</t>

              <t hangText="Value">&lt;VSS&gt;</t>

              <t hangText="Reference:"><xref target="VSS"></xref> <vspace
              blankLines="1" /></t>

              <t hangText="Name:">LSSM</t>

              <t hangText="Value">&lt;LSSM&gt;</t>

              <t hangText="Long Name:">Layered Stream Statistics Metrics</t>

              <t hangText="Reference:"><xref target="LSSM"></xref> <vspace
              blankLines="1" /></t>

              <t hangText="Name:">VSLDM</t>

              <t hangText="Long Name:">Video Stream Loss and Discard
              Metrics</t>

              <t hangText="Value">&lt;VSLDM&gt;</t>

              <t hangText="Reference:"><xref target="VSLDM"></xref> <vspace
              blankLines="1" /></t>

              <t hangText="Name:">VSBM</t>

              <t hangText="Long Name:">Video Stream Burst Metrics</t>

              <t hangText="Value">&lt;VSBM&gt;</t>

              <t hangText="Reference:"><xref target="VSBM"></xref> <vspace
              blankLines="1" /></t>

              <t hangText="Name:">SMQM</t>

              <t hangText="Long Name:">Synthetical Multimedia Quality
              Metric</t>

              <t hangText="Value">&lt;SMQM&gt;</t>

              <t hangText="Reference:"><xref target="SMQM"></xref> <vspace
              blankLines="1" /></t>
            </list></t>
        </list> This document also registers seven SDP <xref
      target="RFC4566"></xref> parameters for the "rtcp-xr" attribute in the
      RTCP XR SDP Parameters Registry: <list>
          <t><list style="symbols">
              <t>"RTP-flows-syn"</t>

              <t>“audio-video-ofset”</t>

              <t>“multimedia-quality-metrics”</t>

              <t>“video-stream-loss-metrics”</t>

              <t>“video-stream-burst-metrics”</t>

              <t>“video-stat-summary”</t>

              <t>“layered-stream-stat-metrics”</t>
            </list></t>
        </list> <vspace blankLines="1" /> The contact information for the
      registrations is: <figure align="center">
          <artwork>
Qin Wu
sunseawq@huawei.com
101 Software Avenue, Yuhua District 
Nanjing, JiangSu 210012 China
</artwork>
        </figure></t>
    </section>

    <section title="Security Considerations">
      <t>TBC</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors would like to thank Bill Ver Steeg, David R Oran, Ali
      Begen,Colin Perkins, Roni Even,Youqing Yang, Wenxiao Yu and Yinliang Hu
      for their valuable comments and suggestions on this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &I-D.ietf-avt-rapid-rtp-sync;

      &I-D.ietf-avt-rtp-svc;

      &rfc2250;

      &rfc3611;

      &rfc2119;

      &rfc4566;

      &rfc5234;

      &rfc3550;

      <reference anchor="ISO-IEC.13818-1.2007">
        <front>
          <title>Information technology - Generic coding of moving pictures
          and associated audio information: Systems</title>

          <author>
            <organization>International Organization for
            Standardization</organization>
          </author>

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

        <seriesInfo name="ISO" value="International Standard 13818-1" />
      </reference>
    </references>

    <references title="Informative References">
      &rfc3357;

      <reference anchor="DSLF">
        <front>
          <title>Triple-play Services Quality of Experience (QoE)
          Requirements</title>

          <author fullname="Tim Rahrer" initials="T.R." role="editor"
                  surname="Rahrer">
            <organization>Nortel</organization>

            <address>
              <postal>
                <street>3500 Carling Ave.</street>

                <city>Ottawa</city>

                <region>Ontario</region>

                <country>Canada</country>
              </postal>

              <phone>+1.613.763.4479</phone>

              <email>tim.rahrer@nortel.com</email>
            </address>
          </author>

          <author fullname="Riccardo Fiandra" role="editor" surname="Fiandra">
            <organization>FastWeb, SpA</organization>

            <address>
              <email>riccardo.fiandra@fastweb.it</email>
            </address>
          </author>

          <author fullname="Steven Wright" role="editor" surname="Wright">
            <organization>BellSouth Telecommunications</organization>

            <address>
              <email>steven.wright@bellsouth.com</email>
            </address>
          </author>

          <date day="13" month="December" year="2006" />
        </front>

        <seriesInfo name="DSL Forum Technical Report" value="TR-126" />
      </reference>

      <reference anchor="G.1082">
        <front>
          <title>Measurement-based methods for improving the robustness of
          IPTV performance</title>

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

          <date month="April" year="2009" />
        </front>

        <seriesInfo name="ITU-T Recommendation" value="G.1082" />
      </reference>

      <reference anchor="P.NAMS">
        <front>
          <title>Non-intrusive parametric model for the Assessment of
          performance of Multimedia Streaming</title>

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

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

        <seriesInfo name="ITU-T Recommendation" value="P.NAMS" />
      </reference>

      <reference anchor="IEEE">
        <front>
          <title>Human Perception of Jitter and Media Synchronization</title>

          <author>
            <organization>IEEE</organization>
          </author>

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

        <seriesInfo name="IEEE Journal on Selected Areas in Communications"
                    value="Vol. 14, No. 1" />
      </reference>

      <reference anchor="I-D.ietf-fecframe-interleaved-fec-scheme">
        <front>
          <title>RTP Payload Format for 1-D Interleaved Parity FEC</title>

          <author fullname="Ali Begen" initials="A" surname="Begen">
            <organization>Cisco</organization>
          </author>

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

        <seriesInfo name="Internet-Draft"
                    value="draft-ietf-fecframe-interleaved-fec-scheme-09" />

        <format target="http://tools.ietf.org/html/draft-ietf-fecframe-interleaved-fec-scheme-09"
                type="TXT" />
      </reference>

      <reference anchor="I-D.ietf-fecframe-raptor">
        <front>
          <title>Raptor FEC Schemes for FECFRAME</title>

          <author fullname="Mark Waston" initials="M" surname="Waston">
            <organization>Qualcomm</organization>
          </author>

          <date month="March" year="2010" />
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-ietf-fecframe-raptor-02" />

        <format target="http://tools.ietf.org/html/draft-ietf-fecframe-raptor-02"
                type="TXT" />
      </reference>
    </references>
  </back>
</rfc>
