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

<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

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

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

  <front>
    <title abbrev=" RTCP XR TS Decodability">RTP Control Protocol (RTCP)
    Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program
    Specific Information (PSI) Decodability Statistics Metrics
    Reporting</title>


    <author fullname="Jiangang Tong" initials="J." surname="Tong">
      <organization abbrev="China Telecom">Shanghai Research Institute of
      China Telecom Corporation Limited</organization>

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

          <city>Shanghai</city>

          <code>200122</code>

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

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

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

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

          <city>Shanghai</city>

          <code>200122</code>

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

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

    <author fullname="Roni Even" initials="R." surname="Even">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>14 David Hamelech</street>

          <city>Tel Aviv</city>

          <code>64953</code>

          <country>Israel</country>
        </postal>

        <email>roni.even@mail01.huawei.com</email>
      </address>
    </author>

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

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

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

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

        <email>bill.wu@huawei.com</email>
      </address>
    </author>

    <author fullname="Rachel Huang" initials="R." surname="Huang">
      <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>rachel.huang@huawei.com</email>
      </address>
    </author>

    <date month='November' year="2014"/>

<keyword>TR 101 290</keyword>

    <abstract>
      <t>An MPEG2 Transport Stream (TS) is a standard container format used in
      the transmission and storage of multimedia data. Unicast/multicast MPEG2
      TS over RTP is widely deployed in IPTV systems. This document defines an
      RTP Control Protocol (RTCP) Extended Report (XR) block that allows the
      reporting of MPEG2 TS decodability statistics metrics related to
      transmissions of MPEG2 TS over RTP. The metrics specified in the RTCP XR
      block are related to Program Specific Information (PSI) carried in MPEG
      TS.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <section title="MPEG2 Transport Stream Decodability Metrics">
        <t>The European Telecommunications Standards Institute (ETSI) has
        defined a set of syntax and information consistency tests and
        corresponding indicators <xref target="ETSI"/> that are recommended
        for the monitoring of MPEG2 Transport Streams <xref
        target="ISO-IEC.13818-1.2007"/>. The tests and corresponding
        indicators are grouped according to priority: 

<list style="hanging" hangIndent="15">
            <t hangText="First priority:">Necessary for decodability (basic
            monitoring)</t>

            <t hangText="Second priority:">Recommended for continuous or periodic
            monitoring</t>

            <t hangText="Third priority:">Recommended for application-dependent
            monitoring</t>
          </list></t>



        <t>This memo defines a new block type for use with MPEG2 Transport
        Streams <xref target="ISO-IEC.13818-1.2007"/> to augment those
        defined in <xref target="RFC3611"/>. The new block type supports
        reporting of the number of occurrences of each Program Specific
        Information (PSI) indicator in the first and second priorities listed
        in Sections 5.2.1 and 5.2.2, respectively, of
	<xref target="ETSI"/>. The third
        priority indicators are not supported. The metrics defined here
        supplement information from the PSI-Independent Decodability
        Statistics Metrics Block <xref target="RFC6990"/>.</t>
      </section>


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

      <section title="Performance Metrics Framework">
        <t>The Performance Metrics Framework <xref target="RFC6390"/> provides guidance on
        the definition and specification of performance metrics. The RTP
        Monitoring Architectures <xref target="RFC6792"/> provides guidelines
        for RTCP XR block formats. The new report block described in
        this memo is in compliance with the monitoring architecture specified
        in <xref target="RFC6792"/> and the Performance Metrics Framework
        <xref target="RFC6390"/>.</t>
      </section>

      <section title="Applicability">
        <t>These metrics are applicable to any type of RTP application that
        uses the MPEG2 TS standard format for multimedia data, for example,
        MPEG4 over MPEG2 TS over RTP. This new block type can be useful for
        measuring content stream or TS quality by checking TS header
        information <xref target="ETSI"/> and identifying the existence (and
        characterizing the severity) of bitstream packetization problems that
        may affect users' perception of a service delivered over RTP. It may
        also be useful for verifying the continued correct operation of an
        existing system management tool.</t>
      </section>
    </section>

<section title="Terminology">

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

    </section>
