<?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" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3550 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3611 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3611.xml">
<!ENTITY rfc3711 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY rfc4566 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY rfc5124 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5124.xml">
<!ENTITY rfc5234 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY rfc6390 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6390.xml">
<!ENTITY rfc6709 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6709.xml">
<!ENTITY rfc6776 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6776.xml">
<!ENTITY rfc6792 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6792.xml">
]>
<!-- xml2rfc v2 -->
<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" number="6990" consensus="yes" submissionType="IETF"
     ipr="trust200902">
  <front>
    <title abbrev=" RTCP XR TS Decodability">RTP Control Protocol (RTCP)
    Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program
    Specific Information (PSI) Independent Decodability&nbsp;Statistics&nbsp;Metrics&nbsp;Reporting</title>

    <author fullname="Rachel Huang" initials="R." surname="Huang">
      <organization>Huawei</organization>

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

          <city>Nanjing</city>

          <code>210012</code>

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

        <email>rachel.huang@huawei.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>bill.wu@huawei.com</email>
      </address>
    </author>

    <author fullname="Hitoshi Asaeda" initials="H." surname="Asaeda">
      <organization abbrev="NICT">National Institute of Information and
      Communications Technology</organization>

      <address>
        <postal>
          <street>4-2-1 Nukui-Kitamachi</street>

          <city>Koganei</city>

          <region>Tokyo</region>

          <code>184-8795</code>

          <country>Japan</country>
        </postal>

        <email>asaeda@nict.go.jp</email>
      </address>
    </author>

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

      <address>
        <postal>
          <street>227/358 Thanon Sanphawut</street>

          <city>Bang Na</city>

          <region>Bangkok</region>

          <code>10260</code>

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

        <phone>+66 (0) 8-1000-4155</phone>

        <email>glenzorn@gmail.com</email>
      </address>
    </author>

    <date month="August" year="2013" />

<keyword>RTCP, XR, MPEG-2, PSI, Decodability</keyword>

    <abstract>
      <t>An MPEG-2 Transport Stream (TS) is a standard container format used in
      the transmission and storage of multimedia data. Unicast/multicast MPEG-2
      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 MPEG-2 TS decodability statistics metrics related to
      transmissions of MPEG-2 TS over RTP. The metrics specified in the RTCP XR
      block are not dependent on Program Specific Information (PSI) carried in
    MPEG-2 TS.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <section title="MPEG-2 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 MPEG-2 Transport Streams <xref
        target="ISO-IEC.13818-1.2013"/>. The tests and corresponding
        indicators are grouped according to priority: 

        <list style="symbols">
            <t>First priority - Necessary for decodability (basic
            monitoring)</t>

            <t>Second priority - Recommended for continuous or periodic
            monitoring</t>

            <t>Third priority - Recommended for application-dependent
            monitoring</t>
          </list></t>

        <t>This memo is based on information consistency tests and resulting
        indicators defined by ETSI <xref target="ETSI"/> and defines a
        new block type to augment those defined in <xref
        target="RFC3611"/> for use with MPEG-2 Transport Stream (TS)
        <xref target="ISO-IEC.13818-1.2013"></xref>. The new block type
        supports reporting of the number of occurrences of each PSI-independent indicator in the first and
        second priorities; third priority indicators are not supported.</t>
      </section>

      <section title="RTCP and RTCP Extended 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 document defines a new Extended Report block for use with <xref
        target="RFC3550"></xref> and <xref target="RFC3611"></xref>.</t>
      </section>

      <section title="Performance Metrics Framework">
        <t>"Guidelines for Considering New Performance Metric Development" <xref target="RFC6390"/> provides guidance on
        the definition and specification of performance metrics. "Guidelines
