<?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-xrblock-rtcp-xr-quality-monitoring-08"
     ipr="trust200902">
  <front>
    <title abbrev="RTCP XR QoE Report Blocks">RTCP XR Blocks for QoE metric
    reporting</title>

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

      <address>
        <email>r.geoff.hunt@gmail.com</email>
      </address>
    </author>

    <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="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="Roland Schott" initials="R." surname="Schott">
      <organization abbrev="DT">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>

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

    <date year="2011" />

    <abstract>
      <t>This document defines an RTCP XR Report Block and associated SDP
      parameters that allow the reporting of QoE metrics for use in a range of
      RTP applications.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <section title="QoE Metrics Report Block">
        <t>This draft defines a new block type to augment those defined in
        <xref target="RFC3611"></xref>, for use in a range of RTP
        applications. <vspace blankLines="1" />The new block type provides
        information on multimedia quality using one of several standard
        metrics.<vspace blankLines="1" />The metrics belong to the class of
        application level metrics defined in <xref target="MONARCH"></xref>
        (work in progress).</t>
      </section>

      <section title="RTCP and RTCP XR Reports">
        <t>The use of RTCP for reporting is defined in <xref
        target="RFC3550"></xref>. <xref target="RFC3611"></xref> 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 RFC3550 and RFC3611.</t>
      </section>

      <section title="Performance Metrics Framework">
        <t>The Performance Metrics Framework <xref target="PMOL"></xref>
        provides guidance on the definition and specification of performance
        metrics. Metrics described in this draft either reference external
        definitions or define metrics generally in accordance with the
        guidelines in <xref target="PMOL"></xref>.</t>
      </section>

      <section title="Applicability">
        <t>The QoE Metrics Report Block can be used in any application of RTP
        for which QoE measurement algorithms are defined.</t>

        <t>The factors that affect real-time AV 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 real time
        application (e.g., 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.</t>

        <t>Compared with application-specific factors, the transport-dependent
        factors sometimes are not sufficient to measure real time data
        quality, since the ability to analyze the real time data 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
        content quality is required.</t>

        <t>In order to provide accurate measures of real time application
        quality when transporting real time contents across a network, the
        synthentical multimedia quality Metrics is highly required which can
        be conveyed in the RTCP XR packets[RFC3611] and may have the following
        three benefits: <vspace blankLines="1" /><list style="symbols">
            <t>Tuning the content encoder algorithm to satisfy real time data
            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>
      </section>
    </section>

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

        <t>The terminology used is <vspace blankLines="1" /><list>
            <t>Numeric formats S X:Y<vspace blankLines="1" /><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 anchor="SMQM" title="QoE Metrics Block">
      <t>This block reports the multimedia application performance or quality
      beyond the information carried in the standard RTCP packet format.
      Information is recorded about multimedia application QoE metric which
      provides a measure that is indicative of the user's view of a service.
      Multimedia application QoE metric is commonly expressed as a MOS ("Mean
      Opinion Score"), MOS is on a scale from 1 to 5, in which 5 represents
      excellent and 1 represents unacceptable. MOS scores are usually obtained
      using subjective testing or using objective algorithm. However
      Subjective testing to estimate the multimedia quality may be not
      suitable for measuring the multimedia quality since the results may vary
      from test to test. Therefore using objective algorithm to calculate MOS
      scores is recommended. ITU-T recommendations define the methodologies
      for assessment of the performance of multimedia stream <xref
      target="G.107"></xref><xref target="P.564"></xref><xref
      target="G.1082"></xref><xref target="P.NAMS"></xref><xref
      target="P.NBAMS"></xref> and provides a method to evaluate QoE
      estimation algorithms and objective model for video and audio. Hence
      this document recommends vendors and implementers to use these
      International Telecommunication Union (ITU)-specified methodologies to
      measure parameters when possible. <vspace blankLines="1" /></t>

      <section title="Metric Block Structure">
        <t>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 QoE Metrics
        Block with a non-zero value in any field flagged as unreported. The
        encoding of QoE metrics block payload consists of a series of 32 bit
        units called segments that describe MOS Type, MoS algorithm and MoS
        value.</t>

        <t>The QoE 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 |   Rsd     |        block length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Segment  1                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Segment 2                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ..................
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Segment n                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   </artwork>
          </figure></t>
      </section>

      <section title="Definition of Fields in QoE Metrics Block">
        <t><list style="hanging">
            <t hangText="Block type (BT): 8 bits"><vspace blankLines="1" />The
            QoE Metrics Block is identified by the constant &lt;SMQ&gt;.
            <vspace blankLines="1" /></t>

            <t hangText="Interval Metric flag (I): 2 bit "><vspace
            blankLines="1" />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=01) (the
            Interval Duration) or to the accumulation period characteristic of
            cumulative measurements (I=00) (the Cumulative Duration) or to the
            value of a continuously measured or calculated that has been
            sampled at end of the interval (I=10) (Sampled Value). <vspace
            blankLines="1" /></t>

            <t hangText="Rsd.:6 bits "><vspace blankLines="1" /> 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="1" />The
            length of this report block in 32-bit words, minus one. For the
            QoE Metrics Block, the block length is variable length.<vspace
            blankLines="1" /></t>

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

            <t hangText="Segment i: 32 bits"><vspace blankLines="1" />There
            are three segment types : single stream per SSRC segment,
            multi-channel audio per SSRC segment, multi-layer per SSRC
            segment. Multi-channel per SSRC segment and multi-layer per SSRC
            segment are used to deal with the case where multiple elementary
            streams or components are carried in one RTP stream while single
            stream per SSRC segment is used to deal with the case where there
            is no more than one elementary stream or component in one RTP
            stream. The left two bits of the section determine its type. If
            the leftmost bit of the segment is zero, then it is single stream
            segment. If the leftmost bit is one and the second bit is zero,
            then it is multi-channel audio segment, if the leftmost bit is one
            and the second bit is one, then it is multi- view segment. Note
            that in these three segment type,any two segment types can not be
            present in the same metric block. <vspace blankLines="1" /></t>
          </list></t>

        <section title="Single Stream per SSRC Segment">
          <figure>
            <artwork>
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  MT   |CAlg |     Rsv.      |        MOS Value              |      
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure>

          <t><list style="hanging">
              <t hangText="Segment Type ( S): 1 bit"><vspace
              blankLines="1" />A zero identifies this as a single stream
              segment. Single stream means there is only one elementary stream
              carried in one RTP stream. The single stream segment can be used
              to report the MoS value associated with this elementary stream.
              If there are multiple streams and they want to use the single
              stream segment to report the MOS value, they should be carried
              in the separate RTP streams with different SSRC. In this case,
              multiple QoE Metrics Blocks are required to report the MOS value
              corresponding to each stream using single stream segment.<vspace
              blankLines="1" /></t>

              <t hangText="MoS Type (MT): 4 bits"><vspace
              blankLines="1" />This field is used to indicate the MOS type to
              be reported. The MOS type is defined as follows: <vspace
              blankLines="1" /><list>
                  <t>0000 MOS-LQ - Listening Quality MoS.</t>

                  <t>0001 MOS-CQ - Conversation Quality MoS.</t>

                  <t>0010 MOS-A - Audio Quality MOS.</t>

                  <t>0010 MOS-V - Video Quality MOS.</t>

                  <t>0011 MOS-AV - Audio-Video Quality MOS.</t>

                  <t>0100~1111 - Reserved for future definitions.<vspace
                  blankLines="1" /></t>
                </list>MoS-LQ measures the quality of audio for listening
              purposes only while MoS-CQ measures the quality of audio for
              conversation purpose only. MoS-A,MoS-V and MoS-AV measures the
              quality of audio application, the quality of video application
              and Audio-Video application respectively. Both MoS-LQ and MoS-CQ
              are commonly used in VoIP applications. MOS-LQ uses either
              wideband audio codec or narrowband audio codec, or both and does
              not take into account any of bidirectional effects, such as
              delay and echo. MOS-CQ uses narrowband codec and takes into
              account listening quality in each direction, as well as the
              bidirectional effects. G.107 and P.564 and ETSI TS101 329-5
              specify three MoS algorithms that are used to estimate speech
              quality or conversation quality. P.NAMS and P.NBAMS specify two
              MoS algorithms that are used to estimate multimedia quality
              including video quality, audio quality and audio-video quality.
              If MoS type is MoS-LQ and MoS-CQ, the MoS value can be
              calculated based on ITU-T G.107<xref target="G.107"></xref>,
              ITU-T P.564 <xref target="P.564"></xref>or ETSI TS 101 329-5
              <xref target="ETSI"></xref>, if the Mos type is MoS-V or MoS-AV,
              the Mos value can be calculated based on ITU-T P.NAMS <xref
              target="P.NAMS"></xref>or ITU-T P.NBAMS <xref
              target="P.NBAMS"></xref>. If new MOS types are defined, they can
              be added by an update to this document. If the receiver does not
              understand the MOS type defined in this document it should
              discard this report. If MoS Type does not match the MoS
              algorithm in the report (e.g., specify a voice MOS algorithm for
              a video quality MOS), the receiver should also discard this
              report.<vspace blankLines="1" /></t>

              <t hangText="Calculation Algorithm (CALg):3 bits"><vspace
              blankLines="1" /><list>
                  <t>000 - ITU-T P.564 Compliant Algorithm [P.564] (Voice)</t>

                  <t>001 - G.107 [G.107] (Voice)</t>

                  <t>010 - ETSI TS 101 329-5 Annex E [ ETSI] (Voice)</t>

                  <t>011 - ITU-T P.NAMS [P.NAMS] (Multimedia)</t>

                  <t>100 - ITU-T P.NBAMS [P.NBAMS] (Multimedia)</t>

                  <t>101~111 - Reserved for future extension.<vspace
                  blankLines="1" /></t>
                </list></t>

              <t hangText="Rsd.:8 bits "><vspace blankLines="1" /> 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="MOS Value: 16 bits"><vspace blankLines="1" />The
              estimated mean opinion score for multimedia application quality
              is defined as including the effects of delay,loss,
              discard,jitter and other effects that would affect multimedia
              quality . It is expressed in numeric format 8:8 with the value
              in the range 0.0 to 255.996. The valid the measured value ranges
              from 0.0 to 50.0, corresponding to MoS x 10 as for MoS. If the
              measured value is over ranged, the value 0xFFFE SHOULD be
              reported to indicate an over-range measurement. If the
              measurement is unavailable, the value 0xFFFF SHOULD be reported.
              Values other than 0xFFFE,0xFFFF and the valid range defined
              above MUST NOT be sent and MUST be ignored by the receiving
              system. <vspace blankLines="1" /></t>
            </list></t>
        </section>

        <section title="Multi-Layer per SSRC Segment">
          <figure>
            <artwork>
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|1|  MT   |CAlg |   SSID  |Rsv|        MOS Value              |      
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure>

          <t><list style="hanging">
              <t hangText="Segment Type ( S): 1 bit"><vspace
              blankLines="1" />A one identifies this as either a multi-channel
              segment or multi-layer segment.<vspace blankLines="1" /></t>

              <t hangText="Media Type (M): 1bit"><vspace blankLines="1" />A
              one identifies this as a multi-layer video segment.<vspace
              blankLines="1" /></t>

              <t hangText="MoS Type (MT): 4 bits"><vspace blankLines="1" />As
              defined in Section 3.2.1 of this document. If the value of this
              field is not for MoS-V, the receiver using multi-layer segment
              should discard this invalid segment with the wrong MoS
              Type.<vspace blankLines="1" /></t>

              <t hangText="Calculation Algorithm (CALg):3 bits"><vspace
              blankLines="1" /><list>
                  <t>000~010 - Reserved.</t>

                  <t>011 - ITU-T P.NAMS [P.NAMS] (Multimedia).</t>

                  <t>100 - ITU-T P.NBAMS [P.NBAMS] (Multimedia).</t>

                  <t>101~111 - Reserved for future extension.<vspace
                  blankLines="1" /></t>
                </list></t>

              <t hangText="Sub Stream Identifier (SSID): 5 bits"><vspace
              blankLines="1" />If multiple layers of video are carried in the
              same RTP stream, each layer will be viewed as a sub stream.
              Specially, If multiple views of video are carried in the same
              RTP stream, each view will be viewed as a sub stream. This field
              is used to identify each layer of video that is carried in the
              same media stream. NAL unit type is one example of such SSID.
              <vspace blankLines="1" />(Editor's Note: It's not sufficient to
              simply say that a "NAL unit type is one example", the draft
              needs to give normative rules for the use of this field)<vspace
              blankLines="1" /></t>

              <t hangText="Rsd.:2 bits "><vspace blankLines="1" /> 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="MOS Value: 16 bits"><vspace blankLines="1" />As
              defined in Section 3.2.1 of this document.<vspace
              blankLines="1" /></t>
            </list></t>
        </section>

        <section title="Multi-Channel per SSRC Segment">
          <figure>
            <artwork>
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|  MT   |CAlg |  CHID | Rsv.|        MOS Value              |      
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure>

          <t><list style="hanging">
              <t hangText="Segement Type ( S): 1 bit"><vspace
              blankLines="1" />A one identifies this as either a multi-channel
              segment or multi-layer segment.<vspace blankLines="1" /></t>

              <t hangText="Media Type (M): 1bit"><vspace blankLines="1" />A
              zero identifies this as a multi-channel per SSRC segment.<vspace
              blankLines="1" /></t>

              <t hangText="MoS Type (MT): 4 bits"><vspace blankLines="1" />As
              defined in Section 3.2.1 of this document. If the value of this
              field is not for MoS-CQ or MoS-LQ, the receiver using
              multi-channel segment should discard this invalid segment with
              the wrong MoS Type. <vspace blankLines="1" /></t>

              <t hangText="Calculation Algorithm (CALg):3 bits"><vspace
              blankLines="1" /><list>
                  <t>000 - ITU-T P.564 Compliant Algorithm [P.564] (Voice)</t>

                  <t>001 - G.107 [G.107] (Voice)</t>

                  <t>010 - ETSI TS 101 329-5 Annex E, [ ETSI] (Voice)</t>

                  <t>011~100 - Reserved.</t>

                  <t>101~111 - Reserved for future extension.<vspace
                  blankLines="1" /></t>
                </list></t>

              <t hangText="Channel Identifier (CHID): 4 bits"><vspace
              blankLines="1" />This field is used to identify each channel
              that is carried in the same media stream. If multiple channels
              of audio are carried in one RTP stream, each channel of audio
              will be viewed as a independent channel(e.g., left channel
              audio, right channel audio). Channel mapping follows static
              ordering rule described in the section 4.1 of <xref
              target="RFC3551"></xref>. <vspace blankLines="1" />(Editor's
              Note: It is not clear that the channel mapping in RFC 3551
              Section 4.1 is the only one in use)<vspace blankLines="1" /></t>

              <t hangText="Rsd.:3 bits "><vspace blankLines="1" /> 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="MOS Value: 16 bits"><vspace blankLines="1" />As
              defined in Section 3.2.1 of this document.<vspace
              blankLines="1" /></t>
            </list></t>
        </section>
      </section>
    </section>

    <section title="SDP Signaling">
      <t>One new parameter is defined for the report block 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>. It has 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 = qoe-metrics
         qoe-metrics = "multimedia-quality-metrics"
</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 block types for RTCP XR are subject to IANA registration. For
      general guidelines on IANA considerations for RTCP XR, refer to <xref
      target="RFC3611"></xref>.</t>

      <section title="New RTCP XR Block Type value">
        <t>This document assigns the block type value NDEL in the IANA "RTCP
        XR Block Type Registry" to the "QoE Metrics Block".</t>

        <t>[Note to RFC Editor: please replace SMQ with the IANA provided RTCP
        XR block type for this block.]</t>
      </section>

      <section title="New RTCP XR SDP Parameter">
        <t>This document also registers a new parameter "qoe-metrics" in the
        "RTCP XR SDP Parameters Registry".</t>
      </section>

      <section title="Contact information for registrations">
        <t>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="New registry of calculation algorithms for single stream per SSRC segment">
        <t>This document creates a new registry for single stream per SSRC
        segment defined in the section 3.2.1 to be called "RTCP XR QoE metric
        block - multimedia application Calculation Algorithm" as a
        sub-registry of the "RTP Control Protocol Extended Reports (RTCP XR)
        Block Type Registry". This registry applies to the multimedia session
        where each type of media are sent in a separate RTP stream. Specially
        this registry also applies to the layered video session where each
        layer video are sent in a separate RTP stream. Policies for this new
        registry are as follows: <vspace blankLines="1" /><list
            style="symbols">
            <t>The information required to support this assignment is an
            unambiguous definition of the new metric, covering the base
            measurements and how they are processed to generate the reported
            metric. This should include the units of measurement, how values
            of the metric are reported in the one 16-bit fields "MoS
            Value".</t>

            <t>The review process for the registry is "Specification Required"
            as described in Section 4.1 of <xref target="RFC5226"></xref>.</t>

            <t>Entries in the registry are integers. The valid range is 0 to 7
            corresponding to the 3-bit field "CAlg" in the block. Values are
            to be recorded in decimal. <vspace blankLines="1" /></t>

            <t>Initial assignments are as follows:<vspace
            blankLines="1" /><list style="numbers">
                <t>ITU-T P.564 Compliant Algorithm [P.564] (Voice)</t>

                <t>G.107 [G.107] (Voice)</t>

                <t>ETSI TS 101 329-5 Annex E [ ETSI] (Voice)</t>

                <t>ITU-T P.NAMS [P.NAMS] (Multimedia)</t>

                <t>ITU-T P.NBAMS [P.NBAMS] (Multimedia)<vspace
                blankLines="1" /></t>
              </list></t>
          </list></t>
      </section>

      <section title="New registry of calculation algorithms for multi-layer per SSRC segment">
        <t>This document creates a new registry for multi-layer per SSRC
        segment defined in the section 3.2.2 to be called "RTCP XR QoE metric
        block – layered application Calculation Algorithm" as a sub-registry
        of the "RTP Control Protocol Extended Reports (RTCP XR) Block Type
        Registry" if multi-layer video are carried in the same RTP stream.
        Policies for this new registry are as follows: <vspace
        blankLines="1" /><list style="symbols">
            <t>The information required to support this assignment is an
            unambiguous definition of the new metric, covering the base
            measurements and how they are processed to generate the reported
            metric. This should include the units of measurement, how values
            of the metric are reported in the one 16-bit fields "MoS
            Value".</t>

            <t>The review process for the registry is "Specification Required"
            as described in Section 4.1 of <xref target="RFC5226"></xref>.</t>

            <t>Entries in the registry are integers. The valid range is 0 to 7
            corresponding to the 3-bit field "CAlg" in the block. Values are
            to be recorded in decimal.</t>

            <t>Initial assignments are as follows:<vspace
            blankLines="1" /><list style="numbers">
                <t>ITU-T P.NAMS [P.NAMS] (Multimedia)</t>

                <t>ITU-T P.NBAMS [P.NBAMS] (Multimedia)<vspace
                blankLines="1" /></t>
              </list></t>
          </list></t>
      </section>

      <section title="New registry of calculation algorithms for multi-channel per SSRC segment">
        <t>This document creates a new registry for multi-channel per SSRC
        segment defined in the section 3.2.3 to be called "RTCP XR QoE metric
        block – multi-channel application Calculation Algorithm" as a
        sub-registry of the "RTP Control Protocol Extended Reports (RTCP XR)
        Block Type Registry" if multi-channel voice data are carried in the
        same RTP stream. Policies for this new registry are as follows:
        <vspace blankLines="1" /><list style="symbols">
            <t>The information required to support this assignment is an
            unambiguous definition of the new metric, covering the base
            measurements and how they are processed to generate the reported
            metric. This should include the units of measurement, how values
            of the metric are reported in the one 16-bit fields "MoS
            Value".</t>

            <t>The review process for the registry is "Specification Required"
            as described in Section 4.1 of <xref target="RFC5226"></xref>.</t>

            <t>Entries in the registry are integers. The valid range is 0 to 7
            corresponding to the 3-bit field "CAlg" in the block. Values are
            to be recorded in decimal.</t>

            <t>Initial assignments are as follows:<vspace
            blankLines="1" /><list style="numbers">
                <t>ITU-T P.564 Compliant Algorithm [P.564] (Voice)</t>

                <t>G.107 [G.107] (Voice)</t>

                <t>ETSI TS 101 329-5 Annex E [ ETSI] (Voice)<vspace
                blankLines="1" /></t>
              </list></t>
          </list></t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>The new RTCP XR report blocks proposed in this document introduces no
      new security considerations beyond those described in <xref
      target="RFC3611"></xref>.</t>
    </section>

    <section title="Authors">
      <t>This draft merges ideas from two different drafts addressing the QoE
      metric Reporting issue. The authors of these drafts are listed below (in
      alphabetical order) : <list>
          <t>Alan Clark &lt; alan.d.clark@telchemy.com &gt;</t>

          <t>Geoff Hunt &lt; r.geoff.hunt@gmail.com &gt;</t>

          <t>Martin Kastner &lt; martin.kastner@telchemy.com &gt;</t>

          <t>Kai Lee &lt; leekai@ctbri.com.cn &gt;</t>

          <t>Roland Schott &lt; roland.schott@telekom.de &gt;</t>

          <t>Qin Wu &lt; sunseawq@huawei.com &gt;</t>

          <t>Glen Zorn &lt; gwz@net-zen.net &gt;</t>
        </list></t>
    </section>

    <section title="Acknowledgements">
      <t>The authors would like to thank Alan Clark, 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">
      &rfc3611;

      <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="RFC3551">
        <front>
          <title>RTP Profile for Audio and Video Conferences with Minimal
          Control</title>

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

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

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

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

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

      &rfc2119;

      &rfc4566;

      &rfc5234;

      <reference anchor="RFC5226">
        <front>
          <title>Guidelines for Writing an IANA Considerations Section in
          RFCs</title>

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

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

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

        <format target="http://www.rfc-editor.org/rfc/rfc5226.txt" type="TXT" />
      </reference>
    </references>

    <references title="Informative References">
      <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.564">
        <front>
          <title>Conformance testing for narrowband Voice over IP transmission
          quality assessment models</title>

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

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

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

      <reference anchor="G.107">
        <front>
          <title>The E Model, a computational model for use in transmission
          planning</title>

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

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

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

      <reference anchor="ETSI">
        <front>
          <title>Quality of Service (QoS) measurement methodologies</title>

          <author>
            <organization>ETSI</organization>
          </author>

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

        <seriesInfo name="ETSI" value="TS 101 329-5 V1.1.1" />
      </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="P.NBAMS">
        <front>
          <title>non-intrusive bit-stream model for 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.NBAMS" />
      </reference>

      <reference anchor="MONARCH">
        <front>
          <title>Monitoring Architectures for RTP</title>

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

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

        <seriesInfo name="ID" value="draft-ietf-avtcore-monarch-00" />

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

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

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

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

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

        <seriesInfo name="ID" value="draft-ietf-pmol-metrics-framework-12" />
      </reference>
    </references>

    <section title="Change Log">
      <section title="draft-wu-xrblock-rtcp-xr-quality-monitoring-03">
        <t>The following are the major changes compared to previous version
        02: <list style="symbols">
            <t>Remove the tag field.</t>

            <t>Define MOS Value field as 32 bits integer value field.</t>

            <t>Clear unused references.</t>

            <t>Add text to MOS type field for clarification.</t>

            <t>Other Editorial changes.</t>
          </list></t>
      </section>

      <section title="draft-wu-xrblock-rtcp-xr-quality-monitoring-04">
        <t>The following are the major changes compared to previous version
        03: <list style="symbols">
            <t>Add Numeric format definition and express the MoS-Value in
            Numeric format.</t>

            <t>Change 32bits MoS Value into 16bits MoS Value.</t>

            <t>Add some text to MoS Type definition to clarify the algorithm
            calculation.</t>

            <t>Separate MoS-A into MoS-LQ and MoS-CQ and add some text to
            clarify the difference between them.</t>

            <t>Add one more reference for MoS-LQ and MoS-CQ value
            calculation.</t>

            <t>Other Editorial changes.</t>
          </list></t>
      </section>

      <section title="draft-wu-xrblock-rtcp-xr-quality-monitoring-05">
        <t>The following are the major changes compared to previous version
        04: <list style="symbols">
            <t>Merge this draft with Clack's draft</t>

            <t>Define three segment types to distinguish multiple elementary
            stream carried in the same RTP stream from multiple elementary
            stream carried in each different RTP stream</t>

            <t>Allocate 3 bit for MOS calculation algorithms in each
            segment.</t>

            <t>Allocate or move 4 bit for MOS Type to each segment</t>

            <t>Other Editorial changes.</t>
          </list></t>
      </section>

      <section title="draft-wu-xrblock-rtcp-xr-quality-monitoring-06">
        <t>The following are the major changes compared to previous version
        05: <list style="symbols">
            <t>Specify how sub-streams are identified.</t>

            <t>Change multi-view segment into multi-layer segment.</t>

            <t>Move MoS Type field before Calg field.</t>

            <t>Provide guidance on how new calculation algorithms can be
            registered</t>

            <t>Define the channel mapping algorithm for multi-channel
            segment</t>
          </list></t>
      </section>

      <section title="draft-wu-xrblock-rtcp-xr-quality-monitoring-07">
        <t>The following are the major changes compared to previous version
        05: <list style="symbols">
            <t>Add MoS-A as one new MoS Type to distinguish from MoS-LQ and
            MoS-CQ.</t>

            <t>Add guidance on which algorithm is appropriate for which MOS
            type.</t>

            <t>Add restriction on MOS Type and algorithm choice to multi-layer
            segment and multi-channel segment.</t>

            <t>Other editorial changes.</t>
          </list></t>
      </section>

      <section title="draft-wu-xrblock-rtcp-xr-quality-monitoring-08">
        <t>The following are the major changes compared to previous version
        07: <list style="symbols">
            <t>Define registries for each segment type rather than various
            applications.</t>

            <t>Add cross references to each registry.</t>

            <t>Typo fixed for section number.</t>
          </list></t>
      </section>
    </section>
  </back>
</rfc>