</section>

    <section anchor="TDM"
             title="MPEG2 TS PSI Decodability Statistics Metrics Block">


      <t>ETSI TR 101 290 <xref target="ETSI"/> generally defines indicators
      related to error events whereas the XR block defined in this document
      contains counts of occurrences of the <xref target="ETSI"/> indicators.
      The block defined in this document reports MPEG2 TS PSI decodability
      statistics metrics beyond the information carried in the standard RTCP
      packet format and PSI-Independent Decodability Statistics Metrics Block <xref target="RFC6990"/>,
      which are measured at the receiving end of the RTP stream. It contains
      counts of seven metrics defined in ETSI TR 101 290 <xref target="ETSI"/>.
      Information is reported about basic monitoring parameters necessary to
      ensure that the TS can be decoded, including:
      <list style="symbols">
          <t>Program Association Table (PAT) errors</t>

          <t>PAT2 errors</t>

          <t>Program Map Table (PMT) errors</t>

          <t>PMT2 errors</t>

          <t>Packet Identifier (PID) errors</t>
        
      </list>Information is also reported about continuous monitoring parameters necessary to ensure
      continuous decoding, including: 
      <list style="symbols">
          <t>Cyclic Redundancy Check (CRC) errors</t>

          <t>Conditional Access Table (CAT) errors</t>

        </list>In these parameters, PAT2 errors and PMT2 errors are actually
      replacements for and improvements on PAT errors and PMT errors,
      respectively, and are therefore preferred in future implementations. In
      addition, measurement results for some of these parameters (e.g., PAT
      errors or PMT errors) may be different based on whether scrambling is
      employed. The other parameters defined in Section 5 of <xref
      target="ETSI"/> are ignored
      since they do not apply to all MPEG2 implementations. For further
      detailed information on these parameters, see <xref target="ETSI"/>.</t>
      <t></t>
      <t>The MPEG2 TS PSI Decodability 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=32    |    Reserved   |         block length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     SSRC of source                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          begin_seq            |             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        PAT_error_count        |      PAT_error_2_count        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                    
   |        PMT_error_count        |      PMT_error_2_count        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       PID_error_count         |      CRC_error_count          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        CAT_error_count        |        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        </figure><list style="hanging"> 
	  <t hangText="block type (BT): 8 bits"><vspace blankLines="1"/>
	  The MPEG2 TS PSI Decodability Metrics Block is identified by the
          constant 32;.</t>

          <t hangText="Reserved: 8 bits"><vspace blankLines="1"/>
	  These bits are reserved. They MUST be set to zero by senders ignored by
          receivers (see Section 4.2 of <xref target="RFC6709"/>).
	  </t>
	  
          <t hangText="block length: 16 bits"><vspace blankLines="1"/>
	  The constant 6, in accordance with the definition of this field in
          Section 3 of <xref target="RFC3611"/>. The block MUST be discarded if the block
          length is set to a different value.</t>

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

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

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

          <t hangText="PAT_error_count: 16 bits"><vspace blankLines="1"/>A
          count of the number of PAT errors that occurred in the above
          sequence number interval. The Program Association Table (PAT) is the
          only packet with Packet Identifier (PID) 0x0000. A PAT error occurs when
          (1) a packet with PID 0x0000 does not occur at least every 0.5
          seconds, (2) a packet with PID 0x0000 does not contain table_id
          0x00 (i.e., a PAT), or (3) the Scrambling_control_field in the TS packet
          header is not 00 for a packet with PID 0x0000. See Section 5.2.1 of
          <xref target="ETSI"/>. Every program within the MPEG TS stream is listed in the
          PAT; if it is missing, then no programs can be decoded. 
	  <vspace blankLines="1"/>
	  The measured value is an unsigned value. If the
          measurement is unavailable, then the value 0xFFFF MUST be reported.  NOTE 1 of the table in Section 5.2.1 of <xref target="ETSI" /> recommends using
   PAT_error_2_count.

 Upon
          reception, if PAT_error_2_count is available (that is, other than
          0xFFFF), then receivers MUST ignore PAT_error_count.</t>


          <t hangText="PAT_error_2_count: 16 bits"><vspace blankLines="1"/>A
          count of the number of PAT2 errors that occurred in the above
          sequence number interval. A PAT2 error occurs when (1) a packet
          with PID 0x0000 containing table_id 0x00 does not occur at least
          every 0.5 seconds, (2) a packet with PID 0x0000 contains a table
          with a table_id other than 0x00, or (3) the Scrambling_control_field in
          the TS packet header is not 00 for a packet with PID 0x0000. See
          Section 5.2.1 of <xref target="ETSI"/>. <vspace blankLines="1"/>The measured value
          is an unsigned value. If the measurement is unavailable, then the value
          0xFFFF MUST be reported.</t>

          <t hangText="PMT_error_count: 16 bits"><vspace blankLines="1"/>A
          count of the number of PMT errors that occurred in the above
          sequence number interval. A PMT_error occurs when (1) a packet
          containing a table with table_id 0x02 (i.e., a PMT) does not occur at
          least every 0.5 seconds on the PID that is referred to in the PAT or
	  (2) the
          Scrambling_control_field in the TS packet header is not 00 for all
          packets with PID containing a table with table_id 0x02 (i.e., a PMT).
          See Section 5.2.1 of <xref target="ETSI"/>. 
	  <vspace blankLines="1"/>
	  The measured value is an unsigned value. If the measurement is unavailable,
          the value 0xFFFF MUST be reported. NOTE 2 of the table in Section 5.2.1 of <xref target="ETSI" /> recommends using
   PMT_error_2_count.


 Upon reception, if PMT_error_2_count is available
          (that is, other than 0xFFFF), then receivers MUST ignore
          PMT_error_count.</t>

          <t hangText="PMT_error_2_count: 16 bits"><vspace blankLines="1"/>A
          count of the number of PMT2 errors that occurred in the above
          sequence number interval. A PMT2_error occurs when (1) a packet
          containing table_id 0x02 (i.e., a PMT) does not occur at least every
          0.5 seconds on each program_map_PID that is referred to in the PAT
	  or (2) the
          Scrambling_control_field in the TS packet header is not 00 for all
          packets containing a table with table_id 0x02 (i.e., a PMT) on each
          program_map_PID that is referred to in the PAT. See Section 5.2.1
          of <xref target="ETSI"/>. 
	  <vspace blankLines="1"/>
	  The measured value is an unsigned
          value. If the measurement is unavailable, then the value 0xFFFF MUST be
          reported.</t>

          <t hangText="PID_error_count: 16 bits"><vspace blankLines="1"/>A
          count of the number of PID errors that occurred in the above
          sequence number interval. A PID error occurs when no data stream is
          present corresponding to a given PID. This may be caused by
          multiplexing or demultiplexing, then remultiplexing. See Section
          5.2.1 of <xref target="ETSI"/>. 
	  <vspace blankLines="1"/>
	  The measured value is an
          unsigned value. If the measurement is unavailable, then the value 0xFFFF
          MUST be reported.</t>

          <t hangText="CRC_error_count: 16 bits"><vspace blankLines="1"/>A
          count of the number of CRC errors that occurred in the above
          sequence number interval. A CRC_error occurs if data corruption
          occurred in any of the following tables -- CAT, PAT, PMT, Network
          Information Table (NIT), Event Information Table (EIT), Bouquet
          Association Table (BAT), Service Description Table (SDT), or Time
          Offset Table (TOT), as defined in Section 5.2.2 of <xref target="ETSI"/>.
          <vspace blankLines="1"/>The measured value is an unsigned value. If the
          measurement is unavailable, then the value 0xFFFF MUST be reported.</t>


          <t hangText="CAT_error_count: 16 bits"><vspace blankLines="1"/>A
          count of the number of CAT errors that occurred in the above
          sequence number interval. A CAT_error occurs when (1) a packet with
          PID 0x0001 contains a table with a table_id other than 0x01 (i.e., not a
          CAT) or (2) a packet does not contain a table with table_id = 0x01
          (i.e., a CAT) when scrambling is employed (i.e., the Scrambling_control_field is set as a value other than 00). See Section 5.2.2 of
          <xref target="ETSI"/>. <vspace blankLines="1"/>The measured value is
	  an unsigned
          value. If the measurement is unavailable, then the value 0xFFFF MUST be
          reported.</t>

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

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

      <section title="SDP rtcp-xr-attrib Attribute Extension">
        <t>This session augments the SDP attribute "rtcp-xr" defined in
        Section 5.1 of <xref target="RFC3611"/> by providing an additional value of
        "xr-format" to signal the use of the report block defined in this
        document.  The ABNF <xref target="RFC5234" /> syntax is as follows:<figure>
            <artwork>
