One document matched: draft-wu-avtcore-multisrc-endpoint-adver-00.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-00.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>

    <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 traffic
          travelling over the link between sending endpoints and receiving
          endpoint, which may cause network congestion issue and 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>One way is to define three new SDES items to advertise the
        reporting sources from endpoint with multiple sources that are used
        for reception report sending, receiving and monitoring respectively
        (See section 5.1 and section 5.2 for protocol format details).</t>
      </section>
    </section>

    <section title="Consideration for Session member numbers updating">
      <t>As described in section 6.2.1 of RFC3550, Calculation of the RTCP
      packet interval mainly depends upon the number of members. For an
      endpoint with multiple sources in communication with another endpoint
      with multiple sources, it is more desirable to set the number of sender
      for such endpoint as one and the number of receiver as one. However
      according to RFC3550, each source within such endpoint is considered
      valid until multiple packets carrying the new SSRC have been received,
      or until an SDES RTCP packet containing a CNAME for that SSRC has been
      received. In order to invalid the source that are not elected as report
      source, it is necessary to define new SDES item to indicate other
      sources that are not chosen as report sources(See section 5.4 for more
      details). Also we can define an RTP header extension [RFC5285] to
      indicate the other sources that are not chosen as report sources(See
      section 5.4 for more details).This extension can be sent by the endpoint
      with multiple sources either at the beginning of the RTP session or in
      the middle of the RTP session. Another way is to use RTCP NACK packet
      [RFC4585] to suppress the unnecessary reception report from an endpoint
      with multiple sources. The NACK can be sent by the endpoint with
      multiple source when the endpoint with multiple sources is aware of
      reception report duplication.</t>
    </section>

    <section title="Protocol formats">
      <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. 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. 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 title="SDES item for Invalid Report Source list">
        <t>This sub-section defines the format of the Invalid Report Source
        list 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. In the SDES packet,
        the PT field is set to SDES(202).</t>

        <section title="IRSL: Invalid Report Source List 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    IRSL=TBD   |     length    | Invalid Report Source SSRC
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   ....
      +-+-+-+-+-+-+-+-+
</artwork>
          </figure>

          <t>The Invalid Report Source list Item is not mandatory item and
          intended for indicating the invalid report source(s) for an endpoint
          with multiple sources. The invalid Report Source is one that is not
          elected as report source for an endpoint with multiple sources and
          SHOULD not be counted as session member or RTP packet sender if
          multiplexing multiple media type in the same RTP session is used.
          This item may carry one or more than one invalid Report Source
          SSRCs. The invalid 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. The SSRC/CSRC identifier field at the
          beginning of the chunk is the SSRC of one elected report source from
          multiple source for the same endpoint. This item MUST be ignored by
          applications that are not configured to make use of it.</t>
        </section>
      </section>

      <section title="RTP header extension for Invalid Report Source list">
        <t>This sub-section defines the format of RTP header extension
        [RFC5285]for carrying a list of Invalid Report Sources. The RTP header
        extension is composed of a header with fixed-length fields for the
        fixed bit pattern “0x1000”, and length, followed by zero or more
        extension elements. Each extension element is followed by one two type
        header and one Invalid Report Source for an endpoint with multiple
        sources. The invalid report source is carried in 32 bit field and
        identified using SSRC.<figure title="RTP Header Extension Block">
            <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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      0x10     |      0x00     |            length=TBD         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       ID      |     length    |  Invalid Report Source SSRC
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         ... ... ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure></t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>RTCP reports or RTP header extension elements 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. In addition,
      the RTP header extension elements can be protected using mechanisms
      defined in [I-D.ietf-avtcore-srtp-encrypted-header-ext].</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 four 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 Receiving Source     TBD
RRMS: Reception Report Monitoring Source    TBD
IRSL: Invalid Report Source List            TBD
</artwork>
          </figure></t>

        <t>[Note to RFC Editor: please replace NDEL with the IANA provided
        RTCP XR block type for this block.]</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.westerlund-avtcore-multiplex-architecture">
        <front>
          <title>Guidelines for using the Multiplexing Features of RTP</title>

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

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

        <seriesInfo name="ID"
                    value="draft-westerlund-avtcore-multiplex-architecture-02" />

        <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-00" />

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