One document matched: draft-wu-avtcore-multisrc-endpoint-adver-02.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-wu-avtcore-multisrc-endpoint-adver-02.txt"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="Multiple Source Advertisement">Advertisement for
    multi-source endpoint multiplexing multiple media type in the same RTP
    session</title>

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

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

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

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

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

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

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

          <city>Tel </city>

          <region>Aviv </region>

          <code>64953 </code>

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

        <email>ron.even.tlv@gmail.com </email>
      </address>
    </author>

    <date year="2012" />

    <area>Real-time Applications and Infrastructure Area</area>

    <workgroup>Audio/Video Transport Working Group</workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <keyword>Real Time Control Protocol</keyword>

    <abstract>
      <t>When two endpoints with multiple media sources are in communication,
      each media source or each receiver within either endpoint may send or
      receive reception report independently. This may incur a lot of
      duplicated reception report to and from the endpoint with multiple
      sources. This document discusses how to tackle these problems and
      propose three phases for suppressing reception reports.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>For some applications that use unicast transport, e.g., in RTCWeb
      application, an endpoint with multiple media sources
      (i.e.,multiple-source hosts, e.g., a client with several cameras) may
      use a different SSRC for each medium but sending them in the same RTP
      session, which reduces communication failure due to NAT and firewall
      when using multiple RTP sessions or transport flows.</t>

      <t>However when two endpoints with multiple media sources are in
      communication, each media source within either endpoint may send
      reception report independently and the receiving endpoint may not know
      the reception reports received from different media source are from the
      same sending endpoint. This creates the following three problems:<list
          style="symbols">
          <t>An endpoint with multiple media sources involved in one RTP
          session may send the reception report with duplicated information
          about the same remote media source from each of local media
          sources.</t>

          <t>An endpoint with multiple media sources involved in one RTP
          session may receive the reception report with duplicated information
          about the same local media source from each of remote media
          sources.</t>

          <t>An endpoint with multiple media sources involved in one RTP
          session also may send reception reports about one of its own media
          sources from another of its own (This is also referred to as RTCP
          self-reporting). Such reception reports cause additional redundant
          traffic travelling over the link between sending endpoints and
          receiving endpoint, which changes the report interval and may affect
          the media qualities.</t>
        </list></t>

      <t>This document discusses how to tackle these problems. Three phases
      for suppressing reception reports are proposed.<list style="symbols">
          <t>Grouping of media sources originate from a single endpoint and
          classifying these media sources into multiple groups.</t>

          <t>Electing one single SSRC for reception report sending and one
          single SSRC for reception report monitoring based on local
          policy.</t>

          <t>Advertising the SSRC that is used either for reception report
          sending or reception report monitoring.</t>
        </list></t>
    </section>

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

    <section title="Protocol Overview">
      <t>In order to suppress unnecessary reception reports to and from
      multi-source endpoint, multi-source endpoint should group media sources
      originating from a single endpoint and elect one or a set of specified
      SSRCs for reception report processing (e.g., reception report sending,
      reception report receiving and reception report monitoring).</t>

      <section title="Report Source Grouping">
        <t>When an endpoint with multiple sources multiplexes multiple media
        types in the same RTP session, the media source originating from the
        same endpoint should be grouped together. Similarly the endpoint with
        multiple sources may have multiple one or more than one report source
        for monitoring. These report sources for monitoring should also be
        grouped together. Therefore an endpoint with multiple sources should
        at least split all its own media sources or receivers into two
        groups(i.e., split SSRCs into two groups): One is sending group, the
        other is monitoring group. Each group may have one or several group
        members. Each group member is identified by a different SSRC.</t>
      </section>

      <section title="Report Source Election">
        <t>When grouping for each endpoint with multiple sources is available,
        in order to prevent group members receiving duplicated data, one or
        more than one group member MUST be elected from sending group as
        report source for reception report sending. When one report source
        leaves the session or is down, another candidate report source can
        replace instead. If the monitoring is used, each endpoint with
        multiple sources MUST have at least one report source for monitoring
        purpose. One or more than one reporting sources MUST be selected from
        monitoring group for monitoring use.</t>

        <t>Each endpoint with multiple sources at least has one SSRC for
        reception report sending. If the monitoring is used, the endpoint with
        multiple sources should choose another SSRC from monitoring group as
        monitoring report source.</t>
      </section>

      <section title="Report Source Advertisement">
        <t>When report sources are elected for reception report sending, and
        monitoring purpose respectively, it is necessary to signal which
        report source is used for which purpose.</t>

        <t>In this document we define two new SDES items to advertise the
        reporting sources from endpoint with multiple sources that are used
        for reception report sending and monitoring respectively (See section
        5.1 and section 5.2 for protocol format details).</t>

        <t>When those report sources are advertised, the selected report
        source can send reception report about the same remote media source on
        behalf of the media sources of its own, which prevent duplicated
        reception report sent from all the local media sources of its own for
        the same event.</t>

        <t>If the other media source which is not selected as report source
        knows or understands the advertised report source, it should suppress
        the reception report for the same event.</t>

        <t>If the other media source which is not selected as report source
        does not know or understand the advertised report source and detects
        the need to send reception report, this media source should wait for a
        (short) random dithering interval to check whether it sees a
        corresponding reception report message from any other receiver or
        other media sources of its own reporting the same event. If a
        corresponding reception report for the same event is received from
        other media sources or any other receivers, it should refrain from
        sending the reception report message.</t>

        <t>In order to prevent duplicated reception report sent from one of
        its own media sources to another of its own within the same endpoint
        with multiple sources(i.e., self-reporting), the report source should
        know the other media sources of its own and suppress sending the
        reception report on the remote source to its own media sources.</t>

        <t>Editor's note: Current draft does not discuss topologies like
        source projection mixer where the mixer keeps the original ssrc so
        even though they arrive from the mixer they have different CNAMEs. It
        will be useful to discuss those topologies in the future version.</t>
      </section>
    </section>

    <section title="Protocol formats">
      <t>Editor's note: It is not clear if you need to signal which one is
      used or what is the group but if needed it may be better to allow the
      sender to indicate which SSRCs are part of a group. It will also require
      an negotiation in the offer/answer to verify that this mode is supported
      by the stream senders. </t>

      <section title="SDES item for Reception Report Sending">
        <t>This sub-section defines the format of the Reception Report Sending
        SDES item. The SDES item is carried in the RTCP SDES packet. The
        packet format for the RTCP SDES is defined in Section 6.5 of
        [RFC3550]. Each SDES packet is composed of a header with fixed-length
        fields for version, source count, packet type (PT), and length,
        followed by zero or more chunks. Each chunk consists of an SSRC/CSRC
        identifier followed by zero or more SDES items. If this SDES item is
        carried, the CNAME SDES item should also be carried together with this
        SDES item in the same chunk. In the SDES packet, the PT field is set
        to SDES(202).</t>

        <section title="RRS: Reception Report Sending SDES Item">
          <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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    RRS=TBD    |     length    | Candidate Report Source SSRC
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   ....
      +-+-+-+-+-+-+-+-+