xr-format =/  xr-tpd-block

xr-tpd-block = "ts-psi-decodability"
</artwork>
          </figure></t>

      </section>

      <section title="Offer/Answer Usage">
        <t>When SDP is used in Offer/Answer context, the SDP Offer/Answer
        usage defined in <xref target="RFC3611"/> for unilateral "rtcp-xr"
        attribute parameters applies. For detailed usage of Offer/Answer for
        unilateral parameters, refer to Section 5.2 of <xref
        target="RFC3611"/>.</t>
      </section>

      <section title="Usage Outside of Offer/Answer">
        <t>For usage outside of Offer/Answer, refer to Section 5.3 of <xref
        target="RFC3611"/>.</t>
      </section>
    </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 Section
      6.2 of <xref target="RFC3611"/>.</t>

      <section title="New RTCP XR Block Type Value">
        <t>This document assigns the block type value 32 "MPEG2 Transport Stream PSI Decodability Statistics Metrics
        Block" in the "RTCP XR Block Type" subregistry of the IANA "RTP
        Control Protocol Extended Reports (RTCP XR) Block Type Registry".</t>

      </section>

      <section title="New RTCP XR SDP Parameter">
        <t>This document also registers a new parameter "ts-psi-decodability"
        in the "RTCP XR SDP Parameters" subregistry of the "RTP Control Protocol Extended Reports (RTCP XR) Session
        Description Protocol (SDP) Parameters Registry".</t>
      </section>

      <section title="Contact Information for Registrations">
        <t>The contact information for the registrations is:</t>

        <figure align="center">
          <artwork>
