<?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-asaeda-xrblock-rtcp-xr-synchronization-07"
     ipr="trust200902">
  <front>
    <title abbrev="SDO Report Blocks">RTCP XR Blocks for Synchronization Delay
    and Offset Metrics Reporting</title>

    <author fullname="Hitoshi Asaeda" initials="H" surname="Asaeda">
      <organization>Keio University</organization>

      <address>
        <postal>
          <street>Graduate School of Media and Governance</street>

          <street>5322 Endo</street>

          <city>Fujisawa</city>

          <region>Kanagawa</region>

          <code>252-0882</code>

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

        <email>asaeda@wide.ad.jp</email>
      </address>
    </author>

    <author fullname="Rachel Huang" initials="R" surname="Huang">
      <organization abbrev="Huawei">Huawei Technologies Co.,
      Ltd.</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@huawei.com</email>
      </address>
    </author>

    <author fullname="Qin Wu" initials="Q" surname="Wu">
      <organization abbrev="Huawei">Huawei Technologies Co.,
      Ltd.</organization>

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

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

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

        <email>sunseawq@huawei.com</email>
      </address>
    </author>

    <date year="2012" />

    <abstract>
      <t>This document defines two RTCP XR Report Blocks and associated with SDP
      parameters that allow the reporting of synchronization delay and offset
      metrics for use in a range of RTP applications.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This draft defines two new block types to augment those defined in
      <xref target="RFC3611"></xref>, for use in a range of RTP applications.</t>

      <t>The first new block type supports reporting of
      Initial Synchronization Delay to establish multimedia session.
      Information is recorded about time difference between the start of RTP
      sessions and the time the RTP receiver acquires all components of RTP
      sessions in the multimedia session <xref target="RFC6051"></xref>.</t>

      <t>The second new block type supports reporting of
      the relative synchronization offset time of two arbitrary streams (e.g.,
      between audio and video streams), with the same RTCP CNAME included in
      RTCP SDES packets <xref target="RFC3550"></xref>. Information is
      recorded about the synchronization offset time of each RTP stream
      relative to the reference RTP stream with the same CNAME and General
      Synchronization Offset of zero.</t>

      <t>These metrics belong to the class of terminal related transport level metrics defined in <xref target="MONARCH"></xref>.</t>
    </section>

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

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

        <t><list style="hanging">
            <t hangText="Initial Synchronization Delay:"><vspace
            blankLines="1" />A multimedia session comprises a set of
            concurrent RTP sessions among a common group of participants,
            using one RTP session for each media type. Initial synchronization
            Delay is the average time for receiver to synchronize the
            components of a multimedia session <xref
            target="RFC6051"></xref>.<vspace blankLines="1" /></t>

            <t hangText="Synchronization Offset:"><vspace blankLines="1" />The
            absolute delay variance of the measured RTP stream relative to
            the reference RTP stream in the multimedia session. <vspace
            blankLines="1" /></t>
          </list></t>
      </section>
    </section>

    <section title="Applicability">
      <t>The report blocks defined in this document could be used by dedicated
      network monitoring applications.</t>

      <t> When joining each session in layered video sessions <xref
      target="RFC6190"></xref> or the multimedia session, a receiver may not
      synchronize playout across the multimedia session or layered video
      session until RTCP SR packets have been received on all of the component
      RTP sessions. The component RTP session are referred to as each RTP
      session for each media type in multimedia session or separate RTP
      session for each layer in the layered video session. For unicast
      session, the delay due to negotiation of NAT pinholes, firewall holes,
      quality-of-service, and media security keys is contributed to such
      initial synchronization playout. For multicast session, such initial
      synchronization delay varies with the session bandwidth, the number of
      members, and the number of senders in the session. The RTP flow Initial
      synchronization delay block can be used to report the initial
      synchronization delay to receive all the RTP streams belonging to the
      same multimedia session or layered video session. In the absence of
      packet loss, the initial synchronization delay equals to the average
      time taken to receive the first RTCP packet in the RTP session with the
      longest RTCP reporting interval. In the presence of packet loss, the
      media synchronization needs to based on the in-band mapping of RTP and
      NTP-format timestamps <xref target="RFC6051"></xref> or wait until the
      reporting interval has passed, and the next RTCP SR packet is sent. </t>

      <t>In an RTP multimedia session, there can be an arbitrary number of
      streams carried in different RTP sessions, with the same RTCP CNAME.
      These streams may be not synchronized with each other. For example, one
      audio stream and one video stream belong to the same session and audio
      stream are transmitted lag behind video stream for multiple tens of
      milliseconds. The RTP Flows Synchronization Offset block can be used to
      report such synchronization offset between video stream and audio
      stream. </t>
    </section>

    <section anchor="RFISD"
             title="RTP Flows Initial Synchronization Delay Report Block">
      <t>This block is sent by RTP receivers and reports Initial
      synchronization delay beyond the information carried in the standard
      RTCP packet format. Information is recorded about time difference
      between the start of RTP sessions and the time the RTP receiver acquires
      all components of RTP sessions <xref target="RFC6051"></xref>.</t>

      <section title="Metric Block Structure">
        <t>The RTP Flows Initial Synchronization Delay Report Block has the
        following format: <figure>
            <artwork>
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    BT=RFISD   |   Reserved    |         Block length=2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      SSRC of Source                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Initial Synchronization Delay                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure></t>
      </section>

      <section title="Definition of Fields in RTP Flow Initial Synchronization Delay Metrics Block">
        <t><list style="hanging">
            <t hangText="Block type (BT): 8 bits"><vspace blankLines="1" />The
            Statistics Summary Report Block is identified by the constant
            &lt;RFISD&gt;. <vspace blankLines="1" /></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="Block length: 16 bits"><vspace blankLines="1" />The
            constant 2, in accordance with the definition of this field in
            Section 3 of <xref target="RFC3611">RFC 3611</xref>. <vspace
            blankLines="1" /></t>

            <t hangText="SSRC of Source: 32 bits"><vspace blankLines="1" />The
            SSRC of the media source SHALL be set to the value of the SSRC
            identifier carried in an arbitrary RTP stream belonging to the
            same multimedia session. <vspace blankLines="1" /></t>

            <t hangText="Initial Synchronization Delay: 32 bits"><vspace
            blankLines="1" />The average delay, expressed in units of 1/65536
            seconds, from the RTCP packets received on all of the components
            RTP sessions to the beginning of session <xref
            target="RFC6051"></xref>. The value is calculated based on the
            information contained in RTCP SR packets or the in-band mapping
            of RTP and NTP-format timestamps <xref target="RFC6051"></xref>.
            If there is no packet loss, the initial synchronization delay is
            expected to be equal to the average time taken to receive the
            first RTCP packet in the RTP session with the longest RTCP
            reporting interval. <vspace blankLines="1" />If the measurement is
            unavailable, the value of this field with all bits set to 1 SHOULD
            be reported. </t>
          </list></t>
      </section>
    </section>

    <section anchor="RFSO"
             title="RTP Flows Synchronization Offset Metrics Block">
      <t>In the RTP multimedia sessions, there can be an arbitrary number of
      streams and each stream (e.g., audio stream or video stream) is sent in
      a separate RTP stream. The receiver associates RTP streams to be
      synchronized by means of RTCP CNAME contained in the RTCP Source
      Description (SDES) packets <xref target="RFC3550"></xref>.</t>

      <t>This block is sent by RTP receivers and reports synchronization
      offset of the arbitrary two RTP streams that needs to be synchronized in
      the RTP multimedia session. Information is recorded about the actual
      delay variance of the measured RTP stream relative to he reference RTP
      stream with the same CNAME. The reference RTP stream can be chosen as
      the arbitrary stream with minimum delay according to the common criterion
      defined in section 6.2.2.1 of <xref target="Y.1540"></xref>.</t>

      <section title="Metric Block Structure">
        <t>The RTP Flow General Synchronization Offset Report Block has the
        following format: <figure>
            <artwork>   
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    BT=RFSO    |   Reserved    |         Block length=3        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Synchronization Offset, most significant word         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Synchronization Offset, least significant word        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure></t>
      </section>

      <section title="Definition of Fields in RTP Flow General Synchronization Offset Metrics Block">
        <t><list style="hanging">
            <t hangText="Block type (BT): 8 bits"><vspace blankLines="1" />The
            RTP Flow General Synchronization Offset Report Block is identified
            by the constant &lt;RFSO&gt;. <vspace blankLines="1" /></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="Block length: 16 bits"><vspace blankLines="1" />The
            constant 3, in accordance with the definition of this field in
            Section 3 of <xref target="RFC3611">RFC 3611</xref>. <vspace
            blankLines="1" /></t>

            <t hangText="SSRC of Source: 32 bits"><vspace blankLines="1" />The
            SSRC of the media source SHALL be set to the value of the SSRC
            identifier of the reference RTP stream to which the XR relates.
            <vspace blankLines="1" /></t>

            <t hangText="Synchronization Offset: 64 bits"><vspace
            blankLines="1" />The synchronization offset of one RTP stream
            relative to the reference RTP stream with the same CNAME. The
            Synchronization Offset of the reference stream should be zero.
            This value is calculated based on the interarrival time between an
            arbitrary RTP packet and the reference RTP packet with the same
            CNAME, and timestamps of this arbitrary RTP packet and the
            reference RTP packet with the same CNAME. The value of this field
            is represented using a 64-bit NTP-format timestamp as defined in
            <xref target="RFC5905"></xref>, which is 64-bit unsigned
            fixed-point number with the integer part in the first 32 bits and
            the fractional part in the last 32 bits. <vspace
            blankLines="1" />If the measurement is unavailable, the value of
            this field with all bits set to 1 SHOULD be reported. </t>
          </list></t>
      </section>
    </section>

    <section title="SDP Signaling">
      <t>Two new parameters are defined for the two report blocks defined in
      this document to be used with Session Description Protocol (SDP) <xref
      target="RFC4566"></xref> using the Augmented Backus-Naur Form (ABNF)
      <xref target="RFC5234"></xref>. They have the following syntax within
      the "rtcp-xr" attribute <xref target="RFC3611"></xref>: <figure
          align="left">
          <artwork>
            rtcp-xr-attrib =  "a=rtcp-xr:"
                              [xr-format *(SP xr-format)] CRLF
            xr-format = RTP-flows-init-syn-delay
                      / RTP-flows-syn-offset
            RTP-flows-init-syn-delay = "RTP-flows-init-syn-delay"
                                       ["=" max-size]
            RTP-flow-syn-offset = "RTP-flows-syn-offset"
                                  ["=" max-size]
            max-size = 1*DIGIT ; maximum block size in octets