</artwork>
          </figure>

          <t>The Reception Report Sending Item is not mandatory item and
          intended for indicating the elected report source for an endpoint
          with multiple sources, which is responsible for reception report
          sending. The SSRC/CSRC identifier included in the same chunk (at the
          beginning of this chunk) as the item is the SSRC of elected sending
          report source. Additionally, this item may carry one or more than
          one Candidate Report Source SSRCs. The candidate Report Source SSRC
          follows the same format as SSRC/CSRC identifier defined in RFC3550.
          Its length is described by the length field. The value of the length
          field does not include the two octet SDES item header. This item
          MUST be ignored by applications that are not configured to make use
          of it.</t>
        </section>
      </section>

      <section title="SDES item for Reception Report Monitoring">
        <t>This sub-section defines the format of the Reception Report
        Monitoring SDES item. The SDES item is carried in the RTCP SDES
        packet. The packet format for the RTCP SDES is defined in Section 6.5
        of [RFC3550].Each SDES packet is composed of a header with
        fixed-length fields for version, source count, packet type (PT), and
        length, followed by zero or more chunks. Each chunk consists of an
        SSRC/CSRC identifier followed by zero or more SDES items. If this SDES
        item is carried, the CNAME SDES item should also be carried together
        with this SDES item in the same chunk. In the SDES packet, the PT
        field is set to SDES(202).</t>

        <section title="RRM: Reception Report Monitoring SDES Item">
          <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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    RRM=TBD    |     length    | Candidate Report Source SSRC
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   ....
      +-+-+-+-+-+-+-+-+