for Use of the RTP
        Monitoring Framework" <xref target="RFC6792"></xref> provides
        guidance on the reporting block format using RTCP XR. The new report
        block described in this memo is in compliance with the monitoring
        architecture specified in <xref target="RFC6792"></xref> and the
        performance metrics framework <xref target="RFC6390"></xref>.</t>
      </section>

      <section title="Applicability">
        <t>This block type allows a count of MPEG-2 Transport Stream quality
        metrics that are measured in accordance with ETSI TR 101290 <xref
        target="ETSI"></xref> to be reported by an endpoint. These metrics are
        useful for identifying bitstream packetization and transport stream
        encoding problems that may affect the user's perception of a video
        service delivered over RTP.</t>
      </section>
    </section>

    <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 anchor="TDM"
             title="MPEG-2 TS PSI-Independent Decodability Statistics Metrics Block">
      <t>ETSI TR 101290 <xref target="ETSI"></xref> generally defines metrics
      related to error events while this document contains counts of those
      metrics defined in <xref target="ETSI"/>. The block defined in this document reports
      MPEG-2 TS PSI-independent decodability statistics metrics beyond the
      information carried in the standard RTCP packet format, which are
      measured at the receiving end of the RTP stream. It contains counts of
      eight metrics defined in ETSI TR 101290 <xref target="ETSI"></xref>.
      Information is reported about basic monitoring parameters necessary to
      ensure that the TS can be decoded, including:

      <list style="symbols">
          <t>Transport Stream Synchronization Losses</t>

          <t>Sync byte errors</t>

          <t>Continuity count errors</t>
        </list> 

  and continuous monitoring parameters necessary to ensure the
      continuous decoding, including: 

      <list style="symbols">
          <t>Transport errors</t>

          <t>Program Clock Reference (PCR) errors</t>

          <t>PCR repetition errors</t>

          <t>PCR discontinuity indicator errors</t>

          <t>PCR accuracy errors</t>

          <t>Presentation Time Stamp (PTS) errors</t>
        </list>

      The other parameters are ignored since they do not apply to all
      MPEG-2 implementations. For further information on these parameters, see
      <xref target="ETSI"/>. Note that when the report of this block
      spans across more than one measurement interval <xref target="RFC6776"/>, the count of
      the metrics (e.g., Sync byte errors and PCR errors) defined in <xref
      target="ETSI"/> may reflect a problem in the current or previous
      measurement interval.
</t>

<t>
The MPEG-2 TS PSI-Independent Decodability 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=22     |    Reserved   |         Block Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     SSRC of Source                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          begin_seq            |             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      TS_sync_loss_count                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sync_byte_error_count                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Continuity_count_error_count                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Transport_error_count                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        PCR_error_count                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   PCR_repetition_error_count                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            PCR_discontinuity_indicator_error_count            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     PCR_accuracy_error_count                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       PTS_error_count                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        </figure> <list style="hanging">
          <t hangText="Block Type (BT): 8 bits"><vspace blankLines="1" />The
          MPEG-2 TS PSI-Independent Decodability Statistics Metrics Block is identified by
          the constant 22. <vspace blankLines="1" /></t>

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

          <t hangText="Block Length: 16 bits"><vspace blankLines="1" />The
          constant 11, in accordance with the definition of this field in
          Section 3 of RFC 3611. The block MUST be discarded if the block
          length is set to a different value.<vspace blankLines="1" /></t>

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

          <t hangText="begin_seq: 16 bits"><vspace blankLines="1" />The RTP
          sequence number corresponding to the start of the measurement
          period, as defined in Section 4.1 of RFC 3611.<vspace
          blankLines="1" /></t>

          <t hangText="end_seq: 16 bits"><vspace blankLines="1" />The RTP
          sequence number corresponding to the end of the measurement period,
          as defined in Section 4.1 of RFC 3611.<vspace blankLines="1" /></t>

          <t hangText="TS_sync_loss_count: 32 bits"><vspace blankLines="1" />A
          count of the number of TS_sync_loss errors that occurred in the
          above sequence number interval. A TS_sync_loss error occurs when
          there are two or more consecutive incorrect sync bytes within the
          MPEG-2 TS, as defined in Section 5.2.1 of <xref
          target="ETSI"/>.<vspace blankLines="1" /></t>

          <t hangText="Sync_byte_error_count: 32 bits"><vspace
          blankLines="1" />A count of the number of Sync_byte_errors that
          occurred in the above sequence number interval. A sync byte error
          occurs when the sync byte is not equal to 0x47 in any TS packet
          contained in the MPEG-2 TS, as defined in Section 5.2.1 of
          <xref target="ETSI"></xref>.<vspace blankLines="1" /></t>

          <t hangText="Continuity_count_error_count: 32 bits"><vspace
          blankLines="1" />A count of the number of Continuity_count_errors
          that occurred in the above sequence number interval. A
          Continuity_count_error occurs when any of the following faults
          happen within the MPEG-2 TS -- incorrect packet order, a packet
          occurs more than twice, or a packet is lost, as defined in Section
          5.2.1 of <xref target="ETSI"></xref>. <vspace blankLines="1" /></t>

          <t hangText="Transport_error_count: 32 bits"><vspace
          blankLines="1" />A count of the number of Transport_errors that
          occurred in the above sequence number interval. A Transport_error
          occurs when an erroneous TS packet cannot be corrected within 
the MPEG-2 TS, as defined in Section 5.2.2 of <xref
          target="ETSI"></xref>. <vspace blankLines="1" /></t>

          <t hangText="PCR_error_count: 32 bits "><vspace blankLines="1" />A
          count of the number of PCR_errors that occurred in the above
          sequence number interval. A PCR_error occurs if the primary clock
          reference (PCR) is not seen for more than 100 ms within the 