</artwork>
        </figure> Refer to Section 5.1 of <xref target="RFC3611">RFC
      3611</xref> for a detailed description and the full syntax of the
      "rtcp-xr" attribute.</t>
    </section>

    <section title="IANA Considerations">
      <t>New report block types for RTCP XR are subject to IANA registration.
      For general guidelines on IANA allocations for RTCP XR, refer to <xref
      target="RFC3611">Section 6.2 of</xref>.</t>

      <t>This document assigns two new block type values in the RTCP XR Block
      Type Registry: <list>
          <t><list hangIndent="12" style="hanging">
              <t hangText="Name:">RFISD<vspace blankLines="0" /></t>

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

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

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

              <t hangText="Name:">RFSO<vspace blankLines="0" /></t>

              <t hangText="Long Name:">RTP Flows Synchronization Offset
              Metrics Block<vspace blankLines="0" /></t>

              <t hangText="Value">&lt;RFSO&gt;<vspace blankLines="0" /></t>

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

      <t>This document also registers two new SDP <xref
      target="RFC4566"></xref> parameters for the "rtcp-xr" attribute in the
      RTCP XR SDP Parameters Registry: <list>
          <t><list style="symbols">
              <t>"RTP-flows-init-syn-delay"</t>

              <t>"RTP-flows-syn-offset"</t>
            </list></t>
        </list></t>

      <t>The contact information for the registrations is: <list>
          <t><list style="hanging">
              <t>Qin Wu</t>

              <t>sunseawq@huawei.com</t>

              <t>101 Software Avenue, Yuhua District</t>

              <t>Nanjing, Jiangsu 210012, China</t>
            </list></t>
        </list></t>
    </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="Acknowledgements">
      <t>The authors would like to thank Bill Ver Steeg, David R Oran, Ali
      Begen, Colin Perkins, Roni Even, Kevin Gross, Jing Zhao, Fernando Boronat Seguí,
      Youqing Yang, Wenxiao Yu and Yinliang Hu for their valuable comments and
      suggestions on this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC6190">
        <front>
          <title>RTP Payload Format for Scalable Video Coding</title>

          <author fullname="Stephan Wenger" initials="S" surname="Wenger">
            <organization></organization>
          </author>

          <author fullname="Ye-Kui Wang" initials="Y" surname="Wang">
            <organization></organization>
          </author>

          <author fullname="Thomas Schierl" initials="T" surname="Schierl">
            <organization></organization>
          </author>

          <author fullname="Alex Eleftheriadis" initials="A"
                  surname="Eleftheriadis">
            <organization></organization>
          </author>

          <date month="May" year="2011" />

          <abstract>
            <t>This memo describes an RTP payload format for Scalable Video
            Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264,
            which is technically identical to Amendment 3 of ISO/IEC
            International Standard 14496-10. The RTP payload format allows for
            packetization of one or more Network Abstraction Layer (NAL) units
            in each RTP packet payload, as well as fragmentation of a NAL unit
            in multiple RTP packets. Furthermore, it supports transmission of
            an SVC stream over a single as well as multiple RTP sessions. The
            payload format defines a new media subtype name "H264-SVC", but is
            still backwards compatible to [I-D.ietf-avt-rtp-rfc3984bis] since
            the base layer, when encapsulated in its own RTP stream, must use
            the H.264 media subtype name ("H264") and the packetization method
            specified in [I- D.ietf-avt-rtp-rfc3984bis]. The payload format
            has wide applicability in videoconferencing, Internet video
            streaming, and high bit-rate entertainment-quality video, among
            others.Table of Contents</t>
          </abstract>
        </front>

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

        <format octets="34293"
                target="http://www.rfc-editor.org/rfc/rfc6190.txt" type="TXT" />
      </reference>

      &rfc3611;

      &rfc2119;

      &rfc4566;

      &rfc5234;

      &rfc3550;

      <reference anchor="RFC6051">
        <front>
          <title>Rapid Synchronisation of RTP Flows</title>

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

          <author fullname="Thomas Schierl" initials="T" surname="Schierl">
            <organization></organization>
          </author>

          <date day="10" month="November" year="2010" />

          <abstract>
            <t>This memo outlines how RTP sessions are synchronized, and
            discusses how rapidly such synchronisation can occur. We show that
            most RTP sessions can be synchronized immediately, but that the
            use of video switching multipoint conference units (MCUs) or large
            source specific multicast (SSM) groups can greatly increase the
            synchronisation delay. This increase in delay can be unacceptable
            to some applications that use layered and/or multi-description
            codecs. This memo introduces three mechanisms to reduce the
            synchronisation delay for such sessions. First, it updates the RTP
            Control Protocol (RTCP) timing rules to reduce the initial
            synchronisation delay for SSM sessions. Second, a new feedback
            packet is defined for use with the Extended RTP Profile for
            RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to
            rapidly request resynchronisation. Finally, new RTP header
            extensions are defined to allow rapid synchronisation of late
            joiners, and guarantee correct timestamp based decoding order
            recovery for layered codecs in the presence of clock skew.</t>
          </abstract>
        </front>

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

        <format target="http://tools.ietf.org/html/rfc6051" type="TXT" />
      </reference>

      <reference anchor="RFC5905">
        <front>
          <title>Network Time Protocol Version 4: Protocol and Algorithms
          Specification</title>

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

          <author fullname="J.Martin" initials="J." surname="Martin">
            <organization></organization>
          </author>

          <author fullname="J.Burbank" initials="J." surname="Burbank">
            <organization></organization>
          </author>

          <author fullname="W. Kasch" initials="W." surname="Kasch">
            <organization></organization>
          </author>

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

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

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

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

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

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

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

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

      <reference anchor="Y.1540">
        <front>
          <title>ITU-T Rec. Y.1540, IP packet transfer and availability
          performance parameters</title>

          <author fullname="" initials="" surname="">
            <organization>ITU-T</organization>
          </author>

          <date month="November" year="2007" />
        </front>
      </reference>
    </references>

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

      <section title="draft-asaeda-xrblock-rtcp-xr-syncronization-07">
        <t>Editorial changes are made from the previous version 06.</t>
      </section>

      <section title="draft-asaeda-xrblock-rtcp-xr-syncronization-06">
        <t>The following are the major changes compared to previous version
        05:<vspace blankLines="1" /><list style="symbols">
            <t>Define synchronization offset as 64 bit NTP-format timestamp to
            meet synchronization resolution requirements for some RTP
            applications.</t>

            <t>Add the definition of Initial Synchronization Delay in section
            2.</t>

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

      <section title="draft-asaeda-xrblock-rtcp-xr-syncronization-05">
        <t>The following are the major changes compared to previous version
        04:<vspace blankLines="1" /><list style="symbols">
            <t>Remove per packet reporting and only report a single value of
            general synchronization offset.</t>
          </list></t>
      </section>

      <section title="draft-asaeda-xrblock-rtcp-xr-syncronization-04">
        <t>The following are the major changes compared to previous version
        03:<vspace blankLines="1" /><list style="symbols">
            <t>Add a definition for synchronization offset.</t>

            <t>Use additional text in applicability section to clarify the
            difference between synchronization delay and offset.</t>

            <t>Add a reference to tell how to select the reference stream.</t>

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

      <section title="draft-asaeda-xrblock-rtcp-xr-syncronization-03">
        <t>The following are the major changes compared to previous version
        02:<vspace blankLines="1" /><list style="symbols">
            <t>Support multiple general synchronization offset reporting.</t>

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

      <section title="draft-asaeda-xrblock-rtcp-xr-syncronization-02">
        <t>The following are the major changes compared to previous version
        01:<vspace blankLines="1" /><list style="symbols">
            <t>Clarify which synchronization is reported in section 4 and
            5.</t>

            <t>Allow calculating the synchronization delay based on RTP header
            extension defined in RFC6051</t>

            <t>Explain what the components of RTP session are in section
            3.</t>
          </list></t>
      </section>

      <section title="draft-asaeda-xrblock-rtcp-xr-syncronization-01">
        <t>The following are the major changes compared to previous
        version:<vspace blankLines="1" /><list style="symbols">
            <t>Separate Synchronization Delay and Offset Metrics Block into
            two independent block based on comments on the list.</t>
          </list></t>
      </section>

      <section title="draft-asaeda-xrblock-rtcp-xr-syncronization-00">
        <t>The following are the major changes compared to previous
        version:<vspace blankLines="1" /><list>
            <t>This document is separated from
            draft-wu-xrblock-rtcp-xr-quality-monitoring-01 with some editorial
            changes and focuses on RTP Flow Initial Synchronization Delay and
            RTP Flows General Synchronization Offset.</t>
          </list></t>
      </section>
    </section>
  </back>
</rfc>