RAI Area Directors &lt;rai-ads@tools.ietf.org&gt;
</artwork>
        </figure>
      </section>
    </section>

    <section title="Security Considerations">
      <t>This proposed RTCP XR block introduces no new security
      considerations beyond those described in <xref target="RFC3611"/> and
      <xref target="RFC6990"/>.</t>
    </section>
  </middle>

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



<reference anchor='RFC5234' target='http://www.rfc-editor.org/info/rfc5234'>

<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker'>
<organization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'>
<organization /></author>
<date year='2008' month='January' />
<abstract>
<t>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF.  It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='STD' value='68' />
<seriesInfo name='RFC' value='5234' />
</reference>



      <reference anchor="RFC3550" target="http://www.rfc-editor.org/info/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='RFC3611' target="http://www.rfc-editor.org/info/rfc3611">

<front>
<title>RTP Control Protocol Extended Reports (RTCP XR)</title>
<author initials='T.' surname='Friedman' fullname='T. Friedman'>
<organization /></author>
<author initials='R.' surname='Caceres' fullname='R. Caceres'>
<organization /></author>
<author initials='A.' surname='Clark' fullname='A. Clark'>
<organization /></author>
<date year='2003' month='November' />
</front>

<seriesInfo name='RFC' value='3611' />
<format type='TXT' octets='126736' target='http://www.rfc-editor.org/info/rfc3611.txt' />
</reference>


<reference anchor='RFC2119' target="http://www.rfc-editor.org/info/rfc2119">

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
</front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/info/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>


<reference anchor='RFC4566' target="http://www.rfc-editor.org/info/rfc4566">

<front>
<title>SDP: Session Description Protocol</title>
<author initials='M.' surname='Handley' fullname='M. Handley'>
<organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'>
<organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'>
<organization /></author>
<date year='2006' month='July' />
</front>
<seriesInfo name='RFC' value='4566' />
<format type='TXT' octets='108820' target='http://www.rfc-editor.org/info/rfc4566.txt' />
</reference>


      <reference anchor="ETSI">
        <front>
          <title>Digital Video Broadcasting (DVB); Measurement guidelines for
          DVB systems</title>

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

          <date month="June" year="2014"/>
        </front>

        <seriesInfo name="ETSI" value="TR 101 290"/>
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="RFC6709" target="http://www.rfc-editor.org/info/rfc6709">
        <front>
          <title>Design Considerations for Protocol Extensions</title>

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

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

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

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

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

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

      <reference anchor="RFC6792" target="http://www.rfc-editor.org/info/rfc6792">
        <front>
          <title>Guidelines for Use of the RTP Monitoring Framework</title>

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

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

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

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

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

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

      <reference anchor="RFC6390" target="http://www.rfc-editor.org/info/rfc6390">
        <front>
          <title>Guidelines for Considering New Performance Metric
          Development</title>

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

          <author fullname="Benoit Claise " initials="B." surname="Claise">
            <organization abbrev="Cisco Systems, Inc."/>

            <address>
              <postal>
                <street>De Kleetlaan 6a b1</street>

                <city>Diegem</city>

                <code>1831</code>

                <country>Belgium</country>
              </postal>

              <phone>+32 2 704 5622</phone>

              <email>bclaise@cisco.com</email>
            </address>
          </author>

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

        <seriesInfo name="BCP" value="170"/>

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

      <reference anchor="RFC6990" target="http://www.rfc-editor.org/info/rfc6990">
        <front>
          <title>RTP Control Protocol (RTCP) Extended Report (XR) Block for
          MPEG2 Transport Stream (TS) Program Specific Information (PSI)
          Independent Decodability Statistics Metrics reporting</title>

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

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

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


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

          <author>
            <organization>ISO/IEC
            </organization>
          </author>

          <date year="2013"/>
        </front>

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