MPEG-2 TS, as defined in Section 5.2.2 of <xref
          target="ETSI"></xref>. The time interval between two consecutive PCR
          values should be no more than 40 ms.<vspace blankLines="1" /></t>

          <t hangText="PCR_repetition_error_count: 32 bits"><vspace
          blankLines="1" />A count of the number of PCR_repetition_errors that
          occurred in the above sequence number interval. A
          PCR_repetition_error occurs when the time interval between two
          consecutive PCR values is more than 40 ms within the MPEG-2 TS, as defined in Section 5.2.2 of <xref
          target="ETSI"></xref>. <vspace blankLines="1" /></t>

          <t
          hangText="PCR_discontinuity_indicator_error_count: 32 bits"><vspace
          blankLines="1" />A count of the number of
          PCR_discontinuity_indicator_errors that occurred in the above
          sequence number interval. A PCR_discontinuity_indicator_error occurs
          if the time interval between two consecutive PCR values is more than
          100 ms within the MPEG-2 TS, as defined in Section 5.2.2 of
          <xref target="ETSI"></xref>. <vspace blankLines="1" /></t>

          <t hangText="PCR_accuracy_error_count: 32 bits"><vspace
          blankLines="1" />A count of the number of PCR_accuracy_errors that
          occurred in the above sequence number interval. A PCR_accuracy_error
          occurs when the PCR accuracy of the selected program is outside the
          range of +/&wj;-500 ns within the MPEG-2 TS, as defined in Section
          5.2.2 of <xref target="ETSI"></xref>. <vspace blankLines="1" /></t>

          <t hangText="PTS_error_count: 32 bits"><vspace blankLines="1" />A
          count of the number of PTS_errors that occurred in the above
          sequence number interval. A PTS_error occurs when the PTS repetition
          is more than 700 ms within the MPEG-2 TS, as defined in
          Section 5.2.2 of <xref target="ETSI"></xref>. Note that the PTS is
          contained in the MPEG-2 TS and is used to aid the decoder in
          presenting the program on time, at the correct speed, and
          synchronized.<vspace blankLines="1" /></t>
        </list></t>
    </section>

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

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

xr-tpid-block = "ts-psi-indep-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"></xref> 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"></xref>.</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 RFC 3611.</t>

      <section title="New RTCP XR Block Type Value">
        <t>This document assigns the block type value 22 in the IANA "RTP
        Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
        the "MPEG-2 Transport Stream PSI-Independent Decodability Statistics
        Metrics Block".</t>

      </section>

      <section title="New RTCP XR SDP Parameter">
        <t>This document also registers the new parameter
        "ts-psi-indep&nbhy;decodability" in 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 registrations is:</t>

        <figure>
          <artwork>
   Qin Wu (sunseawq@huawei.com)
   101 Software Avenue, Yuhua District 
   Nanjing, Jiangsu  210012
   China
</artwork>
        </figure>
      </section>
    </section>

    <section title="Security Considerations">
      <t>There might be some relationship between reported error counters and
      contractual Service Level Agreements (SLAs); hence, an attack (e.g.,
      RTP endpoints reporting false data, or an attacker in the path
      modifying the data being reported) might deliberately corrupt these error
      counters, resulting in financial implications for the
      network operator (either as a result of unneeded performance metrics,
      or penalty charges for SLA failure).</t>

      <t>A solution to prevent such an attack is to apply an authentication and
      integrity protection framework for the RTCP XR block. This can be
      accomplished using the RTP profile that combines Secure RTP <xref
      target="RFC3711"></xref> and the Audio-Visual Profile with Feedback (AVPF)
into Secure AVPF (SAVPF) <xref
      target="RFC5124"></xref>.</t>

      <t>Besides this, the RTCP XR block in this document
      introduces no new security considerations beyond those described
      in <xref target="RFC3611"></xref>.</t>
    </section>

    <section title="Acknowledgements">
      <t>Thanks to Ray van Brandenburg, Claire Bi, Colin Perkins, Roni Even,
      Dan Romascanu, Ali Begen, Alexey Melnikov, Bert Wijnen, Gonzalo
Camarillo, Benoit Claise, and Alan Clark for useful reviews and
      suggestions.</t>
    </section>
  </middle>

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

      &rfc3550; 

      &rfc3611;

      &rfc2119;

      &rfc4566;

      &rfc5234;

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

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

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

        <seriesInfo name="Technical Report" value="TR 101 290" />
      </reference>

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

      <?rfc include="reference.RFC.5124"?>
    </references>

    <references title="Informative References">

 &rfc6390;
 &rfc6709;
 &rfc6792;
 &rfc6776;

      <reference anchor="ISO-IEC.13818-1.2013">
        <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="May" year="2013" />
        </front>

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