</artwork>
          </figure>

          <t>The Reception Report Sending Item is not mandatory item and
          intended for indicating the report source for an endpoint, which is
          responsible for reception report monitoring. The SSRC/CSRC
          identifier included in the same chunk as the item (at the beginning
          of this chunk) is the SSRC of elected sending report source.
          Additionally, this item may carry one or more than one Candidate
          Report Source SSRCs. The candidate Report Source SSRC follows the
          same format as SSRC/CSRC identifier defined in RFC3550. Its length
          is described by the length field. The value of the length field does
          not include the two octet SDES item header. This item MUST be
          ignored by applications that are not configured to make use of
          it.</t>
        </section>
      </section>
    </section>

    <section title="Security Considerations">
      <t>RTCP reports can contain sensitive information, including information
      about report source grouping for endpoint with multiple source and
      member of a session established between two or more endpoints.
      Therefore, the use of security mechanisms with RTP, as documented in
      Section 9 of [RFC3550] applies.</t>
    </section>

    <section title="IANA Considerations">
      <t>New SDES types for RTCP SDES are subject to IANA registration. For
      general guidelines on IANA considerations for RTCP SDES, refer
      to[RFC3550].</t>

      <section title="New RTCP SDES Type values">
        <t>This document assigns two additional SDES type in the IANA "RTCP
        SDES Item Types Registry" to the new SDES items as follow:<figure>
            <artwork>
abbrev.      name                          value
RRSS: Reception Report Sending Source       TBD
RRRS: Reception Report Monitoring Source     TBD
</artwork>
          </figure></t>

        <t>[Note to RFC Editor: please replace RRSS and RRMS with the IANA
        provided RTCP SDES Item Types.]</t>
      </section>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
          Requirement Levels</title>

          <author fullname="Scott Bradner" initials="S." surname="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 month="March" year="1997" />

          <area>General</area>

          <keyword>keyword</keyword>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. Authors who follow these
            guidelines should incorporate this phrase near the beginning of
            their document: <list>
                <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 RFC 2119.</t>
              </list></t>

            <t>Note that the force of these words is modified by the
            requirement level of the document in which they are used.</t>
          </abstract>
        </front>
      </reference>

      <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="RFC5285">
        <front>
          <title>A General Mechanism for RTP Header Extensions</title>

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

          <author fullname="H. Desineni" initials="H." surname="Desineni">
            <organization></organization>
          </author>

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

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

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

      <reference anchor="RFC4585">
        <front>
          <title>Extended RTP Profile for Real-time Transport Control Protocol
          (RTCP)-Based Feedback (RTP/AVPF)</title>

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

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

          <author fullname="N.Sato" initials="N." surname="Sato">
            <organization></organization>
          </author>

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

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

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

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

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

    <references title="Informative References">
      <reference anchor="I-D.ietf-avtcore-multi-media-rtp-session-00">
        <front>
          <title>Multiple Media Types in an RTP Session</title>

          <author fullname="M.Westerlund" initials="M." surname="Westerlund">
            <organization></organization>
          </author>

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

        <seriesInfo name="ID"
                    value="draft-ietf-avtcore-multi-media-rtp-session-00" />

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

      <reference anchor="I-D.lennox-avtcore-rtp-multi-stream">
        <front>
          <title>Real-Time Transport Protocol (RTP) Considerations for
          Endpoints Sending Multiple Media Streams</title>

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

          <author fullname="M.Westerlund" initials="M." surname="Westerlund">
            <organization></organization>
          </author>

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

        <seriesInfo name="ID" value="draft-lennox-avtcore-rtp-multi-stream-00" />

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

      <reference anchor="I-D.wu-avtcore-multiplex-multisource-endpoint">
        <front>
          <title>Bandwidth and RTCP timing issues for multi-source
          endpoint</title>

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

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

        <seriesInfo name="ID"
                    value="draft-wu-avtcore-multiplex-multisource-endpoint-01" />

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